Experiences on scaling agile
1 like999 views
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.
Experiences on scaling agile
- 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