Businesses demand high levels of product quality, development productivity, planning reliability, employee satisfaction, and customer loyalty. And yet, people and organizations often ignore all those goals and focus on building systems with as many features as possible delivered by a specific due date. When the work is complete, retrospectives surface the dissatisfaction concerning missed dates, poor quality, technical debt, and more. Richard Hensley describes his last three years at McKesson, where they have delivered 103 production releases with no significant defects, fulfilled sixteen multi-million dollar contracts, maintained high employee morale, and trained 5,000 users. Employing the Kanban approach for change management, McKesson implemented new tools selected from RUP, XP, Scrum, and lean—daily focused planning, stand-up meetings, retrospectives, TDD, information radiators, user stories, etc. They automated anything they could and measured everything possible. Most importantly, though, they developed a culture that puts quality and continuous improvement at the forefront. Richard outlines the ideas behind McKesson’s cultural and delivery success, and describes how their approaches can work in your business.
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
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
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
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
Notas del editor
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