Business agility

2,317 views
2,114 views

Published on

Business Agility is optimizing the process from the time you have an idea to the time you've been paid for it. It's like combining Lean Startup with Agile. I gave this presentation at Sheridan College for Silicon Halton with Michael Lant in May 2011.

Published in: Technology

Business agility

  1. 1. Agile 101 What is Business Agility?Wednesday, June 15, 2011
  2. 2. Wednesday, June 15, 2011
  3. 3. An Idea!Wednesday, June 15, 2011
  4. 4. An Idea...Wednesday, June 15, 2011
  5. 5. An Idea... ...you’ve been paid for!Wednesday, June 15, 2011
  6. 6. What is Business Agility? generating validation that the developing getting paid the idea idea is a good one the idea for that ideaWednesday, June 15, 2011
  7. 7. What is Business Agility? generating validation that the developing getting paid the idea idea is a good one the idea for that idea BUSINESS AGILITY = OPTIMIZE THIS PROCESS!Wednesday, June 15, 2011
  8. 8. Where Does “Agile” Fit In? generating validation that the developing getting paid the idea idea is a good one the idea for that ideaWednesday, June 15, 2011
  9. 9. Where Does “Agile” Fit In? generating validation that the developing getting paid the idea idea is a good one the idea for that idea People Values Principles Excellence DisciplineWednesday, June 15, 2011
  10. 10. Where Does “Agile” Fit In? generating validation that the developing getting paid the idea idea is a good one the idea for that idea People Process Values Scrum Principles XP Excellence Lean Discipline KanbanWednesday, June 15, 2011
  11. 11. Where Does “Agile” Fit In? generating validation that the developing getting paid the idea idea is a good one the idea for that idea People Process Technical Values Scrum TDD Principles XP Pair Programming Excellence Lean Refactoring Discipline Kanban Test AutomationWednesday, June 15, 2011
  12. 12. Where Does “Agile” Fit In? generating validation that the developing getting paid the idea idea is a good one the idea for that idea People Process Technical Values Scrum TDD Principles XP Pair Programming Excellence Lean Refactoring Discipline Kanban Test Automation not enough!Wednesday, June 15, 2011
  13. 13. Agile Origins Agile Deming TPS “Scrum” Scrum XP Manifesto 20s+ 1948 1986 1994 1996 2001Wednesday, June 15, 2011
  14. 14. Agile Origins Agile Deming TPS “Scrum” Scrum XP Manifesto 20s+ 1948 1986 1994 1996 2001 Individuals and Interactions over Processes and ToolsWednesday, June 15, 2011
  15. 15. Agile Origins Agile Deming TPS “Scrum” Scrum XP Manifesto 20s+ 1948 1986 1994 1996 2001 Individuals and Interactions over Processes and Tools Working Software over Comprehensive DocumentationWednesday, June 15, 2011
  16. 16. Agile Origins Agile Deming TPS “Scrum” Scrum XP Manifesto 20s+ 1948 1986 1994 1996 2001 Individuals and Interactions over Processes and Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract NegotiationWednesday, June 15, 2011
  17. 17. Agile Origins Agile Deming TPS “Scrum” Scrum XP Manifesto 20s+ 1948 1986 1994 1996 2001 Individuals and Interactions over Processes and Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to Change over Following a PlanWednesday, June 15, 2011
  18. 18. Agile Origins Agile Deming TPS “Scrum” Scrum XP Manifesto 20s+ 1948 1986 1994 1996 2001 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”Wednesday, June 15, 2011
  19. 19. What’s the Difference? Analysis Design Build Test Release 6 month traditional or “waterfall” projectWednesday, June 15, 2011
  20. 20. What’s the Difference? Analysis Design Build Test Release 6 month traditional or “waterfall” project A A A A D D D release D Future B B and B Sprints B feedback! T T T T Sprint 2 Sprint 4 Sprint 1 Sprint 3 (2 months) (1 month) 6 month Agile project using Scrum/XP or Iterative process (2 Week Sprints)Wednesday, June 15, 2011
  21. 21. What’s the Difference? Analysis Design Build Test Release 6 month traditional or “waterfall” project A A A A Benefits: - release working software earlier D D - validate your idea is worth D release D money earlier - get the software in the hands of Future B B and B Sprints real users earlier - no phases or handoffs, use cross- B feedback! functional teams - do ‘just enough’ planning to get T T T T started Sprint 2 Sprint 4 Sprint 1 Sprint 3 (2 months) (1 month) 6 month Agile project using Scrum/XP or Iterative process (2 Week Sprints)Wednesday, June 15, 2011
  22. 22. Scrum Process ModelWednesday, June 15, 2011
  23. 23. How Are Companies Getting Agile? Scrum - simple, open and pourWednesday, June 15, 2011
  24. 24. How Are Companies Getting Agile? Scrum - simple, open and pour XP Practices - need more skill & precisionWednesday, June 15, 2011
  25. 25. How Are Companies Getting Agile? Scrum - simple, open and pour XP Practices - need more skill & precision Lean/Kanban - need the basics firstWednesday, June 15, 2011
  26. 26. 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)Wednesday, June 15, 2011
  27. 27. 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) 11Wednesday, June 15, 2011
  28. 28. Agile War StoriesWednesday, June 15, 2011
  29. 29. 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 definition •Unclear objectives •Belief that the process would save the dayWednesday, June 15, 2011
  30. 30. 1 – Start-Up in Turmoil 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 directorWednesday, June 15, 2011
  31. 31. 1 – Start-Up in Turmoil Results •Weak management buy-in •Weak team buy-in •XP abandoned within four months •Returned to previous chaotic approach (entropy)Wednesday, June 15, 2011
  32. 32. 1 – Start-Up in Turmoil 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 •Don’t blame the developersWednesday, June 15, 2011
  33. 33. 2 – Start-Up in Turmoil Situation •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 outWednesday, June 15, 2011
  34. 34. 2 – Start-Up in Turmoil Objectives •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 quickerWednesday, June 15, 2011
  35. 35. 2 – Start-Up in Turmoil 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 callsWednesday, June 15, 2011
  36. 36. 2 – Start-Up in Turmoil 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 flow •Management did not respect the process and used inappropriate comparisons/ metricsWednesday, June 15, 2011
  37. 37. 2 – Start-Up in Turmoil 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 objectivesWednesday, June 15, 2011
  38. 38. 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 decisionsWednesday, June 15, 2011
  39. 39. 3. Established Small Company Objectives •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 AgileWednesday, June 15, 2011
  40. 40. 3. Established Small Company Action •Implemented Agile (Scrum) in a very light fashion because of team reductions •Some training •Executive support (sort of) •Daily Scrums •Sprints •RetrospectivesWednesday, June 15, 2011
  41. 41. 3. Established Small Company 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 lateWednesday, June 15, 2011
  42. 42. 3. Established Small Company Analysis •Process (Agile) is not to be used as a stick •To be effective, Agile must involve the team in decisionsWednesday, June 15, 2011
  43. 43. 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 developersWednesday, June 15, 2011
  44. 44. 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 fasterWednesday, June 15, 2011
  45. 45. 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 •RetrospectivesWednesday, June 15, 2011
  46. 46. 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 companyWednesday, June 15, 2011
  47. 47. 4. Start-Up (Two Years Old) Analysis •Agile can be very successful •Openness of the process was important •Public buy-in of CEO was criticalWednesday, June 15, 2011
  48. 48. 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 trainingWednesday, June 15, 2011
  49. 49. 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? 33Wednesday, June 15, 2011
  50. 50. 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! 34Wednesday, June 15, 2011

×