Kanban - Allan Kelly

Focus on flow

Agile, Kanban / allan kelly / June 4, 2024 / flow

I have happy memories of the days when was doing my masters degree and I would be among the first into the University library. After my morning swim I’d breakfast at the cafe opposite the library and when it opened I’d be straight in. Up to the top where I would sit for the next 3 or 4 hours completely absorbed in my studies. Reading, writing assignments and later my dissertation. I was working towards something and had complete focus. I would enter the fabled state of flow.

While flow is hard to define its an idea that occurs both personal level – as I just described – and at the organization level. Personal flow is hard enough to come about but organizational flow is an order of magnitude harder. So much more needs to be co-ordinated. You need a flow friendly system, it rarely happens my accident.

Perhaps thats why I’m so excited about both the featureban flow video I published last week and the Featureban Flow Experience workshop I’m running in a few weeks time.

Digital flow

Digital tools make flow both harder to achieve and more important. The constant stream of interrupts, e-mail, WhatsApp, notification, updates and so on, makes flow more elusive. But when machines do most of the “heavy lifting” work what remains requires human thinking. Focus and flow.

If machines companies are to get the most out of their machines the machines too need to enter a state of flow. If they are regularly stalling, maybe because they run out of parts, something fails or another human intervention is needed then they will not deliver their maximum return on investment. We, the humans, need to engine flow for the machines.

That’s why the Featureban game in the video is so important. It helps us understand the process of work, the work flow. Its kind of a throw back to the days of “time and motion men.” But really what we are doing is debugging the work system and keeping it, well, flowing. The game illustrates what happens when things go wrong and how we should respond – which can be counter intuitive.

For example, consider the players in the video: each one an expert agile/kanban coach who understands how problems arise. But it doesn’t require much before these players have created a mess. Its possible the mess would have been even bigger if the players were not such experts!

There is little anyone person can do to fix the problems. (If you want another illustration watch the old HP Stockless Production video also on my channel.)

Also notice that once Mike changes the rules of the system everyone does better. The rule changes, limiting WIP, are counter intuitive to many people but they work. Throughput is increased, output rises, and we can reason about the system.

The is also a socio-technical aspect here – as Russ Lewis points out near the end. In the first round when things aren’t going well a lot of dark humour passes between the players. I’ve worked in many companies like this: things aren’t going well and such humour is the coping mechanism for people who don’t feel in control. Actually, in the video the players are often channeling real-life complaints made by staff and management edicts which make things worse.

A lot of this dark humour replaces serious conversation about how the team could do better. The team feel powerless to change things so they don’t.

In the second round there is less humour but a lot more productive discussion as team members seek to work together to improve flow, increase output and resolve difficulties. Good flow leads to better flow. Humour gives way to satisfaction at a job well done.

3 ways to learn about flow

1. Flow may be hard to define but you know it when you see it. If you haven’t watched it yet what are you waiting for? The Featureban flow experience.

2. Now I’m please to announce that the template we used to play Featureban is now available in KanbanZone and is free to use. I’ll post instructions soon but I think you can probably work it out yourself.

3. Finally, join my online Featureban Flow Experience game on June 24th (code “ABlog20” gets you a healthy discount).

Focus on flow Read More »

Dealing with unplanned but urgent work

Agile, Agile Process, Kanban, Xanpan / allan kelly / October 3, 2018

3) Maintenance and Evolution
To keep a product alive, we choose backlog stories that will bring value, and do them one after the other.
But… as support of the application may take a huge part the work. And when the problem is critical, there is nothing you can do but stop what you do and fix it. This can blow any estimation.
How do you deal with firefighting in a #NoProjects world?
And techniques to avoid it.
How does #NoProject and DevOps work together?

Let me take the last part of this question first. Operations has never been plagued by the project model the way development has. When does a SysAdmin ever say “The project is finished so I’m not going to restart the server” ?

DevOps (aka Continuous Delivery) and Continuous Digital are a natural fit. The team is responsible and accountable: writing the code, deploying it and supporting it there after: “You built it, you operate it” as DevOps people like to say.

Of course the team needs to contain all the skills needed to service this approach. That might mean having an individual specialist on the team or it might mean that team members have multiple skills. A Continuous team is not just a DevOps team, it is also a Business-Technology team – or #BizTech to coin a hashtag. (This week I heard such a team called a BizDevOps team. That is one portmanteau too far for me.)

