Blog : Agile

Thursday, August 16, 2012

Kanban Coaching Professional

Today Lean-Kanban University announced the launch of the Kanban Coaching Professional program and the designation KCP for those who have demonstrated an advanced knowledge of Kanban and success leading change initiatives using the method.

Background

The KCP program comes as a direct response to community reaction after the launch of the Accredited Kanban Trainer program in February 2012. On the Kanbandev list some prominent community members expressed dissatisfaction that the AKT designation was showing favoritism to those who offer Kanban training classes, while those who were doing great work within corporations were going unrecognized by the authoritative body that controls the quality standards for the Kanban Method.

This was a real and genuine concern. The AKT program was never intended to cast a negative light on those who don’t teach. Its intent was always a positive one of bringing quality standards to Kanban training throughout the world and building trust in the LKU brand for corporate training.

For those who have taken advanced Kanban training, my coaching and leadership workshop as it was known, now the Advanced Masterclass, they will instantly recognize the sociology in this situation, it is both tribal and relative. By giving a designation to some members of the tribe, it was interpreted as a slight on the others. Professional and experienced Kanban coaches would not only recognize this behavior, they ought to be able to predict it. So today, Lean-Kanban University fixes this tribal issue by introducing a designation for those experienced in leading and coaching Kanban change initiatives.

Organization and Structure

The KCP program will be controlled by an advisory board. This board is chaired by me and initially includes Mike Burrows (Positive Incline, UK), Jeff Anderson (Deloitte LEAN, Canada), Klaus Leopold (LEANability, Austria), Håkan Forss (Avega Group, Sweden), Michael Robillard (McKesson, USA), Laurent Morriseau (Morriseau Consulting, France), Chris Shinkle (SEP, USA), and Stephen Reid (Ultimate Software, USA). The advisory board will set the requirements for achieving KCP status and will appoint review panels for each application. The review panels will consist of advisory board and charter members who volunteer to serve on a panel to review new applications. There are a considerable number of people in the community who already meet the requirements for the program. Each of them is being invited to join as a charter member. These invitations are going out overnight.

Requirements

Applicants for the KCP designation are currently required to have completed a 3-day Advanced Kanban Masterclass. Currently, such classes are only offered by David J. Anderson & Associates. After completing the educational requirements, applicants must submit an application to the advisory board detailing their experience leading Kanban initiatives. A panel will then be appointed to review their case. The panel may request a face-to-face interview and these interviews are likely to happen at Lean Kanban conferences and Kanban Leadership Retreats. An annual fee is levied for KCP members. The fee is adjusted, like all LKU fees, for purchasing power parity, in some regions and countries. This makes involvement in LKU affordable for those in countries where their currency has a low value and the cost of living is relatively cheap in comparison with the United States.

How do I get started on the road to KCP?

For complete beginners the road to KCP starts by attending a 2-day accredited Kanban training class offered by one of over 20 member companies throughout the world. For those already with Kanban experience the second stage is to attend a 3-day Advanced Kanban Masterclass. These advanced classes take up where the Kanban book leaves off. These 3-days of intensive content involve material not yet published or not easily discoverable - presented at conferences or in blog posts in years gone by. Following this, those leading Kanban initiatives must gain experience and document it before submitting an application to the KCP advisory board. The next two 3-day classes are in Chicago and Stockholm in September. Sign up now to progress on your personal journey to the KCP designation.

Advantages of Becoming a KCP

Lean-Kanban University hopes to build a trusted brand around the KCP designation. We already know that alumni of the advanced 3-day classes have a much higher chance of success leading Kanban initiatives than those who have not attended. Learning the psychology and sociology of change initiatives and understanding how to avoid basic mistakes that invoke resistance are elementary to the 3-day training. Graduates of the 3-day training are automatically invited to Kanban Leadership Retreat events and together as a group they have a shared language. They understand why “Kanban should be like water” and why the philosophy of Bruce Lee provides an important framing for the Kanban Method. They understand the answer to the question, “How many Kanban coaches does it take to change a lightbulb?” They understand how to identify the rocks that will stand in the way of successful change within an organization and they learn how to design kanban systems so that those rocks are motivated to change or simply diminish and go away. Coaching Kanban is about judgment, system thinking, and knowing how to design a system to catalyze a desirable outcome. Those bearing the new KCP designation are trusted by Lean-Kanban University to know these skills and to utilize them to delivery superior results when leading improvement initiatives.

