We are a web development company and for years had clients asking for solutions around Kanban board, but for totally different businesses. They just didn’t know it’s called Kanban…

So we developed smartQ - (http://www.getsmartQ.com).It’s basically Kanban for the masses - makes it easy to adjust it to any process and business type.

With distributed teams the whiteboards and yellow stickers will move online, so tools like that should help more teams get to know Kanban or Kanban-type methods.

Neither methodology it would seem has all the answers to this aspect of software development, with Kanban trying to correct for where Agile would seem to have failed.

I’d just like to add the point though, that in bringing on new methodologies, we lose sight of the fact that it is not the methodology , or the client , or even the technology that causes low quality software or project overruns, it is P O L I T I C S.

With this in mind, consider the case where a PM or scrum master choses to laydown the law and prescribe a 1 week sprint to cover say 7 tasks out of 3 stories. Whether or not the tasks were fully scoped, The fact of the matter is , that POLITICS rears up and forces the PM to cut quotes by 25% for no methodical reason beyond pressure from above. When pressed on this decision at a post mortem, the PM may say that Agile demands short iterations, yet the PM may have failed to acknowledge that Agile also demands consultation with the system developers , not just ‘make my date’ or else.

Kanban or any other new methodology cannot account for or combat these failures to adhere to development guidelines. Its the Politics that makes the methodology look faulty.

We use both methodologies, each where they shine most:
Scrum for development of new software; Kanban for recurring activities (e.g. maintanance).

Neither of these methodologies is superior in general. It all depends on the problem you want to solve.

For details see here: http://www.infoq.com/minibooks/kanban-scrum-minibook

You say:

“What if members of the team are non-developers, i.e. testers, UX, UI people.”

I assume therefore that the block occurs in development and not in test? If you don’t have any resources that can help out to solve the block, then some of your resources will be idle. In such a situation these idle resources can pair up with developers. This may be fruitful both for developers and non-developers as they can learn from each other.

When the bottleneck is solved the team should try to find the root cause of the problem and take appropriate action based on the findings. If its a recurring problem, then one possible solution can be to reduce the WIP limit for development station. This will decrease the lead time and help the team push features faster through the system. Setting the correct WIP and queue limits is something that a team should experiment with If you have 3 developers on your team an approriate limit could be 3-5. Start with something simple and adjust as you go, but don’t change values too often. When a system change, it needs some time to stabilize.

Hope this answers your question.

“It might not be necessary, or even possible, for all team members to help out. Instead, these resources can spend time improving the overall quality of the software being built (more tests, refactoring etc…).”

What if members of the team are non-developers, i.e. testers, UX, UI people. If they don’t have the skill sets necessary to help remove the bottleneck and we continue to enforce the queue and WIP limits do they run the risk running out of work and/or being under utilized?

You’re asking a question that avoids the issue (from a Project Management standpoint) -

Would I rather have a team improve their estimation techniques or their software-building techniques?
I want both. The two are not mutually exclusive. I want a team that knows what they’re doing and knows how long it will take.

“Don’t write more specs than you can code, don’t code more than you can test and don’t test more than you can deploy”

That’s good advice. It’s also what I would call estimating. The problem is that, in your example, you don’t know what that amount is until AFTER you’ve started.

The problem we are trying to solve is in my opinion:

How can we deliver high quality software aligned with what the customer wants within a predictable time frame.

These days people more or less agree on that splitting the delivery of a product or projects into smaller deliverables is preferable over delivering the entire product at the end. In order to accomplish this there will of course be a need for planning. This is something that I don’t get into details about in the article, but you always need to plan your work. People claiming that agile equals no planning has got it all wrong. In Kanban there is in fact continuous planning. When the ready queue (holding the work that has been planned) is starting to get empty, the team (together with stakeholders of course) need to do a planning session to carve out new features/bugs to fix etc… which will then end up in the ready queue. How much to plan in each session is something that needs to be experienced with.

The clue is, stated so elegantly by Corey Ladas:

“Don’t write more specs than you can code, don’t code more than you can test and don’t test more than you can deploy”

The world changes and if we do to much up-front planning we run the risk of basing our plans on the wrong assumptions. Experience shows that delaying decisions to the last responsible moment is almost always feasible. The reason is of course that you increase your knowledge as you go. This does not mean that you can’t make predictions about the cost of a project at a high level, you should. I also think that t-shirt sizing features (that are testable valuable units) can have some value. But I consider doing detailed estimations of each task in a project to be waste. I think Troy describes it nicely:

“Would you rather a team try to improve their software estimation skills/techniques, or would you rather they try to improve their software building skills/techniques?

I know what I will choose.

My response is, would you rather a team try to improve their software estimation skills/techniques, or would you rather they try to improve their software building skills/techniques?

Kanban frees teams to concentrate on the latter.

Also, generally, the less project management work needed is a positive sign for the team and project. If you find yourself immersed in PM work, then your already in trouble, you just may not realize it yet.

Maybe I’ve got this wrong, but it sounds basically like you’re removing the ‘management’ part of Project Management and simply reacting to emergencies.

Your Kanban appears to be a less a new method and more a reaction to poor planning/estimating techniques -

“The team starts on the new sprint but after a few days it becomes clear that the team has under-estimated the complexity of the stories.”

“After a while you can start making predictions like: “We can deliver user story X within 7 days”. In my opinion this is far more predictable than saying: “We think we can deliver stories X, Y, Z within 4 weeks”.

Yes, it’s more predicable. It’s even more predicable to say “here’s what we’ll have done tomorrow and what we won’t.”

That’s not management, that’s status update.

now (Just In Time) Kanban approach in software development/maintenance would mean the client who asks for the services needs to be more aware of the limitations of what (s)he wants and when.

In the real world, the development team following agile methodology is never given the authority to decide what they can deliver and what they can’t. it is the client who still calls the shots…

so implementation of Kanban to that extent would have to be again considered with the client approach in mind…

but let’s hope this is a better way.. only implementation will tell

You can find out more about Kanban Systems for Software Engineering at the Limited WIP Society

Karl

I can see how it gates the flow of work through the development phases (stations) and puts priority on the completeness of the work product vs how quickly it gets done. Like lean manufacturing systems, the overall speed (ie end-end lead time) can be increased later by appropriate throughput balancing of each station.

I’m going to keep my eye open for more articles on this technique and monitor its adoption.