Which brings us quite nicely to the first part of this question: how do you manage – and perhaps even plan for: unplanned work?

What I would like to happen when unplanned work appears is that it is written on a card and placed in the backlog. It then takes its place with all the other possible work. But… as the questioner states: this work can’t wait, it is urgent.

Unplanned but urgent simply needs to be done. Quite possibly other work, less valuable work or work which is not time critical may even be interrupted.

At this point I was about to refer readers to an old blog post about Yellow Cards. But it turns out that I never wrote that post. Despite talking about Yellow cards for years I’ve never blogged about them. I wrote about them in Xanpan but for some reason or another I never wrote the blog… so here you go…

When a team is mid-sprint and unplanned work appears the team should:

First ask “Can this work wait?” – If so then write it on a regular card and put it in the backlog
If not then ask, is this more valuable than work we are doing now? – If not then someone needs to find the source of the request and explain why is isn’t going to get done.
Assuming it is urgent then it gets written on a Yellow card.
If it is really really urgent then someone drops what they are doing and works on the yellow card immediately.
If it can wait a little while then the next person who finishes their current work picks up the card and does it.
Once the yellow card is done mark it as done as with any other card and work continues as it was before.

Accepting unplanned work into a sprint impacts the other work the team is doing. I’m not a big fan of the commitment protocol so to me it is no big deal if this work displaces something else. But if your team are expected to hold fast to hard commitments while dealing with unplanned work then you have a problem, call me, we need to talk more.

At the end of the iteration we can look at the cards and reason about them. Now we can see the work we can manage it and decide what to do about it.

I count up the yellow cards – and all the planned work cards. That allows me to calculate a ratio of planned versus unplanned work. (Sometimes teams put a retrospective points estimate on a yellow but doing a card count is often sufficient.)

This can be tracked over time – graph it, make it visible again. Now we can look at the work and the pattern of work, reason about it, maybe do some root-cause analysis. Perhaps:

Perhaps much of the urgent work isn’t really so urgent, perhaps the team should push back more. Maybe the team, or one of the team leaders, needs to the authority to say No.
Perhaps most of the unplanned work comes from a particular person. Maybe this person doesn’t realise the impact of their unplanned requests, or maybe they need to be included in the planning process, or … a million other reasons.
Perhaps the unplanned work is coming from the same sub-system, maybe some remedial work on that sub-system could reduce the amount of unexpected work.
Perhaps the unplanned work is just the nature of the business and being responsive is valuable.

Looked at this way we can think about reducing the amount of unplanned work. But also, we can plan for unplanned work.

It is likely that over time a pattern will emerge. One team I know found that 20% to 25% of their work in any sprint was unplanned. They simply planned for 20% less work. They now had the capacity to cope with unplanned work. At the least they could expectation manage stakeholders.

One team found that each sprint they were doing about 20% IT support tasks (new PCs, Word problems, etc.) so they hired a support technician.

Another team who agonised about unplanned work found that actually they only had about one unplanned card a week. Their problem was not excessive unplanned work but the fact that unplanned work tended to have a very high profile in the company.

Teams which find they have very high levels of unplanned work on a regular basis (e.g. over 50% of work for several months) may well decide to adopt a full Kanban system. Indeed, Kanban folk probably recognise my description as a very simple example of quality-of-service and policies.

I say more about Yellow Cards for unplanned but urgent in Xanpan so you might like to continue reading there.

This is the third question carried over from the #NoEstimates/#NoProjects August workshop in Zurich.

If you have any questions about Continuous Digital, Project Myopia and #NoProjects please mail them over and I’ll do my best to answer them in this blog.

Receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Dealing with unplanned but urgent work Read More »

How much did it cost?

Business, Kanban / allan kelly / November 7, 2017

An interesting question came up at an event last week:

“My Kanban team has been asked by accounts to put a cost on each story that is done. How do I calculate this?”

My initial thought was: easy, and it is easy to give a simple answer to this question but if you unpack the question and the motivation behind it things get more interesting. Although the question was asked about a Kanban team most of the answer applies equally to Kanban, Scrum or Xanpan teams but contrasting the Kanban and Scrum approach offers an interesting insights.

So, first off the easy answer:

