Kanban

Proto-Replenishment Semi-Push System

January 7, 2016 by David Anderson

There is a class of replenishment meeting which I believe we need to call out and name separately. In these replenishment meetings the backlog is already committed and often already prioritized. I am proposing we label these proto-replenishment meetings. This post explains why and asks whether the name proto-replenishment is appropriate or not…

Emerging Roles in Kanban – SDM and SRM

January 6, 2016 by David Anderson

Kanban has always been the “start with what you do now” method, and no one gets a “new role, responsibilities, or job titles” at least not initially. However, it is now clear that some roles are emerging in the field with some implementations. So, it is valuable to report this, while they remain suggestions, options, or ideas, rather than prescribed roles for a Kanban implementation. This post follows my previous one that Kanban doesn’t share Agile’s cross-functional team reogranization agenda, and has always been a cross team, cross function solution for service delivery workflows. What follows is in the context of a service delivery workflow which spans functions or teams and is (most likely) orthogonal to the organizational structure of the enterprise, business or product unit.

Service Delivery Manager

From the early days of Kanban, we talked about the need for a manager to take on responsibility for flow of work. Perhaps, echoing the concept of scrummaster, in some implementations the role of person responsible for flow has been nicknamed flow manager or sometimes “flowmaster”. It’s a sticky, if arcane and tribal, title. For our official literature, I wanted something more corporate friendly, and something that is more outwardly facing. “Flow manager” is inwardly facing and focused on process problems. I prefer names that are outwardly focused and address customer needs. This is in line with the Kanban value of “Customer Focus.”

There is precedent for renaming concepts in Kanban to give them more customer focus. Inspired by the Improvement Kata in Toyota Kata, we defined and named, the System Capability Review meeting in 2012. This was later renamed to Service Delivery Review (SDR). The name change was to give the meeting an outward focus on customer needs, rather than an inward focus on process performance. By keeping the naming, the language, and the values, externally focused, we insure that the right metrics are used to drive relevant, valuable improvements. An outward focus is vital to insure “fitness for purpose” and to deliver on the Kanban agenda of survivability.

So, the “flow manager” concept is called the Service Delivery Manager. It is primarily intended to be a role played by an existing member of staff and not a new job title or position. So, by creating Service Delivery Manager, we do weaken the message that no one gets new responsibilities – actually someone does, the someone who takes on the SDM role.

The SDM role existed in 2007 in our first full scale Kanban Method implementation. It was usually played by a project manager from the PMO. The SDM carried responsibility for the Replenishment Meeting, the Delivery Planning Meeting, escalating blocker tickets, and what we would now call Risk Review. Replenishment, Delivery Planning and Risk Review are 3 of the Kanban Cadences.

In more recent implementations the SDM also facilitates the daily Kanban Meeting. In 2007, this role was taken by one of the function managers in the workflow. The SDM role was usually played by someone from the PMO.

Service Request Manager

For some number of years, the question has existed, what do you do with middle-men in the workflow? As a general rule, we wish to remove non-value-adding middle-men positions from the workflow. However, we also wish to avoid resistance to change. These are two core tenets of Kanban coaching and general goals we might have for change management when deploying Kanban in an organization. And the following guidance has existed since 2009: we seek to elevate the role of the middle-man, above the workflow, out of the value stream. The most common example of this is shown in the diagram, “What do you do with the Product Owners?”

The goal is to reposition the role of product owner as a risk manager and facilitator: someone who owns the policies for the system which frame decisions together with facilitating the decision making mechanism. This role is of higher value, is transparent and open to scrutiny and relieves us of the risk of the “hero product owner” who magically understand where the best business value is to be found. This elevated risk management and policy owning position improves corporate governance, improves consistency of process, and reduces personnel risk associated with a single individual.

Nevertheless, an individual with a “hero product owner” self-image will resist such a change. Kanban Coaching Professionals are trained to manage this resistance as part of their training in the Kanban Coaching Masterclass.

When the product owner is successfully repositioned above the workflow as the owner of the policies for risk assessment, scheduling, sequencing and selection, they have successfully transitioned into the Service Request Manager (SRM) role.

Again, we are weakening the “no one gets new responsibilities” principle, but this transition is generally managed over a period of time and isn’t necessarily thrust upon individuals at the start of Kanban adoption.

