Blog

We've updated the LeanKanban Training Roadmap for 2015 following the introduction of the modular 5-day Enterprise Services Planning class.

2015 Edition LeanKanban Training Roadmap

The new training roadmap includes the new Enterprise Services Planning classes but also introduces a new intermediate training class called "The Kanban Method." People completing the Foundation Level "Getting Started with Kanban - Improving your Service Delivery" class together with the Advanced Practitioner Level "The Kanban Method - Success Evolutionary Change for Your Technology Business" will receive the Kanban Management Professional (KMP) credential.

Enterprise Services Planning is a new modular 5-day training curriculum for managing modern businesses involving lots of knowledge work and creative services. If your organization contains people who must think and make decisions for their living then Enterprise Services Planning is the management training framework that will transform your business. While ideally taken together as 5 days of intensive emersion, ESP training is offered in 4 modules. The following blog post describes the curriculum of Module 4 - Portfolios, Programs and Dependencies.

Enterprise Services Planning is a new modular 5-day training curriculum for managing modern businesses involving lots of knowledge work and creative services. If your organization contains people who must think and make decisions for their living then Enterprise Services Planning is the management training framework that will transform your business. While ideally taken together as 5 days of intensive emersion, ESP training is offered in 4 modules. The following blog post describes the curriculum of Module 3 - Project and Capacity Planning.

Enterprise Services Planning is a new modular 5-day training curriculum for managing modern businesses involving lots of knowledge work and creative services. If your organization contains people who must think and make decisions for their living then Enterprise Services Planning is the management training framework that will transform your business. While ideally taken together as 5 days of intensive emersion, ESP training is offered in 4 modules. The following blog post describes the curriculum of Module 2 - Enterprise Services.

Enterprise Services Planning is a new modular 5-day training curriculum for managing modern businesses involving lots of knowledge work and creative services. If your organization contains people who must think and make decisions for their living then Enterprise Services Planning is the management training framework that will transform your business. While ideally taken together as 5 days of intensive emersion, ESP training is offered in 4 modules. The following blog post describes the curriculum of Module 1 - Portfolio Management

This year, we're officially introducing Enterprise Services Planning (ESP) as a concept and specifically as a management training curriculum. Later this year, I anticipate the launch of Enterprise Services Planning software tools to support the mechanisms and methods taught in our classes.

It is now 10 years this month that I started work with Microsoft in the Team Foundation Server product unit. In my first week I was given the specification for the tracking software and asked to review it. On the 4th day I went to my boos, Keith Rowe and told him, "this product isn't designed to work the way real software teams work. Real teams do not adopted prescribed, defined processes wholesale on a single day, instead they adopt practices incrementally and their process evolves." The issue was with the mechanism for loading a process definition and a set of work item type definitions for TFS to track. It had to be done at the start of a project. Once loaded the project would use the same set of work item definitions, they couldn't be changed mid-project. Mechanisms like this act as an impediment to process improvement. This problem isn't unique to Team Foundation Server, it is common across many of the popular work tracking products.

The reason work tracking software works the way it does, with very static work type state transition definitions, is that firstly, the product managers specifying these products don't have to use them in the way that developers, analysts, architects and testers have to use them, and they don't have to manage software development teams adopting process changes. And secondly, building a flexible tool that enables work type state changes to be modified on-the-fly is actually quite hard. Visualizing the change is trivial but what do you do with all the existing data? What do you do with work items in-progress? These work items need to transition through a new set of states from that envisaged when the work item was created. And how do you handle metrics reporting when the state transition model changed during the time period to be displayed in the chart or graph?

Kanban tools such as LeanKit and Swift Kanban were designed and architected from the ground up to handle this problem. Kanban tools were designed to facilitate evolutionary process improvement and to do so gracefully.

I'd like to post some thoughts on the Siemens Healthcare Kanban implementation and case study. This case study from the United States has received a lot of coverage and the author and his Kanban coach have appeared at several Lean Kanban conferences presenting the story.

