One of the most exciting aspects of a delivery phase is the very beginning – any changes you make are reminiscent of open-heart surgery. Today, I’m going to continue the story of my first project and I will show you the way we solved further problems generated during the project planning and initiation stage. Has the patient survived? You will find out in a moment.
When the project status of the initiation phase started to turn sour, it became clear that SCRUM, by means of which we originally planned to work in the delivery phase, wouldn’t work. Facing tight schedule and high volume of encountered issues, we had to find a way that would allow optimal tasks distribution. Additionally, our goal was to minimize overhead from SCRUM artifacts that we wanted to keep. In order to achieve so, we elaborated a new way of working, which was as follows:
- we split the team into three double sub-teams
- UI developers were assigned to some of the sub-teams and became engaged in the work when necessary
- every sub-team had a fixed assignment of the User Stories together with a strict development order
- planning meetings were conducted on sub-teams level and included 1-2 closest User Stories only
- backlog refinement was carried out on a regular basis based on the work progress of particular sub-teams
It quickly turned out that the applied strategy began to bring the expected results. During the whole delivery phase, the team members stayed focused on their own part of backlog. What’s more, the time spent on planning meetings proved to be significantly shorter than it was in the case of classic SCRUM. Thanks to this setup we were able to minimize the impact of unplanned absences, which were unfortunately quite common. In case they occurred, the work replanning was made on a sub-team level only.
Obviously, our solution wasn’t perfect and brought a number of consequences. Introducing the siloses impeded spreading knowledge grasping potential conflicts on the code level. The next consequence, caused by parallelization of development made testers feel overwhelmed as they couldn’t keep up with the amount of work. In extreme cases, almost a week passed until quality verification was started. This hindered our efficiency and most importantly, made us less predictable.
As already mentioned in the first post, the most significant mistake made during the project preparation was to devote insufficient amount of time for the needs and expectations of the IT department responsible for:
- enforcement of given technical standards and best coding practices
- quality verification of code developed by our team
- technical debt management
One and each of the above points were sources of additional tasks, crucial for correct implementation of business requirements. Unfortunately, we found out about most of them during the implementation. As a consequence, the volume of unexpected and unplanned work grew day by day.
Taking into consideration the fact that we worked in Fixed Price, we were under a lot of pressure, which certainly didn’t make things easier.
How did we deal with this issue? Well, basically we did not have much room for manoeuvre, especially that our oversight was the source of the problem. The countermeasure we chose was to devote more time to the analysis of technical requirements before the planning process started. Thanks to that step, our estimates became more and more precise with each iteration. Although they were still higher than initially assumed, we were no longer taken by surprised. Finally, we decided on the next steps in a controlled and conscious manner.
Just the UI and the job is done
After the unexpected amount of work, we had to cope with yet another serious challenge that was effectively disorganizing our work. It was UI, or more precisely the need for support of numerous and various devices and screen resolutions. In a number of cases, the component developed from scratch became a source of problems, the solution of which was quite time-consuming. I also recall cases where solving one issue was the source of the next two.
What was the consequence? We didn’t manage to deliver a single complete feature within the first three weeks of the delivery phase. Moreover, we often started development of new features while there were still open ones blocked by UI tasks. On the one hand, it let us move forward. On the other hand, there was time when almost 25% of the whole backlog was work in progress, which significantly increased the project risk.
Unfortunately, in that case, the only reasonable solution was to assign yet another UI developer in order to help compensate for the delay and be back on track. Despite doing our best, we achieved that just before the end of the project. Team extension took longer than expected which affected the budget of the project.
Daily – the most important artefact ever
We started each day with a daily standup, during which every team member reported what they did yesterday, and what they were planning for today. Yes, “reported” describes well what happened there. Driven by bad habits, I appropriated this meeting by asking about status updates. As a result, I got a bunch of information, which I couldn’t make use of, and the team was losing the opportunity to share knowledge and jointly define the plan for the upcoming day. Luckily for me, my Tribe Master joined one of such standups and was willing to share his observations and suggestions regarding the things that could be improved.
On the next day, I took two steps backward, letting the team take full responsibility for the meeting. The results could be noticed instantly. Laconic reports gave way to live discussions. With each subsequent meeting, the team focus was shifting from doing to achieving goals. Thanks to this seemingly small change we slowly started to regain control over the situation. At the beginning of each day, we had an action plan for the next 24 hours. Even if we failed to put it into practice in 100%, we had good reference point allowing us to clearly define project status, spot encountered issues and make sure we wouldn’t have to do it twice.
From a time perspective, I think that was the change that made the biggest difference.
Finally, after 4 months of intensive work, we managed to deliver the agreed scope within timeline. The project turned out to be successful despite exceeding the budget. It strenghtened our relationship with the Client to a greater extent. However, our work has not ended with the last line of the code. As we know, we learn from our mistakes, and since there were a lot of them within our project, there were many conclusions to be drawn as well. Thanks to the lessons learned, we identified as many as 37 problems affecting our work. One and each of them deserved a detailed analysis and countermeasures. Nevertheless, sticking to a small-steps approach, we chose 4 recommendations to help us and other project teams at Objectivity to improve the process of software delivery. They are as follows:
- the time spent on preparations and project kick-off should be aligned with its complexity and the number of potential unknowns
- the needs of all key stakeholders must be identified (and estimated, if possible) before a project starts
- in case of a rapidly growing number of issues with key components, the team should consider putting project on hold and focusing on resolving current problems while anticipating the ones that might pop up
- to avoid nasty surprises during implementation. The decision on the re-use of the out of the box third party components should be preceded by Proof of Concepts or spikes
In the posts published so far (post 1, post 2), you’ve had a chance to find out about the issues and challenges we have faced as a team. However, there is still the last missing puzzle to give you a complete picture of the situation, which is a project manager’s perspective. In the next post, which is also the last one from the series, I will try to discuss the issues I faced as well as the reaction of the organization I work into my further mistakes and tripping.