Stories From The Battlefield: #1 – Make It Awesome


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?

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.

7 thoughts on “Stories From The Battlefield: #1 – Make It Awesome”

  1. I agree that communication among team members and customers is critical – you need to create what customer wants and you need to coordinate team efforts.
    However, even with perfect communication you will fail if you don’t meet other agile postulates: test your code (constant bug reports is not the form of customer communication you look forward to), planning (reporting constant schedule slips is not the form of communication the customer looks forward to), failing to constantly improve the development process itself (whatever simple would it be).
    Not to mention the development skills themselves – perfect communication will not make your software work. javac will – if you provide it with valid input 😉

    1. Sure, you need all of these things you mentioned, otherwise you will fail. The thing is though that you don’t need a process (agile or otherwise) if you don’t need to communicate. Processes in software development are all about communication. Other engineering disciplines (designing, testing etc.) are tools of the craft that are of different type and I glossed over them on purpose.

    2. Replace “Java skills” with “software engineering skills”. The rest is definitely true.

      Communication is the most important (similarly to other factors :)), but what if one guy (or two good friends) is working on their own product? He has vision, He doesn’t actually communicate with customers. Indeed, he does not need any Scrum or other agile software process then. Still he may end up with an awesome software.

      So there are no golden rules. Including this one.

  2. While I agree with you that agile facilitates communication with customers and between team members and that this is an important part of agile. I disagree when you say that agile is not faster.

    All the practices of Agile (communication, pair programming, extensive testing, short iterations) are there to keep developers focused on the problem that should be solved. Traditional processes, with large feature lists often resulte in people implemented features that they never need.

    Losing focus is what causes us to miss delivery dates and agile methods are constantly reminding us not to lose focus. For this reason, I think that agile *is* faster.

    1. See, this is the common misconception. Agile is not necessarily faster when you are talking about the whole product backlog. Indeed, a well-run traditional project can deliver the full product feature set faster than the equivalent agile project, when you take into consideration that it is normal for agile projects to redo user stories when the customer decides that what has been delivered is not what they really wanted.

      However, agile projects have a much shorter lead time for delivering individual features requested by the customer. This makes agile projects much more efficient if you prioritize user stories properly – this is due to the Pareto principle: any product contains 80% of its value in 20% of its features.

      I am going to devote the wohle blog post to this phenomenon, as I have interesting practical observations to share 🙂

  3. “Indeed, a well-run traditional project can deliver the full product feature set faster than the equivalent agile project, when you take into consideration that it is normal for agile projects to redo user stories when the customer decides that what has been delivered is not what they really wanted.”

    Are you sure about that? Is there any indication that up front design is in fact faster than emergent design? Is there any indication that defining the right requirements up front is any faster than doing so incrementally and iteratively?

    Or are you in fact saying that delivering a full product that the customer in fact doesn’t want is faster than delivering one that the customer does want?

    1. Well, agile development is not a silver bullet. It is not the end-all solution to all our problems, sorry – despite the fact that I like this methodology much more than any other, because it works better in most cases than any other.

      There is a vast class of areas where agile development is not necessarily a good fit, at least not in all its full glory.

      Say you are designing a satellite. You have exactly one shot to make it right. There is no way to “fix stuff iteratively” later. Upfront specs that *have to* be right. Otherwise you end up missing Mars by a thousand kilometers or cratering into it. Just ask NASA.

      Also – I *will* argue that you can deliver *the whole* backlog using agile methododlogies no faster than using traditional ones. It is just the 20/80 rule at play here – the product that you deliver in agile way begins to be useful much sooner than if you used traditional processes.

Leave a Reply

Your email address will not be published. Required fields are marked *