Comments on: Patterns of software engineering workflow (part 1)

By: gaya

gaya — Wed, 19 Aug 2009 09:39:04 +0000

good and fine book

By: Patterns of software engineering workflow

Patterns of software engineering workflow — Sun, 12 Jul 2009 02:25:13 +0000

[...] 25, 2009 03:36 by Chad Albrecht Corey Ladas has a good post on Kanban-controlled workflow systems here. 39ab478f-77a6-4d82-95d6-08c006fd5db3|0|.0 Tags: kanban, patterns, workflow Categories: Software [...]

By: Sebastiano

Sebastiano — Fri, 03 Jul 2009 19:14:02 +0000

thanks Corey, kind as usual.

By: Corey Ladas

Corey Ladas — Thu, 02 Jul 2009 15:52:52 +0000

Making the stories similarly sized means the cost for everything is similar and you prioritize on value alone. Reinertsen’s advice is to prioritize based on the cost of delay. If that cost is difficult to calculate, I wrote a couple of articles about consensus prioritization.

The point about estimation is not to do it or avoid it for moral reasons, it’s about cost and value. Estimation can have high cost and low value. We want to make it cheaper and the cheapest estimation of all is no estimation. A histogram of cycle times will tell you how much effort is worth investing in estimation. Some people do estimate with kanban systems, and you can limit something like function points instead of cards. My first suggestion would be to very quickly triage work items into two categories when they show up in the design queue: too-big / not-too-big. Not-too-big items go forward. Too-big items are requeued for further analysis. You can reduce the number of too-big work requests by making QA part of the analysis process. Right-sizing features is a matter of analysis skill and it can be learned.

By: Sebastiano

Sebastiano — Thu, 02 Jul 2009 08:07:16 +0000

About the tracking instead, I love the fact that Kanban introduces much more precise metrics that I missed a lot when I used pure scrum.
Personally I think that the most important difference between commonsense and agile methodologies eventually is the tracking process, because thanks to the tracking you can be aware of what you are doing and then you can improve yourself .

By: Sebastiano

Sebastiano — Thu, 02 Jul 2009 08:03:44 +0000

I read now your answers .
It’s ok but I can’t understand how you can prioritize if you can’t estimate.
Isn’t the prioritazion a process based on the ratio between the feature value and the feature cost? Or you prioritize using gut feelings (that probably is very possible too)?
I thought for a long while about the idea to think about to create equally sized stories and eventually I could guess that maybe it’s possible.
So if the story become an unit, I was thinking if it could have been different to measure a feature size in terms of number of stories.
But as you know all of this is just a mental excercise, since I can’t even test it in my current environment .
What I know is that I’m looking forward to test Kanban in a real environment, since I’m sure it a great step forward compared to the basic scrum process.

By: Corey Ladas

Corey Ladas — Tue, 16 Jun 2009 20:37:24 +0000

That is such a powerful lesson. Thank you for sharing!

By: Richard Hensley

Richard Hensley — Tue, 16 Jun 2009 20:13:13 +0000

People are happy with the pace. However, the level of transparency provided by the metrics and the kanban board have upset folks due to work allocation.

Basically, we surfaced something that engineering knew but could not quantify. We surfaced that we were spending in excess of 70% of our capacity on rework and technical debt repayment. We were ignoring much of this needed rework and allowing it to build. This was primarily due to the implementation of Scrum in our context. We were very much a doing lots of stuff, barely getting it done, and adding quality. We flipped that to focusing on quality, getting things done, and limiting what we are doing.

The focus on quality combined with the metrics has made the technical debt problem stick out. So, we are fixing it. Because we are tracking our trends and metrics closely, we can are seeing a decline in the rework, and predict a stabilization point. As the allocation to rework declines, the allocation to features goes up. We are also seeing a consequent increase in our feature through put, which is what the system is all about.

By: Corey Ladas

Corey Ladas — Mon, 15 Jun 2009 22:44:48 +0000

Thank you, Richard, that’s a great story. Sounds like your process has stabilized. Do people seem happy with the pace?

By: Richard Hensley

Richard Hensley — Mon, 15 Jun 2009 21:36:12 +0000

I will jump on the measure cost instead of estimate cost band wagon. It took us about 2 weeks into our kanban implementation to realize all estimating was completely wasted energy.

We track adherence to SLA, cycle times, through put, work allocation, and quality.

The interesting thing is that cost to produce value changes very slowly over time. We know our staffing and infrastructure costs on a weekly basis, we also know the number of features we produce in a week. So, a feature will cost pretty close to the same as the other features.

The key for us has been tracking and ensuring that we stick to our service level agreements on cycle times. Turns out that it takes the all members participating along our value stream to keep the SLA intact.