Category Archives: Kanban

Kanban, Scrum, XP and Lean, Uncategorized

The Real Relationship Between Scrum & Kanban

3 Comments

(Image: Cover image of the book Essential Kanban Condensed by David J. Anderson and Andy Carmichael.)

Many people I interact with seem to believe that Kanban is another Agile methodology for helping Agile teams manage their work. The aim of this post is to help people see how Kanban can be so much more.

I am aware that there are some who believe that a high performing, self-organizing, cross-functional Agile team is as good as it gets and that it is the job of Leadership to change the organization such that this kind of team becomes a reality. This is a belief that I also held for many years, during which time I actively advised my clients to pursue this lofty goal and I invested a great deal of time and effort towards helping them achieve it. I understand this belief. It is very powerful, so powerful that it shapes identity. Therefore, it was a big part of my own professional identity and this was not easy for me to change. I empathize with those who struggle in similar ways as I have.

I could go on with my personal story, but I’ll get back to my opening statement. Kanban is so much more than just another Agile methodology. So what does this mean? How can it be so?

In my own experience helping businesses improve for over a decade and from the many stories I’ve listened to of the people I’ve met in my consulting engagements, training classes, conferences and meetups, the ideal of fully cross-functional teams is not a reality, not even a feasible possibility for their organizations and this reality is causing them pain and harm.

Let’s be clear about what we mean by cross-functional teams: According to the Scrum Guide (paraphrasing), a cross-functional team is a team that possesses all the skills required for starting and delivering potentially releasable product increments in a Sprint. A Sprint is a complete project that must be completed in one month or less. Many organizations add to this the idea of establishing stable teams (membership does not change) and Sprints of 1-2 weeks in duration. For many organizations, integrating all of the above is simply not realistic.

Most people I meet who are working with Agile teams (mostly Scrum teams) have already done everything they can to create the conditions for their teams to realize this ideal. Teams are already as “Agile” as they can be under the current constraints. Leaders have already done everything in their power to remove the constraints.

Some would describe this as a “failed Agile transformation”. But it need not be so. Rather, I have begun to see it as a natural stage in some organizations’ maturation process. Perhaps at an organizational level it is analogous to the “Storming” stage of the Tuchman maturity model: “Forming”, “Storming”, “Norming” and “Performing”. Regardless of the best analogy, the important point is that an apparent failed transformation does not have to be a bad thing. It also doesn’t mean you need to start all over again (with another re-org) in the hopes that you will “get it right” the next time. Rather, it is a natural stage of organizational maturation and the frustration, pain and conflict you are experiencing are telling you that your organization has an opportunity to evolve.

Kanban helps organizations move beyond this difficult stage. The Kanban principles of service orientation and evolutionary change help organizations focus on improving survivability of the business and the sustainability of the work. All of the Kanban practices are evolutionary stimulants for whole-organization improvements and they all scale naturally to all levels of an organization.

Kanban can help Scrum teams. Kanban can help with project, program and product management. Kanban can help with portfolio and enterprise services planning and management. Finding ways to implement the practices, little by little, at all levels of your organization will enable your organization to become fitter for the purposes of your customers, fitter for survival.

The Kanban Method, as opposed to other approaches, has built in double loop learning feedback loops. This makes it always contextually appropriate to help any organization. -Martin Aziz

The Kanban Principles:

Change Management Principles:

  • Start with what you do now;
  • Agree to pursue evolutionary change;
  • Encourage acts of leadership at all levels;

Service Delivery Principles:

  • Understand and focus on customer needs and expectations;
  • Manage the work, let people self-organize around it;
  • Evolve policies to improve outcomes.

The Kanban Practices:

  • Visualize the work;
  • Limit work in progress;
  • Manage the flow of work;
  • Make policies explicit;
  • Implement system feedback loops;
  • Improve & evolve with data, models and the scientific method.

 

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile coaching, coaching, Kanban

On Commitment In Kanban

2 Comments

Most people would rather be wrong than uncertain. When the prospect of being right is questionable, human beings would rather commit to a position and be wrong, rather than hold a posture of uncertainty and avoid commitment altogether.

Our order of preference is: #1 – to be right, #2 – to be wrong, and #3 – to remain uncertain. Why #’s 1 and 2? Because we are addicted to the false sense of security that commitments give us.

Organizations that are part of a domain where uncertainty is high, such as knowledge work or professional services, pay a heavy price if they take a similar approach to commitments about what and when to work on customer requests.

Making too many commitments results in unpredictable delivery times. We have so much work in the system that we really have no idea when things are going to get done. There are too many potential outcomes (variability) stemming from unmanageable levels of work in progress (WIP). Unfortunately, even though customers are going to be disappointed, we feel good because many things have been committed to. That’s a false sense of security.

We are emotionally attached to the idea of just saying yes! However, many ideas that initially seemed like good ideas are often discarded once we receive more information. In fact, 50% is a commonly observed discard rate! We should strive to keep customer requests optional for as long as we reasonable can. We should also limit the amount of time we spend in the care and feeding (grooming) of optional work – especially if 50% of it is likely to be discarded.

Another downside of committing too early is that we are more likely to abort the work once we have already invested time and money in starting it. Why? If you say yes to everything, or say yes too early, you’re likely agreeing to a lot of bad ideas! We become so emotionally attached to our commitments that it can be hard to let go. Choose wisely!

It is ideal to keep work optional and un-prioritized for as long as you can. Options have value in uncertain domains.

Developing options before converting them (committing) is an important risk mitigation strategy. It does cost money to develop options, but think of it as buying insurance to protect you from much larger negative consequences down the road (like starting work you did not really want to do and having to abort it at great expense). The more uncertain the environment, the more insurance you are likely to want.

Okay! So committing to start work too early (or taking too much of it on) and not keeping our options open can be a costly strategy in uncertain domains. We should aim to defer commitment and keep customer requests optional for as along as we reasonable we can!

How do we do that?

The Kanban Method encourages deferred commitment and provides a set of principles and practices that are receptive to developing an approach to managing risk that enables work to remain optional. In doing so, service delivery of customer requests is more predictable and reliable. It also helps to increase the likelihood that we are working on the right things at the right time.

Constructs within the Kanban Method that help to leverage deferred commitment are:

  • Upstream Kanban – a way to marshal options before the commitment is made.
  • Clearly identifying commitment points.
  • Two-phase commitments: a commitment to start and a commitment to deliver.
  • Mechanisms to funnel options (pay our insurance) before we choose to convert them.
  • Shaping Demand – a way to balance demand with capability by allocating capacity to certain types work and risk.
  • Enabling a responsible approach to the discarding of options so that we can avoid aborting after commitment.
  • A practice of limiting the amount of work in the system so that we do not make commitments that exceed our capacity and make our delivery unpredictable.
  • Visualizing the flow of work and the policies around our work – so that when we do commit, we can meet our promise to deliver.
  • Visually seeing the interruptions to the flow of work in a WIP limited system encourage us to have discussions and evolve our policies.

