Business Agility

Agile 101
What is Business Agility?
Wednesday, June 15, 2011
An Idea!
An Idea...
An Idea...
...youve been paid for!

generating the idea validation that the idea is a good one developing the idea getting paid for that idea

BUSINESS AGILITY = OPTIMIZE THIS PROCESS!
Where Does Agile Fit In?


People Values Principles Excellence Discipline

Process Scrum XP Lean Kanban

Process Scrum XP Lean Kanban
Technical TDD Pair Programming Refactoring Test Automation

Process Scrum XP Lean Kanban not enough!
Technical TDD Pair Programming Refactoring Test Automation
Agile Origins
Deming 20s+ TPS 1948 Scrum 1986 Scrum 1994 XP 1996 Agile Manifesto 2001
Agile Origins
Individuals and Interactions over Processes and Tools
Agile Origins
Individuals and Interactions over Processes and Tools Working Software over Comprehensive Documentation
Agile Origins
Individuals and Interactions over Processes and Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation
Agile Origins
Individuals and Interactions over Processes and Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan
Agile Origins
Individuals and Interactions over Processes and Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan
while there is value in the statements on the right, we value the statements on the left more
Whats the Difference?

Analysis Design Build Test Release
6 month traditional or waterfall project

6 month traditional or waterfall project A D B T

Sprint 3
A D B T
Sprint 1
A D B T
Sprint 2 (1 month)
release and feedback!
D B T
Sprint 4 (2 months) Future Sprints
6 month Agile project using Scrum/XP or Iterative process (2 Week Sprints)


6 month traditional or waterfall project A D B T

Sprint 3
A D B T
Sprint 1
A D B T
Sprint 2 (1 month)
release and feedback!
D B T
Sprint 4 (2 months) Future Sprints
Benets: - 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 crossfunctional teams - do just enough planning to get started
6 month Agile project using Scrum/XP or Iterative process (2 Week Sprints)

Scrum Process Model
How Are Companies Getting Agile? Scrum - simple, open and pour
How Are Companies Getting Agile? Scrum - simple, open and pour XP Practices - need more skill & precision
How Are Companies Getting Agile? Scrum - simple, open and pour XP Practices - need more skill & precision Lean/Kanban - need the basics rst
Why Adopt Agile?*
Top 3 Reasons for Adopting Agile: 37% cite faster time to market as the reason 36% cite enhancing ability to manage priorities 27% cite increased productivity Bottom 3 Reasons: 10% Reduce Cost/Improve Morale 8% Improve Engineering Discipline 5% Manage Distributed Teams
* Version One 2010 Agile Survey (5th Year)

Why Agile Adoption is Failing*
Top 3 Reasons for Failure 51% cite in-ability to change Org Culture 40% General Resistance to Change/Lack of Agile Skills 34% Management Support Bottom 3 Reasons: 16% Perceived Time to Transition 13% Budget Constraints 12% None
* Version One 2010 Agile Survey (5th Year)

11
Agile War Stories

1 Start-Up in Turmoil
Situation CTO Fired, New CEO, CTO, Director of Dev $24M VC money invested Six year old company Mature product Objective for Agile Implementation Unclear problem denition Unclear objectives Belief that the process would save the day
Actions 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
Results Weak management buy-in Weak team buy-in XP abandoned within four months Returned to previous chaotic approach (entropy)
Analysis 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 Dont blame the developers
Situation Very early stage (pre-commercialization) CTO red Weak, ineffective, geographically dispersed team Project very much behind, and off target Huge pressures to deliver before the money ran out
Objectives Unclear objectives other than get it done as quickly as possible Unclear denition of the problems Belief that the process would x the problems and make development quicker
Action 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
Results 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 ow Management did not respect the process and used inappropriate comparisons/ metrics
Analysis 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 Company

Situation 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

Objectives Belief that the process would x 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

Action Implemented Agile (Scrum) in a very light fashion because of team reductions Some training Executive support (sort of) Daily Scrums Sprints Retrospectives

Results
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

Analysis 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 rst product Excellent development team No process CEOs idea du jour Constant pivots and reorganization of priorities by CEO 25 products and projects and only ve developers
4. Start-Up
(Two Years Old)
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 x the problems and make development faster
4. Start-Up
(Two Years Old)
Action Implemented Agile (Scrum) Got training for the entire team Story cards Story boards around the office (high visibility) Daily Scrums Sprints Retrospectives
4. Start-Up
(Two Years Old)
Results Overall very successful Signicant and very public buy-in from CEO Signicant team buy-in Visibility of the process helped CEO understand why he couldnt have everything all at once Able to contain the CEO Targets were dened, negotiated and achieved Team much happier and more effective Process adopted across the company
4. Start-Up
(Two Years Old)
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 x a broken organization Agile is not a big stick for control of a team Executive support is essential Team must benet Process must be transparent Process must be inclusive Software tools are not needed menu cards work ne Get training
Where Can You Start?

Understand: - the reasons you want to use Agile. Whats your business goal? - your culture, organization structure and the people in your organization. - its 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: - nd 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 (certication is less important than learning something!) - hire a consultant Reect: - gure out what to measure, measure it and adjust - do retrospectives across all Organizational levels - is the Agile implementation strategy you picked working?
33
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!
34

Business Agility

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Business Agility

Uploaded by

Copyright:

Available Formats

Agile 101

What is Business Agility?

Wednesday, June 15, 2011

Wednesday, June 15, 2011

Wednesday, June 15, 2011

Wednesday, June 15, 2011

...youve been paid for!

Wednesday, June 15, 2011

What is Business Agility?

Wednesday, June 15, 2011

What is Business Agility?