PI Planning in the Trenches
Anniversaries are always a good time to reflect on the past year, what you have learned and accomplished and how you can improve in the upcoming year. I recently marked the one-year anniversary of a Scaled Agile Framework (SAFe) transition I helped lead for my customer, and here are a few things I learned along the way.
When I began supporting this customer in December of 2018, the team was essentially one large 45+ person (and growing!) “scrum” team. They were working mostly in silos, with three-week sprints, while tracking their work in Jira and Confluence. The team would meet once a week, on Mondays, to status each work item, person by person. As you can imagine, this was a long status meeting, and not a fun way to start the week. My customer knew it was time for a change, and one of my first tasks was to plan how we would do a transition to a Scaled Agile Framework (SAFe) structure. At the time, I wasn’t very familiar with SAFe, so I did a lot of research and talked with colleagues that had experience with that framework. I put together a transition plan and presented it to my customer.
You likely have heard that no plan survives first contact. This plan was no different — my customer accepted parts of my proposal, modified some and rejected others. It was still a win, though! I needed a solid starting point for the conversation. The resulting negotiations with my customer provided insight into what was important to the organization, where I needed to focus them on potential benefits and what was simply “a yard too far.” This let us come to agreement on a new plan. We executed our transition and began our first Program Increment (PI).
Lesson #1: Adapt the framework to what will work for and be accepted by your customer, and then adjust from there.
You have to meet people where they are. The organization wasn’t ready for a full, textbook SAFe transition. I believe this is true for nearly every organization out there. I quickly realized the best thing I could do was tailor our framework by accommodating what was important to my leadership and leaving out some features for which they weren’t quite ready. With a customized framework my leadership would accept, we could analyze how it went and easily adjust from there. That seemed like the right agile approach, so I felt it was a good path forward.
As an example, prior to the transition my customer tracked work by major initiatives. At the time, there were about 15–20 active initiatives managed by 12–15 “Initiative Owners” (IOs). As part of the transition, I proposed the idea of moving to two Product Managers (PMs) that would replace the IOs. Based on my familiarity with the organization, two PMs would be sufficient to understand customer needs, set the vision for the different products or initiatives, and flow priorities and needs down to the development teams. This would also free up several people to either move to development or support the PMs in other ways, such as areas in the spanning palette. My customer had already decided they wanted to go to three development teams, each with its own Product Owner (PO). Having up to 15 IOs for 3 POs simply wouldn’t make sense, and would needlessly complicate and confuse development. My customer, though, wanted to keep the IO role in place. I needed to be patient, with an eye on readdressing this construct in the future.
We were suffering from “too many cooks in the kitchen.”
Once we transitioned, the POs were receiving priorities and direction from too many people. This led to confusion, conflicting priorities and task overload. As we began planning for our third PI, I showed leadership how this setup was complicating planning and feature delivery. Both our director and workers were frustrated with their inability to understand progress toward our goals.
My wait paid off as I could now show them the impacts of this structure, not just tell them at the start.
I reviewed these impacts with my leadership and encouraged them to adopt the two PM model. Now that they could see specific problems the IO structure was causing, they accepted my recommendation. Doing so has greatly simplified the lines of communication, given the organization focus and helped us to truly solidify what the priorities are. The time and effort to get here was well worth the result!
Lesson #2: History can be overcome, but it may take patience and encouragement
With any transition, there is a risk that the old way of doing things will impact or creep back into the new way. This has been a particularly relevant point for our transition within the defense industry. This industry has historically been dominated by waterfall development processes, with developers siloed into a specific development niche. While some of the developers have embraced the ideas of team goals, owning the work and cross-functional teams, many others have strongly resisted the change.
Through my own interactions and watching others on the program, I have found that the best strategy to overcome this situation is based on patience and encouragement. This may mean acknowledging that a team is really just a group of siloed individuals, and then working to help them become a singularly focused, cross-functional team. Some of the keys to shepherding this evolution are:
- Ensure people know they are valuable and you care about them, whether they are embracing or resisting the changes.
- Find those on the team that buy in, encourage them to be leaders and highlight how they are helping the team achieve success.
- Encourage team members to cross train on other areas of interest within the team.
- Help each team member find the right way to add value while they adjust to the new way doing things.
- Encourage team members to take more and more ownership of the team’s work as time goes on.
- Perhaps most importantly, have patience when things aren’t going the way you think they should. It will take time for people to adapt.
It won’t be easy, but with patience and encouragement, you will be catalyzing agile minds in no time.
Lesson #3: Visualize the work and map the value flow
During our first PI Planning, our teams were overloaded with suggested features to work on. These features were poorly defined, had no relevant priority scheme (everything was high priority) and didn’t take into account external dependencies. The teams also didn’t know how to determine their capacity. As you can guess, once we got into PI Planning, it was difficult for the teams to make a plan they could meet. The teams also didn’t feel they were empowered to push back regarding the amount of work they were being asked to do. In many ways, our first PI Planning was a disaster that would lead to too much work-in-progress and too few features actually being delivered by the end of the PI.
In order to better prepare for PI Planning events, we adopted something we call storyboards to map out the long-term vision of how a given initiative can be completed. This may be different from storyboards you have seen elsewhere, but they serve a very similar purpose.
Each PI, the Release Train Engineer (RTE) and Chief Architect host a storyboard review with the PMs, POs, Scrum Masters and few key technical leads. We identify features or steps that we can use to build to the full capability. These storyboards include time ordering, internal and external dependencies, milestones and which teams will work the features. That said, the intent is to keep the storyboard high level, so we use the following guidelines.
- We don’t spend too much time on details, just enough to see the sequence and dependencies.
- We identify target increments for the work, which allows us to focus on the features we believe will be on the table for the following PI.
- We create a good description and acceptance criteria for each of these features, along with a 1-to-n objective priority for each team.
This approach gives the team a much better understanding of how a given feature fits into the long-term vision. As a result, the number of committed features has decreased, while the number of completed features has increased. We continue to look at how we can improve our pre-planning process to better prepare our teams and ensure we give them every opportunity to do the best planning possible.
I have learned a lot over the last year, and I am excited to discover more in the coming year. I will continue to look for those lessons that will help me improve our ability to operate in a way that both maximizes value and lets us work in a sustainable manner. I want to help our developers deliver the best products they can, and I want them to be happy and fulfilled.
I hope all of you are finding success helping your organizations thrive. As you work to make things better, remember to be flexible and tailor your approach to your organization, be patient and encouraging, and visualize your value flow. Accept that things probably won’t go right the first time, but constantly strive to improve. You will make positive changes to your organization, increase the value it delivers and, most importantly, make the environment better for the people that work there.
I am an Agile Consultant and the Head of Talent Management at Centil. We are revolutionizing the way our nation builds software for defense, through the adoption of agile and DevOps practices. If you would like to read more from Centil, we have an on-going series of blog posts. You can also find me on LinkedIn.