If you are interested in learning more about each of these practices and how to apply them in your place of work, consider signing up for one of my premium management training workshops. I offer three LeanKanban University accredited management classes:

Team Kanban Practitioner

Kanban System Design

Kanban Management Professional

Follow me on Twitter @jamesdsteele

 

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile coaching, Agile Management, agile training, Kanban

On Managing Work – Not People

4 Comments

Most leaders I work with have a common frustration they express to me: an inability to achieve significant gains in how quick and predictable they are in delivering work to their customers.

In my work as a consultant, coach, and trainer, there is one strategy that I help them discover that results in dramatic change to their thinking and how they view work and workers within their organization. So what is the strategy?

Flow Efficiency

Work items (ie: user stories, features, epics), or whatever artifacts represent customer recognizable value within your context, can spend their lifespan alternating between two states: active and waiting. Work is active when we are currently engaged in adding value to a work item – it has our attention and we are actively working on it. Work is in a waiting state when it has been started, but is then interrupted (for a variety of reasons) to address something else. The active time in relation to the total lifetime of a work item is a construct known as Flow Efficiency. An understanding of this relation can have serious implications on how you view your work and the decisions you make.

It’s expressed as a percentage using the following formula: (Active Time / Total Time) * 100

Here is an example. A user story has taken 26 hours to complete (from start to finish). Out of that 26 hours, only 2 hours where actually spent working on the item and 24 hours of the total was in a wait state. That is a flow efficiency of 7.7%.

( 2 / 26 ) * 100 = 7.7

You may be surprised – as are many of my clients and students – to discover that in knowledge work (ie: Software Development) a typical flow efficiency is measured at 4-8%! In fact, 40%+ would be VERY good.

Think about that!

This means that work items spend their existence primarily in a waiting state. Even though we have started to work on something, 92-96% of the time we are not adding value to the work item! There are numerous reasons as to why work items are placed in a waiting state: task-switching, queues, blockers, internal/external dependencies, etc… (Remember: If you are working on more than one item, every time you put aside one item to work on another, that item effectively goes into a wait state.)

So what are the implications of a low flow efficiency system and how might it change how we work and the decisions we make?

Implication #1: How busy people are is largely irrelevant.

20th century management techniques have engrained in us an obsession with the high-utilization of people. Everyone must be busy working on as many work items as they can.

This stems from a desire within us to measure what we can see, and unless we are in a manufacturing environment, what we can see are usually people! In knowledge work we can’t see the work going on – it is for the most part invisible. It happens inside people’s heads. Yet managers consume themselves with ensuring that people are busy in the hopes that this will churn out more work in less time. And even if it doesn’t, at least they can claim they were getting the most out of their people!

In a low flow efficiency environment high-utilization of people is not the path to greater speed and predictability. The fact of the matter is that if work spends the majority of it’s time in a waiting state, then it really does not matter how busy people are – to the contrary. More work for individuals in a low efficiency environment only contributes to a degrading flow efficiency – particularly because of task-switching.

Customers are not paying for key strokes. They don’t care how busy your workers are. They care about speedy delivery, reliability, and quality. Idle work, not idle people should be the centre of your attention. Your customer’s needs will be more positively impacted by focusing on the flow of work (and removing delay within that flow), not the utilization of people.

Implication #2: The performance of people is largely irrelevant.

In an effort to increase the speed and amount of work that teams deliver, the response from most managers is to hire more people and/or make people work faster and harder. The majority of my coaching engagements usually begin with a manager meeting with me and pleading for help to “please go make my teams faster”! Thus begins the process of me helping them understand that if they are in a low flow efficiency environment (they usually are) focusing on improving the performance of individuals (or hiring more of them) is not really going to have much of an impact in addressing their pain points. Why?

Imagine this frustrated manager has an environment where flow efficiency is 6%. So 94% of the time work is in a wait state, and only 6% of the time is value actually being added to work. If we choose to focus on optimizing the performance of the 6% of active work, any improvements are going to be very marginal on the overall increase in delivery time of work over its entire lifespan – we are only addressing 6% of the total!

Let’s suppose that out of that 6%, that 2% of that time is development work. Even if you make your development team 10 times faster, or double the size of your development team, you are going to have very little impact on the whole.

The opportunities for improvement that are really going to shift the needle in delivery times and predictability are in tackling the 94% of delay that exists in the flow of work. In such an environment we need to help managers move away from managing and measuring people, and instead managing and measuring the flow of work.

Implication #3: Your estimates are doomed.

Most organizations are horrible at estimating. There are numerous reasons for this, but a key contributor to why our estimates are so unreliable is that when we estimate we are producing “effort” estimates. We are estimating the amount of effort we think it will take to complete a work item, and when we do this we are estimating the 4-8% of active value-adding-work-time we anticipate to incur. But we are NOT estimating the amount of wait time that our work item is going to spend in its lifespan. That’s 92-96% of the lifespan of a work item that we are not taking into consideration. No wonder we are so far off in our estimates. We can try and game the system by adding buffers to our estimates, but alas this tactic is often futile and detrimental to developing predictability.

Implication #4: Focusing on team performance is not the path to business agility.

It has been my experience, that in most organizations of more than 50 people, the notion of self-organizing cross-functional teams is a fantasy. Time and time again, when I look at how work flows through an organization, it rarely exists within the boundary of one team and independent of any other teams. What I more commonly witness are cross-functional silo’d teams that have dependencies between each other.

Even more detrimental to the delivery times and predictability of our work is the delay that exists between teams. If work is flowing through more than one team (it usually is) and that work is not arriving to the right-team-at-the-right-time then delay is going to be introduced – and with delay we have negative impact to our flow efficiency.

It won’t matter how optimized individual teams are if the flow of work amongst them is not managed to create smooth flow. Business agility is not achieved by how many high-performing teams you have, but rather, how well you manage the interactions amongst teams.

“The performance of a system is not the sum of its parts. It’s the PRODUCT of its INTERACTIONS.” – Dr. Russell Ackoff.

Let’s Do Something About It

Now that we are aware of some of the implications of a low flow efficiency, what practical and actionable guidance should we consider in order to improve our service delivery and deliver value to our customers when they need it? How can we do this in a way that favours managing and measuring work OVER managing and measuring people?

Visualize work: Knowledge work and professional services are domains in which the work we do is largely invisible. We need to find a way to make this work visible so that we have something tactile that we can have conversations about. We need to see how-our-work-works!

Limit the amount of work in progress: If we are to catalyze improvements in how we work and develop a sustainable pace, we need to start limiting the amount of work we commit to at once. Predictability in our delivery is not possible unless we limit the amount of work in progress.

Manage the Flow of Work: As we have discussed in this article, we need to focus our efforts on identifying those things that hinder the flow of work. We need to shift our attention from the utilization of people towards the management of work and how it flows.

Make Policies Explicit: Whenever we discover flow impediments we should strive to resolve them. Part of the resolution should include updating the policies of how work flows through our system and making them visible. Evolving our policies and making them explicit is a cornerstone to continuous improvement.

