Recommandé
Contenu connexe
Dernier
Dernier (20)
En vedette
En vedette (20)
Sustainable Quality at Warp Speed
- 1. @Warp Speed Richard Hensley – McKesson Corp rhensley99@msn.com “The perfect is the enemy of the good enough.” - Voltaire
- 2. What do I want you to get? What is the case study? How did we do it? What is a plan for you? Copyright 2012 - Richard Hensley
- 3. Copyright 2012 - Richard Hensley
- 4. Copyright 2012 - Richard Hensley Business and Technology can co-create peacefully.
- 5. No Silver Bullet Discipline Flexibility Copyright 2012 - Richard Hensley
- 6. Are you willing to think differently about the tools and practices you use in your business today? Copyright 2012 - Richard Hensley
- 7. Copyright 2012 - Richard Hensley
- 8. Start with a small high profile product line Implement Lean Software Engineering Scale the product line business up Scale Lean Software Engineering across line of business and seven product lines Reliable Release Planning defined as within 10% of plan for cost and due date performance Two parts, Pilot and Scaling Copyright 2012 - Richard Hensley
- 9. • April 2009 Missing Major Commitments Missing Sprint Commitments Growing Defect Backlog Growing Customer Base Growing Customer Complaints No Predictable Release Planning Possible 1 Customer – 3 Users 14 Product Development Staff 1 Product Line in 1 Line of Business 1 Line of Business 3 Year Timeline Copyright 2012 - Richard Hensley
- 10. 2010-2011 – Exceeded Planned Production by 7% and 13% 2010-2011 – Due Date Performance – 95% 2010-2011 – Delivered 30 Production Releases ◦ Zero Critical Defects ◦ Less than 90 Total System Defects Release Planning is “Easy” Business Scaled to 16 customers with 5000 users 60 Product Development Staff 7 Product Lines in 1 Line of Business Copyright 2012 - Richard Hensley
- 11. Implement Lean Software Engineering across three lines of business 24 product lines 250 Staff Members Product Line Business Models include ◦ Software as a Service ◦ Installed Products Little or No impact on the Business Reliable business plans within 10% for productivity and due date performance. 18 Month Timeline Copyright 2012 - Richard Hensley
- 12. Cutting Scope to meet Commitments Celebrating our delivery success without acknowledging the dissatisfaction of the business 24 Product Lines in 3 Lines of Business Large Defect Backlogs Missing Major Commitments Release Planning is painful and produces fodder for fighting August 2011 Copyright 2012 - Richard Hensley
- 13. Fully implemented in one line of business Pilot projects in the two other lines of business Using data to manage and predict the outcomes of product development 100 Staff Members 9 Product Lines CTO and VP’s are selling the change to the business and staff. (MAJOR MILESTONE) Copyright 2012 - Richard Hensley
- 14. Copyright 2012 - Richard Hensley
- 15. Copyright 2012 - Richard Hensley Quality Satisfied Staff Productivity Satisfied Customers Success
- 16. Team Focus Practice Focus Planning Focus Copyright 2012 - Richard Hensley
- 17. Copyright 2012 - Richard Hensley Small 6-8 Cross Functional Mostly Permanent Project Assembled Matrix Organization Performance ReviewsSelf Organized Staff Isolation Social Support
- 18. Copyright 2012 - Richard Hensley Visual Controls Automation Small Batches Focus On One Task Peer Review Cost Reduction Deadline Focus Large Batches Multi Tasking Unneeded Paperwork Creative Destruction
- 19. Copyright 2012 - Richard Hensley Use Data in Planning Trusted Data Common Language Producer Consumer Transparent Reporting Ignoring Past Trends Over Committing Unreliable Data Publishing too Soon Deferring Publishing
- 20. Copyright 2012 - Richard Hensley
- 21. Required Activities Delay Inducing Activities Requirements Design Coding Integration Testing Deployment Training Documentation Requirements Rework Using Old Requirements Building Unneeded Features Fixing Bugs Integration Errors Overbuilding Frameworks Duplicating Components Copyright 2012 - Richard Hensley
- 22. What if you counted your stories for the last six months? What if you evaluated your point estimates for the last six months? AND, what if you planned the next month based on the average for the last six months? OR, what if you counted the number of stories in your next initiative and planned it using simple counts? Is this really naïve? Copyright 2012 - Richard Hensley
- 23. What improvement did you make last week, month, year? Do you know the impact of your changes? How do you know the impact? What was the specific performance need that triggered the improvement? Copyright 2012 - Richard Hensley What did you improve last week? “Ummm…, I don’t know” What did you improve last week? “We talked about continuous integration.” Better answers are needed from any team member!
- 24. What if all initiatives were 4-6 people for 1 to 2 months? What if one team could deliver a complete initiative? What if all user stories took less than three days to complete? What if nothing was done until a customer checked it out? Copyright 2012 - Richard Hensley
- 25. What if the whole business used a single common language? What if the language was related in a hierarchical way? What if all planning, measurement, build, deployment, analysis activities were based in the common language? What would this do to remove delays? Copyright 2012 - Richard Hensley
- 26. Value stream map Implement visual control Implement explicit process policies Gather data Implement Kanban Change Management Copyright 2012 - Richard Hensley
- 27. Copyright 2012 - Richard Hensley
- 28. Copyright 2012 - Richard Hensley
- 29. What do you want to know that I didn’t cover? Copyright 2012 - Richard Hensley
- 30. Richard Hensley – McKesson Corp ◦ AVP Process ◦ Technical Fellow Emeritus richard.hensley@mckesson.com rhensley99@msn.com http://www.linkedin.com/in/richardhensley Copyright 2012 - Richard Hensley
- 31. On the web ◦ www.limitedwipsociety.org ◦ www.leankanbanuniversity.com Authors ◦ David J. Anderson ◦ Donald Reinertsen ◦ Karl Scotland Google Search Terms ◦ Software Kanban ◦ Lean Software Engineering ◦ Software Flow Process Copyright 2012 - Richard Hensley
Notes de l'éditeur
- Today, I want you to have answers to these questions that you can use in your business.And, to leave you with a message of hope. With the practices and techniques today, reliable high performance software delivery is becoming mainstream.
- Key Idea: It is not easy to be a part of a high performing software product business.There are tools that you can use that will help.
- Key Idea: Good process and practices do not abdicate the need for deep thought, courage, and leadership.You probably already know 99% of what I’m going to say.
- Key Idea: These slides are here for context to ensure that the audience is grounded in what is really happening.
- Key Idea: There was trouble in the business, and it was not an emergency.Missed first customer go-live.Consistently had 10% to 20% stories left on the boardDefect backlog growing by about 30-40 defects per monthSoftware Performance ProblemsLack of FeaturesAdding customers quickly
- Key Idea: The business changed and scaled. Product development is now considered a trusted partner in the business.Key Idea: Pilot met all expectations, and exceeded many.
- Key Idea: We are replicating and contextualizing the success from the pilot.
- Key Idea: Poor alignment and fighting between strategy and product management, and product management and product development. General dissatisfaction in the relationship between product development and the business.
- Key Idea: We are at about 50% of the total project, and about 25% of the way in the scaling project.
- Key Idea: Focusing on quality leads to long term positive impact around the circle. Focusing on the others nodes to short term positive outcomes around the circle, and long term negative impact backwards on the circle.Capers Jones has documented evidence that teams working on high quality technology are also the most productive teams.So the key is how do we focus on quality, and prove that we are improving the whole system?
- Key Idea: Transforming a business takes more than technical practices and a team level process, the business must be integrated and operate using the same principles and practices.There are things we do that are good, and we should continue doing them. There are things we do that add delay, we should find them and find a better way.
- Key Idea: A social structure that happens to produce a technical output.Small – Player Coach, Strong Social CohesionCross Functional – Capable, IndependentPermanent – Already Functioning, Bonded, Teams are more capable of overcoming technical challenges than social challengesSelf Organized – Works to get work done, regardless of rolesSocial – Physical Boards, aka new social “water cooler”, open work environmentProject Assembled – Induces social adjustment delaysMatrix Organization – Many managers need updating, delayed decisions, no single point of decision makingPerformance reviews – counter to team accountabilityStaff Isolation – Reduces collaboration, reduces shared knowledge transfer via overhearing, creates opportunity for heroes, creates opportunity for unhealthy knowledge hoarding
- Key Idea: Build in support for small work items to flow through the system very quickly so feedback can be incorporated immediately.Visual Controls are what and why of all work items.Automation – TDD, ATDD, Continuous Integration, Continuous Deployment, One touch build, One Touch Deploy, One Touch UpgradeSmall Batches – maybe even single piece flow. Focus on getting work done, not starting workPeer Review – Capers Jones has documented peer review as the single largest contributor to quality in a software product, deliberate learning is enabled by peer reviewFocus on One Task – Allow Focus, Depending on your source, 2nd is 20% less, etc..Creative Destruction – Allow new practices to destroy your “best practice” ideas. For instance, quality automation completely destroys a traditional QA staffing model, and is very hard to deal with.Cost reduction focus - leads to lower quality and higher costsDeadline focus leads to lower quality and scope cuttingLarge Batches are hard to handle leading to lower quality, most people believe that large batches are efficient. They are efficient at resource utilization and they reduce quality, and they increase lead time, and they reduce through put.Muti-tasking leads to low productivity, lack of focus and lower qualityUnneeded Paperwork leads to out of date documentation which leads to bad knowledge in the team Capers Jones documents paperwork to be up to 40% of the overall cost in a software project.
- Key Idea: Create a even accountability play field by using data and having the producers accountable to producing high quality work and the consumers accountable for requesting high quality content starting at a reasonable time.Using data in planning – count stories per month, requirements per month, something, and then plan based around thatTrusted data – gather and use data that is reliable and focuses on hard data like dates, staff costs, budget run ratesCommon Language – Use a common language to describe work items, have a work item language element owned by stake holder group, have the work items be related with a hierarchical pattern of relationship, i.e. Releases owned by the business, initiatives owned by the strategists, features owned by the product managers, and stories owned by the product developers.Producer Consumer – Product development is accountable for production and quality, Product Management is accountable to content, and dates. Use an interrelated set of control points to ensure your system can meet the production commitments.Transparent reporting – All data is available to anybodyDeferring publishing – What would happen if the roadmap for the year was published as large initiatives were finished. What would happen if the roadmpa was finalized 1 month before delivery?Ignoring past trends – What if your data says you can do 50 stories a month, and your plan calls for 250 in the next 3 months? What if your point velocity is 100 per sprint and you put 115 in the sprint?Over committing – What happens when product development is optimistic in there appraisal of the work at hand and under estimates?Unreliable data – What happens when the data gathered is from a very small part of the value stream? Or, relies on opinion estimation like story points or hoursPublishing to soon – What happens if a roadmap is published in January for a November delivery, and the market changes in August? Can you business respond? How long does it take to plan your deliverables, again? How long does it take to communicate? What is the transaction cost of the market change for your business?
- Key Idea: Technical practices for building quality software are a solved problem. Review the practices from the last decade regarding automation and design patterns.Requirements rework – what if requirements were written JIT relative to start of coding, and coding got done in 2 days?Using old requirements – what if the requirements backlog were well maintained? What if the requirements in the back log were long lasting market requirements?Building Unneeded Features – what if the business model supported rapid deployment? What if feedback was gathered from the customer via automation and logging of actions.Fixing Bugs – What if the product development system allowed few bugs. What if all bugs were fixed when found?Integration Errors – What if strategies were used like continuous integration? For large integrations, what if dummies or fakes were used to simulate the integration partner?Overbuilding Frameworks – What if frameworks were allowed to emerge from the code base? Design Rule of three. First, build it fast and special purpose. Second, build it well with special purpose. Third, build it with a framework.Duplicating Components – What if design patterns were trained and used?
- Key Idea: It is likely that you have the data needed to start measuring and understanding your product development capability.
- Key Idea: Many teams say they continuously improve, and very few actually can identify any improvements that impacted their capability to produce software.
- Key Idea: Reducing the size of your work items allows focus, and allows a sense of accomplishment.
- Key Idea: A common language throughout the business removes the delays in translations, and forms a foundation for consistently managing the product development capability.
- Key Idea: There is a body of knowledge that gives you a place to start.Document - Value Stream Mapping includes a process step, the time spent in the process step, and the time to the next process step. Include Policies, Procedures, and Work Items. Document where you are, not where you want to go.Implement Visual Control – Include Work Items and PoliciesCommitment – Start the Self OrganizationKanban – Include the 5 Core – Visualize Workflow, Limit WIP, Manage Flow, Make Policies Explicit, Improve Collaboratively
- Key Idea: Think different, work hard, transform, get started!
- Key Idea: Working Hard and Thinking Differently leads to peaceful co-making