The document discusses scaling agile processes across multiple teams and levels from strategy to implementation. It recommends using Kanban at the strategic level for flow management and Scrum at the team level for detailed planning. The program level in between uses Kanban to coordinate epics from strategy to the team backlogs. Regular strategy and product days are suggested to align stakeholders. A single tool is proposed to provide transparency of plans, progress, and dependencies across all levels.
Innovate and Collaborate- Harnessing the Power of Open Source Software.pdf
Scaling Agile from Strategy to Teams
1. Experiences on scaling agile Jens Wilke, LangFox, www.langfox.com
Index
–Changing team structure as scale evolves
–Process from strategy to team level work
–Strategy and product days
–(Single) tool for shared understanding and KPI performance
Jens Wilke, LangFox, www.langfox.com
2. 0 Targets
•Clear process for company strategy to guide the actual work done by the teams
•Transparency regarding the work planned, progress and dependencies
•Clear roles and ownership
Jens Wilke, LangFox, www.langfox.com
3. 1 Scaling the team structures
•Organizations scaling from very small to big. Following slides show some models that I have seen functioning in practice.
Jens Wilke, LangFox, www.langfox.com
4. Assumptions regarding the work
•A software project or projects in dynamic market situation. Effective and agile throughput matching the customer needs is assumed to be the top priority.
Jens Wilke, LangFox, www.langfox.com
5. From very small (1-4 persons)
•With a very small team Kanban is great, due to it‘s low overhead. In a small team, communication can be effective through frequent brief meetings.
•As team size grows, the Kanban process can be scaled towards scrum
Kanban
Team
Jens Wilke, LangFox, www.langfox.com
6. To quite small (5-9 persons)
•Scrum teams typically are sized between 5 and 9 persons. Throughput per head is reduced, as the team size grows, and too big teams should be avoided.
Scrum Team
Graph from: Succeeding with Agile, Mike Cohn
Jens Wilke, LangFox, www.langfox.com
7. Jens Wilke, LangFox, www.langfox.com
To multiple teams (10+)
•As team size grows, the team should be split to multiple teams. If there are dependencies, they can be managed through (1) shared backlog visibilities and (2) scrum of scrums. Each backlog should have single master owner for avoiding stalemates.
Scrum
Team
Scrum Team
PO
SM
SM
PO
Program/Strategic level backlog, e.g. Big features or epics
Scrum of scrums
8. Jens Wilke, LangFox, www.langfox.com
To multiple teams, bigger (20+)
•Larger amount of domains with dependencies needs some coordinating entity between them, e.g. Program manager. It is not mandatory to have same agile model in all teams.
Scrum
Team
Scrum
Team
SM
SM
PO
Program Manager/ Team
Kanban
Team
PO
Scrum
Team
SM
PO
9. Jens Wilke, LangFox, www.langfox.com
Larger organizations (50+)
•Larger organizations can have more entities, e.g. for strategic planning.
Scrum
Team
Scrum Team
SM
SM
PO
Program Manager/ Team
Kanban
Team
PO
Scrum
Team
SM
PO
Program Manager/ Team
Scrum Team
SM
PO
Portfolio Team
Strategy Team
10. 2 Process from strategy to the team backlogs
Jens Wilke, LangFox, www.langfox.com
11. Assumptions
•Regarding the process scale, I‘m assuming a 3 level, that would suitable for medium and large scale software development. These tiers are
1.Strategy
2.Program
3.Team
Jens Wilke, LangFox, www.langfox.com
12. Team level
•If teams are working with Scrum, they should also use the Scrum process for managing their work. This works, as the progress is quite foreseeable, and can be effectively planned. Planning happens on detailed level.
Tier 1 – Strategic level
Tier 2 – Program level
Tier 3 - Team level: Scrum
Jens Wilke, LangFox, www.langfox.com
13. Strategic level
•On strategic level, short sprints are not meaningful, and Kanban is more effective for managing the flow. On this level, backlog consists of highest level epics.
Tier 1 – Strategic level: Kanban
Tier 2 – Program level: Kanban
Tier 3 - Team level: Scrum
Jens Wilke, LangFox, www.langfox.com
14. Jens Wilke, LangFox, www.langfox.com
Program level
•On program level (above team level), the predictability is not good enough, e.g. planning 2 weeks sprints would not make sense. Kanban is the choice for managing the flow. Tight co- operation with team level.
Tier 1 – Strategic level
Tier 2 – Program level: Kanban
Tier 3 - Team level: Scrum
15. Jens Wilke, LangFox, www.langfox.com
Flow from strategy to team work
•The company product vision and strategy should guide the work. Strategy is reflected by the strategic epics on the highest level. Program level adds enough detail for effective planning and Team level adds needed detail for the implementation.
Tier 1 – Strategic level: Kanban
Tier 2 – Program level: Kanban
Tier 3 - Team level: Scrum
16. Process example in practice
•Case: Strategy update
•Strategy team updates the strategy and strategic epics. This update is then discussed with program level, so that the impact to planned epics becomes clear to all parties involved. For example, prioritizing a new strategic epic will delay an epic in implementation. Thus from strategic level work is pulled (per Kanban) to Program leven and from there it goes to implementation by the Scrum teams.
Jens Wilke, LangFox, www.langfox.com
17. Jens Wilke, LangFox, www.langfox.com
Example of the 3 levels in the form of a Kanban board.
•Described process shown as Kanban table. Strategic and Program levels manage the flow of items. Team level adds the details and builds using Scrum.
•Work in progress (wip) limits highlight the fact that on all levels there should not be too much work in single phase. Could be useful.
Tier 1: Strategy
Tier 2: Program
Tier 3: Team
18. 3 Regular strategy and product days
•The teams usually have great understanding regarding the market
•The planning process should be 2 way process, and not just a flow from top down
•One way to regularly bring all the relevant stakeholders together are regular events. For example:
–Bi-annual strategy days
–Quarterly product days
Jens Wilke, LangFox, www.langfox.com
19. Strategy day
•Business environment update
–Where we are
–Where is the market going, and where will we be there
•Vision and strategy update
–Any new strategic level items planned
–Feedback
•Possibly workshop with program and team on relevant topics
–Note that strategic level updates can be updated any time. Then triggering the more detailed planning with program and team levels (no need to wait for strategy day)
•Precede product day, so that the strategy changes can be taken into account in product planning
Jens Wilke, LangFox, www.langfox.com
20. Product day
•Update by teams (short)
–Plans
–Actual progress vs. plans
–Product specific competitive environment news
•Portfolio/big picture update
–How everything comes together
•Sales and marketing update
–Sales usually has a good touch on the market sentiment
–Sales and marketing feedback
Jens Wilke, LangFox, www.langfox.com
21. 4 (Single) tool for shared views and KPIs
Jens Wilke, LangFox, www.langfox.com
22. Transparency all ways
•The plans and progress should be clear to all parties. This includes:
1.Plan visibility on all 3 levels
2.Transparency on progress
3.Clear dependencies
Jens Wilke, LangFox, www.langfox.com
23. Jens Wilke, LangFox, www.langfox.com
Plan visibility on all 3 levels
•Teams below strategic tier, can see what has been planned well into the future
•From the strategic level, it‘s broken down to smaller items for program level planning and team level implementation.
•There should be a mapping from the team level items to the strategic level, so that team level progress can be effectively seen on strategic level.
•Detailed team level planning does not reach far to the future.
Tier 1: Strategy
Tier 2: Program
Tier 3: Team level
Q1
Q2
Q3
24. Transparency on progress
•Selected tool should enable seeing progress on all levels, as progress is being made.
Tier 1: Strategy
Tier 2: Program
Tier 3: Team
Jens Wilke, LangFox, www.langfox.com
25. Clear dependencies
•Most top level items require the work of multiple teams
•Higher level items need then map to multiple teams, so that dependencies become clear on all levels
•Possible issues are identifiable and can be effectively managed.
Tier 3: Team A
Tier 3: Team B
Strategy level epic
Jens Wilke, LangFox, www.langfox.com
26. 5 Summary
•Agile process should span all the way from strategic planning to the work done by teams
•Clear ownership on all levels
•Teamwork for best possible plans and effective implementation
•Transparency throughout all the levels will make the planning and work more effective
•On further note, VersionOne and Rally have some great webinars on this topic
Jens Wilke, LangFox, www.langfox.com