Upload
nishith-mahanty
View
205
Download
0
Tags:
Embed Size (px)
DESCRIPTION
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.
Citation preview
Agile Adoption
Tales from the Coalface
By Nish Mahanty
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
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
A BIG Sponsor
Strong, committed, present,
Show me the money!
A Critical Event
When it gets painful, you want to remind them of when it was even more painful
Remove Myths
“We’re agile, we don’t have any documentation”
Start your Communications early.
And often, and to everyone
Target the “Frozen Middle”
Get them on board by addressing their concerns
loss of control, loss of work, disruption of SLAs
Agile Readiness Assessment http://www.industriallogic.com/papers/ChangeReadinessAssessment.pdf http://agileassessments.thoughtworks.com/Agile-Onsite-Assessment-ThoughtWorks.pdf http://jamesshore.com/Agile-Book/assess_your_agility.html
2. Understand the problem you are solving
Define it, agree on it, measure it
Agreeing on the problem is not easy
because the people who caused the problem still work here…
“My bit is okay, its those guys who need to change”
But you need to agree, so that you can measure progress…
And keep renewing the funding
What is the biggest problem?
Fix that first.
Repeat.
This works better than trying to fix all the problems in one go.
To help identify the problems use
Lean Value Stream Maps, Alignment to Business Strategy,
Current State assessments Interviews
Ask the team (They always know)
Project Risk Risk Mitigation
Over Time
Over Budget
Wrong Quality
Deliver the wrong thing
Project Risk Risk Mitigation
Over Time
Work in Iterations Continuous Feedback 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) Automated Build/Package/Deployment Build Pipelining
Over Budget
Wrong Quality
Test Driven Design Automation Testing Pair Programming Quality Metrics (Static code analysis, etc)
Deliver the wrong thing
High Bandwidth Communications Co-Located Teams Business part of the team Daily Standups, Showcases, Retrospectives Clear requirements process (Stories, and BDD)
Agile transformations involve combinations of:
Technical Practices adoption Governance /Structural changes Cultural / Behavioural changes
Each organisation finds its own equilibrium
point
Three Levels of Agility Commitment
Strategic
Portfolio
Operational
CEO
CIO
CAO CTO ...
Learn by doing, with a player-coach
The best way to learn is through embedded coaches
Be wary of “process” coaches
A parable
This is Brad
Stolen Reused with permission from Steve Hayes www.CogentConsulting.com.au
htt
p:/
/ww
w.f
lickr
.co
m/p
ho
tos/
ote
r/3
31
67
95
81
5/
Brad is an Agile coach and consultant
Brad is offered a gig at
Ponderous Software Development
Ponderous want to become agile
Brad gives Ponderous his “Agile 101” presentation, and they love it
They ask Brad to coach their adoption
However, Ponderous can see that agile as Brad described it, clearly won’t
work for them…
Because they are different!
Brad can do whatever he wants, except…
He can’t change anything about operations or the production
environment
(different department)
He can’t have access to the business people
(they’re too busy)
Every project needs a business case accurate to +/- 10% before Execution
(CFO requirement)
Projects must have fixed costs, fixed scope, and fixed delivery date before
development starts
(business requirement)
All the requirements need to be documented to ISO-666 before
development starts
(audit requirement)
The process needs to be identical across all teams
(QA requirement)
The tools needs to be identical across all teams
(We got a great deal on licensing)
Developers can’t access
(or download from) the internet
(security requirement)
He can’t post information on the walls
(facilities requirement)
He can’t spend any money on hardware or software
(budget constraint)
Development must be in a new language, with no developers
experienced in that language, and no training budget
(architectural requirement)
70% of the workforce must be contractors/ delivery partners
(onshore and offshore)
(Division requirement)
You must use all of the PMO Project Lifecycle templates
(PMO Requirement)
You actually need to be willing to change!
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
Change the mindset
Value Chain not Siloed Services
Use your Consultants
Good Cop – Bad Cop
What about my Governance?
Governance is hard! But it is critical that you get it right.
In Summary
Understand your readiness to change Agree on the problem
Adopt the necessary techniques Challenge the constraints
Tips
At some point you will have a conversation
“Are we really up for this?”
• Be prepared
You will get staff turnover
• Be prepared
What about Scrum?
• Scrum for common naming
• XP for technical techniques
• Lean for reducing waste
Align KRAs to match the goals
• Reduce Sev 1s in production
• Improve Customer satisfaction score
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
Focus your efforts on converting the 80% “undecided” into “on-board”
Sabotage Workshop
• How would I make this fail?
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