Business agility

transcript

Agile 101What is Business Agility?

Wednesday, June 15, 2011

An Idea!

An Idea...

...you’ve been paid for!

What is Business Agility?

generatingthe idea

validation that the idea is a good one

getting paidfor that idea

developingthe idea

What is Business Agility?

generatingthe idea

developingthe idea

BUSINESS AGILITY = OPTIMIZE THIS PROCESS!

Where Does “Agile” Fit In?

generatingthe idea

developingthe idea

generatingthe idea

developingthe idea

People

ValuesPrinciplesExcellenceDiscipline

generatingthe idea

developingthe idea

Process

ScrumXP

LeanKanban

People

generatingthe idea

developingthe idea

Process

ScrumXP

LeanKanban

Technical

TDDPair Programming

RefactoringTest Automation

People

generatingthe idea

developingthe idea

Process

ScrumXP

LeanKanban

Technical

TDDPair Programming

RefactoringTest Automation

People

not enough!

Agile Origins

Deming TPS “Scrum”

1994 1996

AgileManifesto

194820s+

Agile Origins

1994 1996

AgileManifesto

194820s+

Individuals and Interactions over Processes and Tools

Agile Origins

1994 1996

AgileManifesto

194820s+

Individuals and Interactions over Processes and ToolsWorking Software over Comprehensive Documentation

Agile Origins

1994 1996

AgileManifesto

194820s+

Customer Collaboration over Contract Negotiation

Agile Origins

1994 1996

AgileManifesto

194820s+

Customer Collaboration over Contract NegotiationResponding to Change over Following a Plan

Agile Origins

1994 1996

AgileManifesto

194820s+

Customer Collaboration over Contract NegotiationResponding to Change over Following a Plan

“while there is value in the statements on the right, we value the statements on the left more”

What’s the Difference?

Analysis Design Build Test Release

6 month traditional or “waterfall” project

6 month Agile project using Scrum/XP or Iterative process (2 Week Sprints)

Sprint 1 Sprint 2(1 month)

Sprint 3

releaseand

feedback!

Sprint 4(2 months)

Future Sprints

6 month Agile project using Scrum/XP or Iterative process (2 Week Sprints)

Sprint 1 Sprint 2(1 month)

Sprint 3

releaseand

feedback!

Sprint 4(2 months)

Future Sprints

Benefits:- release working software earlier- validate your idea is worth money earlier- get the software in the hands of real users earlier- no phases or handoffs, use cross-functional teams- do ‘just enough’ planning to get started

Scrum Process Model

How Are Companies Getting Agile?

Scrum- simple, open and pour

XP Practices- need more skill & precision

Lean/Kanban- need the basics first

Why Adopt Agile?*

Top 3 Reasons for Adopting Agile:37% cite faster time to market as the reason

36% cite enhancing ability to manage priorities27% cite increased productivity

Bottom 3 Reasons:10% Reduce Cost/Improve Morale8% Improve Engineering Discipline

5% Manage Distributed Teams

* Version One 2010 Agile Survey (5th Year)

Why Agile Adoption is Failing*

Top 3 Reasons for Failure51% cite in-ability to change Org Culture

40% General Resistance to Change/Lack of Agile Skills34% Management Support

Bottom 3 Reasons:16% Perceived Time to Transition

13% Budget Constraints12% None

* Version One 2010 Agile Survey (5th Year)

Agile War StoriesWednesday, June 15, 2011

1 – Start-Up in TurmoilSituation•CTO Fired, New CEO, CTO, Director of Dev•$24M VC money invested•Six year old company•Mature product

Objective for Agile Implementation•Unclear problem definition•Unclear objectives•Belief that the process would save the day

1 – Start-Up in TurmoilActions•Implemented Agile (XP)•No Agile consultants•No training•No software to support the process•Executive support (sort of)•One set of story cards held by the director

1 – Start-Up in TurmoilResults•Weak management buy-in•Weak team buy-in•XP abandoned within four months•Returned to previous chaotic approach (entropy)

1 – Start-Up in TurmoilAnalysis•Depended on heroics of individuals•Project(s) succeeded – neither because of, or in spite of agile•Agile is not the cure for cultural, management and organizational problems•Management buy-in critical•Don’t blame the developers

2 – Start-Up in TurmoilSituation•Very early stage (pre-commercialization)•CTO fired•Weak, ineffective, geographically dispersed team•Project very much behind, and off target•Huge pressures to deliver before the money ran out

