Right to Left

Dealing with Resistance to WiP Limits

This is one of what will become a series of blog posts that discuss and give options on how to deal with resistance to WiP limits.

Having WiP limits for the first time can be confronting for many teams and organisations. For those who have been utilisation or specialisation focused, the concept of flow and WiP limits may take time to get used to. It may involve unlearning what could be years of habit with another process – it’s not something that’s done overnight and it needs continual adjustment, encouragement and monitoring. Until teams have gotten into the discipline of following explicit WiP limits, there may be other ways to help enforce the WiP limits.

The catch-cry of many a Kanban team is “Stop starting, start finishing”. This often sounds simpler than what it means in practice. So, to help out I often suggest to teams that they use the “walk the board” from “right to left” during their daily stand-up / Kanban meeting. What does this mean? Consider this example board for a software team:

Get the team to start the stand up by looking at the right hand side of the board first. We have 2 items in Deployment – if anyone is free, ask if they can help with the deployment activities.

Then move to the next column to the left – Testing. If there are any defects then get any free engineers to focus on fixing the defect. Alternatively, you could have the engineers help testers with automation, data setup or any other activities that could help get the testing done.

Next, move onto development. Are there any free engineers to help with code reviews, build pipelines or any other development activities? If so focus on getting the development done for these tickets.

If there is nothing downstream for an idle engineer, then and only then can they pick up a new card from the To Do column.

Even without explicit WiP limits, you will find that just using this practice will assist your teams in limiting their work in process. By more explicitly focusing on moving the downstream tickets before starting new ones you will have “Stopped starting and started finishing”.

Once the team is used to this habit you can have deeper conversations with the team about what the explicit WiP limits should be.

RETURN TO BLOG

 Posted on January 27, 2020 by

 Kanban, WiP Limits

     ,

Validate Assumptions

I’ve seen a number of common patterns over the years in relation to assumptions. Sometimes using assumptions can be useful, you can proceed with  an initiative and begin to make progress and check in on points as they are discovered, since we can’t know everything up front. Other times, assumptions can be downright dangerous and many of those times it’s because we haven’t realised that they are assumptions that need to be validated or invalidated. By validating assumptions, we have a solid information on which to base decisions – without such a foundation our initiatives are destined to crumble and fall.

One of the common patterns I’ve seen is the use of a “Business Requirements Document”. This kind of pattern has other manifestations, but essentially it comes at the outset of the imitative and the underlying assumption is that all this work will achieve the outcome. Often there is a lot of complexity in the underlying initiative and it’s too hard to predict exactly what will occur. Indeed, perhaps this is a good general rule – there’s no way to predict with absolute certainty exactly how your customers / users will react to a change. Thus, our path becomes set with a series of assumptions.

I’d rather see the word “Requirements” replaced with assumptions that will need to be validated somewhere along the lifecycle. Which leads me to my next point – the lifecycle or the knowledge discovery steps don’t take into account validating those assumptions in the real world. Often, I see Kanban boards like this:

When really, if the team were to add an additional knowledge discovery step along the lines of the following, the team would be prompted that they’re working with assumptions and they have to think about how they’re going to validate them:

What often results is that people focus on purely “getting stuff done” rather than ensuring “someone’s need was fulfilled” (I like this “Definition of Done” from Mike Burrows) – and by that, I mean we know through validation that the need was actually fulfilled. That’s being fit for your customers purpose. That’s really what we need to be focusing on.

Instead what results is that either we don’t validate that we’ve solved the problem and move on to the next shiny thing, or we have to go back for one or more swings at it. If you’ve got stakeholders that are counting on your promises that you’ll solve their problem the first-time round, then you’ve got a fairly serious stakeholder management issue. Also, what was the opportunity cost of learning this so late? What could we have been doing with the time and money that we’ve spent to invalidate this assumption?

Wouldn’t it be simpler to plan this from the start? In areas of uncertainty and complexity, we really shouldn’t be blind to our assumptions, rather we should be acknowledging we don’t know everything, but we plan to learn as soon as possible. Even if we’re using leading indicators to show we’re heading in the wrong direction this can be better than relying on the assumption to hold.

