Scrum Under Pressure
Sharing my experience using Scrum under tight schedule and other constraints
Scrum is a great development methodology. It is aligned with the contemporary approaches for developing quickly and producing success/fail faster.
In my case of implementing Scrum, I had to adjust it to the circumstances. Want to hear more? You’re welcome to read the whole story below.
When I formed a development team from scratch for a new project, I chose Scrum as the development methodology, as I was an enthusiastic advocate of its concepts. I’ve implemented this method in my previous role as a team leader, so I thought it would be a good idea to embrace it again for my new team as well. Once all team members were recruited, after two dry-run sprints, we commenced the official project development.
As I couldn’t foresee what aspects of Scrum would work best for the team, I decided to stick to the original Scrum principles. My managers supported me, and we decided to monitor the process in order to find out whether or not it’s effective or not, and fine-tune it when is required. If there is a need to improve or change the process, it can be done at a later stage.
After three months, the team seemed to perform a good pace. The members found Scrum very useful, especially the sprint concept: the team had a common goal to achieve. If that goal was achieved, I could see the proud and satisfied faces of my team members.
In addition, managing tasks on a daily basis and tracking them on a physical cork task board, facilitated the rising of problems quite quickly at an early stage of the sprint. Moreover, the ritual of the daily meeting increased the collaboration between the team members and contributed to the knowledge sharing and problem-solving promptly.
It seemed everything was on track. I managed the sprint deliveries according to the overall project schedule in order to arrive prepared for the onsite tests as planned.
Changing the Plans
You’re probably waiting for the “but”, otherwise this post wouldn’t be interesting, so here it comes.
After several sprints, when the test cases became more extensive, I revealed a major problem. Some assumptions we took, while planning the project, were wrong. The project was based on a software infrastructure that was perceived to be solid and stable, but it was not the case. It was not a matured platform as assumed. Sprint after sprint, we failed to pass the internal tests since the SW infrastructure was not stable.
Our product couldn’t handle the load tests simulations: too many users and transactions. Thus, the team’s tasks diverted from developing the project’s features to stabilizing the SW core, which led to poorly developed project modules. Our bugs rate increased rapidly.
In addition, the customer’s requirement changed frequently without ceasing, so we were forced to implement features and had to redo some of the work. The team was aware of the problems, and although the team members worked hard, they went into a sluggish mode. It seemed they’d lost faith that they could change the situation and achieve the ultimate goal.
This situation forced me to rearrange the team’s tasks and reassess the whole project schedule.
I’ve reflected this situation and the consequences to my managers. The higher management decided this project was too crucial for the company, hence the delivery quality must be achieved. As professionals, we could not compromise on quality. Luckily, new team members joined the team to reinforce the current staff. Unlike before, it was obvious to me that continuing the Scrum approach as it is, would lead to failure.
A change must be implemented.
Executing the change
Firstly, I’ve asked the product team to cease changing requirements. The ground should be stabilized, otherwise, a delay in delivery would be inevitable. After some discussions, the customer agreed to freeze the requirements. Any change would be added to subsequent deliveries.
Secondly, I knew the development methodology should be changed. I focused on two key values to promote a change: transparency and responsibility. I couldn’t let the team choose its tasks anymore, as the traditional sprint planning wouldn’t work. I wanted to cultivate expertise to achieve results quickly. Furthermore, the sprint goal should be mandated and aggressive.
Therefore, personal goals were set beforehand in each sprint planning. The team members were limited in choosing their tasks, in order to increase efficiency.
Nevertheless, keeping daily meetings was a must. It served both the key factors, “transparency” and “responsibility”. Each team member knew his or her tasks and was fully committed and responsible to meet the deadline. Beyond the personal goals, I wanted to raise the awareness to all team members, to ensure they were involved. I was seeking for a tangible and reachable way to present the current status and targets, so I hung whiteboards and cork boards in the corridors.
The project’s schedule and its status were posted on the wall on a weekly basis. I wanted everyone to see the progress, as well as the problems. I deemed using only emails and virtual tasks board as not enough to shake the team. One can overlook a soft-copy burn-down chart, as opposed to a chart hanging in the corridor.
The desired change became clear after three sprints. All project members could see the new course. It encouraged them to keep up the pace.
How to Reduce the Bugs Rate?
Now, the development process was on track, but we had tons of bugs. I’ve studied and analyzed the development process and decided to change the traditional approach for certain modules. The traditional development process should be adapted to the new challenge; the process of developing and then unit-testing and sending to QA team should be broken. It was too cumbersome for some modules. I decided to shorten it for specific modules, especially ones with intricate logic.
I asked the QA engineers to work closely with the developers and run test-scenarios in the development lab. This way, the problems were revealed on the spot and the developer fixed them promptly. It was similar to pair programming, but instead of two programmers, it was a developer and a QA engineer.
Subsequently, this change contributed to reducing the number of open bugs. It also aligned with the responsibility value: both the developer and the QA engineers were devoted to their modules.
Reflection and Awareness
To reflect the success, as well as the problems, I posted a weekly chart of the bugs’ status per module. Anyone could see the progress in one glance.
It encouraged the team members who were responsible for an improving module, but also discouraged the owners of a problematic module. To address that and overcome potential obstacles, I emphasized the number of bugs and the complexity of the problematic modules.
The team was tense and worked very hard, but continued to stay focused. It is not easy to be productive and efficient under high pressure and tight deadlines. I wanted to lighten up the atmosphere, but still keep them focused, so I hung catch-phrases on the walls. For example:
“you’ve found a bug — you won’t need to pack a bag” (meaning to travel to the customer’s site to fix it).
And here is another one: “Clear all the dust — find problems fast”.
No one could overlook the scattered messages all over the place. It was funny, but with more than a grain of truth.
Some managers were surprised to see the charts, tables, posters and slogans in the corridors. It seemed weird and untraditional. However, eventually, the team performed well and professionally. Our goal was achieved — we managed to pass the onsite tests successfully!
That was a great ride and a challenging experience, and I’m lucky to share this with you as well 👏.
I hope you enjoyed reading my story. Feel free to drop a comment and share your thoughts 👇.
— Lior
