Monday, April 30, 2012

Tolerance #2

Yesterday’s post was inspired by my recent bike rides around my home neighborhood in Clallam County, Washington. I typically ride the last few miles home on the Discovery Trail - a bike path crafted out of an abandoned railway line that ran from Port Angeles to Sequim and on toward Discovery Bay. About 5 miles from home, the path is cut by a gravel road inside the Carlsborg, WA, industrial park. Recently, the road was resurfaced with rather course gravel, some of the small rocks measuring 1”-2” in size - fine for trucks, not so easy for a racing bike with 25mm tires. When I hit the road spinning at about 20 mph, I had only few seconds before hand to recognize the resurfacing work. I didn’t anticipate how chunky some of it was going to be. As I hit it my bike started to shake violently and bounce left and right.

My instinct was to grip tighter - to force more control. Instinctively I wanted to keep the bike moving forward within a very narrow band of variation to the left or right. But I had to fight that instinct, to loosen my grip and let go of the handle bars. I had to let the bike shake left and right - i had enough momentum to get across the rough gravel and safely onto the smooth bike path on the far side. To grip too tightly, to fight the wild oscillations would be to risk making the bike unstable and tipping over - a nasty road rash awaits the unlucky cyclists who tries too hard. Sometimes we have to loosen our grip. We need to be tolerant to variation. We need to ride with a loose rein.

Parents reading this will recognize the parental advice - children controlled too tightly react unpredictably and ultimately rebel. We have to learn to let go if we want our organizations to be stable. We need to recognize that we’ll get knocked left and right in the short term but it’s the longer term trend that interests us. Loosen your grip and ride the bumps - don’t crash and burn in a vain attempt at control!

Tolerance #1

My father was a real engineer. He used to get his hands dirty with machinery. He was a machinist (a turner) by trade. He spent much of the latter part of his career commissioning plant and machinery at an explosives factory. Often he or his colleagues would hand craft some of the manufacturing tools with their own machine tools. He spent a lot of time thinking about tolerances. The tolerance in the actual size of a machined part, or a manufactured component, from its specification. These are typical measured in microns, or in his younger days, fractions of an inch. In his broad Glasgow brogue he’d talk of “thous.” Precision was important but like all engineers he was a pragmatist. Perfection wasn’t necessary - near enough was good enough. I worry that recent trends in the Agile community are losing sight of the inherent pragmatism seen in engineers like my father…

Over the last four or five years, I see ever greater focus on planning and estimation and ever more elaborate methods for sizing, prioritizing and planning work. We seem to be trying to be very precise about commitments. We’re not embracing the natural variation that is inherent in software development. We are creating specifications with very little tolerance and the band of acceptable tolerance is almost certainly too tight to be practical.

Software development has inherently large amounts of common cause variation. I see velocity trend reports that commonly show variation of a factor of 2 above and below a mean, e.g. a mean of 20 story points per sprint may exhibit a variation from as little as 10 to as high as 40. However, we persist in making commitments that are not tolerant to the nature of our work. We relentlessly pursue precision in order to make better plans to improve our chances of delivering on our commitments.

I see the Agile community pursuing a vicious spiral and ironically aping the mistakes of an earlier era - it’s just the practices and techniques that are different. New tribe, new set of tribal rituals, same old mistakes! These elaborate estimation and prioritization methods are an attempt to bring a level of deterministic planning to Agile development, with a level of precision that is not possible given the nature of the work. Making commitments with a narrow tolerance is setting ourselves up for failure and attempts to drive out the variation through every more elaborate methods of planning is simply waste. The variation cannot be eliminated. It must be embraced!

Meanwhile, I predict many will spend more time in training learning these elaborate techniques. Already there are certifications in such activities and doubtless more will emerge. More and more time will be spent planning Agile software development. More time will be spent analyzing user stories, though this activity is disguised by calling it “estimation.” And perhaps it won’t be so long before we’re back where we started, asking ourselves, “When are we actually going to build some software?”

Thursday, April 26, 2012

Kanban - What are we Certifying?

When we announced the Accredited Kanban Training program in Lean Kanban University in February some people initially believed we were announcing a certification scheme for individuals taking Kanban training. We were not! Instead we were introducing standards into Kanban training by introducing a defined curriculum and accredited training material against that curriculum. We were also providing a professional designation of Accredited Kanban Trainer (AKT) to those individuals that we believed to be qualified to teach the curriculum adequately. We were “certifying” trainers.

Certification of a Role

Certification schemes tend to attach to roles played by individuals. Certified Scrummaster is an acknowledgement of some level of knowledge for playing the role of Scrummaster. Scrum has two roles, Scrummaster and Product Owner and two widely offered certifications - Certified Scrummaster and Certified Scrum Product Owner. There are also Certified Scrum Coach and Certified Scrum Trainer. I’m picking on Scrum as an example but many other methods and professions certify roles played at some level of proficiency or capability.

Certification in Kanban

There are members of LKU who wanted to introduce a certification scheme for individuals. In the current economy, all of our businesses need something to make it a little easier. Certifications do attract customers. People like to have professional recognition and a certification and some letters to put after your name, is one way of achieving such recognition. Under pressure in the meeting at the Hilton Royal Parc in Netherlands, I simply replied, “What are we certifying?” And that was the end of the discussion. Kanban defines and prescribes no roles. As I explained last week, this lack of roles is a strength. So, I will not be adding roles for the convenience of creating a certification scheme to make training companies money. Without roles, how do you create a certification scheme for individuals taking Kanban training?