When the SRM role exists, the SRM usually takes responsibility for the Replenishment Meeting and will play a role in the Strategy Review and Risk Review.

When Do We Need SDM & SRM Roles With Kanban?

January 6, 2016 by David Anderson

With the emergence of the SDM & SRM roles with Kanban, we need to ask the questions, when do we need these roles? When do we need both? And are they merely roles an existing member of staff takes on as new responsibilities, or might they be new positions for which we need to hire? This post provides guidance based on what we’ve seen in the field so far.

rolesandservicedeliveryworkflow

When do we need a Service Delivery Manager?

I genuinely believe you always need a service delivery manager. This role has existed since the first Kanban at Microsoft in 2005. In the early days the SDM role was always played by a project manager. So it isn’t a new position but a refinement of existing responsibilities for an existing member of the staff. The SDM is therefore a role played by someone external to the value stream or workflow.

In the upper diagram, a service delivery workflow is shown spanning a functionally silo’d organization. The SDM facilitates the Replenishment Meeting receiving customer requests and facilitating a collaborative decision making process to select, sequence and schedule work to flow through to delivery. The SDM will collaborate with the functional manager or team leads and play a reasonably active part in the day-to-day operation of the kanban system, definitely attending and perhaps facilitating the Kanban Meeting.

It’s been reported to me that in some organizations, the concept of a service delivery workflow is very weak, while the functional silos and structure are very strong. Usually, such companies lack any significant focus on customer satisfaction or any service-orientation in their thinking, mindset or value system. I’ve specifically had this reported to me from a large Swedish industrial company and several companies in China in the technology or finance sectors. In these instances, the change agents, usually process coaches or members of the PMO, felt it was necessary to create the Service Delivery Manager role as a specific position within the firm. The act of doing so, is actually making a very clear commitment to service delivery and customer satisfaction. In other words, the bar for the change initiative is raised – senior leaders are being asked to acknowledge that service delivery and customer satisfaction are important. They are being asked to explicitly put customer focus in the spotlight and make it part of the corporate value system. This is a non-trivial but hugely important step.

So where there is a current lack of customer focus and a lack of understanding of existing service delivery workflows, where the concept is weak, you need to create a position for SDMs.

When do we need a Service Request Manager?

A Service Request Manager is likely to be needed when contact with the customers, or service requestors is weak or distant. The SRM becomes a proxy or advocate for the customers. However, it is important that we don’t place the SRM in a decision making role. We don’t want them becoming a dysfunctional proxy for the customer, showing bias towards one over the others. We always want the SRM as the facilitator of selection not the person doing the selection. In organizations, where contact with the customers is weak, there is often already an intermediary possibly a sales engineer, an account manager, a product manager or in Agile adopting organizations a product owner. So we want to elevate that person’s role into the role of SRM. It is a set of new responsibilities, not a new position.

When the SRM role exists, the SRM will take on the responsibility for the Replenishment Meeting and will play roles in the Strategy Review and Risk Review.

When might we need SRM as a new position? If the SDM is the “flow manager” for service delivery, then the SRM is the “flow manager” for ideation or discovery. So we might expect to see SRM emerge as a specific role when we have an upstream or discovery kanban system. The more focus we have on ideation, option validation and discard, and discovery and validation of concepts (or minimum viable products, MVPs) the more likely we are to need a SRM as a specific position in our organization.

discoverydeliverywithroles

The SRM role is described as “marshalling options”. This is the act of facilitating flow, and discard or upstream kanban work.

When might we need both roles?

In discussing this amongst my colleagues and with leaders in the Kanban community, Mike Burrows commented, “I have seen the need for one or the other but never both.” And that is probably a fair statement, we have seen firms adopting SDM or SRM roles but so far we haven’t seen both, at least not explicitly. With larger scale ESP implementations, we do see a lot of SRMs. One client advertised for SRMs by placing job advertisements for Product Owners. This makes sense. You recruit for a title that people are familiar with, then you mold them into what you need. That client has a strong sense of service delivery and without doubt function managers or team leads are playing the role of SDM. It just hasn’t been made explicit in that company.

