1. Being agile
while standing in a Waterfall
Mike Edwards
mike@leanintuit.com
Twitter: @mikeeedwards
Blog: www.mikeeedwards.ca
References: agilewaterfall.ca
Friday, 25 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 )
Friday, 25 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
Friday, 25 October, 13
violated. Either the requirements must be modified, or a substantial change in the design is required. In effect
6. Computing: Then & Now
IBM System/360
.034 MIPS
max 16MB memory
225MB Disk
$50k/month to lease
$15mm to buy
Friday, 25 October, 13
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
Friday, 25 October, 13
12. Go!
• 15 contractors in the door within 2 weeks
• Secured a team room
• Broke the work out into projects
• Published a team manifesto
• Developed a mantra: “Failure is not an
option”
• Strong executive sponsorship
Friday, 25 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!
Friday, 25 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
Friday, 25 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
Friday, 25 October, 13
17. The Result!
• Finished early
• Finished slightly under budget
• Features delivered exceeded customer
expectation
• No quality issues after go-live
• Happy customer!
Friday, 25 October, 13
20. 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.
Friday, 25 October, 13
21. Agile Manifesto
Principles
1.Our highest priority is to satisfy the customer through early and continuous delivery
of valuable software.
2.Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
3.Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
4.Business people and developers must work together daily throughout the project.
5.Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done.
6.The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
Friday, 25 October, 13
22. Agile Manifesto
Principles
7.Working software is the primary measure of progress.
8.Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
9.Continuous attention to technical excellence and good design enhances agility.
10.Simplicity--the art of maximizing the amount of work not done--is essential.
11.The best architectures, requirements, and designs emerge from self-organizing teams.
12.At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
Friday, 25 October, 13
25. Learning vs. Improving
We can learn the mechanic
didn’t latch the cowling
Feel better?
What does it mean
to improve?
Friday, 25 October, 13
26. Improve how you Improve
•
•
•
Empower teams to improve
•
Friday, 25 October, 13
Conduct regular retrospectives
throughout the project
Make improvement an objective
for teams
Make room for ongoing
improvements
27. Ideas
Make it about principles
Conduct regular Retrospectives & Improve
Friday, 25 October, 13
28. People
•
•
•
•
•
•
Friday, 25 October, 13
Support those who deliver value
Motivate them
Trust them
Create sustainable pace
Foster responsibility
Have fun!
31. Collaborate!
•
•
•
•
•
•
Friday, 25 October, 13
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
32. Ideas
Make it about principles
Conduct regular Retrospectives & Improve
Create a high performance team
Friday, 25 October, 13
36. Ideas
Make it about principles
Conduct regular Retrospectives & Improve
Create a high performance team
‘Deliver’ frequently
Simplicity
Friday, 25 October, 13
38. 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
Friday, 25 October, 13
43. 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
Friday, 25 October, 13
44. Ideas
Make it about principles
Conduct regular Retrospectives & Improve
Create a high performance team
‘Deliver’ frequently
Simplicity
Defer decisions until the last responsible
moment
Friday, 25 October, 13
45. How do you report status?
a.k.a.:
Navigating
through
the rear
window
Friday, 25 October, 13
46. 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
Friday, 25 October, 13
47. Ideas
Make it about principles
Conduct regular Retrospectives & Improve
Create a high performance team
‘Deliver’ frequently
Simplicity
Defer decisions until the last responsible
moment
Keep status reports transparent and real
Friday, 25 October, 13
50. The importance of timeliness!
Hermann Ebbinghaus
Friday, 25 October, 13
51. Some words of wisdom
a.k.a. Things I’ve learned the hard way
Friday, 25 October, 13
52. Things I’ve learned
•
•
Start from where you are today and never be
satisfied
•
•
•
•
Friday, 25 October, 13
Culture cannot be changed - change how the work
is done and culture will follow
Improve the whole
Improve one step at a time
Iterate (Build Measure Learn)
Have fun!
