Being agile while standing in a waterfall
Upcoming SlideShare
Loading in...5
×
 

Being agile while standing in a waterfall

on

  • 686 views

 

Statistics

Views

Total Views
686
Views on SlideShare
527
Embed Views
159

Actions

Likes
0
Downloads
12
Comments
0

1 Embed 159

http://leanpmsolutions.com 159

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Being agile while standing in a waterfall Being agile while standing in a waterfall Presentation Transcript

  • 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
  • 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
  • Agenda Stories What worked for me Views & experiences Where to from here Friday, 25 October, 13
  • Does Waterfall work? Friday, 25 October, 13
  • 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
  • Computing: Then & Now IBM System/360 .034 MIPS max 16MB memory 225MB Disk $50k/month to lease $15mm to buy Friday, 25 October, 13
  • What is Agile? Friday, 25 October, 13
  • Saying you do one of these ... XP RAD FDD SAFe Scrum Agile Lean RUP Kanban Friday, 25 October, 13 DSDM DAD Crystal
  • ... can be like carrying one of these Friday, 25 October, 13
  • Story time! Friday, 25 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 Friday, 25 October, 13
  • 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
  • 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
  • Another story! Friday, 25 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 Friday, 25 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 Friday, 25 October, 13
  • 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
  • Ideas for being Agile? Friday, 25 October, 13
  • Describe the characteristics of a successful project? Friday, 25 October, 13
  • 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
  • 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
  • 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
  • Ideas Make it about principles Friday, 25 October, 13
  • Post-Mortem Friday, 25 October, 13
  • 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
  • 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
  • Ideas Make it about principles Conduct regular Retrospectives & Improve Friday, 25 October, 13
  • People • • • • • • Friday, 25 October, 13 Support those who deliver value Motivate them Trust them Create sustainable pace Foster responsibility Have fun!
  • 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. Friday, 25 October, 13
  • The 5 dysfunctions of a team Friday, 25 October, 13
  • 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
  • Ideas Make it about principles Conduct regular Retrospectives & Improve Create a high performance team Friday, 25 October, 13
  • Why do we schedule? Friday, 25 October, 13
  • An ineffective schedule An effective schedule? Friday, 25 October, 13
  • Schedule Friday, 25 October, 13
  • Ideas Make it about principles Conduct regular Retrospectives & Improve Create a high performance team ‘Deliver’ frequently Simplicity Friday, 25 October, 13
  • “The customer just asked for a couple changes” Friday, 25 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 Friday, 25 October, 13
  • Scope  O 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  Friday, 25 October, 13 Blah blah blah blah blah blah blah Blah blah blah blah blah blah blah
  • Scope Scope Statement   Friday, 25 October, 13 In Scope  Add a feature <to the system> and supporting functionality Out of Scope
  • Delay decisions to the last responsible moment User Story format: As a <user>, I want <some goal>, so that <some reason> Friday, 25 October, 13
  • Scope Scope Management Front Burner User Stories Friday, 25 October, 13 Back Burner Fridge Freezer
  • 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
  • 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
  • How do you report status? a.k.a.: Navigating through the rear window Friday, 25 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 Friday, 25 October, 13
  • 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
  • Tracking Progress Critical Path Actual vs Target Hours 15 Hours 11 Burn up 8 2000000 4 1500000 0 8-Mar 15-Mar 22-Mar 29-Mar 5-Apr Daily burn 12-Apr 19-Apr 1000000 500000 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Budget Friday, 25 October, 13 Cumulative Actuals Cumulative Planned
  • Measurements Time sheets Schedule Accuracy Be careful what you measure ... COBIT You might just get it! OPM3 CMMI Friday, 25 October, 13 ITIL
  • The importance of timeliness! Hermann Ebbinghaus Friday, 25 October, 13
  • Some words of wisdom a.k.a. Things I’ve learned the hard way Friday, 25 October, 13
  • 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!
  • Thanks! For more Information: http://agilewaterfall.ca http://bit.ly/VKyFD5 Stay in Touch! Mike@leanintuit.com Twitter: @mikeeedwards Blog: www.mikeeedwards.ca Friday, 25 October, 13 My upcoming LeanPub book: Being agile while standing in a waterfall!