2 – Start-Up in TurmoilObjectives•Unclear objectives other than “get it done as quickly as possible”•Unclear definition of the problems•Belief that the process would fix the problems and make development quicker

2 – Start-Up in TurmoilAction•Implemented Agile (Scrum) in a very lightweight fashion•Brand new team (A players)•No Agile consultants•No training•No software to support the process•Executive support (sort of)•Daily Scrum calls

2 – Start-Up in TurmoilResults•Maintained the very lightweight Agile process•Achieved all project results•Management used the notion of Agile as an excuse for chaotic injections of new and changing requirements into the flow•Management did not respect the process and used inappropriate comparisons/metrics

2 – Start-Up in TurmoilAnalysis•Project(s) succeeded because of heroics – not because of, or in spite of agile•Agile is not a cure for a weak team, poor management, poor planning and lack of clear objectives

3. Established Small CompanySituation•Scrum already in place•Recent corporate split into two separate entities (reshaping of business)•Went through 75% downsizing - Outgoing Dev Manager•Software tools already in place (Rally Dev)•Established products but Small customer base•Losing market share because of out-dated products and more competition•Process had become rigid, not driven by the development team•Overbearing CEO who constantly interfered and overruled team decisions

3. Established Small CompanyObjectives•Belief that the process would fix the problems and make development faster•CEO a process wonk (Hidden Agenda)–Process was the objective, not a tool, but did not fully support Agile

3. Established Small CompanyAction•Implemented Agile (Scrum) in a very light fashion because of team reductions•Some training•Executive support (sort of)•Daily Scrums•Sprints•Retrospectives

3. Established Small CompanyResults–Ruthless adherence to the schedule by CEO (Process was the stick)–Process became the mechanism for control and the excuse for interference–CEO overruled almost every team decision–Met all development objectives–CEO abandoned the project and implemented his vision. That project was more than a year late

3. Established Small CompanyAnalysis•Process (Agile) is not to be used as a stick•To be effective, Agile must involve the team in decisions

4. Start-Up (Two Years Old)

Situation•Good people in the organization but revolving door•Overbearing CEO who constantly interfered and overruled team decisions •Recent launch of first product•Excellent development team•No process•CEO’s idea du jour•Constant pivots and reorganization of priorities by CEO•25 products and projects and only five developers

Objectives•Make the team faster•Demonstrate to potential investors that there was an effective process•Shield development team from CEO (team)•Establish priorities (team)•Team autonomy (team)•Huge pressures to produce as quickly as possible•Belief that the process would fix the problems and make development faster

Action•Implemented Agile (Scrum) •Got training for the entire team•Story cards•Story boards around the office (high visibility)•Daily Scrums•Sprints•Retrospectives

Results•Overall – very successful•Significant and very public buy-in from CEO•Significant team buy-in•Visibility of the process helped CEO understand why he couldn’t have everything all at once•Able to contain the CEO•Targets were defined, negotiated and achieved•Team much happier and more effective•Process adopted across the company

Analysis•Agile can be very successful•Openness of the process was important•Public buy-in of CEO was critical

Agile War Story Summary•Will not fix a broken organization• Agile is not a big stick for control of a team• Executive support is essential• Team must benefit• Process must be transparent• Process must be inclusive• Software tools are not needed – menu cards work fine• Get training

Where Can You Start?

Understand:- the reasons you want to use Agile. What’s your business goal?- your culture, organization structure and the people in your organization.- it’s hard, you will need to learn a lot!- “metrics” are the wrong thing to start with!- you cannot ‘measure’ Agile success in any other term other than business outcomes.

Educate:- find local Agile User Groups/Events (XP Toronto, Agile Toronto Tour)- read some books (Succeeding with Agile by Mike Cohn, Implementing Lean Software Development by Mary/Tom Poppendieck- get training (certification is less important than learning something!)- hire a consultant

Reflect:- figure out what to measure, measure it and adjust- do retrospectives across all Organizational levels- is the Agile implementation strategy you picked working?

Thank You!• Michael Lant, CTO @ ENC Security Systems

( www.michaellant.com)• Jason Little, Product Owner/Agile Coach @

Q4 Web Systems ( www.agilecoach.ca )

• look for a blog post on SiliconHalton.com!

Business agility

Technology