AGILEMANAGEMENT
Nice.
I've used an approach that's about 90% similar in somewhat smaller shops. It works. Also, it addresses several things that can cause immense problems with other approaches.
- This avoids is creating second-class "sustaining engineers" (This, BTW is nonsense even with a separate "sustaining" group. Who put the problems in there in the first place? The other guys.)
- It also avoids artificially limiting the scale of a fix. Sometimes, like on "this old house" the CR is one symptom of a bigger problem. So, fix the whole wrong-hung door, don't just put on another piece of flashing that'll leak just as badly as soon as the wind blows from a different direction. Under the wrong pressure to ship in the next build engineering standards too often get relaxed.
FWIW, I have treated some of the stuff you call "extra" as first-class defects by reserving the right to nominate some internal tech problems into the backlog. I let the tech team nominate items that go into the backlog. That's a bit off from striclty customer / user experience driven issues. Doing so has some down-sides.
The big up-side is buildign some business-team awarness, particularly that there's some stuff, sometimes that simply has to be done or we're out of business. I've seen situations where the available slack isn't enough to keep up with this. Not always.
Thanks, especially for publishing this to get the word out.
Nice description and pictures! One question though. It sounds just like an agile iteration to me. What would be the difference between such a system and regular agile?
Siddharta,
Differences...
(1) There is no estimating of change requests
(2) While releases happen every two weeks, the lead time for most CRs is 30 to 60 days. So we get things done that would be difficult/impossible to do in a 2 week iteration.
(3) There is no negotiation of scope of the release. What gets released is what is ready for release. The releases run like a train schedule. The passengers on the train (the "Release Ready" queue) leave the station. Those who are further back in system wait for the next release.
Love your post! This shows me a way to handle the customers focus on issues and over to release. Our customer often want specific functionality and therefor want a release for it. This creates difficulties when they later change the specification and still want us to deliver to the same date. A more often regular release would not be so bad, the problem for us is often that we have to move the release itself.
On the matter of estimation we also have a problem when the new specification arrives. We are already working on the issue and sometimes we have to redo the code. At this point we do not have time for a new estimation on the issue, which makes it very unpredictable. A predictable release cycle would then be great. The customer do not have to wait that long and we have a bit more predictability.
Thanks again for these pointers, will apply some changes in my project during the next months..
a good blogging. thanks for this posting. regards
Dave
Can't make it out from the photo, so how is the "y-axis" of the table divided up? I'm guessing into project or product streams...
Second question: I do appreciate the benefit and value of using tactiles, such as cards or post-it's, for visual control, but since you have the data in TFS anyway, why not concoct a "heijunka box" view of this data automatically? This could be displayed via beamer for all to see. It's possible, of course, that the physical representation of the items being tracked provides a "psychological" benefit that outweighs the effort required to create such a view, but (as usual) I'm thinking of organizations dealing with hundreds of CRs as opposed to 20-25, where the maintenance of such a display could potentially become a bind.
Marvellous post in any case. Simplicity, elegance, power are the dicerning features of the solution you describe. In a word: Beauty.
M
Mike,
The y-axis columns are the states of the workflow from Engineering Ready Queue through Systems Analysis, Development, Build, Test, Release Ready and In Production. Each state has its own kanban limit shown in red at the top of the column.
Currently, the reporting capability in TFS isn't good enough to give us something we can easily display but you are describing my dream system. As someone who is a member of the customer advisory council for TFS, I'll be providing this feedback to Microsoft at a forthcoming SDR event in Redmond 
David
Sorry, still a little confused. Don't the workflow states comprise x- (as opposed to y-) axis? I.e. Don't the CRs move from left to right? If yes, then I repeat my y-axis question...
duh! Sorry!
There is no significance to the y-axis. Cards are simply in buckets the columns just show buckets for each state. The position in the y-axis is not significant.
So suppose the queue for one of the states; say Build gets full due to some problem there, then work stops at the previous states to prevent feeding into the bottleneck and creating inventory. Is that right?
Would you then wait for the bottleneck to resolve itself, or reshuffle the resources, say moving someone from Development (who are now idle) to Build?
Correct! We halt the line. Nothing moves. Issues are logged, assigned and tracked and line management focuses entirely on resolving the issue and unblocking the work items so that the pull system can resume function.
The idea is to focus the team on getting good at issue resolution. If we allowed work to go around the blockage then the blocked work would be second class, issues wouldn't get resolved quickly and the team wouldn't have an incentive to seek root cause fixes to prevent recurrence. There would be no poka-yoke (mistake proofing).
It is painful at first but the end result is worth it.
By enforcing the rule that cheating the kanban limits is not permitted, I've observed that quality circles spontaneously form to resolve problems with root cause fixes.
So the board tracks work items belonging to a single project (or product), right?
Assuming resources were pooled for use across a number of projects/products, would you advise using separate boards for each project/product, or would you use a single board?
I could envisage advantages and disadvantages for both approaches, and I'm guessing it depends to a large extent on the size of the organisation in question.
Dave
I just re-read your post above where you document your observation that "quality circles spontaneously form".
This is is a ***hugely significant** observation! As numerous quality writers have documented, attempts by Western manufacturing to mimic the benefits of Japanese-style quality circles by officially introducing (read: imposing) QCs on the organisation, usually ends in disappointment, if not abject failure.
Root-cause analysis is therefore rarely instigated by the process executors, but by management, which subsequently engages 3rd parties to find out "why party such-and-such screwed up". Apart from being demotivating for those whose knuckles get wrapped, as well as those party to the wrapping, the process executors will never develop the appropriate mindset for addressing root-causes, and continue to seek locally devised work-arounds which allow them to move forward in the short term. The process ultimately remains subject to special causes and we all know (or should know) what that means for quality.
Clearly it would be naive to assume that, by introducing a Kanban system, QCs will arise naturally in every instance. So what are the other prerequisites? I'll start with: A joint sense of responsibility, reenforced by team-oriented performance measurement and reward scheme...
IMO if the phenomenon of spontaneous formation of QCs proves to be consistent, this must surely be classed as one of THE primary benefits of the approach - although I admit there are so many astounding benefits it's difficult to state which is the most important.
Actually, the board is for our sustaining activity which is on-going. There is no "project" as such. Sustaining/Maintenance spans all systems and applications we support.
The resources for sustaining are normally assigned to a major project and temporarily pulled off to work on sustaining. The departmental commitment is that at any one time, 10% of our resources will be workingon sustaining work rather than major project work.
I haven't figured out how to use this system for major projects, but I believe we'd use a single board per project, i.e. we'd limit the WIP (kanban cards) per project, in accordance with Governance Board approved resource allocation.
On spontaneous QC's...
Great question Mike! I need to think about it and follow up with another blog post to do it justice. Thanks for the stimulating conversation.
Sticky notes? While I totally agree with most of the process and like the analogy of the releases being the train with the CRs being the passengers - a white board with post-its is very limiting. How do remote workers stay in the loop? What happens when a big wind blows your notes off the board?
Mike, The post mentions that everything is tracked electronically through Team Foundation Server. This enables remote workers to see all the work in progress information and naturally allows us to reconstruct the whiteboard accurately whenever we choose to or need to. David
How do you size the item going into the process? There must be some upper limit to what can be processed? Do you split an item into several items as you progress and learn more about the effort an item(s) takes?
Rudiger,
We don't size items but two things can happen during business or systems analysis: The analyst has the opportunity to reject the item as too large; or the analyst working collaboratively with other team members can choose to break the item up - we have a defined process for doing this.
The result of a break up is that the kanban limit is temporarily exceeded. This is self-correcting as nothing new is allowed to enter the system until the split item works it way through and "Engineering Ready" queue spots open up.
All of this will be explained at greater length in a paper Rick Garber and I are presented at the Lean Management Summit in Chicago in June.
David
How do you determine who to pull from other projects to work on the items in the queues?
I've got my engineers rotating through an on-call week in an attempt to distribute the customer support work fairly, but then we loose continuity on issues that take longer to drive to closure. I'm searching for a better recipe...
Jim,
Allocating resources is partially self-organizing i.e. volunteered, and partially controlled by the supervisors (line managers) who allocate specialist resources in-between tasks on major projects.
I delegate the resource management on sustaining work to my line management team. My supervision level is at the "level of commitment", i.e. do we have approximately 10% of my workforce on sustaining on any given day? I do not need to know specifically who is allocated but my line managers do.
I believe that the workload on sustaining _is_ unevenly distributed - some analysts or developers do more of it than others - but the sustaining work is so closely connected to the performance of the business in 2007 that it is very fulfilling work with a gratification event - a release - every two weeks.
Hope that helps
David
Hi David,
At my current client we have a team that has been doing something similar. In the fall of 2005 the enhancements team was stood up and started using Scrum. The team had to support different platforms, and had both offshore and "in the room" team members. We used a 2 week iteration cycle but did releases every week. The work entered the team highly prioritized, and WIP was kept to a minimum, with defects and enhancements tracking across the board through their states to release. Each week, the deliverables that were in the release bucket were what was released.
The iteration planning was useful to manage customer expectations (there are many for this team) and help convey LOE and overall priority. It also was needed because some enhancement developers did not have the specific system knowledge and had to come up to speed to implement a certain fix. Estimation and planning gave them an opportunity to convey this expectation.
The enhancement team could not handle big issues on the platforms, these were still handled by the dev team. While the dev teams could do the enhancement requests faster, they were delivering more value by focusing on new high priority capabilities.
We found that it took a while to train customers to stop "reaching" into the team with "can you just do XXX for me" and developers to turn these requests back to the team's product owner. As you can imagine, when a customer has "pain" from a defect, but they are not in the high value part of the value chain, they get annoyed with being re-prioritized.
Regards,
Robin Dymond
Nice article, this Kanban approach.
I manage an internal development team within a financial institution.
Could you please tell me, in your view, how to specify team capacity? Business demand squared me to deliver about 1,500 CR hours per month and currently I only deliver 200. Thanks.
Marc,
Help me understand... You deliver 200 hours? Really? I don't understand the concept of "delivering" time. And your business customers demanded 1500 hours? or you estimated the work demanded as 1500 hours of effort?
In the Kanban system described we measure capacity based on CR Throughput per month. We allocate resources based on a governance board funding that 10% of resources in my department should be working on sustaining work. Hence, the kanban limits for SA, Dev and Test WIP are set to reflect one work item per person with the number of people representing 10% of the total people available.
Hence, I provide 10% resource allocation. We balance capacity against demand by pulling demand through the system, not pushing it. Excess demand builds up in the approved but not yet selected backlog.
Reading between the lines of your question, it seems like you are working in a "push" world where the business pushes work on to your team, rather than having you pull it as resources become available.
David
This is very cool stuff. I especially like the ongoing incremental change approach over a big-bang scrum implementation.
The one instinct that I have is that you could get additional benefit from decomposing the items (CRs, whatever you're calling them) into smaller chunks.
Having items that take 60 days to pull through the system feels like they are somewhat oversized.
I am intrigued by this concept, although it is scary in some aspects. But it might be perfect for my team considering iterations are not a perfect fit.
Do you have any advice on how to deal with branching? How do you deal with features that are longer and being worked on while you are releasing?
Cleve, This topic of branching has been discussed in the Yahoo! group. You might want to join and read through the archive of posts. You may then find you have some additional questions and some of the folks from my team will be able to answer them in the group. David
Very interesting, a couple of questions:
a) is there a concept of velocity with this approach?
b) I like the idea of a kanban limit. But in reality wonder how practical this is? For instance, in your picture there looks to be 4 post-its when the limit in red is 2?
c) We allocate bugs out as they are found. Some bugs take 10 minutes others much longer. I would assume you wouldnt bother feeding small bugs thru this kanban approach?
d) I like the idea that a release leaves every 2 weeks. However to do this you must be releasing off a release branch as releasing off a development line of delivery would be too unstable?
John,
(d) Correct! We release from our mainline which is synchronized to production. We merge from a dev code line as part of the process. Each CR is merged down separately as part of the process.
(c) all bugs found in test are fixed, by attaching them to the CR. They don't count against the kanban limit. Only production bugs count.
(b) in some of early photos the kanban limit is being exceeded. the management have come to learn over time that this was a bad practice - it pushed the lead time up effectively reducing our agility. The transparency and visibility of the kanban process taught them this lesson.
(a) while you can calculate velocity, it isn't used for estimation. We do report throughput of CRs per month.
David
David,
thanks for your reply.
d) At what point do you merge from dev line to prodn? This merge process in itself is time consuming and risky.
b) So if I understand correctly if you have reached your kanban limit in say the Test category - all previous categorys stop until this frees up? Whats the problem of having 4 entries in Test when the limit is 2 - esp. if they are ready to be tested?
thanks. John
John,
(d) The merge is performed by a build engineer working by the developers at his (happens to be male) discretion. Items ready for build queue up in the kanban system. The build engineer is a non-instant availability resource. Hence the queue in front of build. The engineer typically builds all the items queuing though may choose not to. Each item is shelved in TFS and can be integrated separately.
While the process may be difficult and/or dangerous we have learned to get good at it.
Having a dev line and a production line and merging items individually based on shelve sets allows us keep items flowing through the system and run an iteration-less process.
(b) Your interpretation is correct. If a kanban limit is exceeded it may cause the whole system in front of it to clog up. This though undesirable does focus the attention of team and management on balancing the resources correctly and improving the flow through a bottleneck resource.
Hope that helps
David
Hi,
we run our project in an agile manner with 2 week iterations. As you mention this provides some 'management overhead', but what our team likes is the regular cadence this provides, closure for the team so to speak. Given that you dont do iterations, and many of your CRs take much longer than say 2 weeks - how do you account for the regular cadence that iterations provide?
Dave
Hi,
Very nice. I have suffered a lot from the agilist iterations. Lots of effort wasted trying to fit tasks down to 10 man days, and wasting a man day to the 'agile process' every iteration.
Lets hope Kanban crushes the life out of the agilists and lets us get back to writing software that works when it is needed by the business.
Cheers,
Jonathan
Hi,
A have read both your paper and your blogs about kanban into SW development. Very interesting reading that inspires me to try something similar in my work. I am currently facing the challeng to build an entire new section of approx. 20 developers with responsabilities for a number of internal systems. Some of the section members comes from my old section and are experienced in working lean and agile with Scrum. But we have a problem of way to many old issues lurking around in our issue management systems. Combining that with the huge backlog of some of the new systems that will be added to my section gives us approx. 600 open issues. I think a kanban approach can be used to reduce this.
I will write on my own blog, Lean and Agile at Sony Ericsson, http://aenyberg.blogspot.com/, about how the work proceeds.
Regards,
Anders
Thanks for a nice hands on description of Kanban. I'm kicking off a new agile project tommorow. Beeing experienced with agile and information radiators I think I will try to add a Kanban and see how it goes.
Martin
www.agilethoughts.dk
very interesting/helpful..
a very mundane newbie question...
do you have any thoughts on how to handle/manage non-dev tasks, e.g. development AND support together...?
Commenting by HaloScan
