Its the Product. Not the Project May 17 2017
•Als PPTX, PDF herunterladen•
0 gefällt mir•48 views
It’s the Product, not the Project - Using Agile and Lean to redefine the role of Project Management Featuring Chris Girolamo
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (17)
Ähnlich wie Its the Product. Not the Project May 17 2017
Ähnlich wie Its the Product. Not the Project May 17 2017 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Its the Product. Not the Project May 17 2017
- 1. CHRIS GIROLAMO VICE PRESIDENT SOFTWARE AND SYSTEMS ENGINEERING GROUP STG, INC. PMP, CSM, SA MAY 17, 2017 – PMI RESTON LUNCHEON SERIES IT’S THE PRODUCT N O T T H E P R O J E C T All rights reserved USING AGILE AND LEAN TO REDEFINE THE ROLE OF PROJECT MANAGEMENT
- 2. A G E N D A With the advent and widespread adoption of project standards and models (e.g. CMMI, PMBOK, EVM) over the last decade or two, software project management has matured significantly. However, an overzealous application of these standards has often resulted in not-so-great products wrapped in great projects. To build great products and enhance our project management maturity, a new model is needed where the project management is based on product development principles. Agile and lean practices, which are based on these product development principles, provide the means to build great products wrapped in an effective project management framework. All rights reserved
- 3. P R O J E C T | P R O D U C T All rights reserved
- 4. P R O D U C T D E V E L O P M E N T P R I N C I P L E S T H E P R I N C I P L E S O F P R O D U C T D E V E L O P M E N T F L O W D O N A L D G . R E I N E R T S E N M A N A G I N G Q U E U E S E X P L O I T V A R I A B I L I T Y R E D U C E B A T C H S I Z E U S I N G F A S T F E E D B A C K A P P L Y I N G W I P C O N S T R A I N T S C O N T R O L L I N G F L O W U N D E R U N C E R T A I N T Y All rights reserved
- 5. PROJECT CHARACTERISTICS M A N A G E M E N T A P P R O A C H R U L E O F C E R T A I N T YR U L E O F I N V E R S E C E R T A I N T Y P R O J E C T C H A R A C T E R I S T I C S M A N A G E M E N T A P P R O A C H All rights reserved
- 6. D E F I N E D | E M P I R I C A L All rights reserved
- 7. T H E R U L E O F S M A L L B A T C H E S All rights reserved
- 8. SM ALL B AT C H ES All rights reserved EM ER G EN T D ESI G N I N D UC ED D ESI G N
- 9. W H A T I S D E S I G N ? All rights reserved
- 10. T H E F A L L A C Y O F U T I L I Z A T I O N All rights reserved M A X I M I Z I N G C Y C L E T I M E
- 11. Q U E U E S K I L L All rights reservedAll rights reserved
- 12. YOU CAN ALWAYS GET WHAT YOU WANT All rights reserved
- 13. M U L T I T A S K I N G … T H A N K Y O U H E I N R I C K K I N B U R G Cooper Tory Cullen Clare CadeA S Y N C H R O N O U S C O O P E R T O R Y C U L L E N C L A R E C A D E S Y N C H R O N O U S T A S K 1 T A S K 2 T A S K 3 T A S K 4 T A S K 5 T A S K 1 T A S K 2 T A S K 3 T A S K 4 T A S K 5 T A S K 6 All rights reserved
- 14. I N V E N T O R Y All rights reservedAll rights reserved
- 15. C O N T I N U O U S D E L I V E R Y All rights reserved
- 16. A D A Y I N T H E L I F E Continuous Delivery Pipeline TDD POTENTIALLY DEPLOYABLE RELEASE 9:00 AM 11:00 11:05 11:15 11:45 12:15 AUTOMATED COMMIT TESTING AUTOMATED INSTALLATION SCRIPTING AND TESTING ACCEPTANCE REGRESSION TESTING Code Check In Pass Commit Stage Integration Testing Environment Acceptance Test Production Replicate PassDELIVERY DETECTED BUILD COMMENCES Pass Pass DEFECT? DEFECT? DEFECT? DEFECT? DAILY SCRUM All rights reserved
- 17. F A S T F E E D B A C K All rights reservedAll rights reserved
- 18. R E G E N E R A T I V E Fast Feedback Small Batches Queue Discipline All rights reserved
- 19. S Y S T E M S T H E O R Y SDLC 3.0 – BEYOND A TACIT UNDERSTANDING OF AGILE MARK KENNALEY All rights reservedAll rights reserved
- 20. S U R V E I L A N C E | C O L L A B O R A T I O N All rights reserved
- 21. S T A K E H O L D E R ( S ) | P R O D U C T O W N E R ( ) All rights reserved
- 22. I N S P E C T F O R Q U A L I T Y | B U I L D I N Q U A L I T Y All rights reserved
- 23. M A X I M I Z E U T I L I Z A T I O N | M A N A G E Q U E U E S All rights reserved
- 24. C O N T R O L C H A N G E | A D A P T T O C H A N G E All rights reserved
- 25. S P E E D | C A D E N C E All rights reserved
- 26. A C C I D E N T A L W A T E R F A L L All rights reserved
- 27. P R O J E C T | P R O D U C T All rights reserved
- 28. C H R I S . G I R O L A M O @ S T G . C O M C O N N I E . B I R K L A N D @ S T G . C O M 7 0 3 . 6 9 1 . 2 4 8 0 x 1 2 3 7 w w w . s t g . c o m All rights reserved
- 29. R E F E R E N C E S 1. Cohn, Mike. User Stories Applied, Addison-Welsley, 2010. 2. Hillel Glazer, Entinex, Inc. Jeff Dalton, Broadsword Solutions Corporation, David Anderson, David J. Anderson & Associates, Inc. Mike Konrad, SEI Sandy Shrum, SEI. CMMI® or Agile: Why Not Embrace Both! Hanscom AFB, Massachusetts: Software, 2008 Engineering Institute. – Provides a perceptive historical perspective on CMMI and illustrates the underlying reasons that CMMI can be a false positive as well as the misinterpretations that almost always occur in CMMI implementations that are unhealthy to project and product development. 3. Humble, Jez., Farley, David. Continuous Delivery. Upper Saddle, New Jersey: Addison-Welsley, 2010. – Describes in detail how to extend continuous integration across the full lifecycle to be continuous delivery. Tons of information , exacting detail, tools reviews and great insights on a diverse array of topics including automating acceptance testing and deployment scripting; and hammers the theme, “it it’s hard, do it a lot.” 4. Kennaley, Mark. SDLC 3.0 Beyond a Tacit Understanding of Agile, Fourth Medium Consulting, Inc., 2010. – A discussion with a proposed framework, eponymously named SDLC 3.0, of a tailored hybrid of lean, agile and unified process as a consolidated lifecycle approach. The theme is to dispense with the advantages/disadvantages debate driven by competing approaches. Additionally there is compelling chapter that systems theory which provides applied scientific and mathematical proof that agile is more stable and effective than waterfall. All rights reserved
- 30. R E F E R E N C E S 4. Poppendieck, Mary and Tom. Implementing Lean Software Development: From Concept to Cash. Boston: Addison-Welsley, 2006. 5. Poppendieck, Mary and Tom. Leading Lean Software Development: Results Are Not the Point. Boston: Addison-Welsley, 2010. 6. Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Developent. Redondo Beach: Celeritas Publishing, 2009. 7. Willis, Carol and Donald Friedman. Building the Empire State Building. New York: The Skyscraper Museum, 1998. – Though not specially mentioned in the presentation, this book provides a fascinating summary of the construction of the Empire State building which amazingly was built from cradle to grave in one year. This feat was accomplished with agile and lean concepts such as careful management of queues, management of work in progress and strategies to achieve . chris.girolamo@stginc.com All rights reserved
Hinweis der Redaktion
- Steve Jobs Story
- With the advent and widespread adoption of project standards and models (e.g. CMMI, PMBOK, EVM) over the last decade or two, software project management has matured significantly. However, an overzealous application of these standards has often resulted in not-so-great products wrapped in great projects. To build great products and enhance our project management maturity, a new model is needed where the project management is based on product development principles. Agile and lean practices, which are based on these product development principles, provide the means to build great products wrapped in an effective project management framework. Many of the practices that are important for PD are counter intuitive…… Many are heavily influences by the cultural aspects of the workplace Specifics are product development, but the context I am going to use is swd Software is a product….. ow many build products? How many are SWD? Level of agile adoption?
- If I achieve on this it is this…… PD based on PM or visa a versa What is a project? Upgrade to new version of an operating system Roll out launch of a new product – better mousetrap, toothbrush Build the metro What is a product? Software development is product Don’t know with certainty what your final product should be Don’t know the technology iPhone rev 1.0
- Agile practices started about a dozen years ago………. PD principles have been in place for the past 30 years…..though many organizations are not aware of them. Today’s presentation I have channel the a book by Donal Reinersen….. If you are doing lean, or agile I highly encourage this bookk….. it gives you a perspective that will significantly enhance you understating and ability to implement agile
- Example of empirical vs. defined. Defined – better ability to plan and predict what should happen Empirical - Base your decisions on what is in front of you; observation or a hypothesis that is testable. This mind set feeds Adapting to change Fast feedback Working in small batches
- Small batches is pervasive in an agile environment…. Network example/ reduces risk, reduces overhead 10MB file as single packet and average one error per 1MB; we would average 10 errors per transmission, means 1 in 22K without an error. 10MB file into 10,000 packets of 1K packet each, 1 chance in 1,000 a packet would bet corrupted with an additional overhead of .1% or only 10 packets Lower overhead feedback – not required at intermediate step Small batches means you find errors quickly and can fix them at the time they occur. Small batches is pervasive in an agile environment…. RE SMALL BATCHES; Jeff Bezos of amazon’s rule of thumb – TWO PIZZAs PAUSE
- Small batches encourages proper design Induced design via small component, that are loosely coupled with a well defined interface. I think it is easier to get your head the idea that requirements can evole but design really scares people. .. Separation of concerns/ Small, loosely coupled architectures with well defined interfaces Embrace Refactor Each sprint should be slice of the cake Also allow us to work in parallel on many subsystems with a confidence that it will integrate Encourages subsystem reuse and when we reuse, we reuse testing, doc, and can even reuse the design through design patterns. Decreases cycle time due to less exposure to req. creep/tech change/design changes
- What is design – jack reeves Different paradigm Design ends up with detail specifications written Why important? – it should simplify and reduce our dependence on detailed design specs. And BUFR, BUFD. Emergent design – Neal Ford
- Queuing theory….get to cycle time Performance tuning To control cycle time, don’t try to control capacity, control queues Sprints control queues to assure cycle time
- Queues hurt cycle time, quality and efficiency Increase risk More variability More overhead Lower quality Less motivation LONGER CYCLE TIME If everything is important, nothing is important Morale ????? (SUBTLE, CULTURAL, DISEMPOWERING) Hide behind large queues Wait until priorities change Management spends a lot of time managing queues Bottom line we do not multi-task well CONTRAST WITH SCRUM What did you do yesterday, what are going to complete today, what are your obstacles NOWHERE TO HIDE – BAD METAPHOR Actually, this is very empowering – WANT TO WORK ON IMPORTANT STUFF,
- Why not? Gave me what I asked for but it is not what I want. 70% to 80% of features are seldom or never used. How many people use their living rooms????? MS Word – new revisions The great retailer F. W. Woolworth once said that 50 cents out of every dollar he spent on advertising was wasted. He went on to say that he wished he knew which 50 cents. That is the same problem with requirements: 50% of software features are not used or are wasted, while other needed features are sorely missed. Over- and underbuilding applications are the biggest forms of software development waste. The Standish Group believes optimization based on value is the silver bullet to solve the issue. Expansion of requirements, more times than not, can cause a project disaster or failure. The key to optimization is constraining scope to just those elements that are absolutely necessary.
- Mutli-Tasking Game Cadence vs. Speed Multi-tasking and context switching How many windows to you get open on your workstation?
- ANY BUSINESS that is inventory dependent tries to turn their inventory as quickly as too much WIP We don’t think of having inventory in SWD but we do. BITS ON DISK DRIVE…..it’s on the buffet and it costs How does SWD inventory go bad In some cases we are PROUD of our ability to compile a HUGE INVENTORY of requirements, design documents, completed code which of cost feeds our accidental waterfall So why does inventory cost so much and why is it so bad? First of all it goes stale, it rots. CHANGE happens – enough said. CHANGE is NOT JUST REQUIREMENTS but NEW COMPLEXITIES CHANGE = BACK TO CCB WIP, (on balance sheet) RIP and DIP are not So PICK IT when its RIPE. It will go STALE, it will rot. WORK HAPPENS ALL THE TIME – AGILE CONCEPT
- What if you could deliver sw monthly? Weekly? Daily? Continuous delivery Gold standard XP practice Multi-page instruction sheets
- TOOLS - Cruise control, Hudson, Go Dev/Ops Evolutionary maturity level. POTENTIALLY DEPLOABLE RELEASE
- Our strategy is to fail. Fail in requirements, design and development. They way quality is built is is by failing. Not a new concept but we fail at failing. this all the time. Perfect example of what we do….. Failure is not only an option, it’s required, it’s built in How – scrum team is working to deliver a release all at once Counter intuitive Reduce risk by encouraging failure Reduces risk of long term failure/increase risk of short term failure Stop the line, TPS
- Agile is green it reduces the “carbon footprint” – e.g. the amount of energy to complete work Ecosystem instead of gate driven system it reduces the waste footprint it reduces the documentation footprint (How often do you create doc that never gets read?) it reduces the project management footprint it reduces the surveillance footprint Core principles work together Surveillance is reduced instead you have a recyclable, green machine.
- Systems Theory Complex Adaptive System – number or types of part in the system, and the number of relations between the parts is non-trivial. They can react to chaing condition in the environment in which they exist. Order emerging out of chaos – flock of birds, hurricane, auto-pilot on an airliner BTW, drop these guys a note
- I debated using the word surveillance? It is probably too strong, but I do think it is something we need to think about. When does oversight become project surveillance When does governance become counterproductive How much time do you spending building your software v tracking results How much time do you spend on reporting How about a metric to track that ratio? Show how does agile overcome this surveillance scenario? Product owner is part of the team – works collaborative with the team’ There is no project manager The whole team sees progress every day via information radiators. Characteristics of scrum team
- The stakeholder matrix As we know, the larger the number of stakeholders, the number of interactions increases exponentially. The problem with stakeholders in my mind is they all think they are in charge. But…… you can’t live with one stakeholder. But apple had one……greatest company in the work CPO not CEO Not shy about starting over – essential Related dynamic – here is cultural shift
- Mentioned earlier with queuing theory and small batches Is it more important to maximize utilization or maximize cycle time? Do we maximize cycle time by maximizing utilization?
- How many of you are satisfied with your change control process? Really good. OK It stilnks? They are both brittle and heavy weight. When we use them we feel good about our selves because we avoid risk we get to document a lot of stuff, we induce delay and we can blame it on the change control process. IT MAKES IT HARD TO CHANGE. The name itself indicates it is designed to reduce change. Does a speed control process designed to help you go faster? We need a change ensurement process. The scrum is designed to encourage change. The product owner is empowered to approve change. Change is a collaborative exercise. You can have change and you sprint can always finish on time and be done! Always
- Tortoise v. Hare In a football game Bus Example – maintain it’s schedule In projects we yearn for speed; we should yearn for cadence How? Sprints always finish on time. Always and they are always done.
- Accidental Waterfall or Scrum-fall or vortex Visit to Cornell Cognitive dissonance In psychology, cognitive dissonance is the excessive mental stress and discomfort experienced by an individual who (1) holds two or more contradictory beliefs, ... How many iterative projects are really waterfall. Why do we do this? WE BELIEVE more efficient, reduce waste, improve quality, utilize our specialized talent to the max…… However, the reality is we end up achieving the opposite. Analogy to Totoya Production System….. Good enough for Henry Ford, good enough for us! Fred Brooks, Barry Boehm from Poppendieck books. Accidental Waterfall The vortex Impediments to progress in the federal market TAKE A BREADTH
- Think Different Behave different Don’t get caught in the cognitve dissonance, waterfall, servielanc
- Self Aggrandizement Show Passport
- Surprised at the volume of books on Agile