To meet business goals, a software team’s daily work needs to align with an organization’s strategy. Eric Hilfer, VP of Software Engineering at Rosetta Stone®, believes that “one of the myths about agile is that you deal with what you have right on your plate and you don’t make a plan, and that’s not actually true”.
Agile software development supports a release plan, but it’s challenging to coordinate that on a multi-team level when you’ve got a lot of dependencies between teams.
Rosetta Stone®, a language learning technology company, found a solution to this challenge by bringing their entire development organization together about once per quarter to map out 10 to 12 weeks of work. And last week, I was lucky enough to watch how they do this at their 5th program increment planning (dubbed “PI5”). Read on to see how it went.
Day 1: set context for the roadmap
Day 1 started with vision presentations, where organizational goals and milestones are shared with the entire group (80 people across 15 teams from 6 offices), to ensure everyone starts off on the same page. These presentations included the current state of the business, overall program vision, strategic themes and goals, and the top 10 milestones to be accomplished in the coming quarter.
Eric said the “primary challenge in working with multiple teams is to make sure that they’re working on the right work, at the right time, and that they understand how the work fits together” so the first day is used to set that context. While day one was heavy in presentations, it was important for all of the teams to really understand what their work would be contributing towards and is crucial for any type of agile planning meeting.
Alignment between development goals and business strategy is extremely important. –Eric Hilfer, VP of Software Engineering at Rosetta Stone
Day 2: teams make their plans
On day two, everyone broke out into their teams to tackle day two’s agenda: elaborate, prioritize, sequence and estimate 5 sprints and then to identify, discuss, and document dependencies and risks. Eric said “these quarterly meetings are a fantastic time where the teams come together and interact directly.” The teams identify their dependencies and map those out, and they do a lot of anticipation. A good start for any team (and how the Rosetta Stone® teams start off day 2) is estimating velocity for the coming quarter – will anyone be on vacation? Are there any new hires to the team that will change velocity?
Next, the teams created draft plans, sprint by sprint and then sequenced the backlog items in the sprints until their capacity was full. This was done on the big program board (made from cardboard boxes, duct tape and A LOT of post-it notes) which Eric described as the “central artifact that has all of the teams represented on a line‑by‑line basis.” On this board, teams physically add post-it notes with features and epics, and map out dependencies using a red string.
At this stage, teams also started to draft their initial team program increment objectives (what the team wants to achieve in the upcoming quarter) and then the aggregation of all of the teams’ objectives eventually become the company PI objectives to be approved by the key stakeholders. Rosetta Stone® also encourages teams to include stretch objectives which might not be finished in the next PI. After teams have a draft plan on the program board and draft objectives, they present these WIP plans to key stakeholders, separate from the rest of the group. Because the stakeholders are reviewing the draft plans from all the teams, they have a holistic view and can see if there are any challenges such as scope, resource constraints and dependencies across the teams in the next program increment.
Day 3: present plans and gauge confidence
The final day is when everything comes together. The teams break out once more to make any changes based on the feedback they received the day before, they update the program board and finalize their presentation. One member from each team (usually the Product Owner) presents highlights from their team’s plan to all the other teams in attendance. This includes final program increment objectives, stretch goals, the sequence of stories in each sprint, potential risks and dependencies.
During this presentation, the rest of the group, outside of the team, is encouraged to provide feedback and ask questions. Once all of the teams have presented, a ‘confidence vote’ takes place where teams vote on their confidence in their ability to meet program objectives using the”fist of five” approach.
Day 4 and beyond: Jira Software and Portfolio for Jira
The week after the PI planning, Todd, the head of PMO at Rosetta Stone® and the release train engineer, leads a brief retrospective to capture what went well, what didn’t and what can be done better next time. By this stage, the teams have also entered in all of their sprint plans from the program board into Jira Software, so Todd and Eric use Portfolio for Jira to create a Rosetta Stone® portfolio plan.
Portfolio for Jira uses the team’s scrum boards in Jira Software as a data source to roll up into a multi‑team plan, so that they get a portfolio view without any extra effort, since each team was doing their planning already. “Prior to having Portfolio for Jira a lot of that information on the board, although it could persist and be available, it was hard to update it or revise it to reflect reality” Eric said.
As I was leaving, Todd mentioned that “getting multiple teams to move forward in the same direction at the same velocity is an incredibly hard problem. Scaled agile helps us solve that problem as it gives us absolute visibility across all teams and helps us move forward at the same pace. Using Jira Software, Portfolio for Jira and the scaled agile framework (SAFe) within Rosetta Stone®, allows us to see what all teams are doing at the same time. This is extremely important when you have as many dependencies as we have between teams.”
Rosetta Stone® calls this PI planning and at Atlassian, we call it quarterly planning, regardless the point and importance of these meetings it to get everyone aligned at a micro and macro level. This is important for any size team or organization, and will lay the foundation for strong agile software development that can scale.
Happy planning! 🙂
Did you find this post useful? Share it on your social network of choice so your fellow agilists can learn more about roadmapping, too!