What is agile planning?

Some detractors say that agile is about forgetting plans and documentations to rush straight to the development and go with the flow. Well, I would answer that those are people who didn’t practice agile software development really, or at least not the way it’s intended to be done. Or maybe they didn’t understand it fully.

We value working software over comprehensive documentation. (Agile Manifesto)

An agile process is not about forgetting the documentation, but about prioritizing this task lower than a working feature. Why? Because we prioritize the steps of a projects by their business value.

Planning, on the contrary, is at the center of an agile process because it is critical to the success of a software development project. One of the powerful things of Scrum is that it tells a team to gather every 2 to 4 weeks (or whatever the length of your sprint is, though it should probably be in that range), to review the plans made before, change them if necessary, and polish the plans for the next sprint.

What is important in the scrum template is not the plans that we produce during those meetings. Documents are just a snapshot of our minds at a specific moment. No scrum doesn’t emphasize the plans, but the act of planning on a regular basis, and of updating our ideas with the latest knowledge. After each sprint, a team knows more about its capacity of delivery, about the architecture of the database needed, or about the technology that provides best performance for another feature. The more information you have when you estimate and plan, the fewer mistakes you will make. Agile allows you to look at your plan from an other angle and rethink your ideas more often.

On an agile project, the next planning meeting is never far away. I think this is the key that helps the team to focus on a goal and get things done. More than the rule that scrum implements “no change inside a sprint”, knowing that we will review our vision soon helps letting the team focused on the current goal. We’ll set a new one in the next planning anyway!

Personal experience : What is different?

I can distinguish 3 situations in a software development project :

Waterfall-model

I have not been part of a big project that followed the waterfall model in a professional environment. But as every information system student (sadly), I studied it long. What I remember from it (that was 3 years ago :) ) is that it was a lot of “guessing” about how long an activity might take. We were even told during classes that our estimations were usually half of what will happen, so we should double it. Ouch! At least the message was honest and clear :  You wont get it right. I also remember that we were pushed to apply a heavy waterfall process on a 3 months school project. I had never thought again about it, but the result won’t be surprising : We made plans, wrote documentation, and diagrams… and never looked at it again…

Mess-model

I’ve also been on projects were we didn’t plan anything. Or at least never further than the classic question to the developer “how long do you think it will take?”. On this kind of project, the classic questions comes at an increasing rate. the work accumulates, and we don’t know what to do anymore. It is very hard to focus because we get multiple objectives to reach at the same time. The project I am talking about had a lot of features, but most were only half working, or sometimes the feature would even miss the original idea. Being part of this kind of project was a pain as a developer. It is not pleasant, because we don’t see the end of it. I felt stuck, and overwhelmed.

Agile-model

By this point in this article, or just by the name of this blog, it’s probably clear that this will be my preference, but I am going to make my point anyway. Agile planning starts by setting different horizons. let’s focus on the sprint and the release. When planning an agile project, every one is involved, because everyone has to commit to the plan as a team. this is an important fact that gives the “we’re in this all together ” mindset.

When making an sprint planning, we focus on a short term goal, and on a close delivery. we cut the work into user-stories. I love user-stories. It is a feature expressed by a sentence that points out its business value and the targeted user.

As a Blogger // Targeted user
I want to be able to write my post in Live Writer // Feature
So that I can post without logging in // Business Value

Thanks to this model, the risks of not seeing progress during a sprint are null. We are sure to understand the purpose and the need of the functionality.

What I can see after just 2 sprints on this same project that was following the “mess-model” is that things get done. Turning the requirements into user stories makes developers think about the end-user needs. It is also very rewarding to work in short iteration with user stories. Why? because we see our work delivers value and we can track our progress with a working software. We can also see the progress on different artifacts that Scrum recommends like the Task Board, or the Burn Down Chart.

And last, Scrum is FUN. Yes it’s fun to work as a team, to communicate more, to learn from your colleagues. Software development must be fun, and the Scrum spirit helps you with that one. Here is an example of a great Scrum workspace :) I dare any developer to say it’s not attractive!