Eliassen Group was brought in to help an Agile team that was not experiencing the benefits of Agile that they thought they were supposed to be seeing. There was an important industry deadline approaching, and it would have been trouble if the team missed their deadline, yet each sprint they were slipping further and further behind. Things were further complicated as they were an offshore team spanning 4 time zones with a 10.5-hour difference, during the COVID-19 pandemic. Through making 5 process changes across 4 sprints, Eliassen Group not only helped them get back on track and meet their deadline, but also doubled their story count velocity, and helped them become predictable, able to deliver everything they promised from that point forward.
Background
Eliassen was hired to coach a team within a Healthcare-related software company. The team was already using Scrum-style Agile practices, and had access to online training videos, but they had never had any live training in Agile. They also had never had an Agile coach, and each of their ScrumMasters primarily relied on the methodology and approach that they had learned in their prior jobs before getting hired for their current positions.
On top of all of this, the team had recently been created by merging two teams, one which had been located in the US, and the other in India. As a result, the Architect and the ScrumMaster were living in Colorado, and the Product Owner was in California. A couple developers were located in Pennsylvania, and rest of the developers and the testers were in Mumbai, India. In all, the team members spanned a total of 4 time zones with a 10.5-hour difference, during the COVID-19 pandemic, where everyone on the team was working remotely.
Despite all of these challenges, they were a well-functioning team. They got along together, they cared about their work, they were skilled, and the Product Owner was an expert in the field. The feeling of accountability was very evident, and motivation was not a factor.
The main area of focus as outlined by management, and confirmed by the ScrumMaster, was that the team was facing an industry-imposed deadline, and each sprint they had been slipping behind schedule, little by little. They were afraid that the team would not be able to meet the deadline if they continued to slip, which would have resulted in missed market opportunities, and possible non-compliance fines.
Track Completed User Stories, NOT Hours
The following images are the Burndown Charts from the first 3 sprints by hours. The lines look great, pretty close to the ideal burndown.
Figure 1: Hours - Sprint 1 
Figure 2: Hours - Sprint 2
Figure 3: Hours - Sprint 3
To look at the full story, though, our coach flipped from hours to story points. Below are the same 3 sprints by story points. These graphs told a different story and matched the problems shared with our coach about how the team was not finishing their full sprint commitments and stories were consistently being carried over to the next sprint.
Figure 4: Story Points - Sprint 1
Figure 5: Story Points - Sprint 2
Figure 6: Story Points - Sprint 3
The Sprint Reports confirmed that not enough stories were getting done, that they had to rush at the end of the sprint to get everything done, and they always missed delivering one or more stories. Now, to be fair and accurate, they had just newly formed as a combined team, but the symptoms matched other teams who have also not been able to deliver consistently or quickly.
Figure 7: Sprint Report - Sprint 1
Figure 8: Sprint Report - Sprint 2
Figure 9: Sprint Report - Sprint 3
Recommendation #1: Never use hourly burndown charts.
Always use either Story Point or Story Count Burndown charts.
Visualize Impediments
The first secret to faster delivery is to incentivize them to all work together to get complete stories done and closed. In contrast, a focus on hours often incentivizes team members to make sure that they “do their part” by getting all their own work done first. The reality of Agile is that the best outcomes happen when everyone thinks of it as “our work” with mutual accountability for the whole job.
The Agile keyword for this is the quick resolution of the infamous “impediments”. Upon listening to their daily standups, the following phrases kept appearing: “I’m still waiting on…” and “I didn’t know that you needed me to…” Especially with the time difference between US and India, if an impediment did not get resolved, then it would be another 24-hour cycle at least before it could be addressed. Every use of these phrases represented an unnecessary 24-hr delay.
This kind of problem is never a person problem, though. Everyone is working hard and working earnestly. This is a classic system problem. In the Theory of Constraints it’s called “visualizing the bottlenecks,” or the lack of visualization in this case. Working with their JIRA Admin and the team’s ScrumMaster, we created a new “Blocker” status for all subtasks and created a special column for the sole purpose of drawing attention to any task that prevented a teammate from completing work.
|
|
Figure 10: Kanban Board Configuration
Every standup the ScrumMaster worked hard to make sure that any comment about needing input, or a code review, or a merge, or research, was identified, added as a subtask on the JIRA board, assigned to the person who needed to do the work, and added to that “blocker” status column. As a result, they were quickly resolved! Yay! They finished the sprint with their highest velocity so far as a team!
|
|
Figure 11: Sprint Report – Sprint 4
Recommendation #2: Visualize impediments
Cross Roles & Close Stories as a Team
That uncovered the next obstacle. There was another step for them to take to get even faster: cross-functionality. In Agile we say that it is the job of the entire team to get stories across the finish line. A cross-functional team not only means that you have everyone on the team necessary to get the work done. It also means that when the burden is too great for one particular role on the team, the other teammates “cross functions” to help close the story.
When the focus is on closing subtasks, we miss vital opportunities to improve. If we only think about our own tasks, we miss opportunities to help our teammates solve their problems. In this case, one of the testers went on paternity leave and the new tester was struggling to get up to speed with the new system. The result was the return of the plateau on the right as everything got closed in the last two days, and once again they failed to get everything done in time. It wasn’t a “testing problem,” it was a team problem.
|
|
Figure 12: Burndown by Hours – Sprint 4 |
Figure 13: Burndown by Story Points – Sprint 4
The ScrumMaster worked hard the following sprint on cross-functional behavior and closing stories. They focused on a WIP (Work In Progress) limit of no more than 4 stories open at a time. You can see the result in the next two graphs. The result was that for the first time, the team members were running out of work! They got nervous about not having anything to do, so you can see on the second Friday that they pulled in another story. Not surprisingly, they were unable to finish that story, but except for that choice, they were on the right track to fast delivery of value as seen by the stair-step decent of the story point burndown.
|
|
Figure 14: Burndown by Hours – Sprint 5
Figure 15: Burndown by Story Points– Sprint 5 |
Recommendation #3: Cross Roles and Close Stories as a Team
(Sometimes you have to draw a hard line, but eventually team members
will see that crossing roles to closing stories benefits everyone.)
Reserve Time for Backlog Grooming
When they knew that they were running out of work, our coach’s recommendation for them was to work on “spikes” and research and plan the stories for the next sprint, but without doing the actual coding. The reason for this was two-fold. The first reason, as already stated, was that even the team expressed at the time that they did not believe they could get the story done. The second reason was that the team had been showing up to the Backlog Grooming meetings with no questions, only to uncover questions that blocked them during the following sprint. Encouraging a healthy Backlog Grooming culture is a great practice, and the end of a sprint is the perfect time for it.
Our coach also recommend that teams use the extra found time at the end of a sprint, when they get done early, to work on Technical Debt, but in this case they had been skipping the Backlog Grooming work, so our coach held off on that suggestion for now. Instead we allocated additional time in the sprint for them to track their hours on backlog grooming. Previously research work was considered time outside the sprint, and their budgeted hours per day had been reduced to 5 hours to account for this. To incentivize research, we increased their time allocation back to 5.5 hours per day and included a JIRA ticket for miscellaneous research tasks against which they could track their time.
They had also found their way to one of the most important, core Agile metrics. They had become predictable. They were now capable of delivering everything they had said that they were going to deliver, and more, as seen in their Velocity Chart and their next Sprint Report.
Figure 16: Velocity Chart
Figure 17: Sprint Report – Sprint 5
Upon the end of our engagement, they were still going so fast that they were running out of work, and they were still nervous about running out of work and continued to pull work in mid-sprint, but at least they are getting stories done predictably.
Figure 18: Burndown by Hours – Sprint 6
Figure 19: Burndown by Story Points– Sprint 6
Figure 20: Sprint Report – Sprint 6
Recommendation #4: If you get done early, first help with testing.
If testing help isn’t helpful, then work on backlog grooming
and research before coding future work.
Connect Every Day as Humans
The final thing that the ScrumMaster and our coach worked on was less obvious, but just as important. The original problem statement as described by the ScrumMaster was that team members were not very vocal. Questions were often met with complete silence. What our coach encouraged the ScrumMaster to do was to make sure to leave time every single day to just connect as humans. The ScrumMaster would often take time to ask about the team members’ lives outside of work. She also used an icebreaker at some of the major events to prompt people to share a fun fact about themselves. Our coach encouraged her to never skip these for the sake of time. Our coach also introduced the idea of adding “rounds,” going through each person in the team one-by-one to make sure to ask for their input. In addition, the Product Owner reached out and connected with the Tech Leads to check in on the team members who weren’t speaking up in meetings.
This is not a self-evident practice, but when paired with the other practices, it’s an important step to creating truly cross-functional teams that care about helping each other out when they get stuck.
Recommendation #5: Spend time every day to just connect as humans.
Summary of Recommendations
- Track Completed User Stories, NOT Hours
- Visualize Impediments
- Cross Roles & Close Stories as a Team
- Reserve Time for Backlog Grooming
- Connect Every Day as Humans
Want to learn more about Eliassen Group's Agile Practice? Visit our Agile Consulting page!