Back to Menu

Optimizing a SAFe Scrum Team

In my recent job I took over leadership of a SAFe scrum team that was not performing up to its expected level. Senior management had expressed its concerns with the team to me, on both an organizational as well as his personal level. He really wanted to know what the issue was behind the team’s underperformance, as well as wanted it resolved. The team was simply not completing committed objectives on time.

In the high pressure development situation that we were in, there was no time for pulling people away from their development and testing duties to interview them to deduce the whys of this. (This was in the trail of a significant administration and personnel change. Morale was quite low.) However, Jira contains velocity charts for SAFe. These bar charts pair two bars for each completed iteration, one for the delivered story points next to one for the committed story points. When I started with the team, the delivered points were typically -70% to -80% of the committed points for each iteration. For example, if the team had committed to 60 story points for an iteration, they actually delivered in the nature of 15 points.

Using this as a baseline, I hypothesized that I could improve this by introducing good estimation skills and individual leadership. My goal was to decrease the delivered/committed variance to +/-15%. The following were the key points of my approach:

1. Emphasized refined estimation skills. I recommended adding padding to their estimates for margin of error and Murphy’s Law. As a personal benefit this would also be healthy for their stress levels.
   
   I reinforced this at the beginning of every planning and refinement session until it was second nature to them. I also reminded them to be mindful of all the steps to be included in an estimate: initial development, automated testing, manual testing, bug fixing, code coverage, promotion through the development environments, all the way to deployment live.

2. Coached the team on ownership. This meant to not just do the work, but to own the outcomes as I wanted to increase the internal leadership of the team.

3. Established a rapport with each team member individually and learned their career interests. In doing so, I was clear that every job is a stepping stone to the next one and I wanted to know what they wanted their next ones to be so that I could help them in that direction.
   
   This allowed them to feel heard and that they were not just “resources”, and fed their ambitions as much as possible. Whenever I could, I put them into assignments that would allow them to stretch towards their goals. I believe this lifted their collective engagement level as they were clearly working for themselves as well as the project.

4. For those with leadership oriented ambitions, I spelled out the foundations of it, recommended good books on it, and point out nuances as such occasions presented themselves. I also sent them relevant podcasts on Youtube.
   
   My intention, again, was to raise the internal leadership level of the team so that they would be more self-directed and engaged.

5. For populating the team backlog with user stories, I spelled out the stories as best I could but wasn’t hung up on making them the final word. I wanted to let them ask questions and fill them out as they saw fit. By doing this, and them driving the internal conversations, they were building their share of the ownership of them. (Going back to point #2.)

6. Didn’t put my estimates of story points on the stories as this may have given them an expectation to try to live up to. Instead, I let them deliberate and vote on the story points, attaching the numbers that they arrived at. This in turn helped to build their ownership over the stories.

Back to Menu

The end result was that this optimized the work delivered/committed variance from -70% to +/- 10%. (Indicated in the Jira velocity charts.) It took the better part of a Program Increment to do so, but it remained fairly consistent once hit. That delivered points fluctuated within -10% to +10% of the committed points was better than I anticipated.

With this the team started to consistently hit its commitments, and it was also pointed out to me that the team’s collective stress level went down noticeably. This made it a ka-ching in my book as both the senior management as well as customer leadership appreciated it. If you have any questions about this, or the nuances of it, please reach out to me.

. . .

Steven Kury, MBA, is a software product manager. Throughout his career he has contributed vision and leadership to a breadth of online applications. Contact him at steve@steve-kury.biz or (717) 350-6781 to discuss how he could contribute to your system.