Implement Feedback Loops: Business agility and continuous improvement are rooted in a desire to quickly learn and respond to feedback. We need to establish mechanisms where we can collect and evaluate feedback so that we can maintain or correct our course. These mechanisms should foster an ability to gather meaningful feedback that we can act on.

Collaborate and Experiment: An agreement to pursue evolutionary improvement by encouraging acts of leadership and collaboration at all levels of an organization are necessary if we aspire to a culture where change can flourish through experimentation founded on the scientific method. Our approach needs to move towards a non-deterministic probabilistic way of thinking, and away from a speculative and wishful mindset.

Helping organizations develop an understanding of the implications of poor flow efficiency and then using these practices to help overcome that challenge is a strategy that has proven very effective for myself and my clients. My premium management training classes provide in-depth practical guidance on how to apply these techniques.

Conclusion

I’m not suggesting that an obsession with accurately tracking flow efficiency will be time well spent, in-fact, even if you wanted to, it can be quite difficult to do without electronic tools. However, even an approximate understanding of your flow efficiency, or being on the lookout for interruptions of flow (blocked items, items aging in queues, dependencies, etc..), and focusing on developing smooth-fast-flow, can have tremendous benefits to your ambition of delivering more quickly and more reliably to your customers.

Focus on eliminating wait times of your work items! Strive for flow that is smooth and fast! Spend more time managing and measuring work, less on managing and measuring people.

If you are interested in learning more about each of these practices and how to apply them in your place of work, consider signing up for one of my premium management training workshops. I offer three LeanKanban University accredited management classes:

Team Kanban Practitioner

Kanban System Design

Kanban Management Professional

Follow me on Twitter @jamesdsteele

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, coaching, culture, Kanban, Professional Development

Towards a Culture of Leadership: 10 Things Real Leaders Do (and So Can You)

Leave a comment

This article is adapted from a session proposal to Toronto Agile Conference 2018.

Leadership occurs as conscious choice carried out as actions.

Everyone has the ability to carry out acts leadership. Therefore, everyone is a potential leader.

For leadership to be appropriate and effective, acts of leadership need to be tuned to the receptivity of those whose behaviour the aspiring leader seeks to influence. Tuning leadership requires the ability to perceive and discern meaningful signals from people and, more importantly, the system and environment in which they work.

As leaders, the choices we make and the actions we carry out are organic with our environment. That is, leaders are influenced by their environments (often in ways that are not easily perceived), and on the other hand influence their environments in ways that can have a powerful impact on business performance, organizational structures and the well-being of people. Leaders who are conscious of this bidirectional dynamic can greatly improve their ability to sense and respond to the needs of their customers, their organizations and the people with whom they interact in their work. The following list is one way of describing the set of capabilities that such leaders can develop over time.

  1. Create Identity: Real leaders understand that identity rules. They work with the reality that “Who?” comes first (“Who are we?”), then “Why?” (“Why do we do what we do?”).
  2. Focus on Customers: Real leaders help everyone in their organization focus on understanding and fulfilling the needs of customers. This is, ultimately, how “Why?” is answered.
  3. Cultivate a Service Orientation: Real leaders design and evolve transparent systems for serving the needs of customers. A leader’s effectiveness in this dimension can be gauged both by the degree of customer satisfaction with deliverables and to the extent which those working in the system are able to self-organize around the work.
  4. Limit Work-In-Progress: Real leaders know the limits of the capacity of systems and never allow them to become overburdened. They understand that overburdened systems also mean overburdened people and dissatisfied customers.
  5. Manage Flow: Real leaders leverage transparency and sustainability to manage the flow of customer-recognizable value through the stages of knowledge discovery of their services. The services facilitated by such leaders is populated with work items whose value is easily recognizable by its customers and the delivery capability of the service is timely and predictable (trustworthy).
  6. Let People Self-Organize: As per #3 above, when people doing the work of providing value to customers can be observed as self-organizing, this is a strong indication that there is a real leader doing actions 1-5 (above).
  7. Measure the Fitness of Services (Never People): Real leaders never measure the performance of people, whether individuals, teams or any other organization structure. Rather, real leaders, practicing actions 1-6 (above) understand that the only true metrics are those that provide signals about customers’ purposes and the fitness of services for such purposes. Performance evaluation of people is a management disease that real leaders avoid like the plague.
  8. Foster a Culture of Learning: Once a real leader has established all of the above, people involved in the work no longer need be concerned with “safe boundaries”. They understand the nature of the enterprise and the risks it takes in order to pursue certain rewards. With this understanding and the transparency and clear limits of the system in which they work, they are able to take initiative, run experiments and carry out their own acts of leadership for the benefit of customers, the organization and the people working in it. Fear of failure finds no place in environments cultivated by real leaders. Rather, systematic cycles of learning take shape in which all can participate and contribute. Feedback loop cadences enable organic organizational structures to evolve naturally towards continuous improvement of fitness for purpose.
  9. Encourage Others to Act as Leaders: Perhaps the highest degree of leadership is when other people working with the “real leader” begin to emerge as real leaders themselves. At this level, it can be said that the culture of learning has naturally evolved into a culture of leadership.
  10. Stay Humble: Real leaders never think that they have it all figured out or that they have reached some higher state of consciousness that somehow makes them superior to others in any way. They are open and receptive to the contributions of others and always seek ways to improve themselves. Such humility also protects them from the inevitable manipulations of charlatans who will, form time to time, present them with mechanical formulas, magic potions, palm readings and crystal ball predictions. Real leaders keep both feet on the ground and are not susceptible to the stroking of their egos.

If you live in Toronto, and you would like to join a group of people who are thinking together about these ideas, please feel welcome to join the KanbanTO Meetup.

Register here for a LeanKanban University accredited leadership class with Travis.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
agile training, Kanban, OpenAgile, Scrum Guide

Scrum, Kanban, OpenAgile: Same Goals, Different Approaches

4 Comments

The inspiration of this opinion piece comes from a professional student who just finished reading “The Scrum Guide” by Ken Schwaber and Jeff Sutherland, “Essential Kanban Condensed” by David J Anderson and Andy Carmichael, and “The OpenAgile Primer” by Mishkin Berteig and The Berteig Consulting Team. These thoughts come from a humble place and is very open to feedback, differing opinions, or just comments in general. If I’m out to lunch, let me know!

On the surface of what seemingly looked like 3 very similar practices–after careful deliberation–turned out to be 3 unique approaches to creating high performance teams that deliver quality services. The objective of my article is to share some of the key differences that I uncovered after reading about each practice.

 

Differences in Structure:

All 3 agile practices rely on iterative development and continuous feedback to optimize the delivery of products and services. However, the difference I see is in the structure of each. Scrum is a defined framework with a set prescription to maximize the output of software delivery and product building. Whereas, Kanban is a flexible method that uses evolutionary change and self-organization as a way to continuously build out value and services, without overburdening the team. OpenAgile uses self-organizing behaviour that allows team members to commit to tasks based on capacity while prioritizing tasks with the highest value drivers.

 