Select a period of work, say a month.
Count how many things (the things you want to know the cost of, stories, backlog items, tickets) got done (what ever your definition of done) during that period, e.g. 6 user stories might have been completed in the month.
Calculate the burn-rate for your team, e.g. if you have 5 team members who each cost $100,000 a year then the monthly burn-rate for the team is $41,666.
Divide your burn-rate by the number of items done, e.g. $41,666 / 6 = $6,940.

This approach adheres to the maxim “It is better to be roughly right than exactly wrong” – which is often credited to John Maynard Keynes but I believe it actually comes from philosopher Careth Read.

Although you might see many things potentially wrong with this crude calculation it has one redeeming feature: it is quick and therefore the cost of doing this calculation is low.

If you want you can improve on this calculation with more data. At the aggregate level you could consider a longer period with more items. Or you might calculate the statistical distribution and provide a range of answers.

Alternatively if you record the start and end dates of the work you could make this calculation more fine grained:

Work on an item starts on 1 November 2017 and completes on 6 November, 4 elapsed working days
The daily burn rate for the team is $1,923 per day (based on the same team of 5 and 260 working days per year)
Therefore a 4 day story cost: $7,692

Now notice, this figure is $700 higher than the previous figure. Which is the right answer?

As an engineer you want to know the actual figure, there should be an equation here, right?

Well yes, there should, but as with any equation you need to make some assumptions. Accountants know this, just ask them about “exceptional” items on the balance sheet and you will find out how subjective accounting is.

By the way, notice this second calculation is also fast and cheap. Were we to ask everyone who touched the story to record the time spent then two things would happen. Firstly those who recorded their time would be less productive in doing the work itself so the cost of knowing the cost would increase.

Second, you are replacing one set of assumptions with another. Namely: that people can accurately record or recall the time they spend doing something. They can’t, so the figure is subjective again, check out my Notes on Estimation and Retrospective Estimation if you don’t believe me.

Back to accounting…

Now the question that arises is “why even ask this question?” – surely recording costs at such a detailed level is waste itself? What value is knowing the cost of each small piece of work?

Now I agree with this, and I would hope you have a conversation with those asking the question as to what they are trying to achieve, what are they going to use this data for? – what they are going to use the data will influence how you calculate it.

But.

But, if you are leading a team and are approached by an accountant with the question “how much does each item cost?” I would advise you not to open the waste question there and then. My advice is to comply with their request in the most efficient manor, i.e. calculate it by one of the methods above.

Let me suggest that were you to immediately move to the question of “Why are you asking me this?” let alone “Answering your question is waste therefore I will ignore it” is likely to create more problems than it will solve.

For better to answer such questions, win some credit and trust then later return with the bigger questions. And since there are different ways to come up with a number you have an opportunity:

“Bill, you know those ticket costings I’ve been giving you for the last three months?”
“Sure, Betty, they are really useful for the capex/opex report.”
“Well Bill, I think there is a better way of calculating them can we talk about how you are using them?”

The fact that there is some ambiguity in the question and answer is an opportunity to have a discussion. First though, you need to win the right to have the discussion.

Now back to the original question.

The motivation behind the question was in part because Scrum teams assign estimates to stories and these estimates can be used as proxies for cost. In terms of accuracy such an approach is wild, at best it is little more than a random number generator for most teams and at worst it will distort both the estimate and the cost calculation. Numbers based on such estimates are unlikely to be accurate at all.

However the techniques described above will work just as well for a Scrum team as a Kanban team. You probably want to work at the Sprint level:

A team of five did 3 stories in a 2 week Sprint (10 working days)
Each team member costs $100,000 a year therefore each Sprint costs $20,000
Each story cost $6,666 ($20,000 / 3)

Such an approach is going to be far more accurate than anything based on estimates and probably more accurate than anything based on time recording. Again you could use more data to build up an even more accurate picture.

Now my big BUT…

This is all about COST.

Everything so far has been about cost. And I know most teams deal in cost. I know most of you are constantly asked “how much will it cost.”

But I also know there there is someone, somewhere, who will promise to do the same thing for less. While you are on the cost side of the equation you will always loose.

What we should be doing is considering Value. How much are these work items worth?

Rather, or in addition, to reporting cost you want to be reporting Value added:

“Bill, here are the figures from the last month, in total we did 10 items at a cost of $41,000 and we added $86,000 to sales”

Or maybe:

“Bill, here are the figures from the last month, in total we did 10 items at a cost of $41,000 and we added 1,000 site views”
“Bill, here are the figures from the last month, in total we did 10 items at a cost of $41,000 and we made 500 children smile”

