New from BookNet Canada for 2024: BNC BiblioShare - Tech Forum 2024
Being agile while standing in a waterfall
1. Being agile
while standing in a Waterfall
Mike Edwards
mike@leanintuit.com
Twitter: @mikeeedwards
Blog: www.mikeeedwards.ca
References: agilewaterfall.ca
Wednesday, 23 October, 13
2. 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
5. I
SYSTE
M
I
ANALYSIS
PROGRAM
DESIGN
I
coo,.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
“I believe in this concept, but the implementation
described above is risky and invites failures” -Winston Royce (August 1970)
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 will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the
software requirements upon which the design is based and which provides the rationale for everything are
Wednesday, 23 October, 13
violated. Either the requirements must be modified, or a substantial change in the design is required. In effect
11. 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
12. 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
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
15. 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
16. 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
17. 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
20. Start with the
Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Wednesday, 23 October, 13
23. Learning vs. Improving
We can learn the mechanic
didn’t latch the cowling
Feel better?
What does it mean
to improve?
Wednesday, 23 October, 13
24. Improve how you Improve
•
Conduct regular retrospectives
throughout the project
•
•
Empower teams to improve
•
Make improvement an objective
for teams
Wednesday, 23 October, 13
Make room for ongoing
improvements
25. Ideas
Make it about principles
Conduct regular Retrospectives & Improve
Wednesday, 23 October, 13
26. People
•
•
•
•
•
•
Support those who deliver value
Motivate them
Trust them
Create sustainable pace
Foster responsibility
Have fun!
Wednesday, 23 October, 13
29. 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
30. Ideas
Make it about principles
Conduct regular Retrospectives & Improve
Create a high performing team
Wednesday, 23 October, 13
34. Ideas
Make it about principles
Conduct regular Retrospectives & Improve
Create a high performing team
‘Deliver’ frequently
Wednesday, 23 October, 13
35. “The customer just asked for a
couple changes”
Wednesday, 23 October, 13
36. 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
39. 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
41. 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 environment
allowing everyone to learn
Wednesday, 23 October, 13
42. Ideas
Make it about principles
Conduct regular Retrospectives & Improve
Create a high performing team
‘Deliver’ frequently
Defer decisions until the last responsible
moment
Wednesday, 23 October, 13
43. How do you report status?
a.k.a.:
Navigating
through
the rear
window
Wednesday, 23 October, 13
44. 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
45. Ideas
Make it about principles
Conduct regular Retrospectives & Improve
Create a high performing team
‘Deliver’ frequently
Defer decisions until the last responsible
moment
Keep status reports transparent and real
Wednesday, 23 October, 13
48. The importance of timeliness!
Hermann Ebbinghaus
Wednesday, 23 October, 13
49. Some words of wisdom
a.k.a. Things I’ve learned the hard way
Wednesday, 23 October, 13
50. 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
Wednesday, 23 October, 13
Improve one step at a time
Iterate (Build Measure Learn)
Have fun!