Differences in Reflection periods:

All 3 agile practices stress the importance of reflecting and receiving feedback, however, each one implements this important event at different times. One of Scrum’s most vital ceremonies is the “Retrospective”. This time of reflection takes place at the end of every sprint—giving team members the time to reflect on ‘what went right’, ‘what went wrong’, and ‘areas for improvement’. OpenAgile encourages reflection within the ‘Engagement Meeting’ which kicks off every cycle—allowing team members to start off with improvement ideas at the forefront of every new cycle. Kanban on the other hand, incorporates seven specific opportunities for feedback loops (i.e. cadences) which are strategically placed so that feedback is continuous and supports the goal of evolutionary change.

 

Differences in Defining a “Team”:

All 3 writings described the importance and closeness of the “team” that is building these high-value services/products yet, the makeup of these teams differed quite largely between the 3 agile practices. Starting with Scrum—this practice has the defined role of ‘Scrum Master’ and ‘Product Owner’ but a cross-functional group of people who makeup the ‘development team’. The ‘Scum Master’ and ‘Product Owner’ are very intentional roles—serving strict and important functions for the ‘development team’ and their success. This differs from a ‘team’ within the Kanban practice which is just a group of people with no real designated roles. The team as a whole, works collaboratively and self-organizes on their own. Similarly, OpenAgile does not concern itself with defined roles and is also made up of a self-organizing team (or individual). However, OpenAgile does speak on the importance of team members stepping up to serve their teams in necessary capacities in which they name as the process facilitator and growth facilitator.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Kanban, Scrum Master, Uncategorized

Slaying Hydra: The Story of A Business Agility Coaching Partnership

Leave a comment

Part I of III

Summer 2014. The IT group of “Big Data Marketing” was in the full throws of an Agile transformation spearheaded by the new CTO. I was brought in as a Scrum Coach. My initial objective was to launch a couple of Scrum teams and serve as their Scrum Master. Around the same time, the firm’s head of PMO had been re-assigned as the Agile Practices Lead (APL) and he and I began working together on supporting the new Scrum Master community of practice, populated by his new reports. Our work gradually evolved into much more than what either of us could have imagined at the time. This 3-part series is my first attempt at putting down the story of that partnership.

In addition to serving as the initial Scrum Master for some of the teams, I was also trying to help existing team members transition into the Scrum Master role. I wanted to develop internal capacity so that I could focus on supporting a growing program of multiple teams. As the number of Scrum Masters and teams I was supporting increased, so too did the need for collaboration with the APL.

At the time, senior IT leadership was focussed on getting those doing the work of creating value (the teams) to fundamentally change the way they were working. That is, into self-organizing teams with Scrum Masters as “servant-leaders”. This included the reassignment of project managers as Scrum Masters and business analysts as Product Owners and staff into cross-siloed teams.

Chaos and confusion ensued. It was a deliberate strategy of senior leadership: Disrupt the culture of complacency. Force people to transform by throwing them into chaos. Throw everyone into the deep end and the right people will learn to swim.

A great deal of pressure was placed on the Scrum Masters to measure and improve team performance (based on pseudo-metrics such as story point velocity). They were essentially told to create a new identity for themselves and this was painful. Similarly, the APL was on the hook to support all these people in their new roles – to be a “servant-leader of the servant-leaders”. This concept of servant-leadership was front and centre in the conversation: “What is it, and how do we make it work here?” My role was to help create a shared understanding of the desired new culture.

I discovered months later that the day after I started the engagement, around 50 people had been fired. This had nothing to do with me, but naturally people thought that it did. Even years later, this day was commonly referred to by the survivors as “Bloody Monday”. Because of the timing of the mass-exit, unprecedented in the company’s 25-year history, staff understandably regarded me as the consultant who advised the cull. It’s not exaggerating to say that it instilled terror, was emotionally coupled with the transformation as a whole and implicated me as an individual. I thought of myself as one contributing help, but I was regarded as one contributing to harm. I saw myself as a Hippocrates but I was known as a Procrustes. I only learned about this months later, after I had finally managed to cultivate a bond of trust with some folks. A consequence of this fear was that I found myself in many one-on-one sessions with new Scrum Masters who were struggling to adapt and afraid of being the next victim to lose their jobs. Rather than providing Scrum Master therapy, I should have been helping the company to improve its delivery capabilities.

The theme of this first stage was the deep, broad and painful disruption of people’s lives caused by this deep Satir J-curve transformation model deployed by senior management. What I didn’t fully appreciate at the time is that emotionally, people experience change the same way they experience pain. The human brain literally responds the same. Not only were these human beings experiencing deep, chaotic change, they were also experiencing deep pain. And I was complicit in this.

The other contract coaches and I attempted to bring the crisis to the attention of senior management. We believed that it was a leadership problem, they believed that it was a staff complacency problem. The standoff lead to the coaches losing access to the leaders we were trying to help. This was a deep crisis for the group of coaches and the staff. The staff were beginning to see us as their advocates and we failed. For many Agile coaches, their part in the story ends here. In fact, some of the coaches on our team soon decided to move on to other opportunities. Others were not asked to extend their services beyond their initial contract term. Fortunately for me, the story didn’t end here. I will share more about this in Parts II & III of this series.

A teaser: These days, I advise and coach senior management to take responsibility to deliver services to customers, to understand what makes their services fit for the purposes of their customers and to design and evolve service delivery systems the fitness criteria of which are transparent to all those involved in the work. Then, allow people to truly self-organize around how the work gets done. In other words, manage the work not the people.

To be continued…

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Kanban

Interview with Janice Linden-Reed, CPO at Lean Kanban Inc.

Leave a comment
Janice Linden-Reed was asked to help our readers understand the efficacy of Kanban training, as well as its relationship to Agile frameworks. The following is her response (republished from the REALagility Newsletter, Nov. 2017).

“Kanban is useful in any situation where the flow of work is uneven, and/or people are swamped with too much work. It is not a replacement for Scrum; it can be overlaid in any current system a business may be using. Kanban helps organize and manage, so that everyone understands customer demand versus individual capacity. Kanban enables one to sort out, and get back into control of, their work.

There is lots of debate around the relationship between Kanban and being agile. David Anderson, Kanban’s founder, had been experimenting with applying Lean principles to knowledge work in particular. In a sense, Kanban combines being agile with Lean principles. Kanban can create order just in time for changing conditions (disruption). Kanban is not in an either/or position with Scrum; the two can be combined.

Around 2005 David Anderson was approached about a complex project at Microsoft, and started to apply what he’d been learning. By 2010 his book, Kanban: Successful Evolutionary Change, was published. In 2011, the Lean Kanban University (LKU) was established because the capacities of people who were teaching Kanban varied greatly. The university ensures people use the right materials and learn all the elements of a successful Kanban curriculum. Thus an Accredited Kanban Trainers (AKT) is endorsed by LKU.

Kanban teaches: start where you are now, whatever your situation, whatever framework you may be using. The challenge with Kanban is simply knowing what you’re doing at any given moment. Kanban can help you start with getting visibility of the work, so that everyone – managers and employees alike – are on the same page. Kanban is very free about then allowing change to occur.

