experiences on scaling agile

26
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

Upload: jens-wilke

Post on 07-Aug-2015

187 views

Category:

Software


2 download

TRANSCRIPT

Page 1: Experiences on scaling agile

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

Page 2: Experiences on scaling agile

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

Page 3: Experiences on scaling agile

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

Page 4: Experiences on scaling agile

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

Page 5: Experiences on scaling agile

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

Page 6: Experiences on scaling agile

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

Page 7: Experiences on scaling agile

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

Page 8: Experiences on scaling agile

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

Page 9: Experiences on scaling agile

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

Page 10: Experiences on scaling agile

2 Process from strategy to the team backlogs

Jens Wilke, LangFox, www.langfox.com

Page 11: Experiences on scaling agile

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

Page 12: Experiences on scaling agile

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

Page 13: Experiences on scaling agile

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

Page 14: Experiences on scaling agile

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

Page 15: Experiences on scaling agile

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

Page 16: Experiences on scaling agile

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

Page 17: Experiences on scaling agile

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

Page 18: Experiences on scaling agile

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

Page 19: Experiences on scaling agile

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

Page 20: Experiences on scaling agile

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

Page 21: Experiences on scaling agile

4 (Single) tool for shared views and KPIs

Jens Wilke, LangFox, www.langfox.com

Page 22: Experiences on scaling agile

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

Page 23: Experiences on scaling agile

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

Page 24: Experiences on scaling agile

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

Page 25: Experiences on scaling agile

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

Page 26: Experiences on scaling agile

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