The story written by Bennet Valet of Siemens appeared on InfoQ and as such has caught the attention of many people. You can read it here...
Kanban at Scale – A Siemens Success Story

We've been reviewing this case study as a group exercise in KCP Masterclasses throughout this year. It is worthwhile posting some thoughts on this story because of both how it has been presented by Bennet Valet and Daniel Vacanti publicly and some of the claims made in the article.

Firstly, the good news, the story discusses the rollout of kanban systems across multiple services within a business unit at Siemens Healthcare in Malvern Pennsylvania. Around 500 people were involved and they already had Scrum implemented across product development. So this is a large scale Scrumban story where a business unit is adding Kanban to an existing Scrum implementation in order to take it to the next level. There are doubtless many companies interested in this scenario and the outcomes.

It seems that defect rates dropped dramatically after Kanban was implemented and productivity increased by approximately 35%. Achieving faster delivery from a group of 500 people by as much as 35% is a significant result and will have caught the attention of others in similar corporate situations.

So what are the problems with this case study and how it has been presented publicly? Firstly, there has been a salaciousness about the style of presentation and some of the claims made belong in the field of tabloid journalism. What is behind this behavior, I wouldn't like to speculate, but it has caused some chatter in the community that needs addressing. Secondly, there are some claims in the story stated as fact, and I have no doubt the author believes them to be facts but they don't stand up to scrutiny from reading the content of the case study...

For those who missed it, you will find my autumn conference series key note speech very insightful and useful background for this post. Kanban and Evolutionary Management - Lessons we can learn from Bruce Lee's journey in martial arts (video from Lean Kanban Central Europe, Hamburg, November 2013).

Every business or every unit of a business should know and understand its purpose. Sometimes businesses have lost sight of this and there is scope for a workshop exercise amongst senior leaders and business owners to define that purpose. What exactly are they in business to do? And it isn't simply to make money. If they simply wanted to make money they'd be investors and not business owners. They would spend their time managing investment portfolios and not leading a small tribe of believers who want to make something or serve someone. So why does the firm or business unit exist? If we know that we can start to explore what represents "fitness for purpose."

Recently, we've seen a lot of activity in the marketplace focused on "scaling Agile." It seems after a decade or so, people have been willing to admit the "Scrum of Scrums" concept just wasn't cutting it. There is now sufficient evidence of large scale failed Agile transition initiatives to know that previous decade's hypothesis about delivering large scale Agile adoption hasn't worked. Now we have a new wave. IBM has DAD (Disciplined Agile Delivery) and Dean Leffingwell and Rally Software Development have SAFe (Scaled Agile Framework). Other tool vendors in the market are encouraging emergence of "me too" scaled Agile solutions.

None of this is really new. These frameworks are composed of many of the practices we've known for over a decade, almost two decades in some cases. We know these practices work in the small scale. What is new is that they are now offered within frameworks for tailoring, although I am increasing hearing that there is very little tailoring actually happening in the field and the transition is to a prescribed pre-defined enterprise scale process.So, what hasn't changed is the change management approach - large scale transition initiative to prescribed, designed or tailored solutions, with a preference for prescribed, apparently because it is easier and requires less skill and knowledge on the part of the constulants or trainers delivering it. This means consultants and trainers can be certified quickly and on a large scale. It is only a matter of time until most of these initiatives crash and burn against the same old obstacles - (1) the people being changed resist the initiative. The resistance is passive-aggressive and initially is not detected. It takes time before it is obvious the organization hasn't embraced the new way of working, and (2) the managers have not changed their behavior. While managers believe that there operational capability is a "process problem" they will continue to buy process solutions expecting them to fix the workers and how they work, while what is truly broken is the management and how managers make decisions.

Scaled Agile doesn't fix the real problem while it continues to promote the same old failed 20th Century approach to change. There is a truly easy way to scale agility in your organization. You adopt the Kanban Method as an approach to managing service dellivery, and you scale it out, across your organization, in a service-oriented fashion, one service at a time...

Pages