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?
It all boils down to the fact that agile processes and practices let you deliver awesome software, much easier than any other processes.
The reason why your customers want you to write some software for them is that they want to get good value for their money - and that's pretty much the only thing they know. Requirement specs? They don't usually match the real needs of your customers. Even (especially?) if they make you sign contract that requires you to implement everything in the specs to the letter.
On numerous occasions, I have spent time reading hundreds if not thousands of pages of requirements specs, prepared over the course of several months, which don't define any sort of useable product. I had product backlogs with tens and hundreds of user stories, all properly prioritized and thought over. Yet - this backlog didn't last more than a couple of months before the original ordering and feature list fell apart and became irrelevant.
And you know what? This is normal, expected and you should be prepared for it every single time you sit down to start a new project.
Conversations with my daughter (the kid in the photo) before preparing breakfast in the morning, usually goes somewhat like this: "What do you want for breakfast honey?" "Well, I would like scrambled eggs. No, make it boiled. No, make it an omlette. You now what dad? I will have whatever you get me, just make it yummy". This is the key point - "make it yummy". Make it awesome, make them love it and make them come back to you for more good stuff.
How do you "make it awesome" then? Well, this is where it is important to remember that software development is an act of creation rather than manufacturing. You have to become a bit of an artist to make great software. Good taste and critical eye are important. User stories are not everything, they don't give you the full picture - despite the name, they don't tell "the whole story".
However, you don't need agile to be a software artist. What agile does make easier is facilitating good old-fashioned conversations. Conversations with the customers and inside your team. Actually, maintaining the efficient channels for conversation is the only valid reason to have a process (any process) for developing software. All other reasons are unimportant - even if your ScrumMasters tell you otherwise. In order to create awesome software, you have to spend time talking to many people about what you are doing, discuss how it addresses the needs of your target audience and make damn sure to present the customer with results of your work as often as possible.
Being profficient in communication is much more important than being a guru programmer, master-level Java-wrangler whose neurons run on CRL and who has written his first Lisp program at the young age of 6. More important even than having Six-Sigma Black-Belt, CMMI 10 Certified ScrumTrainer certifications.
via http://agilesoftwaredevelopment.com/blog/janusz-gorycki/stories-battlefield
Posts
