Scaling Agile from Strategy to Teams

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

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

1 Scaling the team structures
•Organizations scaling from very small to big. Following slides show some models that I have seen functioning in practice.

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.

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

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

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

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

Larger organizations (50+)
•Larger organizations can have more entities, e.g. for strategic planning.
Scrum
Team
Scrum Team
SM
SM
PO
Kanban
Team
PO
Scrum
Team
SM
PO
Scrum Team
SM
PO
Portfolio Team
Strategy Team

2 Process from strategy to the team backlogs

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

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

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

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

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

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.

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

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

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

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

4 (Single) tool for shared views and KPIs

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

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

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

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

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

Scaling Agile from Strategy to Teams

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a Scaling Agile from Strategy to Teams

Similar a Scaling Agile from Strategy to Teams (20)

Último

Último (20)

Scaling Agile from Strategy to Teams