Where the miracle begins

About two months ago I had a severe argue with one of our lead developers about ‘agile stuff’. After 15 min of listening to my enthusiastic speech his face became red and I could read “Woman, what do you know about the real life?” from it. And then he said the phrase I can’t forget: “And why do we need all of that? Why we can’t just collect our best architects and analytics and write down all requirements, describe models, create the ideal architecture, plan everything and then start development?”

My face when I hear the phrase “And why do we need all of that?”

I stopped talking for 30 sec (and it is a sign that I am very frustrated, as usually I talk all the time). Finally, I murmured “Because…have you listened to me last 15 min???”. We had a couple of beers later that day and he looked rather friendly, when we said good buy, so I hope he is not sharpening the sword for my next visit.

I created this post, because I hear this question too often last time and want to have a link I can send people as answer ^_^

How it usually starts

Mobile app starts with the very high-level “requirements”, produced by the business people. Then they are broken into a lot of smaller requirements, which can be transferred into development tasks. It usually looks like we want to capture the essence of a project in the documentation for the project.

So the flow can be like:

Gather our analysis team – best analytics and architects, project manager and they will think deeply for some time. Then they create the architecture, write down all the requirements, decompose them. Project manager will create the project plan, taking into account all risks (he is brilliant in risk management, haven’t you heard that?). So, when the project documentation is ready and all is planned it is time to involve the development team.

It seems that all the hardest work is done – the development team should only follow the plan. But how many teams succeed in deliver this application according to the plan?

What management usually say, when such project fails? It was the development team fault! The development team manager starts explaining, that the plan was wrong. Then all the faces turn to the analysis team – You created the wrong plan!

And the miracle

Documentation is not bad. And it is not the clue to the solution. The one important component we forgot about is the clue. Plan’s don’t execute projects, but people do. Changing real-world conditions can brake any ideal architecture.  Exhaustive requirements don’t guarantee that we will provide our customers the product they need, but people do.

Agile tells us correctively, that it’s all about the people collaborating around the working code. We write the code to verify our predictions and assumptions. It is a lot different from trying to predict the future with the documentation we create on the initial stages of the project. So, agile presents us the different way to cope with the project:

1. Find a skilled enthusiastic team.
2. Create the documentation, which is just enough for the development(in mobile application case: storymap, prototypes, screen interaction diagrams, flow diagrams, API requests descriptions…whatever we need for the particular application).
3. Collaborate with the customer, he should be the part of the team (not so close, but not on the other bank of the big river, as it happens usually).
4. Build your product iteratively, getting feedback from the customer, users after each iteration. Review your plans often. More transparency for the customer!
5. Monitor your progress, speed, Adjust your process to increase productivity.

As the result your product gets trough all the uncertainties you have in the beginning, the most valuable features are added first. You can release you product earlier and adopt to the market needs – change almost as fast as the market does. The team works together, they are inspired and motivated together and they deliver together. It’s about discussions and openness regarding project state, progress, and trade-offs.

So, the miracle is in the people collaboration. People create amazing software.