Kanban is used by the agile community worldwide, to differing degrees, offering both shallow visuals or deep risk management. It works mainly for knowledge and service work, i.e. insurance companies and banks – work that is essentially invisible, and is of different sizes. Because knowledge work is not visible, management may not know how much an employee has on his or her plate.

A trained AKT understands systems thinking and a pull system, all the way to applying advanced techniques to improve flow and predictability. The training will be eye-opening – time well-spent!”

Read more about Kanban at:

http://www.agileadvice.com/2017/06/01/kanban/kanban-real-scaled-agility-enterprise/

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Kanban

What Kanban Is (And Isn’t)

Leave a comment

The Kanban Method is a management method for…

  • Directly improving service delivery;
  • Catalyzing improvements;
  • Evolving a business to be fit for purpose.

The Kanban Method is also…

  • An evolving and flexible system of pragmatic, actionable, evidence-based guidance;
  • Adaptable to the unique needs of each context to which it is applied;
  • Inclusive of evidence-based guidance from a broad range of professional disciplines, including economics, psychology, sociology, process management and change management.

The Kanban Method is not…

  • A project management method;
  • A software development lifecycle process;
  • Completely defined in a “manifesto” or “guide”;
  • An immutable process framework with binding rules, extant only in its entirety—in other words, you don’t need to be doing all of Kanban for it to be Kanban, nor is it advisable to try.

You would likely benefit from exploring the applicability of Kanban to your business because…

Your organization is an ecosystem of interdependent services—a complex, adaptive system. You introduce a Kanban system into it such that the complex system is stimulated to improve. – Alexei Zheglov

This wikipedia entry provides a fairly accurate description of the Kanban Method:

https://en.wikipedia.org/wiki/Kanban_(development)

The Kanban Method has 3 Agendas:

  1. Survivability (of the business, for business executives);
  2. Service-orientation (for all levels of management);
  3. Sustainability (for professional services knowledge workers);

The Kanban Method could help you if one or more of the 3 agendas above applies to you.

The Kanban Method has 9 values:

  1. Customer focus
  2. Transparency
  3. Understanding
  4. Agreement
  5. Leadership
  6. Respect
  7. Collaboration
  8. Balance
  9. Flow

The Kanban Method has 6 principles; 3 change management principles and 3 service delivery principles.

Change Management Principles:

  1. Start with what you do now.
  2. Agree to pursue improvement through evolutionary change.
  3. Encourage acts of leadership at all levels.

Service Delivery Principles:

  1. Understand & focus on customer needs and expectations.
  2. Manage the work, let people self-organize around it.
  3. Policies govern service delivery.

The Kanban Method has 6 practices:

  1. Visualize
  2. Limit WIP
  3. Manage flow
  4. Make policies explicit
  5. Feedback loops
  6. Improve & evolve

You are “doing” Kanban if your intentions are that…

  • Management behaviour in your organization changes to enable Kanban;
  • The customer interface changes, in line with Kanban;
  • The customer contract changes, informed by Kanban;
  • Your service delivery business model changes to exploit Kanban.

LeanKanban Inc. is the authority on the Kanban Method. LeanKanban University is the accredited training organization of LeanKanban Inc.

David J. Anderson is the founder of the Kanban Method. Essential Kanban Condensed, co-authored by Anderson and Andy Carmichael, is available as a free download.

Travis Birch is an Accredited Kanban Trainer with LeanKanban University. You can sign up for his upcoming public Kanban courses in December 2017 at Berteig World Mindware.

 

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile Management, Kanban, Uncategorized

Kanban: Real Scaled Agility for Your Enterprise

2 Comments

Your business is an ecosystem of interdependent services, a complex adaptive system.

A bunch of organizations I know started their journey of increasing their agility with Scrum. That didn’t solve all of their problems. Kanban enables organizations to evolve their service delivery systems towards mature business agility.

As addressed in How Kanban Saved Agile, pure Scrum is extremely rare. Scrumbut (the disparaging label that spawned from so many organizations reporting that they do Scrum, but…) on the other hand, is extremely common.

In order to not be Scrumbut, you need the following:
  • Cross-functional development team of 7 +/- 2 people—ALL skills needed to ship product is present on the team—there are no dependencies external to the team;
  • One source of demand with no capacity constraints—the Product Owner is the customer AND full-time member of the team;
  • Sprints are one month or less, begin with starting new demand from the Product Owner and end with the delivery of potentially shippable Product Increments, followed by a retrospective about how to do better next Sprint;
  • “Potentially Shippable” means that the decision about whether to actually ship is purely a business decision. All the technical work is done;
  • If all of the technical work required in order to ship isn’t done, then the Sprint is a failed Sprint;
  • The Scrum Master is a servant-leader and Scrum educator to the entire organization.

How many organizations do you know of with Scrum teams that meet all of the requirements above? I don’t know one.

So, what’s the solution? Give up on Scrum? Are we still getting benefits from Scrumbut? Alright, let’s stop it with the Scrumbut already. Let’s acknowledge what’s really going with real teams in the real world and call that Scrum. Let’s refer to the above  checklist as “Ideal Scrum”.

Agile scaling methods have become a popular risk hedging tactic for all the loose ends dangling around the real teams in the real world.

Here are some of the reasons for adding layers of scaling around Agile teams:

  • Teams are not fully cross-functional;
  • Teams have external and opaque depencies;
  • Many of these dependencies are shared services with multiple sources of demand and constrained capacity—often overburdened;
  • External dependencies can be other teams—demand from other teams shows up in their backlogs, prioritized by their own Product Owners;
  • Many dependencies don’t play by the same rules at all—some reside in a different part of the organization, with different structures and political forces;
  • The Product Owners are proxies for multiple stakeholders and customers and the Product Backlogs represent an array of multiple sources of demand, with different service level expectations, strategic origins, degrees of clarity, urgency and political forces pushing them into the deliver organization;
  • The Product Backlogs are made up primarily of solutions defined by stakeholders and translated by the pseudo-Product Owners as pseudo-user stories—how they get there is opaque, the “fuzzy front end”—and somewhere in here a fuzzy delivery commitment was already made;
  • The work of a Sprint includes all of the work that the non-cross-functional teams can get done—then whatever the teams get “done” is “delivered” (handed-off) to a subsequent set of teams or process steps (usually fairly well defined at an organizational level but outside of the teams’ influence);
  • Delivery decisions are made based on constraints imposed by legacy technology, systems and their gatekeepers (for historically good reasons);
  • The teams are “done” at the end of each Sprint, yet much work is still to be done before their “done” work is potentially shippable;
  • The Scrum Master’s are held collectively accountable for the collective deliverables of the teams and their ability to cross-team coordinate and integrate—accountability by committee translates into no one is actually responsible.
  • Middle managers are scrambling to pick up the pieces because they are actually accountable for delivered results.

