Being agile while standing in a Waterfall Mike Edwards [email protected] Twitter: @mikeeedwards Blog: www.mikeeedwards.ca References: agilewaterfall.ca Wednesday, 23 October, 13
May 13, 2015
Being agile while standing in a Waterfall
Mike Edwards
[email protected]: @mikeeedwards
Blog: www.mikeeedwards.caReferences: agilewaterfall.ca
Wednesday, 23 October, 13
Agile will fail at my workplace because of ...
• The concept of dedicating to one task at a time is not supported
• Because of our culture
• They won’t change
• Of me
• It’s counterintuitive and hard to practice
• Too focused on mechanics
• Ridiculous product owners
• What we do already works
• Not everyone on our team understands it
• We only fund capital projects
• My boss who manages with fear
( Taken from Agile 2013 )
Wednesday, 23 October, 13
Agenda
Stories
What worked for me
Views & experiences
Where to from here
Wednesday, 23 October, 13
Does Waterfall work?
Wednesday, 23 October, 13
“I believe in this concept, but the implementation described above is risky and invites failures” -- Winston Royce (August 1970)
I SYSTE M
I ANALYSIS
PROGRAM DESIGN
I c o o , . o
TESTING
I OPERATIONS
Figure 2. Implementation steps to develop a large computer program for delivery to a customer.
I believe in this concept, but the implementation described above is risky and invites failure. The problem is illustrated in Figure 4. The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input /output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required. A simple octal patch or redo of some isolated code wil l not f ix these kinds of diff iculties. The required design changes are l ikely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modif ied, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.
One might note that there has been a skipping-over of the analysis and code phases. One cannot, of course, produce software wi thout these steps, but generally these phases are managed wi th relative ease and have l i tt le impact on requirements, design, and testing. In my experience there are whole departments consumed with the analysis of orbi t mechanics, spacecraft att i tude determination, mathematical opt imizat ion of payload activity and so forth, but when these departments have completed their di f f icul t and complex work, the resultant program steps involvea few lines of serial arithmetic code. If in the execution of their d i f f icul t and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.
However, I believe the illustrated approach to be fundamental ly sound. The remainder of this discussion presents five addit ional features that must be added to this basic approach to eliminate most of the development risks.
329
Wednesday, 23 October, 13
Computing: Then & Now
IBM System/360
Wednesday, 23 October, 13
What is Agile?
Wednesday, 23 October, 13
Saying you do one of these ...
Agile
Lean
ScrumXP
Kanban
DADRUPFDD
DSDM
Crystal
RAD
SAFe
Wednesday, 23 October, 13
... is like carrying one of these
Wednesday, 23 October, 13
Story time!
Wednesday, 23 October, 13
Once upon a time ...
• Final component of a larger program
• Estimated at 1200 days
• Drop dead date of 3.5 months
• Highly visible if we failed
• Core team assigned of 5 IT people
• Waterfall was all we knew
Wednesday, 23 October, 13
Go!
• 15 contractors in the door within 2 weeks
• Secured a team room
• Broke the work out into projects
• Developed a mantra: “Failure is not an option”
• Strong executive sponsorship
Wednesday, 23 October, 13
The Result!
• Delivered on the date we said we would
• Actuals came in $8000 under budget
• Delivered all key scope items
• No significant quality issues after go-live
• Happy customer!
Wednesday, 23 October, 13
Another story!
Wednesday, 23 October, 13
The situation
• Towards end of a larger troubled project (we kept dropping scope)
• Team only available for 3 more months
• Budget defined by available people and time
• Low key enhancement project
• Waterfall was best described as a religion
Wednesday, 23 October, 13
Go!
• Secured a war ‘area’
• Given free reign to ‘try something different’
• Simple one sentence scope statement
• No authority to NOT do something in the department’s process
• Executive sponsorship watched closely
Wednesday, 23 October, 13
The Result!
• Finished early
• Finished slightly under budget
• Features delivered exceeded customer expectation
• No quality issues after go-live
• Happy customer!
Wednesday, 23 October, 13
Ideas for being Agile?
Wednesday, 23 October, 13
Describe the characteristics of a successful project?
Wednesday, 23 October, 13
Start with theAgile Manifesto
We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:
Individuals and interactions over processes and toolsWorking software over comprehensive documentation
Customer collaboration over contract negotiationResponding to change over following a plan
That is, while there is value in the items onthe right, we value the items on the left more.
Wednesday, 23 October, 13
Ideas
Make it about principles
Wednesday, 23 October, 13
Post-Mortem
Wednesday, 23 October, 13
LearningWe can learn the mechanic didn’t latch the cowling
Feel better?
What does it mean to improve?
vs. Improving
Wednesday, 23 October, 13
Improve how you Improve
• Conduct regular retrospectives throughout the project
• Empower teams to improve
• Make room for ongoing improvements
• Make improvement an objective for teams
Wednesday, 23 October, 13
Ideas
Make it about principles
Conduct regular Retrospectives & Improve
Wednesday, 23 October, 13
People• Support those who deliver value
• Motivate them
• Trust them
• Create sustainable pace
• Foster responsibility
• Have fun!
Wednesday, 23 October, 13
OBLIGATION
RESPONSIBILITY
SHAME
The Responsibility Process™
JUSTIFYLAY BLAME
DENIAL
QUIT
ChristopherAvery.com©1991-2012. International trademarks and copyrights apply. Leadership Gift™ is a trademark of Christopher Avery. Responsibility Process™ and Keys to Responsibility™ are trademarks of Christopher Avery and Bill McCarley. Permission is hereby granted to duplicate and distribute only in its entirety without changes or deletions.
CHRISTOPHER AVERY& THE LEADERSHIP GIFT
Wednesday, 23 October, 13
The 5 dysfunctions of a team
Wednesday, 23 October, 13
Collaborate!
• Examine the value of your weekly status meetings
• Tear down the walls
• Eliminate the hierarchy
• Make information visible
• Build a cross functional team
• Build a high performing team
Wednesday, 23 October, 13
Ideas
Make it about principles
Conduct regular Retrospectives & Improve
Create a high performing team
Wednesday, 23 October, 13
Why do we schedule?
Wednesday, 23 October, 13
An effective schedule?An ineffective schedule
Wednesday, 23 October, 13
Schedule
Wednesday, 23 October, 13
Ideas
Make it about principles
Conduct regular Retrospectives & Improve
Create a high performing team
‘Deliver’ frequently
Wednesday, 23 October, 13
“The customer just asked for a couple changes”
Wednesday, 23 October, 13
Why do we need Change Management?
Decisions are made prematurely!
Our customers cannot possibly know what they want in detail at the start of a project
Wednesday, 23 October, 13
Scope
In Scope Blah blah blah blah blah blah blah Blah blah blah blah blah blah blah Blah blah blah blah blah blah blah Blah blah blah blah Blah blah blah blah blah blah blah blah Blah blah blah blah blah blah blah Blah blah blah blah blah blah blah Blah blah blah blah blah blah blah blah blah blah blah blah blah Blah blah blah blah blah blah blah
Out of Scope Blah blah blah blah blah blah blah Blah blah blah blah blah blah blah Blah blah blah blah blah blah blah Blah blah blah blah Blah blah blah blah blah blah blah blah Blah blah blah blah blah blah blah Blah blah blah blah blah blah blah Blah blah blah blah blah blah blah blah blah blah blah blah blah Blah blah blah blah blah blah blah
OWednesday, 23 October, 13
Scope
Scope Statement
In Scope Add a feature <to the system> and
supporting functionality
Out of Scope
Wednesday, 23 October, 13
Delay decisions to the last responsible moment
• User stories and user story maps
User Story format:
As a <user>, I want <some goal>, so that <some reason>Wednesday, 23 October, 13
Scope ManagementFront Burner Back Burner Fridge Freezer
User Stories
Scope
Wednesday, 23 October, 13
What can you do about change?
Embrace it!Welcome changing requirements, even late in
development. Agile processes harness change for the customer's competitive advantage.
(Agile Manifesto - Principle #2)
Create an environmentallowing everyone to learn
Wednesday, 23 October, 13
Ideas
Make it about principles Conduct regular Retrospectives & Improve Create a high performing team‘Deliver’ frequentlyDefer decisions until the last responsible moment
Wednesday, 23 October, 13
How do you report status?
a.k.a.: Navigating through the rear window
Wednesday, 23 October, 13
Status Reporting
• Start ALL projects red
• Check the politics at the door
• Honesty & Transparency
• Put your status on the wall
• Build plans allowing for clearer reporting
Wednesday, 23 October, 13
Ideas
Make it about principles Conduct regular Retrospectives & Improve Create a high performing team‘Deliver’ frequentlyDefer decisions until the last responsible momentKeep status reports transparent and real
Wednesday, 23 October, 13
Tracking Progress
0
4
8
11
15
8-Mar 15-Mar 22-Mar 29-Mar 5-Apr 12-Apr 19-Apr
Critical Path Actual vs Target Hours
Hou
rs
0
150
300
450
600
8-Mar9-Mar10-Mar11-Mar12-Mar13-Mar14-Mar15-Mar16-Mar17-Mar18-Mar19-Mar20-Mar21-Mar22-Mar23-Mar24-Mar25-Mar26-Mar27-Mar28-Mar29-Mar30-Mar31-Mar1-Apr2-Apr3-Apr4-Apr5-Apr6-Apr7-Apr8-Apr9-Apr10-Apr11-Apr12-Apr13-Apr14-Apr15-Apr16-Apr17-Apr18-Apr19-Apr20-Apr21-Apr22-Apr23-Apr
Actual vs projected total
Daily burn
Burn up
Wednesday, 23 October, 13
Be careful what you measure ...
You might just get it!
MeasurementsTime sheets
OPM3
CMMI ITIL
COBIT
Schedule Accuracy
Wednesday, 23 October, 13
The importance of timeliness!
Hermann Ebbinghaus
Wednesday, 23 October, 13
Some words of wisdoma.k.a. Things I’ve learned the hard way
Wednesday, 23 October, 13
Things I’ve learned
• Culture cannot be changed - change how the work is done and culture will follow
• Start from where you are today and never be satisfied
• Improve the whole
• Improve one step at a time
• Iterate (Build Measure Learn)
• Have fun!
Wednesday, 23 October, 13
Thanks!
For more Information:http://agilewaterfall.ca
http://bit.ly/VKyFD5
Stay in [email protected]
Twitter: @mikeeedwardsBlog: www.mikeeedwards.ca
My upcoming LeanPub book:
Being agile while standing in a waterfall!
Wednesday, 23 October, 13