So I suspect that as we see greater emphasis on the use of Kanban upstream and the growth of Enterprise Services Planning, with business emerging where ESP/Kanban is _the_ way that they manage their professional services company then we will see strong growth and use of both SRM and SDM roles.

At smaller scale and where there is little ideation, option development and discard, and a strong connection to the customer together with a strong sense of service delivery, in these cases, I expect only one role, SDM, played by an existing member of the staff. So Kanban as we knew it in 2005-2008 doesn’t involve new positions or additional headcount, but the future with Enterprise Services Planning, particularly in organizations with a weak sense of service delivery and a lack of customer focus, we are likely to see the new job title of Service Delivery Manager emerge. In companies that do a lot of innovation and act as a market leader in an uncertain and emerging market, we are likely to see the emergence of Service Request Manager as a new position. Where both circumstances exist, we’ll see both roles in use, perhaps both as new positions and additional headcount.

Kanban Does Not Share Your Agile Team Agenda

January 5, 2016 by David Anderson

In November 2013 the Kanban coaching community agreed that we recognized 3 specific agendas that come with Kanban implementations: sustainability; service-orientation; and survivability. The first of these three is shared with Agile software development methodologies. The other two are distinctly unique to Kanban and its focus on improved service delivery and evolutionary change. However, Agile software development methodologies come with a distinct cross-functional team agenda. Kanban does not share this, nor does it need to in order to produce exceptional process improvement results. The Kanban approach is to visualize, improve transparency and understanding, reduce coordination costs through the use of boards. Visualize, Don’t Reorganize!

Agile consultants like to talk about teams a lot. My Kanban book talked about teams a lot too. And that was a mistake. I was using team to mean “a group of people who come together to achieve a common goal.” However, in Agile vernacular a team is actually an organizational unit, albeit, one that has been constructed to have a common goal or purpose, such as delivering working software. Agile Consultants generally set about reorganizing you into “teams” and when the work has variation and variety in it that require multiple specialist skills then these teams are referred to as cross-functional teams – teams containing multiple functions. The goal is to eventually cross-skill people on the team so that they are generalists who can perform all and any function, or T-shape people, who have a broad skillset at a shallow level of competence while maintaining a specialization in a single narrow skill with a deep level of competence.

The Agile bargain is that the pain of the reorganization will pay off in the performance of the new cross-functional teams, that they will achieve high levels of efficiency by eliminating delay in hand-offs between functions and eliminate coordination overhead between different functional groups. If you contain everything you need in a single organizational unit then you don’t have to worry about external dependencies. If these organizational units can be small, say 6 people, then coordination overhead should be minimal to non-existent.

And let’s just say that it works. Let’s not even challenge that theory with any performance data or anecdotal evidence that Agile organizations actually spend a lot of time and coordination overhead resolving dependencies and negotiating for scarce skills and availability of shared resources. Let’s ignore that often there aren’t enough scarce skilled people to go around and that bickering, in-fighting and land-grabbing behavior becomes common during Agile planning. Let’s ignore all of that and assume it works.

What I would like you to consider in this post is this, how expensive in time, money, stress and anxiety is the reorganization into these cross-functional teams? I’d like to posit that a large amount of the pain of Agile transitions and the large amount of the coaching needed for new Agile teams is caused by the stress of reorganizing into cross-functional teams. In other words, one of the reasons Agile is costing so much, is because of the cross-functional team agenda.

Kanban does not share Agile’s cross-functional team agenda. Instead Kanban solves this problem a different way. The diagram explains how. The upper half shows a simplified functional organizational hierarchy divided into 8 functions labeled A through H. Each of these functions is a functional team – a group of specialists in some skill or professional service.

The customer makes a request which involves provision of 7 of these services. The Agile solution to this would be to reorganize into teams with all 7 of these skills represented. Kanban takes a different approach. Kanban is the, “start with what you do now method” and that means you start with the organizational structure you have now. Instead Kanban asks us to model the workflow for the customer service request. We would do this using the STATIK (Systems Thinking Approach to Implementing Kanban) method taught in the 2-day Kanban Systems Design classes from Lean Kanban University. This would give us the Kanban Board displayed in the lower half of the diagram. The Kanban Board is said to be “service-oriented” because it models the required service from the customer’s perspective. The board enables members from all 7 teams to collaborate to deliver the service requests to the customer.