I know measuring value is hard but we have to try. If nothing else, estimate value the same way you estimate effort.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

How much did it cost? Read More »

Kanban paradox

Agile, Agile Process, Kanban, Scrum, Xanpan / allan kelly / October 31, 2017 / 3 Comments

For a while now I’ve been seeing a paradox with Kanban. Specifically, Kanban compared to Scrum.

For a team new to Agile – although some regard this as heretical I place Kanban under the Agile umbrella, yes I know its more about Lean than Agile but of cause Agile is itself a Lean method, anyway…

For team, specifically a software team, looking to adopt a new process there is a choice:

Kanban has a very low barrier to entry, to get started Kanban essentially says “visualise your work and manage the result.” Starting Kanban can be as simple as putting up a board and tracking work items. In Kanban visualisation should drive improvement. Change can be incremental and gradual. Change is rooted in learning.
Scrum has a far higher barrier to entry: essentially Scrum says, “Adopt Sprints, designate a Product Owner, appoint a Scrum Master and build out a backlog.” Once these changes are done you can run with Scrum and then the Scrum Master and retrospectives will kick-in and drive further improvement.

Interestingly, neither method says explicitly “Improve your quality.” Yet I always believe a lot of the success of Agile methods is down to good old quality improvement: writing fewer bugs and having fewer bugs to fix means greater predictability and more time to deliver valuable software. But I digress.

It is easier to start with Kanban because it requires less up front change. However that does mean the improvements are slower coming.

Conversely, Scrum drops in, changes a lot and most teams see an immediate improvement. Scrum relies less on subsequent change.

Because Kanban relies more on ongoing change it is more difficult. It is easy to get stuck at the “we built a Kanban board so we are doing Kanban stage.” Change in Kanban requires one to see the need to change, understand what will fix a problem and then follow the change through. That often requires experience. Thus in teams adopting Kanban there is a greater need for a coach, a consultant, someone who has done it before.

Scrum on the other hand makes far more changes upfront and the recipe for improvement is more straight forward. And of cause there are a lot more books on Scrum, blogs on Scrum, Certified Scrum Masters and Scrum experience out there. So while it is harder to get started with Scrum (because more needs to change) there is less need for further change and you change does not require the same level of knowledge.

You see this specifically when you look at statistics. Watching the numbers should be important in both processes but with Kanban it is near essential. Anyone with real understanding of Kanban knows that queuing theory, lead times, possibly weighted lead times, and a bunch of other numbers need to be examined.

Scrum on the other hand doesn’t go much further than a burn-down chart. Yes, making more improvement with Scrum will also benefit from understanding lead times, queuing theory and the rest but you can quite happily use Scrum, and even improve Scrum, a fair bit without understanding these ideas.

So here is the paradox:

It is easier to start with Kanban than it is Scrum without expert knowledge, but it is harder to improve Kanban than Scrum without expert knowledge.

In many ways I prefer Kanban but I find this need for expert knowledge troubling. I suppose I shouldn’t, I’m a consultant, I am that expert, people hire me to help improve their Kanban processes so it does make more work for me.

In the longer run, the Kanban approach is more likely to lead to a genuine all inclusive culture of improvement and is less likely to get stuck in a sub-optimal position – yes Scrum fixes things, but is it the best fix possible?

Looked at like this gives me a new perspective on Xanpan.

I wanted Xanpan to be two things:

An understandable description of actually following an Agile process, specifically a Kanban/XP hybrid processes
An example of how, and why, teams should create their own processes.

The same paradox is here: Xanpan should be easy to start but allow you to improve; creating your own process requires a bit more knowledge that only really comes with experience.

To step back a minute and ask another question: What amount of change can a team handle to start with?

I find that I advocate more initial change than I used to. Because I’m fearful of creating a learned dependency I really want teams to learn to change and improve themselves. But… once a team has decided to change I want to seize the opportunity and install a bunch of changes while enthusiasm is there.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

Kanban paradox Read More »

Utilisation and non-core team members

Agile, Agile Process, Kanban / allan kelly / September 25, 2017

“But we have specialists outside the team, we have to beg… borrow… steal people… we can never get them when we want them, we have to wait, we can’t get them enough.”

It doesn’t matter how much I pontificate about dedicated, stable, consistent teams I hear this again and again. Does nobody listen to me? Does nobody read Xanpan or Continuous Digital?