Generally speaking, the aim of Agile scaling methods is to apply larger Agile wrappers around clusters of Agile teams in order to re-establish some kind of hierarchical structure needed to manage the interdependencies described above. Whether its a Release Train or a Nexus, or whatever else, the idea is that there is an “Agile Team of Teams” managing the interdependencies of multiple, smaller teams. As long as the total number of people doesn’t grow beyond the Dunbar number (~150), the Dunbar-sized group is dedicated and cross-functional, there is a team managing the interdependencies within the Dunbar, there are no dependencies outside of the Dunbar and there is some cadence (1-3 months) of integrated delivery—it’s still “Agile”. All of this scaling out as far as a Dunbar (and only that far) allows the enterprise to still “be Agile”—Scaled Agile.

This is all supposed to be somehow more realistic than Ideal Scrum (with perhaps am overlay of Scrum of Scrums and a Scrum of Scrum of Scrums). It’s not. How many organizations do you know of that can afford to have ~150 people 100% dedicated to a single product? Perhaps today there is enough cash lying around, but soon enough the  economic impact will be untenable, if not unsustainable.

How does Kanban address this problem? Your business is a complex adaptive system. You introduce a Kanban system into it such that it is likely that the complex adaptive system is stimulated to improve. The Systems Thinking Approach to Introducing Kanban—STATIK—is how you can make such a transition more successful (@az1):
  1. Understand the purpose of the system—explicitly identify the services you provide, to whom you provide them and why;
  2. Understand the things about the delivery of the service that people are not happy about today—both those whose needs are addressed by the service and those doing the work of delivering the service;
  3. Define the sources of demand—what your customers care about and why;
  4. Describe the capability of your system to satisfy these demands;
  5. Map the workflow of items of customer-recognizable value (@fer_cuenca), beginning with a known customer need and ending with the need being met through stages of primary knowledge discovery (Scrum teams somewhere in the middle, towards the end)—focus on activities, not looping value streams;
  6. Discover classes of service—there are patterns to how different kinds of work flow through your system (they are not arbitrarily decided by pseudo-Product Owners), what are they? Group them, they are classes of service and knowing them enables powerful risk management;
  7. With all of the above as an input, design the Kanban system for the service;
  8. Learn how to do steps 2-7 and start applying it directly to your own context in a Kanban System Design class;
  9. Socialize and rollout (learn how by participating in a Kanban Coaching Professional Masterclass);
  10. Implement feedback-loop Cadences for continuous evolution—learn the 7 Kanban Cadences and begin applying to your own context in a Kanban Management Professional class;
  11. Repeat with all of the interdependent services in your organization—every “dependency” is a service—Kanban all of them with STATIK and begin implementing the Cadences.

Don’t get hung up on teams, roles, your latest reorg, how people will
respond to another “change”, who’s in, who’s out, etc. These are all part of the service as it is now—your current capability. Initially, no changes are required at this level. The kanban system will operate at a higher level of scale. Through feedback-loop cadences, it will evolve to be fit for the purpose of your customers without a traumatic and expensive reorg.  Who is responsible for this? Identify this person. If you are the one thinking about this problem, there is a good chance that it’s you. Whoever it is, this is the manager of the service; take responsibility, do the work and make life better for everyone.

For more information about LeanKanban University Certified Kanban courses provided by Berteig, please go to www.worldmindware.com/kanban. Some spots are still available for our classes in Toronto, June 12-16.

For Agilists who have read this far and still don’t get it, start here:

14 Things Every Agilist Should Know About Kanban

The story below may be familiar to some:

Our IT group started with Scrum. Scores of people got trained. Most of our Project Managers became “Certified” Scrum Masters. Most of our Business Analysts became “Certified” Product Owners. We purged some people who we knew would never make the transition. We reorganized everyone else into cross-functional teams – mostly developers and testers. But now they are Scrum Developers. We tried to send them for “Certified” Scrum Developer training but hardly anyone of them signed up. So they are Just Scrum Developers. But we still call them developers and testers. Because that’s still how they mostly function—silos within “cross functional teams”, many tales of two cities rather than just one.

After the Scrum teams had been up and running for a while and we were able to establish some metrics to show the business how Agile we were (since they didn’t believe us based on business results), we had a really great dashboard showing us how many Scrum teams we had, how many Kanban teams, how many DevOps, how many people had been trained. We even knew the average story point velocity of each team.

The business didn’t get it. They were worried that Agile wasn’t going to solve their problem of making commitments to customers and looking bad because we still weren’t able to deliver “on time”.

As IT leadership, we were really in the hot seat. We started to talk about why the transformation wasn’t going as it should. We knew better than to bring the Agile coaches into the boardroom. They were part of the problem and needed to be kept at arms length from those of us who were making important decisions. Besides, their Zen talk about “why?” was really getting old fast. Some thought it was because we didn’t have the right technology. Others were convinced it was because we didn’t have the right people. After all, we didn’t go out and higher experienced (above-average) Scrum Masters and Product Owners, instead we just retrained our own people. Clearly that wasn’t working.

We started with improving the Scrum Masters. We went out and hired a few with impressive resumes. We developed some Scrum Master KPIs (HR jumped all over this one). Then one day we had a collective flash of brilliance—since the ScrumMasters are the servant leaders of teams, we will make them responsible for collecting and reporting team metrics and this will tell us how well the teams are doing and how they need to improve. This surely would be the key to improving the performance of IT and get us on a better footing with the business.

But we didn’t get the response we were hoping for. The ScrumMasters soon complained that the metrics of the teams were impacted by dependencies that they had no influence over. When we pushed harder and shamed them publicly for failing to produce meaningful metrics, they tried harder, but they weren’t able to do it. Some began disengage. “This is not the job I signed up for” became their new mantra. This was puzzling. We were empowering them and they were recoiling. Maybe we didn’t get the right Scrum Masters after all. Maybe we needed to go out and find people who could think and act effectively beyond the confines of their own teams. Or…

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Kanban, Professional Development

Learning About Kanban

Leave a comment

From Essential Kanban Condensed by David J Anderson & Andy Carmichael

“Kanban is a method for defining, managing, and improving services that deliver knowledge work, such as professional services, creative endeavors, and the design of both physical and software products. It may be characterized as a “start from what you do now” method—a catalyst for rapid and focused change within organizations—that reduces resistance to beneficial change in line with the organization’s goals.

The Kanban Method is based on making visible what is otherwise intangible knowledge work, to ensure that the service works on the right amount of work—work that is requested and needed by the customer and that the service has the capability to deliver. To do this, we use a kanban system—a delivery flow system that limits the amount of work in progress (WiP) by using visual signals.

http://leankanban.com/wpcontent/uploads/2016/06/Essential-Kanban-Condensed.pdf

I’ve been reading the above book on Kanban (the alternative path to agility) to familiarize myself with the method before taking the Kanban course by Accredited Kanban Trainer Travis Birch.

Two points from my learning are the principles of “Change Management” and “Service Delivery.”