This diagram is simplified for pedagogical purposes. In reality the board design may not have a 1-1 mapping from functional team to column or state in the workflow. Some functions may happen in parallel or in an undefined sequence. We may choose to model activities to be performed using checkboxes on the tickets rather than columns on the board. There is a lot of subtlety and most of these nuances are covered in the training. A qualified Kanban Coaching Professional would be expected to provide guidance on when to model an activity on the board and when to model it on the ticket.

Kanban delivers on the definition of team, I envisaged when writing the Kanban book, “a group of people who come together to achieve a common goal.” The common goal is satisfying the customer request. It is a service-oriented goal. The board and the ticket design provide visualization and insight on the goal. We have plenty of case study evidence to show that this approach works. Many Kanban adopters report increased levels of collaboration at their firms and that this was achieved without painful reorganization, or allocating anyone a new role, responsibility or job title. Kanban improves collaboration through customer focused visualization and creating shared goals for dynamically formed teams of people drawn from different functional groups. With the right board design, it works for shared resources, shared services, functional silos, and of course, it will always work for existing cross-functional teams.

The results from Kanban have been impressive since the beginning. In 2005, the first kanban system spanned across three functional groups and resulted in 230% greater productivity, 90%+ reduction in lead times, and 0% to 98% improvement in predictability and on-time delivery performance. Since then these numbers have been shown to be somewhat mundane. 400% is often reported. 800% has been reported. 50%-90% drops in lead times are common. All of this is achieved without the pain of reorganizing into cross-functional teams; without the pain of Agile transition initiatives; without the cost of Agile transitions and the overhead of Agile coaching.

So even if the cross-functional team does deliver greatly reduced coordination overhead, and even if this does make them “awesome” and “hyper-productive”, and frankly that is a debate that really needs to be had, and if there was any reasonable data, it needs to be studied carefully, but let’s imagine it is all true, given that would it still be a lot faster, easier, cheaper and better to land 200-800% productivity gains, and 50-90% reduction in delivery times from starting with what you do now, and Kanbanizing it? Visualize, don’t reorganize!

Is Agile Costing You Too Much?

January 4, 2016 by David Anderson

For a decade now, Kanban has offered an alternative path to agility. At the time of writing my first book, Agile Management for Software Engineering in 2002, I believed that an alternative path was required because too many people were resisting adoption of Agile methods. After publication in 2003, I set about pursuing an alternative and Kanban is what emerged from that journey. So Kanban was for people and organizations who found Agile wasn’t a good fit for them, wasn’t suited to their culture or the nature of their business.

At the start of 2016, I’d like to take a closer look at why we need an alternative path to agility and identify the problems that are evident in the market with Agile methods and their adoption. The first in this series asks the question, “Is Agile costing you too much?”

In 2011, we collaborated on a conference in Finland called LESS. During a panel session which I facilitated, one question from the floor was “It seems to me, listening to the sessions at this conference that Kanban obviates the need for the Product Owner role in Scrum. I’d like to ask the panel, what would you do if you’d recently hired 400 product owners?”

Me, “I’m sorry, can I clarify that I heard you correctly, I thought I heard you say ‘400 product owners?'” “Yes, that is correct!”

“How many developers do you have?” “2,400. Our Agile consultants told us we needed one product owner for every six developers. So what should we do with these 400 new people we have hired?”

Last month, my colleague, Alexei Zheglov, was speaking with an Agile coach whose contract hadn’t been renewed. It is never nice to be laid off at Christmas. What had happened? Well, this coach responsible for coaching just six developers wasn’t renewed because there weren’t sufficient tangible benefits to justify the overhead. His contract was costing $150,000 every six months.

On December 24th, I met the CTO of a bank in China. This fairly mature IT organization was running a side-by-side comparison of Kanban against Scrum. The consultants and trainers for both methods were being supplied by the same firm in Shenzhen under a single purchase order. The Scrum coaching was requiring one fulltime Scrum coach for every twelve employees.