And I wonder: how much management time is spent arguing over who (which individuals) is doing what this week?

Isn’t that kind of piecemeal resourcing micro-management?

Or is it just making work for “managers” to do?

Is there no better use of management time than arguing about who is doing what? How can the individuals concerned “step up to the plate” and take responsibility if they are pulled this way and that? How can they really “buy in” to work when they don’t know what they doing next week?

Still, there is another answer to the problem: “How do you manage staffing when people need to work on multiple work streams at once?”

Usually this is because some individuals have specialist skills or because a team cannot justify having a full time, 100%, dedicated specialist.

Before I give you the answer lets remind ourselves why the traditional solution can make things worse:

When a resource (people or anything else) is scarce queues are used to allocate the scarce resources and queues create delays
Queues create delays in getting the work done – and are bad for morale
Queues are an alternative cost: in this case the price comes from the cost-of-delay
Queues disrupt schedules and predictability
In the delay people try to do something useful but the useful thing is lower value, and may cause more work for others, it can even create conflict when the specialist becomes available

The solution, and it is a generic solution that can be applied whenever some scarce resource (people, beds, runways):

Have more of the scarce resource than is necessary.

So that sounds obvious I guess?

What you want is for there be enough of the scarce resource so that the queues do not form. As an opening gambit have 25% resource more than you expect to need, do not plan to use the scarce resource more than 75% of the available time.

Suppose for example you have several teams, each of who needs a UX designer 1-day a week. At first sight one designer could service five teams but if you did that there would still be queues.

Why?

Because of variability.

Some weeks Team-1 would need a day-and-a-half of the designer, sure some week they would need the designer less than a day but any variability would cause a ripple – or “bullwhip effect”. The disruption caused by variation would ripple out over time.

You need to balance several factors here:

Utilisation
Variability
Wait time
Predictability

Even if demand and capacity are perfectly matched then variability will increase wait time which will in turn reduce predictability. If variability and utilisation are high then there will be queues and predicability will be low.

If you want 100% utilisation then you have to accept queues (delay) and a loss of predicability: ever landed at Heathrow airport? The airport runs at over 96% utilisation, there isn’t capacity to absorb variability so queues form in the air.
If you want to minimise wait time with highly variable work you need low utilisation: why do fire departments have all those fire engines and fire fighters sitting around doing nothing most days?

Running a business, especially a service business, at 100% utilisation is crazy – unless your customers are happy with delays and no predicability.

One of the reasons budget airlines always use the same type of plane and one class of seating is to limit variation. Only as they have gained experience have they added extras.

Anyone who tries to run software development at 100% is going to suffer late delivery and will fail to meet end dates.

How do I know this?

Because I know a little about queuing theory. Queuing theory is a theory in the same way that Einstein’s Theory of Relativity is theory, i.e. it is not a theory, its proven. In both cases mathematics. If you want to know more I recommend Factory Physics.

So, what utilisation can you have?

Well, that is a complicated question. There are a number of parameters to consider and the maths is very complicated. So complicated in fact that mathematicians usually turn to simulation. You don’t need to run a simulation because you can observe the real world, you can experiment for yourself. (Kanban methods allow you to see the queues forming.)

That said: 76% (max).

Or rather: in the simplest queuing theory models queues start to form (and predictability suffers) once utilisation is above 76%.

Given that your environment is probably a lot more complicated then the simplest models you probably need to keep utilisation well below 76% if you want short lead times and predictability.

As a very broad rule of thumb: if you are sharing someone don’t commit more then three-quarters of their time.

And given that, a dedicated specialist doesn’t look so expensive after all. Back to where I came in.

Read more? Join my mailing list – free updates on blog post, insights, events and offers.

Utilisation and non-core team members Read More »

Notes on a Kanban software development experience

Kanban / allan kelly / January 29, 2009 / 2 Comments

I’ve mentioned the Kanban software development method in this blog before. For those who don’t know its “the new kid on the block” in Agile circles – although the originator (David Anderson) would be quick to point out it is designed to be a Lean development method.

Last year I did some consulting with a large online travel agency. I was involved with helping five teams “get Agile.” This presented an opportunity to try out Kanban in the wild. What I found was: it works, and I feel it is a better models of my own approach to software development than other methods.