Posted by david on 08/16 at 03:06 PM AgileKanbanLeanNewsPermalink

Wednesday, August 15, 2012

A Taste of Lessons #4: Inspired by Deming

For today’s excerpt from Lessons in Agile Management, I thought I would publish the contemporary introduction to chapter 4 - Inspired by Deming, rather than publish one of the articles from the chapter. This will give you a flavor of how the book adds value to old articles and how it frames the content with respect to Agile and the Kanban Method.

Introduction to Chapter 4 - Inspired by Deming

THE WORK OF W. EDWARDS DEMING HAS BEEN A MAJOR SOURCE OF INSPIRATION FOR ME AND IT HAS GREATLY INFLUENCED THE KANBAN COMMUNITY. IT IS DEMING WHO GAVE US THE TERM “CAPABILITY,” WHICH WE PREFER OVER “PRODUCTIVITY” OR “PERFORMANCE.” DEMING TAUGHT US how to understand that capability must be viewed in light of its variation and that it isn’t a constant (or an average.) Deming gave us methods for studying and improving working processes. Most of all, Deming truly defined the concept of “respect of people” (within a system of work.)

The Agile and Lean movements both recognize a “respect for people” but I find that many practitioners fail to understand what this means. Deming taught us that to truly respect the people working in our business, managers must design a system that sets them up for success. To do so, there must first be understanding—an understanding of the capabilities of the system within which the workers are performing tasks, and an understanding of the demands set upon that system.

Deming’s work also predicted results in software engineering. Studies done by Boehm (1981) that suggest the highest leverage for improving the effectiveness of software development is through improving management. Deming’s 95/5 rule suggests that 95 percent of the observed capability of a system is determined by the design of the system, and that the differences in the capability of individual workers within that system affect only five percent of the capability. This result is counter-intuitive and generally elicits an emotional denial from talented software developers. With Kanban, I’ve been promoting the concept of understanding the system in operation, explicitly defining the policies that control that system, and rightly making it the role of managers to take ownership of those policies and the system design. Kanban training, therefore, is actually management training—its goal is to improve the quality of management decisions at all levels within an organization.

I’ve chosen to include a paper first developed for the Agile 2005 conference. Because I was in a sponsored speaking slot courtesy of my role with Microsoft at that time, I presented my work on MSF for CMMI® (Capability Maturity Model Integration) Process Improvement, demonstrating that Agile values and principles need not be sacrificed in order to deliver a process that is compliant with CMMI Maturity Level 3.

This work reflects my investigations of Deming’s ideas at that time. I was still very much in the mode of collecting data and validating it against Deming’s ideas. My work in 2004 and 2005 seems to have brought a focus on Deming to the Kanban community. This focus isn’t always healthy. I’ve come to realize that software-development work exhibits wide ranges of common-cause variation and that a narrow focus on reducing it may not be optimal from a customer-service perspective. It is also likely that control limits such as +/–3 sigma and the Shewhart method for calculating control limits1 are not relevant in our world.

I have observed in the Kanban community a tendency for people to use lagging indicators, such as lead time, in control charts. Most Kanban tracking tools support this. It is arguable that such charts are of little use other than as historical report cards to reflect upon significant process changes, or to show an improvement in average lead time and predictability through reduced variation in lead time. The intent of control charts as a management intervention tool both to teach and to avoid what Deming called Mistake #1 and Mistake #2 are lost.

So although this article is included for historical reasons and for its value in connecting the CMMI with Agile, the title of this chapter was carefully chosen. Choose to be inspired by Deming rather than dogmatically following his methods. Deming worked in a different era and, given his own nature, I am sure he would have sought to understand knowledge work just as he did manufacturing work. The results would likely have led to an evolution of his approach. The Kanban community has this opportunity today and I’d like to see where it takes us.

