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.

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. ?
nish@mahanty.com