What made this engagement more interesting was that I was able to start one team using the Blue-White-Red Agile (BWR) development method I’ve described before and two teams using Kanban so making for an interesting comparison.

The BWR team had been tasked with a project for which a large functional specification had been written. The spec wasn’t perfect but the organization expected them to complete it. BWR allowed the team to break the spec down and attempt it piecemeal. Some upfront estimates were made and a burn-down chart created.

(It almost looked Scrum like, that is, if you ignored the Project Manager, Development Manager, Team Leader, Architect and second Project Manager who joined the project later – and lets not forget me as Agile Coach. Its hard for a team of five developers (and a Product Mmanager) to be self-organizing when there is an equal number of self-organizers.)

This worked well. In the first few weeks I took a lot of heat because I refused to let a completion date for the work be given. Simply we did not have enough date to go on. Once the data started to come through I could do that.

The two Kanban teams were in a different position. Although they had “projects” to do most of their work was sustaining work. There were systems in place and issues needed fixing. Many of the things the company called “projects” were really to small to be worthy of the name – but that’s another story.

As a result the teams had more diversity in their work and more variability. Work would just appear – and disappear. They would have been hard pressed to keep to an unchanged task list (backlog) for a one week iteration, let alone a four week sprint.

This is the first good point about Kanban: its easier to handle changing work loads.

The teams still did “iterations” but the planning meetings quickly changed. Some work would be planned out but this could be usurped at any time. The iteration became the basic unit of comparison, allowing two periods to be compared. This meant that the start/end of iterations meetings were rather more of a review and retrospective session than planning session.

In future I think I would nominally keep iterations for this reason. They are useful time periods to review work and provide a regular review/retrospective point.

Second good point about Kanban: its easier to pick up.

On the whole I found the two Kanban teams needed less training, instruction and coaching than the BWR team (some of whom had been on Scrum training courses.) However, there was some work needed to map out the correct process flow for the Kanban teams to have on their boards.

For anyone creating a Kanban board some advice: big boards a better, involve the team and use coloured tape – insulation tape works well. In the past I’ve just drawn lines on the white board, with Kanban there is more movement and the lines are lost so I used insulation tape to create hard barriers.

A Kanban board

I expected the work in progress (WIP) limits in Kanban to pose a problem. I was expecting managers and others to want to break the WIP limit. This didn’t happen but I found developers breaking the WIP limits.

Developers broke the limits not because they disagreed but because they were accustomed to starting new work when they hit a problem. For example, a developer is working on item X, they come to a block on X so start on Y. In the extreme they block on Y and start on Z. You now have three partially done pieces of work. Trying to instil a “resolve the block” approach was difficult – largely because this organization was overloaded with managers and developers had been “taught” not to resolve these type of issues themselves.

In this organization lots of things blocked. Blocked on other teams. Blocked on IT support. Blocked on administration, etc. etc. I didn’t like it but I added a “blocked” column to the Kanban board. I also added a tally sheet to identify the biggest reoccurring blocks. I then tried to have the managers feel responsible for resolving the blocks. This was only partially successful because managers were themselves blocked because there were so many other “managers” who wanted their time. (The organization used talk as a substitute for action.)

All the teams held daily stand-up (Scrum) meetings and I encouraged the team manager, product manager and BAs to have their own pre-meeting to ensure the prioritisation queue was full and correct. This worked well.

I had the teams tracking cards by making a note on the back of the date as it progressed across the board. The date when it entered the priority queue, the date when work started and stopped, the date when it went for sign-off or test and the date when it was “done.” This data (when complete) was fascinating and started to reveal issues and opportunities, and give an idea of flow. In fact there was so much date I was overwhelmed.

In conclusion I find myself remembering Karl Scotland’s comment from a few months back. Karl had a quote which was something like: “The emphasis in Scrum is on being Agile and improvement follows; the emphasis in Kanban is on improving and being Agile follows.”

In the past I’ve shied away from labelling a team as doing “Scrum” or “XP” because I was aware they were not going it completely and we weren’t seeing all the benefits. I don’t feel that about Kanban, I’m happy to call these teams Kanban. Yes they had problems but we were resolving them. The teams were on a journey.

As anyone who has read Changing Software Development will know, I’m an advocate for incremental improvement. While Scrum (and XP, etc.) hold out the promise of overnight Agile – one big bang and your there – I see Agile as a journey not a destination.

Notes on a Kanban software development experience Read More »