Posted by david on 08/15 at 03:46 PM AgileKanbanLeanPermalink

Monday, August 13, 2012

A Taste of Lessons #3: What Would Drucker Do?

Continuing my series of extracts from Lessons in Agile Management I am selecting an article from Chapter 3: What Would Drucker Do? This article was first posted on August 10th 2004. So, this is just after its 8th anniversary. Here I take leader’s view on the Agile practice of refactoring…

Drucker On Refactoring

Drucker on Refactoring—no, really! What follows is what Peter Drucker might have had to say about refactoring were it available as a practice when he wrote these words in 1954:

A favorite story at management meetings is that of the three stonecutters who were asked what they were doing. The first replied, “I am making a living.” The second kept on hammering while he said, “I am doing the best job of stonecutting in the entire country.” The third one looked up with a visionary gleam in his eyes and said, “I am building a cathedral.”

The third man is, of course, the true “manager.” The first man knows what he wants to get out of the work and manages to do so. He is likely to give a “fair day’s work for a fair day’s pay.

It is the second man who is a problem. Workmanship is essential; without it no business can fl ourish; in fact, an organization becomes demoralized if it does not demand of its members the most scrupulous workmanship they are capable of. But there is always a danger that the true workman, the true professional, will believe that he is accomplishing something when in eff ect he is just polishing stones or collecting footnotes. Workmanship must be encouraged in the business enterprise. But it must always be related to the needs of the whole.

. . . The tendency to make the craft or function an end in itself [in future] will therefore be even more marked than it is today. . . . The new technology will need both the drive for excellence in workmanship and the consistent direction of managers at all levels toward the common goal.

What Drucker is telling us is that craft workmanship such as zealous refactoring is important both to an organization’s morale—it is important that people can take pride in their work—but also to the quality of what is being produced. However, over-zealous refactoring destroys shareholder value. So beware of the cruft polisher on your team. Refactoring should be done for the right reasons—to eliminate technical debt or to facilitate coding of features in future iterations. It should never be done simply because a developer doesn’t like the architecture or the implementation. If you can’t answer, “Yes” to the question, “Does this code prevent us from efficacious delivery of future functionality?” then any refactoring is, to use Drucker’s term, merely “polishing stones.”

Contemporary Commentary

Rereading these words I wrote in 2004, quoting Drucker from the 1950s, it is easy to see how prophetic his words were. In this second decade of the twentyfirst century, we have come to observe that Agile is often pursued for the sake of itself; that “clean code” is pursued for its own sake. There are few in the Agile community, like Joshua Kerievsky with his “Intention Design” technique, who are willing to put an economic framework around technical decision making and the acceptable effort to invest in code craftsmanship.

Posted by david on 08/13 at 11:37 AM AgileKanbanLeanPermalink

Lean Kanban University Train-the-Trainer Course

Lean Kanban University is offering a 5-day residential course to qualify as an Accredited Kanban Trainer. This class provides the opportunity to become a recognized trainer within Lean Kanban University with the ability to offer accredited Kanban training classes. Full Details and Registration, Download the Brochure [PDF]

Posted by david on 08/13 at 11:08 AM AgileKanbanLeanLimitedWIPSocietyPermalink

Thursday, August 09, 2012

A Taste of Lessons #2: On Management

Over the next month, I am running a series of extracts from my new book, Lessons in Agile Management. Today I am highlighting an article from chapter 2 - On Management. This article was included in the book at the very last minute, it doesn’t appear in the galley copies we made available in Boston at the Lean Software & Systems Conference. This article was included when I realized, while visiting Brazil last month, that another article referred to it, and also in direct response to a question from a class attendee in Sao Paulo. This article is enhanced with contemporary commentary. This is common throughout the book. Each chapter is preceded with a contemporary introduction setting the chosen articles in the context of leading Agile change, and the Kanban Method. Where appropriate individual articles are enhanced as this one is. The original of this article was first published on Tuesday, March 25th, 2004.

