Some tasks seem impossible when you get them. This one was exactly that. Impossible. A complete re-writing of the software architecture with a delivery date too close. The consequence of missing the deadline was huge. If we missed it we had to wait a whole year to deliver into the next product cycle. This was not an option. The consequence of not changing the architecture was even worse. It would lead to that our customers would have an outdated enterprise platform and would probably start looking for other alternatives. We simply had to do these changes and deliver on time. Weeks of negotiations with our stakeholders for doing the changes had put us in a situation with only a couple of months left to delivery. With the present velocity, we would miss the deadline with several weeks. How would we increase the speed, increase or at least maintain the same quality and deliver on time?

The first action was to update the development team with the latest deadline and to find out their views on the situation. I presented the numbers to the team together with a made-up burn-down-chart explaining that we had to deliver four times faster than our present velocity every week to meet this deadline! The team understood the gravity of the situation, but instead of giving up they started coming up with solutions for meeting the deadline. Changing the architecture was their idea from the start – of course, they wouldn’t let it go without fighting for it. I summarized all their suggestions based on reality and impact. Having managers buying lunch for the team every day was added lower down in the list while removing unnecessary meetings was a priority. The top actions we came up with were these:

Remove waste

Clear out our responsibility and remove unnecessary tasks from the team. Basically, these means don’t deliver solutions that don’t help the customer or gives any value to the customer. We could use that time to help each other finishing deliveries with higher value instead. We also negotiated with other teams that were more suited for doing smaller tasks that were quite far from our specific responsibility for this delivery.

Break down our short term goals

Create clear weekly goals that everyone in the team could breakdown and understand. When everyone could understand our delivery goal, the overall goals seemed not so far away. Breaking down the tasks was also easier since we could focus on our weekly goals. This resulted in each task to be broken down into roughly 2-3 days, meaning each person could complete about 2 tasks per week.

Remove more waste and minimize interruptions

Stop wasting time on unnecessary meetings, including short ones. We only had our 15-minutes team meetings on Mondays, Wednesdays, and Fridays. Tuesdays and Thursdays were from now on “focus days” with zero meetings and zero interruptions from outside of the team. This meant that the team members could come into the office whenever they felt like it and leave when they wanted and plan their “focus days” as long as we could reach our weekly goals.

The next day we implemented these actions. And the effect was huge! Already the first week we delivered twice as much as we used to. During the coming weeks, we increased our velocity even more and delivered four times more than before. After one month I checked our working hours. There was no overtime. Our average time spent at the office per person was 7 hours and 44 minutes per day! We didn’t even spend 8 hours in the office, still, we delivered four times more than before. The days we delivered most of our work was on Tuesdays and Thursdays, our “focus days” where everyone planned their own time based on our weekly goals. This way of working was a true success for the team. We kept the spirit all the way up to our goal and delivered the new architecture two days before the deadline! Then we celebrated with a big cake!

The different actions we implemented to reach our goal were not unique or unusual. They didn’t come from any best selling agile guru. They were not forced into the team by an overpaid scrum coach. They were just the team members suggestions, built on common sense and experiences in the team. We took time to reflect on our way of working and we built trust within the team by giving feedback and suggesting improvements. When we saw our progress we got more energy to keep up the velocity and we didn’t want to break our workflow. We stuck to this way of working throughout the entire project, even during vacation times and sick periods. You see, most answers to our questions about efficient teamwork will not be found in books or in two-days-courses. Those things should only inspire us to continue searching for the answers. The true answers are within yourself and your team. Get out and find them!