A detailed plan is everything, right? I would have answered this question with a loud and clear yes years ago. Ever since I got in touch with Agile – almost 10 years ago – I don’t anymore. My background is project management. I have done that for many years. I managed big software projects in different environments and I always had a professional, detailed plan. As I said, when getting in touch with Agile I noticed that planning is still necessary, but not to the extent I used to plan. I noticed that there are many other aspects that are more important. One is definitely focus. Provide a team or even an organization with focus and you will certainly be more successful as with a very detailed project plan.
The customer in trouble
When I joined this company I learned that they are having a new release of their main product every 5 to 6 months. For an organization that is organized in scrum teams, running 2 week sprints and developing in a fast paced industry this is not very often, I have to admit. However, there were several reasons for that, but changing it to a shorter cycle was clearly on my agenda. But how? And how long should it be? Changing such a process is not an easy task and many aspects need to be considered. By not considering the right things and by shortening it too much, you can get into a big mess.
In the middle of my analysis and mainly getting to know my new home base we got an urgent request from one of our biggest customers. We should deliver new functionality within the next 5 weeks, as they are forced to shut down some other systems and we need to step in.
Most of the people in my company, which were affected by this, got really nervous. How should we do that? Our next release was planned a couple of months later, definitely too late for this request. Almost every development team was needed to develop parts of it, but were in the middle of something else. In the first days I heard several times the f word and things like “we never ever can make that happen”.
To make this somehow possible, we had to stop working on every other project, re-plan everything and try to get this out the door within 4 – 5 weeks. I am not telling you all the details of how we did it and what worked out and what not. But I can tell you that – at the end – we made it. We delivered 5 weeks after the first call from our customer and with two intense sprints in several development teams.
The change of the process
Before and during the big and stressful project many people were not very positive about this stunt we were trying to do. I definitely was the exception – I thought this is our chance to shorten the release cycle. Maybe not to 1 month, but maybe to two months. I thought, if this will be a success, we have the opportunity to try this. As it became a success, we took the chance we got and changed the standard process.
So what did we do?
We changed three main aspects of the planning process. Before the rough estimation of possible features for the next release were done with the management team only. We changed that aspect and included the teams that were actually delivering the features. Whoever else could do a better estimation job?
We didn’t tell the management team the exact estimated hours of each feature – we changed to t-shirt sizes instead. This is enough to decide whether the feature is in or out for the next release. This was a tough change, but also a success. With this change we were able to avoid long and heated discussions within the management team. In the past they always questioned the estimated hours and thus put a lot of pressure on the teams.
Last, but not least, we allowed just one large feature, two medium sized features and several small sized features to go into one release. And this change – in my perspective – was the biggest success factor. With this we provided the development teams with focus. They could concentrate on just one big (large) topic per release – instead of 4 – 6 in the previous 5 months release cycles.
In addition we established a big, physical Kanban board next to our kitchen area, to allow the whole development department to see what is going on in the current release and what will come in the next ones. For me again an instrument to provide transparency and focus – focus on what is going on!
“Almost” was in brackets!
I strongly believe that focus was the main success factor here. Nevertheless, there are other important aspects as well. We still plan, we still estimate – this is also important. You can’t lead an organization – even an agile one – without planning.
Sounds like a “of course you can’t”, but believe me, many people – new to agile – think that way.
By the way, what I “almost” forgot: Watch the blog in the next weeks – in my next blog I will write about the Kanban board above and process around it! And of course, we’d love getting your feedback — write a comment send an email!