Language Lawyers and Performance Reviews

Fred Brooks introduced the idea of a language lawyer in The Mythical Man Month1 as one role within a surgical team. In Brooks’s model, the surgeon - analogous to a “chief programmer” - is the capacity-constrained resource, and therefore the limitation on throughput of completed working software. All the other roles on the team serve the chief programmer in order to keep him or her productive. The language lawyer is one such role. The language lawyer is the expert on the syntax and function of the computer language being used. The language lawyer is there to answer tough questions about the computer language, and in doing so, keeps the chief programmer fully productive.

Stephen Palmer and John Felsing described how Feature-Driven Development adopted the language lawyer and chief programmer roles in A Practical Guide to Feature Driven Development. Typical language lawyer roles in an FDD team include a Java language lawyer, a design patterns lawyer, a persistence layer lawyer, and a domain modeling (in color) lawyer.

Generally, language lawyers are not dedicated staff positions (as Brooks describes them), but developers or chief programmers who also carry a specific specialist role as an expert in one area. A role as a language lawyer is typically secondary to primary responsibilities on a project. By giving specific team members a specialist role as a lawyer for a specific technical area, a manager creates a means by which to differentiate among team members for the purpose of performance reviews. The team will have specific goals, and every person is expected to pull his or her weight as a functional member to achieve those team goals—delivery dates, production rate, quality objectives. However, a specialist role gives an individual a chance to shine, build respect and trust from colleagues, and show off his or her ability to the boss.

Specific goals and behavior objectives can be set for individual team members, which might include: attending specialist training, attaining certification in the specialist area, keeping up with industry trends and new developments in the technology, knowledge transfer, maintenance of a standards document used at design and code inspections, and coaching of fellow team members. By making the language lawyer responsible for sharing and communicating, the whole team can benefit from the individual’s contribution. Adoption of the techniques across the team and the code can be measured. The team members who work harder to learn, communicate better, and articulate their thoughts best will generate the most shared knowledge and the greatest team benefit.

For the manager it’s a win-win-win. The individual gets to develop and show off worthwhile new skills. The team gets to learn and use new and better techniques that help to maintain or improve completion rate, quality, and lead time of work items. The manager gets a method for measuring individual performance that is aligned with the goals of the team and its customers.

Contemporary Commentary

In 2007, my management team at Corbis worked with me to draw up a list of specialist skills that we required in order to be successful as a department. Shockingly, the list grew to around 180 topics, including obvious things such as C# and SQL. With only 57 full-time employees to cover these 180 skill areas, it was a little daunting. We divided up the list into roughly 30 topics for each of the six managers on my team. They were instructed to have each staff member choose two topics that particularly interested them and in which they wished to develop expertise.

This approach to performance reviews has a number of benefi ts. It helps individuals develop a strong sense of self and a self-image related to their area of expertise. It helps build respect across the whole organization, as everyone earns respect for some narrow fi eld of expertise while continuing to contribute in a general sense to the work of the department. Because of the strong sense of identity attached to the approach, individuals become highly motivated.

The department benefits from building strong capabilities in technical areas; and professional development, training, and review are easily facilitated in a manner that focuses on the individual and not on his or her relative performance contributing to a team goal such as a project delivery. This approach avoids the pitfalls I describe in “Why Individual Measurement is Bad.”

Meanwhile, managers were measured on departmental capability and specific project objectives such as lead time capability, due date delivery performance and throughput (completion rate of customer-valued work) capability.

Extended Blog Commentary

This article shows an example of how I develop, so called, T-shaped people, or specializing generalists. Individuals are measured and rewarded, from an official perspective, by delivering against goals set for their specialization. The generalist skills that contribute to team or departmental performance are only rewarded in a holistic team or departmental fashion. If the team delivers on a goal, and that goal comes with a reward, then the reward is given equally to everyone.

Posted by david on 08/09 at 05:46 PM AgileKanbanLeanPermalink
Page 4 of 24 pages « First  <  2 3 4 5 6 >  Last »