Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile adoption tales from the coalface

This talk discusses how to fail with an Agile change transformation, and lays out some practical tips for successfully adopting agile software delivery processes within your organisation. Presented at Telstra, Superpartners, and several Meetups.

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

Agile adoption tales from the coalface

  1. 1. Agile Adoption Tales from the Coalface By Nish Mahanty
  2. 2. Agenda• The 5 preconditions for success• Understand the problem you are solving• Use Agile as a risk mitigation approach for projects• An Agile Adoption Parable
  3. 3. There are certain preconditions thatyou need in place in order to succeedYou’re more likely to fail if you don’t have them
  4. 4. A BIG SponsorStrong, committed, present,
  5. 5. Show me the money!
  6. 6. A Critical EventWhen it gets painful, you want to remind them of when it was even more painful
  7. 7. Remove Myths“We’re agile, we don’t have any documentation”
  8. 8. Start your Communications early. And often, and to everyone
  9. 9. Target the “Frozen Middle”Get them on board by addressing their concerns loss of control, loss of work, disruption of SLAs
  10. 10. Agile Readiness Assessment ssessment.pdf Assessment-ThoughtWorks.pdf Book/assess_your_agility.html
  11. 11. 2. Understand the problem you are solving Define it, agree on it, measure it
  12. 12. Agreeing on the problem is not easybecause the people who caused the problem still work here…
  13. 13. “My bit is okay, its those guys who need to change”
  14. 14. But you need to agree, so that you can measure progress… And keep renewing the funding
  15. 15. What is the biggest problem? Fix that first. Repeat.This works better than trying to fix all the problems in one go.
  16. 16. To help identify the problems use Lean Value Stream Maps, Alignment to Business Strategy, Current State assessments Interviews Ask the team (They always know)
  17. 17. Project Risk Risk Mitigation Over Time Over Budget Wrong QualityDeliver the wrong thing
  18. 18. Project Risk Risk Mitigation Work in Iterations Continuous Feedback Over Time Big Visible Charts (Burn Down, Burn Up, Risks, Issues) Story Walls Prioritised (Force ranked) Product Backlogs Continuous Integration Tools (Resharper, xUnit, Hudson, Cucumber, Ruby, etc) Good hardware (Lots of RAM) Over Budget Automated Build/Package/Deployment Build Pipelining Test Driven Design Automation Testing Wrong Quality Pair Programming Quality Metrics (Static code analysis, etc) High Bandwidth Communications Co-Located TeamsDeliver the wrong thing Business part of the team Daily Standups, Showcases, Retrospectives
  19. 19. Agile transformations involve combinations of: Technical Practices adoption Governance /Structural changes Cultural / Behavioural changesEach organisation finds its own equilibrium point
  20. 20. Three Levels of Agility Commitment Strategic CEO CIO PortfolioCAO CTO ... Operational
  21. 21. Learn by doing, with a player-coachThe best way to learn is through embedded coaches Be wary of “process” coaches
  22. 22. A parable This is BradStolen Reused with permission from Steve Hayes
  23. 23. Brad is an Agile coach and consultant
  24. 24. Brad is offered a gig atPonderous Software Development
  25. 25. Ponderous want to become agile
  26. 26. Brad gives Ponderous his “Agile 101” presentation, and they love it
  27. 27. They ask Brad to coach their adoption
  28. 28. However, Ponderous can see that agile as Brad described it, clearly won’t work for them…
  29. 29. Because they are different!
  30. 30. Brad can do whatever he wants, except…
  31. 31. He can’t change anything about operations or the production environment (different department)
  32. 32. He can’t have access to the business people (they’re too busy)
  33. 33. Every project needs a business caseaccurate to +/- 10% before Execution (CFO requirement)
  34. 34. Projects must have fixed costs, fixedscope, and fixed delivery date before development starts (business requirement)
  35. 35. All the requirements need to be documented to ISO-666 before development starts (audit requirement)
  36. 36. The process needs to be identical across all teams (QA requirement)
  37. 37. The tools needs to be identical across all teams (We got a great deal on licensing)
  38. 38. Developers can’t access(or download from) the internet (security requirement)
  39. 39. He can’t post information on the walls (facilities requirement)
  40. 40. He can’t spend any money on hardware or software (budget constraint)
  41. 41. Development must be in a new language, with no developersexperienced in that language, and no training budget (architectural requirement)
  42. 42. 70% of the workforce must be contractors/ delivery partners (onshore and offshore) (Division requirement)
  43. 43. You must use all of the PMO Project Lifecycle templates (PMO Requirement)
  44. 44. You actually need to be willing to change!
  45. 45. I’ve been there… Be careful that you don’t give on too many of the constraintsThis is insidious, because the constraints may sound reasonable to their owners Focus on addressing the intent of the constraint
  46. 46. Change the mindsetValue Chain not Siloed Services
  47. 47. Use your Consultants Good Cop – Bad Cop
  48. 48. What about my Governance?Governance is hard! But it is critical that you get it right.
  49. 49. In SummaryUnderstand your readiness to change Agree on the problem Adopt the necessary techniques Challenge the constraints
  50. 50. Tips
  51. 51. At some point you will have a conversation “Are we really up for this?”• Be prepared
  52. 52. You will get staff turnover• Be prepared
  53. 53. What about Scrum?• Scrum for common naming• XP for technical techniques• Lean for reducing waste
  54. 54. Align KRAs to match the goals• Reduce Sev 1s in production• Improve Customer satisfaction score
  55. 55. What about Offshore Agile• Increase comms (video etc)• Visit often – put a face to the voice• Rotate people onshore-offshore• Shared information radiators (Mingle)• Adjust your expectations
  56. 56. Focus your efforts on converting the 80% “undecided” into “on-board”
  57. 57. Sabotage Workshop• How would I make this fail?
  58. 58. Insist on Heavy DocumentationDon’t Empower the teamsDemand tight predictabilityDon’t make your resources availableLip service, but no real supportPromote the blame culturePunish Failure
  59. 59. ?