Late in 2014, I did some consulting for a large telecommunications equipment manufacturer here in the US. Specifically, I was advising a business unit based in sub-urban Boston. The general manager had brought me in because in his own words, “We’ve been doing Scrum for 6 years but we haven’t seen any improvements for at least the last 2 of those years.” The business unit had a Scrummaster for every 6 developers. I attended several retrospectives, usually facilitated by one Scrummaster and then each of the others in turn had an opportunity to speak up and report the Sprint for their teams. Later in the engagement I was discussing the need for someone to play the role of Service Delivery Manager for a kanban system. The GM asked me who should play that role. He suggested no one in his business unit had the skillset. So I innocently asked, “What do your Scrummasters do?” He replied that “they coach the practices of Scrum.” Since then I’ve come across many companies who describe their Scrummasters as Agile coaches and the ratio of coach to value-adding workers is in the range of 1:6 to 1:12.

The role of Product Owner is interestingly ambiguous in its definition. In some organizations, Product Owners are basically business analysts who write requirements. While in others, Product Owners have a role that is very specific to prioritization and they are the decision makers with respect to the sequencing of the work. Ken Schwaber described the Product Owner role as “the single throat to choke” and he clearly had decision making, responsibility and accountability in mind when he used that term. For many the Product Owner is an interface between multiple competing business stakeholders and the delivery organization (or Agile team.) The Product Owner is a curious addition for Agile. At the founding of the movement, Agile was in part about removing middle-men, eliminating signal attenuation and having direct contact with customers – conversations rather than documentation. It is strange, therefore, that to facilitate such a process we need a new form of middle-man, the Product Owner, to prioritize the order of the conversations. Regardless, of exactly what the Product Owner actually does in your organization, it does seem that often these product owners are new hires to the organization and again the ratio of 1:6 seems to be common. One of our own clients in 2015 made a decision to hire about 20 such Product Owners. While it goes against standard Kanban coaching guidance, the client had their own reasons and justification for the decision.

There is a question whether the product owner is a value-adding role or not? In many organizations it appears that it is not: The product owner is a middle-man with authority over prioritization. While sequencing and scheduling when done well will generate value, the act of sequencing one item over another, does not add value to the items themselves and from a Lean value stream mapping perspective it’s a non-value-adding role. Even more curious then that Agile requires you to create non-value-adding positions.

So in some extreme cases, Agile methods appear to have added 2 new people in non-value-adding positions for every 6 in value-adding positions. Put another way, after the Agile transition, 25% of the workforce is additional “Agile” overhead for operating the Agile method. While this is at the higher end of the range, I believe that it is typical for operating expense budgets for IT / product delivery teams to be increased by around 14% to cover the overhead of non-value-adding Agile facilitation positions.

What about Agile training? There are many 2-day, and in the case of scaled Agile solutions, 3 and 4-day training classes available. Many of these come with short examinations at the end and certifications for passing. However, what appears to be the case is that these training classes do not prepare the workers to behave in an Agile fashion or to deliver the promised benefits of Agile methods. The classes often contain abstract or metaphorical content and are filled with games which while fun to play do not teach specific actionable behavioral change in the workplace. All of this is okay, because the Agile transition purchase order includes coaching as well as training and the coaching is essential because the training did not contain anything actionable. The workforce, however, are now “certified”. Strangely this certification does not mean they know how to behave differently or how to produce better outcomes. It appears to mean that they are now certified to receive coaching.

Let’s imagine for a moment that Agile was producing twice as much value than what preceded it. If this were true would you spend 14% more on operating expense in order to generate that additional value? Rationally, you would say yes. It is an obvious and simple executive decision. The ROI is clear. And therein lies the rub with Agile. How many supposedly Agile organizations can show such benefits? The best and most popular Scaled Agile Framework appears to scale by offering quarterly release planning and using 3 month time boxes. The so called “release train planning” involves getting everyone in a room together in order to resolve dependencies between work and to devise a suitable schedule of six incremental 2-week sprints.

One company I know of in Central Europe, transports up to 500 people by plane, train or private cars, to a location near Frankfurt every quarter in order to conduct the scaled Agile release train planning. What is this costing? If we conservatively budget 800 Euros per person for transport, lodging, and catering, and assuming the company has a meeting facility large enough and isn’t renting a banquet hall from a nearby hotel, then we might have a budget of 320,000 – 400,000 euros per quarter.

Meanwhile, releases are only coming every quarter. How often were releases happening prior to the adoption of Scaled Agile? And how much functionality was getting released? Is there any tangible evidence that Agile is delivering the additional value it claims?

