Agile adoption tales from the coalface
2 likes•747 views
The document discusses key preconditions for successful agile adoption, including strong leadership support, understanding the problem to be addressed, and effective communication. It highlights the importance of continuous feedback, risk mitigation, and aligning agile practices with organizational constraints. Additionally, it emphasizes the need for cultural changes and recommends strategies to manage the challenges of agile transformation, particularly in restrictive environments.
Agile adoption tales from the coalface
- 1. Agile Adoption Tales from the Coalface By Nish Mahanty
- 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. There are certain preconditions that you need in place in order to succeed You’re more likely to fail if you don’t have them
- 4. A BIG Sponsor Strong, committed, present,
- 5. Show me the money!
- 6. A Critical Event When it gets painful, you want to remind them of when it was even more painful
- 7. Remove Myths “We’re agile, we don’t have any documentation”
- 8. Start your Communications early. And often, and to everyone
- 9. Target the “Frozen Middle” Get them on board by addressing their concerns loss of control, loss of work, disruption of SLAs
- 10. Agile Readiness Assessment http://www.industriallogic.com/papers/ChangeReadinessA ssessment.pdf http://agileassessments.thoughtworks.com/Agile-Onsite- Assessment-ThoughtWorks.pdf http://jamesshore.com/Agile- Book/assess_your_agility.html
- 11. 2. Understand the problem you are solving Define it, agree on it, measure it
- 12. Agreeing on the problem is not easy because the people who caused the problem still work here…
- 13. “My bit is okay, its those guys who need to change”
- 14. But you need to agree, so that you can measure progress… And keep renewing the funding
- 15. What is the biggest problem? Fix that first. Repeat. This works better than trying to fix all the problems in one go.
- 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. Project Risk Risk Mitigation Over Time Over Budget Wrong Quality Deliver the wrong thing
- 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 Teams Deliver the wrong thing Business part of the team Daily Standups, Showcases, Retrospectives
- 19. Agile transformations involve combinations of: Technical Practices adoption Governance /Structural changes Cultural / Behavioural changes Each organisation finds its own equilibrium point
- 20. Three Levels of Agility Commitment Strategic CEO CIO Portfolio CAO CTO ... Operational
- 21. Learn by doing, with a player-coach The best way to learn is through embedded coaches Be wary of “process” coaches
- 22. A parable http://www.flickr.com/photos/oter/3316795815/ This is Brad Stolen Reused with permission from Steve Hayes www.CogentConsulting.com.au
- 23. Brad is an Agile coach and consultant
- 24. Brad is offered a gig at Ponderous Software Development
- 25. Ponderous want to become agile
- 26. Brad gives Ponderous his “Agile 101” presentation, and they love it
- 27. They ask Brad to coach their adoption
- 28. However, Ponderous can see that agile as Brad described it, clearly won’t work for them…
- 29. Because they are different!
- 30. Brad can do whatever he wants, except…
- 31. He can’t change anything about operations or the production environment (different department)
- 32. He can’t have access to the business people (they’re too busy)
- 33. Every project needs a business case accurate to +/- 10% before Execution (CFO requirement)
- 34. Projects must have fixed costs, fixed scope, and fixed delivery date before development starts (business requirement)
- 35. All the requirements need to be documented to ISO-666 before development starts (audit requirement)
- 36. The process needs to be identical across all teams (QA requirement)
- 37. The tools needs to be identical across all teams (We got a great deal on licensing)
- 38. Developers can’t access (or download from) the internet (security requirement)
- 39. He can’t post information on the walls (facilities requirement)
- 40. He can’t spend any money on hardware or software (budget constraint)
- 41. Development must be in a new language, with no developers experienced in that language, and no training budget (architectural requirement)
- 42. 70% of the workforce must be contractors/ delivery partners (onshore and offshore) (Division requirement)
- 43. You must use all of the PMO Project Lifecycle templates (PMO Requirement)
- 44. You actually need to be willing to change!
- 45. I’ve been there… Be careful that you don’t give on too many of the constraints This is insidious, because the constraints may sound reasonable to their owners Focus on addressing the intent of the constraint
- 46. Change the mindset Value Chain not Siloed Services
- 47. Use your Consultants Good Cop – Bad Cop
- 48. What about my Governance? Governance is hard! But it is critical that you get it right.
- 49. In Summary Understand your readiness to change Agree on the problem Adopt the necessary techniques Challenge the constraints
- 50. Tips
- 51. At some point you will have a conversation “Are we really up for this?” • Be prepared
- 52. You will get staff turnover • Be prepared
- 53. What about Scrum? • Scrum for common naming • XP for technical techniques • Lean for reducing waste
- 54. Align KRAs to match the goals • Reduce Sev 1s in production • Improve Customer satisfaction score
- 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. Focus your efforts on converting the 80% “undecided” into “on-board”
- 57. Sabotage Workshop • How would I make this fail?
- 58. Insist on Heavy Documentation Don’t Empower the teams Demand tight predictability Don’t make your resources available Lip service, but no real support Promote the blame culture Punish Failure
- 59. ? [email protected]