Kanban regards “Change Management” as an incremental, evolutionary process as Kanban is utilized. For example, Kanban starts “with what you do now.” A business agrees to pursue improvement through evolutionary change, which happens over a period of time, based on experience and understanding. If one is using Kanban for the first time, there may be some awkwardness at the beginning, with a number of people trying to understand the principles, and how the visual board works. As the work goes on, understanding is increased, and with the new learning, change occurs in a very organic way. Acts of leadership are encouraged at every level. Changes can occur in all sectors: within individuals, within the environment, and in the cumulative outcomes of the work.

“Service Delivery” in Kanban requires that there is an understanding of and focus on the customer’s needs and expectations. The work is managed by people self-organizing around the work, and by the limiting of work-in-progress (WIP). This can help people feel that they have the right amount of work to accomplish with the right amount of time. WIP limits are policies that need to be made explicit in order to establish flow. The work on the board is “pulled” into the in-progress section only as people become available to do the work. An employee can focus on bringing higher quality to the work, and not feel threatened by a backlog that is crushing them. Policies are evolved to improve outcomes for the customers.

Of the nine values outlined in Kanban, three are directly related to change management and service delivery. The first is “respect;” by limiting the work-in-progress, respect is shown for the employee’s time and efforts, along with respect for the customer’s expectations. “Flow” refers to there being an ordered and timely movement to the work being done that is not overwhelming. “Transparency” occurs because everything is visible on the Kanban board and it becomes clear what is being done, when and by whom.

It’s been proposed that Scrum is for teams and Kanban is for services. In that way, they are both essential to the improvement of many organizations, especially those in which pure Scrum is not enough. They are complimentary from the perspective of improving business.