I hear other claims that Scaled Agile is leading to inefficiencies synchronizing teams with some teams having to take down time while others catch up. So the efficiency of Scaled Agile is being called into question by some of its practitioners. I haven’t seen this explicitly with any of our own clients, so it is hearsay, until I have some solid evidence.

Around 10 years ago I worked with a group of Agile coaches from Sabre Holdings, a firm which included properties such as Travelocity and Last Minute. They were under pressure to show an ROI for the Agile coaching team. The Agile coaching department was costing around $2,000,000 per year and the senior leadership wanted, quite reasonably, to know what they were getting for that money. After some period of time, the group was unable to show real tangible ROI and it was closed down. Some of those coaches found employment with other Agile firms such as Rally. After a period of time, Sabre was once again dabbling with Agile and the costs for consultants and staff augmentation were mounting up. A decision was made to create a new in-house team again. This time the justification was merely deferred cost against consultants and temporary staffing. It was no longer necessary to show an ROI on value created, just enough to show that the internal cost was less than using outside help.

So there have been 15 years of Agile and yet we still don’t have very many case studies showing tangible business benefits and real ROI. Meanwhile, Agile consulting firms thrive on supplying the large numbers of coaches required to “go Agile.” Perhaps, it is time to ask, “Is there an alternative approach to agility that costs a lot less?”

Back to the CTO of the Chinese bank that I met on 24th December. He told me that in 5 months, he’d managed to scale Kanban to 2000 people across 5 locations in China. That the adoption had institutionalized and he’d been able to make a tour of the various locations and inspect many of the Kanban implementations for himself. He told me that Kanban was producing greater productivity and efficiency than Scrum. He, however, didn’t elaborate much, and isn’t ready to share his data. He wants more evidence before he is prepared to go public. What he was willing to share is that the Kanban implementation had been achieved with a total of 200 days of training and consulting. This is a ratio of 1 day for every 10 employees. Meanwhile, Scrum coaching is costing 180 days for every 12 employees, in the same half year time period. He also confirmed that Scrum is failing to institutionalize and is requiring constant coaching.

To put this in perspective, in terms of per employee adoption cost, Kanban is costing this bank 1/150th of the cost of Scrum, and producing better results. How might this huge cost saving be possible? Well, for starters Kanban doesn’t require you to add people to your organization as coaches or product owners, instead it provides existing workers with a means to frame and make better quality decisions. Kanban is empowering and enabling. Workers become more effective at doing their existing jobs in the existing process and workflow – no need for coaching in a new role as part of a new process. It’s simply more effective to stick with what you do now and get better at it, than it is to make grand changes.

We are inviting executives from this Chinese bank to speak at our Spring conferences in London and San Diego. We hope to have both cost and value/productivity data to report by that time.

A week earlier I was in India where I saw a case study presented by a young consultant who was acting for a large Agile consulting firm, advising a large Indian outsource firm, to a large financial institution based in New York. Because of the nature of the contracts between these firms, the actual details are covered by a non-disclosure agreement, so we can’t name names, or any specifics. The client had adopted Scrum largely enterprise-wide and had adjusted all their processes to facilitate a 2-week Sprint cadence. Despite this highly Agile sounding arrangement, actual customer lead times for changes to credit card processing systems were taking 130 days on average. With some courage, the consultant took it open herself to push through a single kanban system implementation. With no other changes, within 6 weeks, lead times had shrunk to just 12.5 days and the client was so happy they are pushing the consulting firm to implement more Kanban. This particular consulting firm is well known to be anti-Kanban and their sales people around the world actively dissuade clients from adopting it. So it took a courageous act from a single professional keeping the client’s best interests at heart to create a huge improvement in value delivery.

That same week in India I saw another presentation where the kanban system had produced a 30% increase in revenue by enabling the firm to process more service requests faster. This is real ROI. Now would you spend 14% on OpEx to get 30% more revenue? Probably not! Revenue isn’t margin or profit. If you only got 30% more revenue but Agile was costing you 14% more OpEx you’d be losing money. The thing is, how many Agile implementations could claim 30% more revenue? Meanwhile, this Kanban implementation cost a handful of coaching days over 6 months. This story was a strange déjà vu with a case study presented at Lean Kanban Benelux by Tina Dudenhoeffer, a consultant, and Marianne Lanting of Winkle. Again, they had increased revenue by 30% in only 5 months by servicing requests for market research surveys faster and more predictably using Kanban. The cost of this implementation was less than 20 consulting days from Tina plus training from Maarten Hoppen of our partner VX Company. Marianne is a manager at Winkle and there was no additional cost for her.

