Boost PC performance: How more available memory can improve productivity
Â
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
2. CHRISTOPHER AVERY
& THE LEADERSHIP GIFT
The Responsibility Processâ˘
RESPONSIBILITY
OBLIGATION
QUIT
SHAME
JUSTIFY
LAY BLAME
DENIAL
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.
3. 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 )
6. 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
7. Computing: Then & Now
IBM System/360
.034 MIPS
max 16MB memory
225MB Disk
$50k/month to lease
$15mm to buy
12. The situation
⢠Towards end of a larger troubled project
(we kept dropping scope)
⢠Team only available for 3 more months
⢠Budget deďŹned by available people and time
⢠Low key enhancement project
⢠Waterfall was best described as a religion
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
14. The Result!
⢠Finished early
⢠Finished slightly under budget
⢠Features delivered exceeded customer
expectation
⢠No quality issues after go-live
⢠Happy customer!
17. 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.
19. Learning vs. Improving
We can learn the mechanic
didnât latch the cowling
Feel better?
What does it mean
to improve?
20. Improve how you Improve
â˘
Conduct regular retrospectives
throughout the project
â˘
â˘
Empower teams to improve
â˘
Make improvement an objective
for teams
Make room for ongoing
improvements
26. 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
31. 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
32. Ideas
Make it about principles
Conduct regular Retrospectives & Improve
Create a high performance team
Defer decisions until the last responsible
moment
36. Ideas
Make it about principles
Conduct regular Retrospectives & Improve
Create a high performance team
Defer decisions until the last responsible
moment
âDeliverâ frequently
Simplicity
37. 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
38. Ideas
Make it about principles
Conduct regular Retrospectives & Improve
Create a high performance team
Defer decisions until the last responsible
moment
âDeliverâ frequently
Simplicity
Start ALL projects red!
42. Some words of wisdom
!
a.k.a. Things Iâve learned the hard way
43. 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
satisďŹed
â˘
â˘
â˘
â˘
Improve the whole
Improve one step at a time
Iterate (Build Measure Learn)
Have fun!
49. 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
50. 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
51. The Result!
⢠Delivered on the date we said we would
⢠Actuals came in $8000 under budget
⢠Delivered all key scope items
⢠No signiďŹcant quality issues after go-live
⢠Happy customer!