As I stated last week, there is a role to played in the change management approach called the Kanban Method - the role of change agent - the person who leads the Kanban initiative and either facilitates or takes responsibility for the kanban system design. Might we be able to certify change agents who use the Kanban Method? Food for thought!

Kanban - Lack of Roles is a Strength

In their mini-book, Kanban and Scrum - making the most of both, Henrik Kniberg and Mattias Skarin point out that the Kanban Method does not prescribe any roles. Often people ask about roles in Kanban, expecting to be trained to play a specific role. The response is that your role remains the same as it is today. This is a core principle of the Kanban Method - you start with what you do now and you initially respect current roles, responsibilities and job titles.

There is a Role in Kanban

There is one role that helps when using the Kanban Method - the role of Change Agent. I hope to document this role when I get around to writing my book on Advanced Kanban. It is this role that my 3-day Advanced Kanban Masterclass (formerly known as the Coaching and Leadership Workshop) prepares people to play. If you are leading a Kanban change initiative then you might benefit from this advanced class.

A Lack of Roles is a Strength

When you create a change management process, a process that is designed to act on a workflow process and catalyze changes within it, you don’t want that change process to create inertia or increase resistance to change.

As Peter Senge wrote, “People do not resist change, they resist being changed.” A job title and a role played and the practices inherent to that role become part of an individual’s identity. Hence, asking them to adopt a new role, or a new job title, or change the practices performed in the role, is an attack on their identity. They will resist the requested change emotionally.

As Joe Campbell taught us 3 years ago, Kanban is telling you to “be like water.” The Kanban Method is design to go around the rock and the metaphorical rock in change management is emotional resistance. Kanban tries to avoid emotional resistance. Is does this in part by embracing current roles, responsibilities and job titles. Kanban does not prescribe roles in order to reduce resistance to change. A lack of roles is a strength!

Separation of Concerns

I truly believe that to have successful change, your process for change needs to be separate from the workflow process used to deliver customer-valued knowledge work such as software. A process cannot be both a delivery mechanism and a change mechanism. To be a delivery mechanism there is a need to design, define and prescribe roles with titles and practices. To be a successful change mechanism there is a need to avoid doing such things.

Lean has now given us two change process mechanisms - Kanban and A3. I consider A3 an alternative, a rival perhaps, to Kanban. A3 and Kanban are peers. A3 is a change process that acts upon delivery processes and workflows. A3 like Kanban doesn’t prescrive process workflow roles.

First generation Agile methods such as Scrum try to be both a delivery mechanism and a change mechanism. Scrum is challenged as a change method because it prescribes roles for the delivery method - the scrum master and the product owner, explicitly. In doing so, Scrum hits the rock head-on. It creates inertia against change by invoking emotional resistance in those being changed.

Summary

Kanban does not define or prescribe roles for the software development or project management process. It does not change the roles in the workflow for delivering customer-valued work. Kanban is a change management process designed to work upon the delivery process. A3 is a peer of Kanban. A3 uses a different approach but it is designed as a separate change management process. Separating the concerns of delivery from change is strength. It reduces resistance to change. Processes, such as Scrum, that couple delivery with change, struggle because the defined roles create resistance to change. It is, therefore, better to keep the change process separate from the delivery process.

Extending the Five Core Practices of Kanban

Readers familiar with the Kanban Method as described in my book, Kanban: Successful Evolutionary Change for your Technology Business, or those who read yesterday’s blog post, will know that I identified five core practices associated with successful Kanban implementations. I am now considering extending this list to seven for a second edition of the book and a revision of the standard guidance on Kanban.

Current Practices

The five core practices currently identified are:

1. Visualize - make the invisible work and its workflow visible;
   
2. Limit WIP - implement a virtual kanban system;
   
3. Manage Flow;
   
4. Make management policies explicit;
   
5. and Improve Collaboratively - using models and the scientific method to implement a “guided” approach to evolution. There are no random mutations of the target process with Kanban.

So What Is Missing?

As I’ve identified in presentations and key note speeches I gave in 2010, 2011 and earlier this year, the biggest oversight is leadership. Small acts of leadership from any member of the team need to happen regularly. It is these acts of leadership that make change happen.

So the 6th practice is: Leadership - give permission for ideas and encourage process innovation from any and all team members.

There is also a need for explicit feedback loops. The Kanban book identifies these at two levels:

• the daily standup meeting at the team and individual contributor level
• and the operations review at the organization and inter-team or across services level

So collaboration to review flow of work and demand versus capability measures, metrics and indicators coupled with anecdotal narrative explaining notable events is vital to enabling evolutionary change. Organizations that have not implemented the second level of feedback - the operations review - have generally not seen process improvements beyond a localized team level. As a result, they have not realized the full benefits of Kanban observed elsewhere.

So the 7th practice is: Implement Organizational Feedback using Quantitative Measures of Demand and Capability

And the question is, “Should these additional two practices be added to the definition of the Kanban Method?