Photo (c) Janusz Gorycki
I would like to start a series of posts, named "Stories From The Battlefield". As the title suggests, I will be describing trails and tribulations of the agile team I am a part of. I want to write about our successes, failures, things we do right, things we struggle with - the real deal, sometimes great, but sometimes rough at the edges.
I hope such a series may be of value to many of our readers, especially those beginning their agile journey and hoping to learn on somebody else's mistakes.
There won't be much theory in here - this is being covered in sufficient detail by other authors on this site. Rather, I will concentrate more on "soft" aspects of what makes an agile team.
Let's start with a fundamental question of "Why?". This question is so basic and simple, that it sometimes eludes many of us in our day-to-day work routines. So why bother with an agile process? It does not make you produce software faster - despite popular myth. It does not necessarily bring higher quality - at least not automatically. It does not let you work less hard - on the contrary, you are supposed to be an efficient long-distance runner. Why then?
Bookmark/Search this post with:
Agile teams try to avoid the over-detalization of the customer requirements. In many cases the initial requirements are specified as loosely as in one sentence. In order to keep focus on the real customer demand (and not on what dialogs he'd like to see) the feature requests are often expressed in a form of "As a , I want [so that ]". For example, "As a network administrator, I want to monitor the most active nodes of the system so that I was able to easily balance the load". This form of requirement works very well until you start to work on it.
Bookmark/Search this post with:
Different potential user groups and even users within the same group can have different opinions on the product features. The only way to see the high-level picture is to question many users and to gather some statistics on the user preferences. If the user opinions are gathered with the help of Kano questionnaires, the answers can be analyzed in a simple table.
Bookmark/Search this post with:

According to the Standish group research on average 45% of a software features are never used and only 20% of features are used always or often. It means that on average you could develop two times simpler product and sell it for the same price. Potentially gains can be even bigger, for the enterprise scale systems two times simpler product often means four times shorter schedules and ten times simpler integration and testing.
Bookmark/Search this post with: