Agile 101What is Business Agility?
Wednesday, June 15, 2011
Wednesday, June 15, 2011
An Idea!
Wednesday, June 15, 2011
An Idea...
Wednesday, June 15, 2011
An Idea...
...you’ve been paid for!
Wednesday, June 15, 2011
What is Business Agility?
generatingthe idea
validation that the idea is a good one
getting paidfor that idea
developingthe idea
Wednesday, June 15, 2011
What is Business Agility?
generatingthe idea
validation that the idea is a good one
getting paidfor that idea
developingthe idea
BUSINESS AGILITY = OPTIMIZE THIS PROCESS!
Wednesday, June 15, 2011
Where Does “Agile” Fit In?
generatingthe idea
validation that the idea is a good one
getting paidfor that idea
developingthe idea
Wednesday, June 15, 2011
Where Does “Agile” Fit In?
generatingthe idea
validation that the idea is a good one
getting paidfor that idea
developingthe idea
People
ValuesPrinciplesExcellenceDiscipline
Wednesday, June 15, 2011
Where Does “Agile” Fit In?
generatingthe idea
validation that the idea is a good one
getting paidfor that idea
developingthe idea
Process
ScrumXP
LeanKanban
People
ValuesPrinciplesExcellenceDiscipline
Wednesday, June 15, 2011
Where Does “Agile” Fit In?
generatingthe idea
validation that the idea is a good one
getting paidfor that idea
developingthe idea
Process
ScrumXP
LeanKanban
Technical
TDDPair Programming
RefactoringTest Automation
People
ValuesPrinciplesExcellenceDiscipline
Wednesday, June 15, 2011
Where Does “Agile” Fit In?
generatingthe idea
validation that the idea is a good one
getting paidfor that idea
developingthe idea
Process
ScrumXP
LeanKanban
Technical
TDDPair Programming
RefactoringTest Automation
People
ValuesPrinciplesExcellenceDiscipline
not enough!
Wednesday, June 15, 2011
Agile Origins
Deming TPS “Scrum”
1986
Scrum
1994 1996
XP
2001
AgileManifesto
194820s+
Wednesday, June 15, 2011
Agile Origins
Deming TPS “Scrum”
1986
Scrum
1994 1996
XP
2001
AgileManifesto
194820s+
Individuals and Interactions over Processes and Tools
Wednesday, June 15, 2011
Agile Origins
Deming TPS “Scrum”
1986
Scrum
1994 1996
XP
2001
AgileManifesto
194820s+
Individuals and Interactions over Processes and ToolsWorking Software over Comprehensive Documentation
Wednesday, June 15, 2011
Agile Origins
Deming TPS “Scrum”
1986
Scrum
1994 1996
XP
2001
AgileManifesto
194820s+
Individuals and Interactions over Processes and ToolsWorking Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation
Wednesday, June 15, 2011
Agile Origins
Deming TPS “Scrum”
1986
Scrum
1994 1996
XP
2001
AgileManifesto
194820s+
Individuals and Interactions over Processes and ToolsWorking Software over Comprehensive Documentation
Customer Collaboration over Contract NegotiationResponding to Change over Following a Plan
Wednesday, June 15, 2011
Agile Origins
Deming TPS “Scrum”
1986
Scrum
1994 1996
XP
2001
AgileManifesto
194820s+
Individuals and Interactions over Processes and ToolsWorking Software over Comprehensive Documentation
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”
Wednesday, June 15, 2011
What’s the Difference?
Analysis Design Build Test Release
6 month traditional or “waterfall” project
Wednesday, June 15, 2011
A
D
B
T
6 month Agile project using Scrum/XP or Iterative process (2 Week Sprints)
Sprint 1 Sprint 2(1 month)
A
D
B
T
Sprint 3
A
D
B
T
releaseand
feedback!
Sprint 4(2 months)
A
D
B
T
Future Sprints
What’s the Difference?
Analysis Design Build Test Release
6 month traditional or “waterfall” project
Wednesday, June 15, 2011
A
D
B
T
6 month Agile project using Scrum/XP or Iterative process (2 Week Sprints)
Sprint 1 Sprint 2(1 month)
A
D
B
T
Sprint 3
A
D
B
T
releaseand
feedback!
Sprint 4(2 months)
A
D
B
T
Future Sprints
What’s the Difference?
Analysis Design Build Test Release
6 month traditional or “waterfall” project
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
Wednesday, June 15, 2011
Scrum Process Model
Wednesday, June 15, 2011
How Are Companies Getting Agile?
Scrum- simple, open and pour
Wednesday, June 15, 2011
How Are Companies Getting Agile?
Scrum- simple, open and pour
XP Practices- need more skill & precision
Wednesday, June 15, 2011
How Are Companies Getting Agile?
Scrum- simple, open and pour
XP Practices- need more skill & precision
Lean/Kanban- need the basics first
Wednesday, June 15, 2011
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)
Wednesday, June 15, 2011
11
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)
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
1 – Start-Up in TurmoilResults•Weak management buy-in•Weak team buy-in•XP abandoned within four months•Returned to previous chaotic approach (entropy)
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
3. Established Small CompanyAnalysis•Process (Agile) is not to be used as a stick•To be effective, Agile must involve the team in decisions
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
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 fix the problems and make development faster
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
4. Start-Up (Two Years Old)
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
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
33
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?
Wednesday, June 15, 2011
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
Wednesday, June 15, 2011
Top Related