Don’t be blind to assumptions, they can be useful when they need to be, but often they are not catered for in many systems of work. It’s not a difficult thing to add the validate step to a board, but changing the behaviours to ensure you really are meeting that customer / user need can take more time. If you’re not validating your assumptions, you’re likely falling behind your competitors who are.

RETURN TO BLOG

 Posted on November 1, 2019 by

 Kanban

     , ,

The key to Kanban is the WiP limits

Recently, I ran a session of “The ship game” that was created by @klausleopold (read up more about it in my earlier blog from LAST conference). During that session, a couple of the attendees looked to me disbelievingly as they saw lead times halved. The look they gave me was “what kind of trick is this” as if I waved some kind of magic wand and magically sped everything up. The answer in the end was that there was no special magic, just the use of Work in Process limits.

Some teams experience lead times halving, some experience even greater improvements. What this group also found that they also had slack in the system when they introduced WiP limits – they were actually not working as hard and they were achieving better results compared to when they didn’t have WiP limits. To me this really highlights one of the key parts of Kanban is really the WiP limit.

Many people have the misconception that “the Kanban” is just the board. So many times, I’ve heard “we’ve got a board so we’re doing Kanban”. Although a board can be useful, you’re really not getting the full benefits out of Kanban – you really need to start limiting WiP to get the benefits. So much so, that I distinguish between the two – now I refer to “the Kanban” as the slot created by the WiP limit that allows you to pull new work in. I refer to the Board as simply the “Visual Management Board”. I really don’t consider it “Kanban” for knowledge work without the use of WiP limits (see https://www.kanbanmaturitymodel.com/ for more details on different kinds of WiP limit implementations).  

The WiP limit is important because it:

  • Allows you to see the capacity available
  • Creates focus to avoid task switching overheads
  • Prevents you from overburdening teams by pushing too much work into the system
  • Stabilises the system such that you can get meaningful lead time metrics
  • Catalyses change by stressing the system (as opposed to the people in the system)
  • Creates slack to allow improvement opportunities to take place

Sometimes it can be hard to introduce this and it certainly may seem counterintuitive when you start, but if you can stick to it, you will get many benefits like those mentioned above. So, please help your team, your customers and ultimately your organisation become more successful by implementing this small change.

If you want to find out more about how to implement a real Kanban system, please check out the upcoming Kanban System Design courses.

RETURN TO BLOG

 Posted on October 14, 2019 by

 Kanban

Why use Kanban?

I often find the answer to this question misunderstood. Often people see Kanban as just the “board”, but there is a lot more to it than that. When answering the why would someone want to use Kanban, I often point to the Kanban Agendas. The three agendas each answer problems that many organisations experience and they each feed into and support each other to allow a more fit for purpose organisation to emerge.

Sustainability

I often find teams that are struggling with too much work to do. There always seems to be an endless “To-do” list and teams can hardly keep their heads above water with all the incoming demand. Some teams that I’ve started working with are working nights and weekends just to try and get everything done. It’s really not a long-term strategy because it kills morale and people leave – which leads to more strain on those who are left. Using Kanban, you can start to limit the work in your system to allow teams to focus on what’s important. You can also start to shape demand so that you can get control of that monstrous “To-do” list.

Service (Customer) Orientation

Once your team get some space to breathe, often you want to the focus on what’s important to your customers. It’s now time to start to evolve your system to better service their needs. You may have different customers with different needs and trying to service all of the competing needs can be difficult. With Kanban, you can start to modify your system to suit not just one type of customer need but being able to serve multiple concurrently. It can help you deal with the seeming different demand and help solve the varying problems your customers have.

Survivability

Now that your able to keep your team to a sustainable pace and serve your current customers, it’s time to look to the future. What are the changes in the market that are occurring? How do you get ahead of the curve? What strategies are you going to employ to get there and how do you balance that with current customer needs? These kinds of questions are all very important to be able to answer to ensure that in the long term your business not only survives but thrives. Kanban can help here as well, helping to form the new strategy, alignment throughout your organisation and then through execution with the required feedback to make sure you keep on track and adapt to changing conditions.  

Getting to this point isn’t an overnight change. You will need to make many small adjustments to the way that you’re working to get to this point. Essentially, this is evolutionary, but you can start now to make things better for your teams, your customers and your organisation.

 Posted on October 4, 2019 by

 Kanban

     , ,

The Melbourne Cup Retro

I’ve been doing this retrospective format for a number of years now and it’s been very useful. Given that we’re moving into Spring here in Melbourne I thought it would be a fitting time to publish this as we prepare for the Spring racing carnival.

For those of you who don’t live in Melbourne, or don’t know what the Melbourne Cup is all about, this will help set some background. Here in Melbourne the first Tuesday in November is a public holiday for the Melbourne Cup. The Melbourne Cup is a horse race – yes, we actually have a public holiday just because of a horse race! It’s more than just a horse race, it’s actually part of the culture here in Melbourne, there’s also the all the fashion, food, wine and socialising that goes on during the what is known as the “Melbourne Cup Carnival” – with events on throughout the week.

This particular retrospective format I’ve derived from the event is actually a “futurespective” – it’s useful to use it at the beginning of a project or product development initiative. It’s really a useful way to start to talk about risk, but to come at it from an oblique angle so that you can explore it openly without a great deal of negative fallout.

I start out with asking participants – “If this project were a horse in the Melbourne Cup, what odds would you give it?”. I ask that the participants write down their answers on a card fold it up and throw it into the middle of the table / room. I then pick up the cards and put them on the board ranking them from shortest to longest odds.

Once the values are on the wall, you can see the variety of responses. Sometimes they are clustered, sometimes they are very well dispersed. I really like it when you get a lot of very different responses, because it will add to the later discussion. One of the first times I ran this, I got one response of “2 to 1” and another of “100 to 1”.

This was actually a very small team with only a few people, so it was interesting to see those responses. When I probed some more “what made you give 2 to 1?”, I got the response “Well, the sponsors really want this to happen, so that will ensure that it’s seen through to conclusion”. Then I asked about the 100 to 1 and got a response along the lines of “The technical implementation has quite a few unknowns – I’m not sure when we hook these things together, if we’ll get it to work”.

So, very quickly we came to understand that our stakeholders are not necessarily going to be a risk, but an asset in seeing this done, but the technical implementation may pose some problems. Very different risk areas and very different responses – which was great!

Now, the next step is to get a better understanding of the risks – I often use the likelihood / impact model for this. I write up a card for each type of risk from the discussion and get the team to decide on where it would fit on the chart:

Normally as part of a retrospective you’ll want to take away a few improvements / countermeasures etc to take away and action and this retro is no different. With the above chart we can decide where we want to spend our next focus for improvement – usually start with the High Likelihood and High Impact and then go from there. There may be several risk mitigating / avoidance actions that you’ll need to take, so discuss how you’re going to do this with the group.

You can add these actions to your Kanban board for follow up in the upcoming days and weeks.

The Melbourne Cup retro is a great way to obliquely address upcoming risks in a forward looking retrospective. It’s not something that you necessarily need to do very often, but you might find it a valuable addition to your retrospective repertoire. If you like this idea for a retrospective and give it a try, please reach out to me (dploeg@evogility.com.au) and let me know how it goes.  

Feature Image:

This image was originally posted to Flickr by PreciousBytes at https://www.flickr.com/photos/72562013@N06/10705862835 and is distrubted under Creative Commons Attribution 2.0 Generic License.

RETURN TO BLOG

 Posted on September 4, 2019 by

 Agile, Retrospectives

     , , ,

Kanban & Cynefin Combined Meetup

On 29 August 2019, the Melbourne Kanban and Cynefin meetup groups held a joint meetup for the first time. The Kanban meeup group has done this a couple of times before with other groups, but I thought it would be a good time to try out a combined session with Cynefin. There are a number of overlaps between Kanban and Cynefin, so I wanted to get together and see if we can explore these to see if they really exist or not.

In choosing the format for the session I was inspired by a number of the conversations I have with Kim Ballestrin (@kb2bkb). Kim has been running the Cynefin meetup group since its inception and over the years we have had a number of discussions about cynefin and agile practices – I often leave the conversation having shifted my viewpoint or at the very least have something new to think about (thanks Kim!). Thus, I thought that this kind of approach would be something worthwhile for the combined meetup.

So, the idea of the “Debate Night” was formed with the purpose being that we’ll try and explore these areas to see if there is any overlap. We figured that we’d use a method for exploring the complex domain or areas of uncertainty and debating had some really positive reasons for doing this, such as putting people in a safe environment to explore things that might be counter to their own current beliefs.  

Kim and I enlisted the help of her meetup co-host Helen Palmer (@helenmpal) to help organise the event. I must take my hat off to Helen (thanks!), she did a wonderful job helping to set things up for this session. Helen’s “snowstorm” idea that we used at the end of the session for summation / feedback is something I haven’t tried before and having seen how she did it I’m sure I’ll use it in the future.

There were 3 topics for the evening, we broke everyone up into randomly organised groups for the affirmative and negative for each topic. Participants were given 20 minutes to discuss and come up with some arguments for their particular side of the topic. Once the preparation was done, each team selected one person to present the arguments / things that they discussed. Due to the time constraints, we couldn’t organise a full debate, but I think we got a lot out of hearing what the discussions provided.

The Topics

Discussing the Topics

Splitting people into their separate groups to explore the domain
Lots of fun had in the discussions

Going through one topic at a time, we heard the arguments for and against each topic statement. Then the audience were given a chance to decide whether they were swayed by one group or the other – and if they had changed their thinking as a result of the presentation. I must admit, that even though I have a strong bias towards Kanban, I did take onboard some of the arguments that were presented and started to think more critically about things.

Amanda Varella arguing in the negative on the topic of “Metrics for 21st century knowledge work need a major overhaul”

As I mentioned earlier, the “Snowstorm” was used to sum up and give feedback. Here are the many points of feedback:

The topic of the use of Kanban for the complex domain generated quite a lot of discussion – we may take this back and run another meetup session on that in the Melbourne Kanban meetup. Also, I believe there may be spin off sessions in the Cynefin meetup group to discuss how each of the domain might / might not apply to a given topic. Watch this space for further developments.

All in all, I think the night was a great success and perhaps it would be a good format to use for future meetups. Special thanks to Elabor8 who provided the meetup venue.

For anyone wanted to get more information on the meetup groups, here are the respective links. Note that the Melbourne Limited WiP Society has been renamed to the Melbourne Kanban Meetup.

Melbourne Kanban Meetup (Limited WiP Society)

Melbourne Cynefin Meetup

 Posted on August 31, 2019 by

 Events, Meetups

     , , ,

Identify Blockers

Another major cause for long lead times are blockers. Blockers are things that prevent the flow of value / work from being done. Often these blockers are caused by things outside the system that we often have little or no control over. As these are a major cause of “tail lead time” issues, you should identify blockers and come up with countermeasures to prevent the key problems from affected your customer delivery.

Some examples of blockers include:

  • Waiting for a particular specialist to perform work
  • Waiting on another team / group to provide a something such as:
    • Waiting on procurement for setting up agreements
    • Waiting for security / compliance to provide a review
    • Waiting on legal for advice
  • Defects / quality issues (although often we separate these out as a specific kind of blocker)

Often times, I see boards that take blockers and place them in a separate column or waiting area. For example:

You should avoid this kind of mechanism for a number of reasons:

  • These areas are out of sight / out of mind. They often get forgotten and don’t get solved in a timely manner
  • They are (usually) not WiP limited – this will cause unpredictability in your system of work
  • They don’t become the focus for improvement
  • When they become unblocked, often you forget where in the flow they were up to before they became blocked and it becomes hard to place them back on the board

You should try, instead, to block the ticket in place and record it with a blocker stickie such as the example below:

The blocker stickie should also contain enough information that you can use it for analysis at a later date to combat commonly occurring blockages that are having the largest effect on your lead time or other fitness criteria (I’ll cover blocker clustering in another post). Here’s an example blocker stickie:

Key things to capture:

  • The work item that was blocked
  • A blocker description (what is blocking the ticket)
  • The date the item became blocked
  • The date the item became unblocked

Along with this, you should also work with your leadership team to let them know what these mean. Leadership should be on the lookout for blocker stickies and actively engage the team asking questions like “how can I help”, “what can I do to remove this blocker”. Keeping your blocked item in the flow will ensure that eventually your WiP limit will be reached which will force you to deal with the blocker.

Blockers are a commonly occurring event in Kanban systems (particularly new ones) and they should be identified in the right way with the right data. The Kanban system should be set up with feedback loops and policies that force you to deal with the problems that cause blockages to ensure that you maintain a healthy flow. If you don’t deal with blockers in this kind of way, your system of work will continue to be unpredictable and experience much longer lead times than it should.

RETURN TO BLOG

 Posted on August 28, 2019 by

 Kanban

     , ,

Identify Queues

I often find teams that are struggling to get their work done, but many of these don’t see the queues and blockages that are impacting their everyday work. For me, these are key things that can be the focus for initial improvement. Oftentimes, by managing queues and blockages you can get a significant improvement in overall lead time without having to work any harder. For today’s blog post I’m going to talk about queues, a future post I will talk about blockages.

Queues appear where work is waiting to move from one workflow / knowledge discovery step to another. A common instance of this is where there is a handoff between teams or to a specialist. Use the visualisations to help make the queues visible.

Starting from this where the queues are not visible / hidden from the board:

As a first step make the queue visible. Often the queue is unbounded; ie it doesn’t have a WiP limit and we can often see items piling up waiting for the next state:

Once they are visible you can start to apply the WiP limit against it (in this case we created the “Testing – Done” column for those items waiting to deploy and applied the overall testing WiP limit which includes the “Testing – Done” queue):

Using a WiP limit will prevent additional work coming into the system before dealing with the source of the blockage. This creates a catalyst for action as work can’t proceed without the problem being remedied – it forces the organisation to deal with the key issues that are preventing work from getting done.

This can be the case particularly as an organisations size gets larger – usually this means more teams are involved to be able to realise the value which creates a series of hidden wait states. I often find this is particularly the case as you start to track the overall project / initiative outside of the immediate team and within the context of the whole organisation (often this is “upstream”). The more interdependencies between teams, the longer work will take. Usually in this situation it’s futile to try and make the work more efficient because the overall flow efficiency is so low that it’s not worth tackling. Instead, make the queues visible and work on the interdependencies to either remove them if they are frequent or be explicit about expectations for delivery to minimise queue wait times.

Sometimes when I’m first trying to understand the overall flow, I’ll put the queue in place and make it visible. If I see that it’s continuing to be a problem I’ll leave it in place. Otherwise I might take it out and put it as a “Definition of Done” for the step, or an “on the line” transition.

Identify queues and the wait time in the system of work. Determine which ones are having the largest impact to your flow efficiency and start to work towards removing them. In really inefficient systems, you can get lead times down to 10-20% of what they originally were without working harder, just manage the flow.  

RETURN TO BLOG

 Posted on August 20, 2019 by

 Kanban

     , ,

LAST Conference – Melbourne 2019

On Tuesday 30 July I attended the LAST (Lean, Agile, Systems-Thinking) Conference in Melbourne. This year I presented a talk entitled “An Introduction to STATIK – getting started with Kanban” plus I also did a workshop of “The Ship Game”. This is actually the second LAST Conference I’ve been to this year, I had already been to the inaugural Adelaide conference where I presented “Kanban for Beginners” and ran a session with “The WiP Game”. Thanks to everyone who could attend my sessions – I hope you got a lot out of it.

For those of you who are unfamiliar with LAST Conferences, they were started by Ed Wong (@littlehelper) and Craig Brown (@brown_note) who wanted a small grass-roots conference that was like “meetups on steroids”. Submissions are open to the public and there’s plenty of space, so if your new to public speaking and you want to try it out, it’s a really great way to get out there and give something a go. It’s also kept at a really low cost, as the speakers aren’t paid – just members of the local community. Sometimes not all of the talks are great – it’s been known to be a little “hit and miss”, but generally the standard is fairly good – plus I know a number of other conferences that I’ve paid a lot more for that have left me disappointed with some talks.

The Melbourne session is very popular and tickets usually sell out so we have a full house. It’s often run on two days, so usually if you miss something on the first, you often can catch it on the second. However this year, it was only one day so it felt like you really did miss quite a bit of content. The Adelaide session, by comparison was actually also sold out, but due to its smaller scale, I think it still retained a lot of the grass-roots feel to it.

Of the talks that I listened to, my favourite was from Neil Kingston from Intelematics who was talking about “Do project managers still matter?“. It was a story about how the project managers and PMO went from a project based system of work to a product based system. What was really interesting for me to hear was how Neil and the others in the PMO transitioned from command and control to what is effectively now a servant leadership role. A true tale of evolution, keeping the useful traits and discovering hidden or creating new talents to see how they can serve and support the overall organisation in its goals.

“An Introduction to STATIK – getting started with Kanban”

This was really a short summation of what Day 2 of my Kanban System Design training is all about (more details available here). During this talk, I describe the “Systems Thinking Approach To Introducing Kanban” and take attendees through the high level steps of how to get started with Kanban. Spoiler alert – no you don’t start by putting stickies on the wall!

During this talk, I describe the “Systems Thinking Approach To Introducing Kanban” and take attendees through the high level steps of how to get started with Kanban. Spoiler alert – no you don’t start by putting stickies on the wall!

For those interested, you can find my slides here:

The Ship Game

First of all I have to credit Klaus Leopold (@klausleopold) with coming up with the game – it’s really a great way to learn the difference between push and pull systems – plus it gives an insight into the metrics and data behind Little’s Law works.

The game is played in two rounds – the first round is using a push system, the second round uses a pull system. In both rounds we bootstrap the system in the first two minutes to get some ships moving through the production line. We record the amount of ships that are done and are in progress. At the end of the line one person is marking the time of exit for each ship. Then we add the “Red ship” which is the last ship to go through the system (using a FIFO – first in, first out – policy).

What we see is that the throughput is (approximately) the same in both rounds, but due to the WiP limits / pull system in place in the second round, we create less WiP – thus we can reduce the lead time through the system. Here is the data from the day:

Team 1

At two minutes:

EventRound 1Round 2
WiP146
Red Ship Enters2:002:00
Red Ship Exits5:283:25
Red Ship Time in Process3:281:25

Throughput:

MinuteRound 1Round 2
011
144
256
342
44
53

Note that the first an last minute of each round are disregarded as that is the system bootstrapping and winding down.

Calculations:

 Round 1Round 2
Average Throughput4.255
Red Ship Lead Time (decimal)3.461.416
Average Lead Time (calculated)3.291.2

Team 2

At two minutes:

EventRound 1Round 2
WiP166
Red Ship Enters2:002:00
Red Ship Exits6:533:46
Red Ship Time in Process4:531:46

Throughput:

MinuteRound 1Round 2
012
143
234
334
43
53
61

Note that the first an last minute of each round are disregarded as that is the system bootstrapping and winding down.

Calculations:

 Round 1Round 2
Average Throughput3.23.5
Red Ship Lead Time (decimal)4.881.766
Average Lead Time (calculated)51.714

The Results

What you can see from this data is that the “pull system” with WiP limits in place substantially decreased the lead time of ships through the process (to between one half to one third of the original time).  This really reflects Little’s Law in action which is effectively:

Average Delivery Rate = Average Work in Process / Average Lead Time

By decreasing the WiP we proportionately decreased the lead time. Furthermore, if we continued without WiP limits in place, the first round would have continually gotten slower delivery to the point where customers would be walking away because the wait is too long.

Thanks to everyone who could come along to my talks, I hope you’ve enjoyed them. I’ll see you again next year!

RETURN TO BLOG

 Posted on August 5, 2019 by

 Conference, Events

     , ,

Encourage acts of leadership at all levels

This is the final of the three Kanban Change Management Principles. Often this may start to emerge early in the process with a few leaders willing to try the Kanban journey. However, in order for it to be truly successful those initial leaders must be participant to making the emergence of leadership at all levels.

Why would this be necessary? Essentially, the Kanban process is evolutionary and will require a number of changes over a sustained period of time so that the organisation will continue to evolve to be more fit for purpose and resilient in the face of changing market conditions. In order for that to happen, the acts of leadership should not be focused on one or two individuals – this will not scale. In order to get the most change, we need to encourage others to play a part in this goal. A friend of mine once commented that he didn’t want just one brain (his) directing 20 other people – he much preferred having the 20 completely engaged people and thinking for themselves solving a problem.

So, what is leadership? In my view there are a few key points to leadership:

  1. Vision
  2. Courage

Vision

Leaders must have a vision as to the direction for the group and help move the team / organisation towards that vision. This is also where we can start to see leadership at all levels. Senior leaders tend to focus on the larger strategic vision for the organisation and how they can start to innovate towards or transform the organisation to fit that new vision. Individual contributors can have a vision for how they are going to implement things. Often the people who are “at the coalface” have a far better understanding of how things work day to day and are the source of many smaller improvements. The middle layer of management connect and coordinate the parts towards achieving the goal – having a vision for how this can be improved often has great benefit to an organisation.

Courage

They must have and display acts of courage. Making changes is often difficult – you may be going against the status quo and learned memory of an organisation, so you will need to be able to cut through the existing malaise to make progress. Acts of courage can come in small sizes as well – the act of making your work or problems visible is often a difficult first step because there might be people concerned for their jobs or bonuses preventing the transparency. Making these small changes should be encouraged and rewarded because they help catalyse larger improvements based on new information. Often the first change is to make it safe for others to make further changes and encourage other leaders to emerge.

Encouraging acts of leadership at all levels is probably one of the hardest and more sustained parts of the Kanban Change Principles. Look out for when your people are showing vision and / or courage and ensure that you don’t stifle this behaviour. Make it safe and appreciated – sometimes it’s as simple as just saying thanks.

If you want the change to scale, then it must become a key part of Kanban journey – so start thinking about it now if you haven’t already. These changes will ultimately make your organisation more fit for purpose and less fragile, plus it also has the bonus side effect of improving the engagement of your employees.

See also Start with what you do now, Agree to pursue improvement through evolutionary change

RETURN TO BLOG

 Posted on July 26, 2019 by

 Change Management Principles, Kanban

     , ,

Agree to pursue improvement through evolutionary change

This is the first in what will be a series of short articles about some of the key aspects of Kanban and how it can help you.

Agree to pursue improvement through evolutionary change

There are many aspects of this statement that I really like, in particular the evolutionary change aspect. This is a clear differentiator between Kanban and many of the other agile methods / frameworks out there, many of which prescribe that you will first need a series of larger disruptive changes to structure and roles.

Improvements are often small and continual, but the cumulative effect of many small changes can move mountains. In some cases, however, you may require some help from management to remove larger systemic bottlenecks and problems from your process. I see both of these as evolutionary changes – some are by their nature small, but some evolutions will require a little more effort to manifest. Leadership here is a key component – sometimes these changes are hard and will require some courage to start to implement.

 

All improvements require a change, however not all changes are improvements. Thus, there is a notion that we have to be active in this activity, not passive. Additionally, there is a feedback loop here. Often, we are dealing with complex or at the very least complicated systems and our hypothesis on the effect of a change may not necessarily prove to be true. In this case, some of the evolutions will need to be reverted / dampened down whilst others will need to be solidified and / or amplified. A key part of evolutionary change is the feedback loop and understanding which changes are effective as improvements and which are not. Of course, one size will not fit all, so you will have to look for improvements that will work in your context.

Another key aspect of this statement is the first word – agree. It implies that a level of discussion and consensus needs to take place before we start down this path. Having these foundations in place can avoid a great deal of resistance to the change down the track. At a very basic level you’re letting people know about what the change is and what to expect so they can understand and be prepared for it. However, there’s also another aspect to this where we want people to actually be involved in the change – having the agreement up front about the direction and mechanism for the changes will assist with this. Some transformations rely on a tell approach, however if you try the alternative Kanban approach, you’ll no doubt find that your change will be more effective in the long term. Sometimes it’s just a simple conversation, but other times it can take some time – particularly if the changes are the larger management led ones.

Evolutionary change can be a wonderful enabler for your organisation to grow to provide products and services that are fit for your customer’s purpose. What’s really important is to start to weave into the culture of the organisation a sense and need of continuous improvement so your organisation will itself evolve to become truly adaptive, whilst not running the risk of over-reaching with change. One of the key aspects of Kanban is the evolutionary change approach and I hope you will agree that this can be a lower risk way of introducing the required improvements into your organisation.

See also Start with what you do now, Encourage acts of leadership at all levels

RETURN TO BLOG

 Posted on May 14, 2019 by

 Change Management Principles, Kanban, Uncategorized

     , ,

Start with what you do now

This is the first in what will be a series of short articles about some of the key aspects of Kanban and how it can help you.

Start with what you do now

This is one of my favourite aspects of Kanban – the “Start with what you do now” change management principle built into Kanban. It’s quite simple and it engenders a foundation of respect for the current organisation that some change initiatives ignore – particularly some of the agile frameworks / methods where it is noticeably missing. I guess this is one of the distinguishing points of the Kanban method – it has an aspect of change management built into it.

There are a couple of additional points worth mentioning that expand on this:

“Understand current processes as they are practiced”
“Respect existing roles and job titles”

One of the key benefits of this kind of approach is that you acknowledge the current organisation and the people in it. “What you do now” has in some way been successful up until now – if not your organisation would likely have gone out of business. The purpose and customers may have changed over time and we can start to make adjustments towards this new purpose, but for now we need to acknowledge the present state. By making such an acknowledgement up front, you’re not going to get people within the organisation off-side when you encourage them to start to make incremental improvements (more on this in a later post). I often get feedback during my Kanban courses that people really love the idea of starting where they are right now.

By respecting the roles and job titles as they currently exist in the organisation, Kanban changes tend to have a low aspect of resistance. People are less threatened and often open to conversation as to how they can be a part of making their system of work better for all involved. That is, it’s often not just the customers that will benefit from this, but the teams involved in doing the work. I find as a coach going in to an organisation, that by using this kind of approach, I avoid a lot of problems before they arise.

Furthermore, with the aspect that we understand current processes as they are practiced tends to be very investigative and requires a curious mind. It should preclude jumping to conclusions as to what the cause(s) of the key issues really are (often this involves symptoms rather than causes of problems). Rather, this will allow us to get a better understanding into the why the problems really exist and to come up with appropriate solutions to those problems based on the specific needs of the contextual domain. Thus, your journey is unique and you’d be doing your organisation a disservice if you just “follow a pattern” to a “standard” end goal. Indeed, how are you competitive if you’re just doing what everyone else is doing?

The bar for change using Kanban has intentionally been set quite low – it allows you to get started rapidly without the large reorganisations and disruptions that other methods often require. That’s not to say you can start to make changes – evolutionary change is a central part to this and will be covered in a subsequent post.

See also Agree to pursue improvement through evolutionary change, Encourage acts of leadership at all levels

RETURN TO BLOG

 Posted on April 22, 2019 by

 Change Management Principles, Kanban

     , ,

Evogility