Scaling agile with Rosetta Stone
Balancing agile practices with long-term business objectives
Software teams value autonomy and independence. However words like scale and standardization can be cringe-worthy, and come at a perceived cost. Regardless, planning work across multiple teams and reporting on multi-team projects is part of growth at any company.
Solving these challenges is well worth it. Scaling agile development produces measurable benefits to program and portfolio planning, and accelerates the delivery of value to customers.
In this presentation we'll cover these topics:
- Portfolio kanban and value stream
- Program increments and multi-team planning
- Balancing just enough consistency with team autonomy
- Architecture roadmap
- Innovation sprints
- Scaling UX with agile
- Test-driven development
- Practical tips for scaling with JIRA Software, Confluence, Portfolio for JIRA and the Atlassian Ecosystem
Watch & learn
Q & A
Our hosts at Rosetta Stone, Eric Hilfer (VP Software Engineering), Todd Glidewell (Manager of the PMO), Chris Coffman (Senior Director, Product), Haris Papamichael (Sr. Product Manager of PO Assessment) and Greg Buron (Sr. Director of Software Engineering), answered the top questions from their presentation. Read on to learn more about their agile success story.
Q1: How long did it take to implement SAFe? How did the staff take the change from Agile/Scrum into SAFe?
A1: We had our first Program Increment (PI) planning about 2 months after we decided to move to SAFe. It was a very messy PI planning compared to what we do now, but it was also a lot of fun and a great learning experience. Implementation and optimization has been ongoing since then. Prior to implementing though you have to train your people and your exectives.
Q2: Who are the key members of your portfolio team? Who manages the funnel process?
A2: At the highest level, the leaders of each stakeholder business guide the ideation and ranking of desired features for their specific market segments. Then the Product Management leaders synthesize those requests into a roadmap vision, working with maintaining flexibility to move quickly when needed by specific business opportunities.
Q3: Did the program planning exercise require a complete product backlog up front? Or were epics less defined upfront and planning done on that limited information?
A3: Program Planning requires a well understood and well communicated vision of where you want to end up at the end of the Program Increment. It’s ideal if the Epics are well written with good Epic Value Statements and Definitions of Done, but honestly some of that elaboration occurs during the multi-day planning session. Working with the teams and the business at the same time during planning often leads to new requirements.
Q4: Do you have dedicated scrum masters per team?
A4: Yes, our PMO members act as scrum masters on every team.
Q5: SAFe seems really prescriptive. Have you found yourselves customizing it or deviating from it to meet the particular needs of your company?
A5: We try to follow the practices from SAFe as closely as possible. SAFe 4.0 scales really well to whatever size your organization is. We have allowed a few small customizations for simplification reasons though.
Q6: How many teams started on your first Program Increment and did more come on later?
A6: We work within a single Agile Release Train (ART) in a single value stream comprised of about 10 teams. This has not changed much since we began.
Q7: How do you incorporate year-long planning into this model, or are you only defining roadmap quarter to quarter?
A7: SAFe does not have a model for year long planning per-se. You create and communicate your objective after Program Increment Planning for a single PI (which is roughly 5-6 two week sprints for us). Beyond that we use the Epics in our Portfolio Backlog to define “Targeted” Features that will be probably be in the next PI, which allows for prioritization conversation to occur as far as 5-6 months out.
Q8: What were the costs/benefits of moving to a common definition of story points?
A8: The benefits are that you begin to understand the velocity of your entire ART. Understanding how much 10 teams can accomplish becomes a powerful tool for increasing predictability, and forces prioritization conversations with the business.
Q9: Do you have a dedicated product owner per team? If not, what is the allocation?
A9: We have dedicated Product Owners per team. A Product Owner though could have up to 2 teams.
Q10: What are some of the big pain points that you still experience despite your efforts and progress?
A10: Things definitely go more smoothly and predictably when we can implement Lean principles within our delivery streams. There are a small number of areas where we still need to segment out full acceptance testing beyond the sprint where features are implemented. We are focusing on bringing the acceptance testing fully into the sprint for all of our teams and components. We are still improving ways to manage capacity across teams when we face major scope discovery or changes in developer availability. We are looking for the best ways to foster cross-team communication without adding additional standing meetings for everyone.
Put it into practice
Get serious about agile ceremonies
Visualize your backlog, burndown, and flow. It's the best thing to happen to meetings since the donut. Explore JIRA Software
Coming up next
The Agile Coach
Our no-nonsense guide to making software better. Keep reading
On a related note...
"Have we met?"
Some people think holding the right meetings are what make a team agile. They're wrong. Keep reading