If you’re interested in the training with Travis Birch, AKT, go to:(http://www.worldmindware.com/TeamKanbanPractitioner).

“Kanban has principles and general practices, but these must be applied in context, where different details will emerge as we pursue the common agendas of sustainability, service-orientation, and survivability. As a result, the journey is an adventure into unknown territory rather than a march over familiar ground” (from Essential Kanban Condensed)

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Kanban, Theory of Agile

How Kanban Saved Agile

6 Comments

In reality, Kanban isn’t actually saving Agile nor is it intended to, nor is any thoughtful and responsible Kanban practitioner motivated by this agenda. What I’m really trying to convey is how human thinking about the business of professional services (including software development) has evolved since “Agile” as many of us know it was conceived around 20 or so years ago. The manifesto is the collective statement of a group of software development thought leaders that captured some of their ideas at the time about how the software industry needed to improve. Essentially, it was about the iterative and incremental delivery of high-quality software products. For 2001, this was pretty heady stuff. You could even say that it spawned a movement.

Since the publication of the manifesto in 2001, a lot of other people have had a lot of other good ideas about how the business of delivering professional services can improve. This has been well documented in well known sources too numerous to mention for the scope of this article.

Substantial contributions to the discourse have been generated by and through the LeanKanban community. The aim of Kanban is to foster environments in which knowledge workers can thrive and create innovative, valuable and viable solutions for improving the world. Kanban has three agendas: survivability (primarily but not exclusively for the business executives), service-orientation (primarily but not exclusively for managers) and sustainability (primarily but not exclusively for knowledge workers). Kanban provides pragmatic, actionable, evidence-based guidance for improving along these three agendas.

Evolutionary Theory is one of the key conceptual underpinnings of the Kanban Method, most notably the dynamic of punctuated equilibrium. Evolution is natural, perpetual and fundamental to life. Long periods of equilibrium are punctuated by relatively short periods of “transformation”—apparent total and irreversible change. An extinction event is a kind of punctuation, so too is the rapid explosion of new forms. Evolutionary theory is not only a scientifically proven body of knowledge for understanding the nature of life. It can be also applied to the way we think about ideas, methods and movements.

For example, science has more or less established that the extinction of the dinosaurs, triggered by a meteor impact and subsequent dramatic atmospheric and climate change, was in fact a key punctuation point in the evolution of birds. In other words, dinosaurs didn’t become extinct, rather they evolved into birds. That is, something along the lines of the small dinosaurs with large feathers hanging around after Armageddon learned to fly over generations in order to escape predators, find food and raise their young. Dinosaurs evolved into birds. Birds saved the dinosaurs.

There has been a lot of social media chatter and buzz lately about how Agile is dead. It is a movement that has run its course, or so the narrative goes. After all, 20 years is more or less the established pattern for the rise and fall of management fads. But too much emphasis on the rise and fall of fads can blind us to larger, broader (deeper) over-arching trends.

The agile movement historically has been about high-performing teams. More recently, market demand has lead to the profusion of “scaling” approaches and frameworks. Scaling emerged out of the reality of systemic interdependence in which most Agile teams find themselves. Most agile teams are responsible for aspects of workflows—stages of value creation—as contributors to the delivery of a service or multiple services. Agile teams capable of independently taking requests directly from and delivering directly to customers are extremely rare. For the rest, classical Agile or Scrum is not enough. The feathers just aren’t big enough. Agile teams attempting to function independently (pure Scrum) in an interdependent environment are vulnerable to the antibodies of the system, especially when such interdependencies are merely denounced as impediments to agility.

Some organizations find themselves in a state of evolutionary punctuation (the proverbial sky is falling) that can trigger rapid adaptations and the emergence of local conditions in which independent service delivery teams can thrive. Most large, established organizations seem to be more or less in a state of equilibrium. Whether real or imagined, this is what change agents have to work with. However, more often than not, the typical Agile change agent seems adamant that the sky is always falling and that everyone accepting that the sky is falling is the first step to real and meaningful change. This is not an attitude held by Agile change agents alone. This is a standard feature of traditional 20th Century change management methods, the key selling point for change management consulting.

Naturally, most self-identifying “Agilists” see themselves as change agents. Many of them find themselves in the position of change management consultants. But the motivation for change can quickly become misaligned: Change needs to happen in order for Agile to work. If you are passionate about Agile, you will seek to bring about the environmental changes that will allow for Agile to thrive. We don’t need to follow this path too far until Agile becomes an end in itself. It is understandable then that for some, Agile appears to be a dead end, or just dead.

But if there is a larger, over-arching historical process playing out, what might that be? Perhaps it has something to do with the evolution of human organization. Perhaps we are living in a period of punctuation.

For my working definition of Kanban, please refer to my previous article 14 Things Every Agilist Should Know About Kanban (this contains links to the Kanban body of knowledge, including Essential Kanban Condensed by David J. Anderson and Andy Carmichael).

For my working definition of Agile, please refer to The Manifesto for Agile Software Development.

 

 

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Agile coaching, Agile Management, coaching, Kanban, Reference Information

14 Things Every Agilist Should Know About Kanban

4 Comments

untitled

So you are embarking on an Agile transformation. One important thing you need to figure out (and hopefully you have some consultants helping you) is how many Scrum Teams you will need for product development and how many Kanban teams you will need for operations, deployment, support, maintenance, keeping the lights on, etc. Because when you create a bunch of cross-functional teams they will have gaps in their Agile engineering practices and their definition of “done” will have to be limited by several organizational factors. The teams won’t have access to many of the environments and there won’t be enough specialized resources to assign to each team. Plus, the nature of the work coming into the ops and support teams are much more finely grained and varied than user stories in a Sprint Backlog and it’s important that the Scrum teams focus on their products and are not disrupted by every little change request from the business. So you need Kanban teams to do the work that the Scrum Teams can’t do yet as well as the stuff that you don’t want your Scrum Teams to be distracted by.

That’s more or less the popular consensus on the role of Kanban in the Agile community. Some acclaimed thought leaders have even written popular books and blog posts about it. But if one digs a little deeper, one finds that there is much more to Kanban than meets the common agilist’s eye (although clearly this is changing, evidenced by the existence of this piece of writing). So here are the 14 things that I can think of off the top of my head:

  1. The Kanban Method is not about transformation. At least not the radical, deep Satir J-Curve brand of transformation that has been attempted in many organizations. All too often with the radical approach, there is enough resistance to change and enough ensuing chaos for the leaders of the organization to lose patience with the change initiative before the system has a chance to recover.
  2. Moreover (and dangerously), many so-called champions of change are not aware that Satir was a psychotherapist and that her J-Curve method was employed to change the identity of her clients, breaking them down and building them up again. What’s important here is that Satir was a psychology professional working with willing clients to help them transform into the people they wanted to be. This is not the case with most professional knowledge workers. Knowledge workers tend to not be seeking this kind of service from managers and coaches. A more brutal version of this technique has been employed to transform teenagers into deadly soldiers.
  3. Instead of deep J-Curve transformation, the Kanban Method proposes small, rapid J-Curve experiments. This approach to change provokes less resistance, avoids extended periods of thrashing in chaos and the severe testing of leadership patience. Well-designed small J-Curve experiments produce just enough organizational stress to stimulate change without drop-kicking people into deep chaos and despair and forcing the regression of an organization to lower levels of trust and maturity.
  4. The Kanban Method is a management system for the design and evolution of the interdependent services of an organization. Such services are often composed of several Scrum Teams, shared services, managers, senior staff and specialists and are often themselves served by other services. Every service is delivered via a system of stages of knowledge discovery (rather than hand-offs). See more on this here.
  5. The design of a system determines the fitness for purpose, flow of value and quality of the service (as demonstrated by Deming’s Red Bead Experiment). It’s not about high-performance teams. It’s about the performance of the system.
  6. Transparency of the system empowers knowledge workers to self-organize around the work because they understand the system and are trusted to know what to do in order to deliver the service.
  7. Kanban managers are systems managers, not people managers and not coaches.
  8. Team-level Kanban is actually a form of proto-Kanban—still Kanban, but in an immature state, an incomplete rendering of a service delivery system.
  9. A Kanban system is a pull system. The capacity of the system is calibrated for optimum flow. New work enters the system when there is sufficient capacity to absorb the new work without overburdening the system and disrupting flow. Demand is balanced against capacity.
  10. All demand is potentially refutable. When there is capacity in the system to start new work, sources of demand collaborate to determine what is the most important work to start next and the system is replenished.
  11. Deciding what to start next is based on economics—transparent and rational risk assessment.
  12. Once the system is replenished and there is a commitment to deliver the newly-started work, risks are managed with explicit policies such as classes of service, work-in-process limits, pull-readiness criteria, feedback loops and relevant metrics (i.e. not team velocity).
  13. Average lead time from project or feature commitment to completion is a basic metric. Improving the system results in a reduction in both lead time and lead time variability. Delivery forecasts are based on historical lead time data. Deadlines are also managed with lead time data (i.e. deciding when to start something).
  14. All of the above is the responsibility of management. This should leave little management capacity for monitoring individual performance and story point velocity of teams (white bead count). A sign of a mature Kanban system is that managers have improved their behaviour and are focused on improving the system and that knowledge workers are free to self organize around the work as skilled, adult professionals.

If you are interested in the history of the Kanban Method, start here.

Best starter book: Essential Kanban.

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Article Reviews, Kanban, Links to Agile Info, Scrum Master

Link: Scrum Vs. Kanban

1 Comment

Vandana Roy writes a most succinct and clear description of Scrum and Kanban in this exceptional article.

Although I was first introduced to OpenAgile in 2013, Scrum and Kanban are relatively new to me this year. While not working in a tech-based department which uses these methods, I am interested in learning as much as possible about each system. I found her explanation and chart very helpful.

Here is a quote and chart she features in the article:

“Both Scrum and Kanban are unique and emphasize on more productivity with quality and efficiency for business. The table below shows advantages of both Scrum and Kanban and the commonality in both is  to keep delivering quality product.”

 

Advantages of Scrum

Advantages of Kanban

Transparency

Flexibility

Improved credibility with clients

Focus on Continuous Delivery

High Product Quality

Increased productivity and quality

Product Stability

Increased efficiency

Team members reach sustainable pace

Team members ability to focus

Allows client to change priorities and requirements quickly

Reduction of wasted work/wasted time

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!
Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 4
2023
Details
Advanced Certified ScrumMaster® (ACSM)
Online
C$1795.00
Apr 5
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1895.00
Apr 11
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 14
2023
Details
Win as a Manager with Your New Agile Coach: ChatGPT
Online
C$0.00
Apr 14
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 17
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Apr 18
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Apr 19
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 25
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1895.00
Apr 26
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Apr 28
2023
Details
Win as a Manager with Your New Agile Coach: ChatGPT
Online
C$0.00
Apr 28
2023
Details
Advanced Certified Scrum Product Owner® (ACSPO)
Online
C$1525.75
May 3
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 5
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1610.75
May 10
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 12
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1100.75
May 16
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
May 16
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
May 17
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
May 17
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 19
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 19
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
May 26
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
May 26
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1610.75
Jun 7
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 9
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 9
2023
Details
Kanban System Design® (KMPI)
Online
C$1610.75
Jun 13
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
Jun 14
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 16
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 16
2023
Details
Kanban for Scrum Masters (ML-KSM)
Online
C$495.00
Jun 20
2023
Details
Kanban for Product Owners (ML-KPO)
Online
C$495.00
Jun 21
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jun 21
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 23
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 23
2023
Details
Real Agility™ Team Performance Coaching with BERTEIG (COACHING-TPC)
Online
C$750.00
Jun 30
2023
Details
Real Agility™ Real Agility™ Ask Me Anything / Coaching
Online
C$750.00
Jun 30
2023
Details
Scrum Master Bootcamp with CSM® (Certified Scrum Master®) [Virtual Learning] (SMBC)
Online
C$1610.75
Jul 5
2023
Details
Kanban Systems Improvement® (KMPII)
Online
C$1610.75
Jul 11
2023
Details
Product Owner Bootcamp with CSPO® (Certified Scrum Product Owner®) [Virtual Learning] (POBC)
Online
C$1610.75
Jul 12
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Jul 19
2023
Details
Team Kanban Practitioner® (TKP)
Online
C$1015.75
Aug 15
2023
Details