In general these results while extreme sounding isn’t surprising. We already know from surveys and reports post Kanban training that our training is more effective than typical Agile training. Lean Kanban training is specifically experiential and uses games, simulations and exercises that simulate or model the actual working environment. Students leave our classes with specifically actionable ideas and designs for changes many of which can be implemented immediately at no or very low cost. They don’t need any or much coaching. They come out of the class understanding what to do and why they want to do it.

For 5 years now, we’ve been selling Kanban coaching engagements that typically look like 2-4 days per month for organizations up to a product unit (or 150 people) in size. Kanban coaching is typically centered around coaching managers on metrics, reporting, and holding the various Kanban Cadences meetings such as Service Delivery Review, Risk Review or Operations Review. We have often found ourselves bidding against Agile consulting firms recommending coaches are on-site for 4 or 5 days per week and often at the ratios we’ve discussed here 1:6 -> 1:12 people. Bizarrely clients have often opted for the latter, usually for 2 reasons. We don’t quote hourly rates for our consultants, only daily rates, and if you do try to calculate an hourly rate, it will be higher than that for a typical Agile coach. We aren’t ashamed of this. We believe our coaching is far more effective because it focuses on high leverage activities that deliver more value, rather than on Agile practice adoption and behavior. Meanwhile, the quantity of consulting days and the number of consultants is dramatically less. Often clients are skeptical of this. Everyone else is advising them they need a lot of Agile coaches and a lot of coaching. They believe it is too risky to go with our model when we appear to be bucking the trend. It seems easier to follow the herd. It is common for us to be quoting less than 1/10th the cost of rival Agile consulting firms, typically, $30,000 – $50,000 against $300,000 – $500,000 and then to be told we didn’t win the business because, and to quote a VP from a travel technology firm, “You are too expensive!” This analysis was based on an hourly rate and not on a total contract cost. Sigh!

So, while we have a bank in China that is rolling out Kanban at large scale at less than one hundredth of the cost of Scrum, we have been and continue to be confident that Kanban, as your alternative path to agility, can be rolled out at only one tenth the cost of competing Agile and Scaled Agile methods. We are prepared to put our money and reputation where our mouth is on this, because we are more than confident with years of experience and real data that we can make it work. So, this month we are launching “The Kanban Challenge” – give us 10% of your Agile budget and we’ll promise to outperform the other 90% producing more and better results over a 6 to 18 month time period. Some conditions apply to this offer so do approach our sales team directly for full details if you are interested.

After 15 years of Agile, it is time that developing true business agility stopped costing you as much as 14% of your OpEx budget. So discover “the alternative path to agility” and take The Kanban Challenge in 2016. Let us show you how much is possible at just a fraction of the cost and impact of Agile methods. Watch out for the launch of The Kanban Challenge later this month. Until then please feel free to contact our sales team with any questions.

Kanban – The Alternative Path to Agility

July 15, 2015 by David Anderson

The Kanban Method was conceived as an alternative path to agility – as a means to improve responsiveness and adaptability without any significant revolution or reorganization in your way or working or political structure of your business. Lean Kanban University has recently introduced a series of training classes developed and evolved from older, tried and tested curriculum to ease adoption of Kanban and communicate the full scope and scale of what is possible when you fully embrace Kanban as a way to manage your modern professional services business.

This table shows The Kanban Method and the alternative path to agility is a single graphic. From left to right you progress from basic introductory shallow kanban boards to full enterprise scale, Enterprise Services Planning.

kanbaninatable

In September our new training facility, the Anderson School of Management opens in Seattle conveniently located near Seattle Center at 200 First Avenue West. We will be offering the full suite of Kanban and Enterprise Services Planning classes every month. Browse our schedule via our training listings. Email our sales team for summer offers and promotions if you register before August 10th, 2015.