How can Kanban handle team interuptions

Our engineering department has to answer to a lot of different parts of the organization  With an existing product with multiple versions released into the field, the obvious problems of developer support of issues and qa handling of  hot fix releases comes into play.  These are all things that come up at any time…they are not planned.

So the big question is “How do we set our Kanban SLA’s when we could get called off to support the existing product at any time?”

And the answer is…”Set your SLA to account for a normal level of distraction.”

This is a tough part to accept.  What we want to do, ideally, is set an SLA to be the time period that we would want to accomplish the work in:  ”That will take 6 hours of effort”.  The problem is that  6 hours of effort is spread over 2 days.

OK.  So we say that 2 days is a reasonable amount of time to accomplish the task.  If we want to get that down to 1 day, we can look at why all those distractions that are occuring and figure out a way to fix it (Kaizen!).    If the distraction rises to the level that it takes 3 days to finish the effort, then we need to look at why support efforts are digging into development time (Kaizen!).

Kanban work looks to when a thing can be accomplished, not the actual effort to accomplish.  If the work takes longer than expected, it becomes a learning opportunity on where there may be inefficiencies in the existing workflow.  If you want to shorten the time to accomplish, that’s also  a learning opportunity.

Trust

There are a lot of reasons why trust within a team is important.  I’m going to delve into two, both of which when lacking manifest as waste.

Item the first:  Lack of trust among developers produces wastful code. I’ve been on enough teams to see how code manifests itself, on average, based on the trust level of the team.  Developers who trust the other developers don’t put a lot of time into over validation because they trust the developer who wrote the calling code won’t pass them garbage.  They also won’t put in a lot of excessive exception handling because they trust the code they are calling won’t throw a lot of garbage at them.  Since there is a lack of trust, they also won’t get up and talk to the other developer (“Stop throwing garbage”, “Stop passing garbage”, etc).  Code Reviews, Pair Programming, Code Analysis tools do a good job of catching this kind of activity and bringing it to light, but still don’t address how to build trust within a team.  I’m sure others have methods for dealing with this, but in my opinion the best way for a developer to gain trust is to not pass garbage…that’s the first step anyway.  It builds slowly from there:  Don’t pass garbase, Don’t accept garbage, build cred, repeat.

Item the second:  Lack of trust among team members produces wastful practices. This one is somewhat new to me.  Team Members who do not trust other team members will perform all sorts of wasteful activities in order to ensure that “things get done right” (The One Right Way Anti-Pattern?).   Emails that CC Management, Requiring team reviews of work at every juncture, Meetings, etc.  A big chuck of the things that interrupt flow seem to originate from this one team dysfunction.  This one seems tougher to address, as you have to find a way to re-introduce flow while also finding a way to satisfy the disbelief that things might actually work through the system, even if they work through it such a way that isn’t The One Right Way.

Ongoing…

Kanban v. Scrum debate

Ron Jeffries writes on concerns about using Kanban to cover over problems that cause iterations to go south in Scrum.

I’ve certainly seen teams whose management or product owner would berate them for falling short of the iteration “promise”, and this can lead to some very bad results. The initial response will be to “under-promise”. Not “under-promise and over-deliver” — they’ll say that, perhaps, but they won’t do it. No one does.

When the team tries to under-promise, this same manager or product owner will push them to commit to more: it’s part of that management pattern. Most teams will cave and try to do more. They want to be cooperative, they want to be appreciated, and so on.

This will not work. They’ll fall short again. Management will continue the pressure. Finally, the team will turn their secret screws and start producing code that is shiny on the outside and rotten on the inside. Velocity will continue to decline, pressure will continue to rise, and things will get bad.

On the surface, we can see that a Kanban approach might fix this, because there is no defined point at which to apply this undue pressure. It’s not a bad idea: it might even be a good one, at least in the interim, for reducing the pressure.

His gist is that Kanbans don’t address the problem but simply provide another way to mask it.  From my experience, so far, I’ve found that the Kanban with the SLA’s and WIP Limits has been great tool to locate, bring to light, and address issues within the team.  Issues that had before been very difficult to get a box around.  We’re in the middle of our Fourth Wave (I’ll get back to that later) and already have seen big improvements beyond the expected “Changing the Process improves Productivity” effect.

There can be a pleasant rhythm to the iteration, and there are things that fit naturally into it. It can be very pleasant to lift our heads up, look around, plan the week, then at the close of the week, lift up again, look around, and see how we did.

There’s work that needs to be done, such as reviewing the backlog, reviewing the product, perhaps some kinds of testing or other wrapup work that are not yet fully continuous. Some of those probably should not be continuous, though many of them should be.

Now Kanban advocates will say that Kanban is better (what else would they say?) because it lets you have whatever rhythms you want rather than “imposing” one. Uh huh, yeah, and that’s why people who don’t cut the grass every week have yards that look like forests.

Kanban says cut the grass when it has grown 1 inch; could be 1 week, could be 3.  Don’t waste time cutting the lawn every week if it hasn’t grown enough to justify it.  Go work on something else around the house.

In our shop, we let the amount of work drive the “iteration”.  Every ten cards completed we hold a Demo for the company and evaluate the performance on the ten cards (see Grading “Iterations” in a Lean environment). We call  the period of time between the first card entering the Kanban and the last card leaving a Wave and we grade our performance within it based on Capacity, Accuracy, and Efficiency.  We review these numbers and try to understand why we missed our goals.  So in this sence, we still have a retrospective; it’s just driven by some meaningful amount of work being done instead of an arbirary amount of time.

Based on how we’ve size the Demo slot, we should complete a Wave every two weeks and it should contain about a months worth of work.  Because all the cards are flowing, the next waves cards are In Process when the current wave completes. And the next, next  waves cards may be just entering.

This is how we get a sense of completing something without intrrupting the flow by stopping work and holding a regularly scheduled meeting just to have a meeting.  The meeting is scheduled (if needed) when we have something meaningful to go over.  The Demo is held when we have something of value to present.

This is just some of the activity driven by the Kanban.  How we evaluate Phase SLA’s and Limits is another piece, which includes critical analysis of process and technique to see how we can shoten SLA’s and increase Limits.  But we don’t do it arbitrarily and we don’t force people to commit to that extra 2 point card to up Velocity.

Even in manufacturing, there comes a point when a door is completed or a car rolls off the assembly line.  These are the points we should feel completedness in our work.  Trying to create a sense of completion by holding a meeting and saying “Yea Us!” seems  like a hollow equivelent, especially if you have a bunch of half made doors and cars with no windsheilds lying around.

Grading “Iterations” in a Lean environment

When we moved from Agile to Lean, one of the items that was ditched was the concept of the iteration (with all the overhead of Planning, Retrospectives, etc) in favor of a fixed size Demo point.  So every 10 features we deliver get Demo’d and that’s our reset point, whether is be 1 week or 1 month.  Part of what I’ve been doing over the last 2 months is capturing all the metrics of when work on a feature card is started and stopped (“Work”) in each phase.  Any gaps between stopping one phase and being started on in the next is considered “Lag”.

Based on our teams SLA for each phase I’ve also calulated what our opimal capacity should be;  the ideal rate that we should see the demo phase fill up.  This is done by taking the total of SLA’s accross the Kanban (in this case 14 days), adding the size of the demo phase (less the size of our “Contraining” phase)  multipled by the SLA of our “Constraining” phase divided by the size of our “Contraining” phase.  Should look something like:

R = T + ( (D – Sc) * (Tc / Sc) )

When we moved from Agile to Lean, one of the items that was ditched was the concept of the iteration (with all the overhead of Planning, Retrospectives, etc) in favor of a fixed size Demo point.  So every 10 features we deliver get Demo’d and that’s our reset point, whether is be 1 week or 1 month.  Part of what I’ve been doing over the last 2 motnhs is capturing all the metrics of when work on a feature card is started and stopped (“Work”) in each phase.  Any gaps between stopping one phase and being started on in the next is considered “Lag”.

Based on our teams SLA for each phase I’ve also calulated what our opimal capacity should be;  the ideal rate that we should see the demo phase fill up.  This is done by taking the total of SLA’s accross the Kanban (in this case 14 days), adding the size of the demo phase (less the size of our “Contraining” phase)  multipled by the SLA of our “Constraining” phase divided by the size of our “Contraining” phase.  Should look something like:

R = T + ( (D – Sc) * (Tc / Sc) )

From here I’m able to calcualte our team performance accross three dimentions: Capacity, Accuracy, and Efficiency.

We can compare our Actual rate of delivery to the ideal to get a grade on capacity (score goes down the farther away from target we go, whether under or over).

We can compare the total time a card spends on the Kanban to the SLA to get a grade on Accuracy (score goes down the farther away from target we go, whether under or over).

We can evaluate the percetage of Lag time to Total time to get a grade on efficiency.

We can take the average of these values to get an Overall Grade.  If any of those dimentions are not on target, the overall score will be affected and it will be a clear indicator that something isn’t right and needs to be evaluate.

The reason for the three dimentions is because they reinforce each other.  The team can’t sacrifice capacity to improve Accuracy and Efficiency.  The team can’t overestimate to acheive Accuracy without sacrificing Efficiency and operating Over Capacity.  The team can’t focus only on efficiency without impacting Capacity.  Everything is forced to be in balance and constantly driving towards better and better numbers.

Only by high performance across all three will the team acheive a high grade.  And with a standardized template and rating mechanism, the team will understand more as issues arise how inaction will be reflected in the overall score.  This helps us avoid the Flacid Kanban as everyone becomes more aware and cognizent of what the Kanban is saying.

You Kanban will tell you when trouble is lurking around the horizon if you stop to listen to it.

The beauty of Lean

When you’re tempted to break the rules, it really means an inefficiency has been exposed…which probably means the rules need to be changed.

I love recursion.

The purpose of a Demo

Off the top of my head, I can name two camps in the “we have a demo” crowd.  One says that we have a Demo to present the functionality we’ve developed to solicit approval of the work we’ve done to the company.  Another says that we present the work we’ve done to the company to solicit approval of the functionality we’ve developed.

There’s a subtle distinction there, and I think it’s a fairly critical one.  

In one case you are saying “Here is the work we’ve done.  If you have a problem with that, I’m sorry (not really)”.  The second says “We’ve done this work.  Did we do it right?”

I think that it’s critical that when functional software is first presented to people that we, as engineers, listen to what’s being said by the pople who support our efforts in the field.While we may know how to break problems down into their elemental properties, it doesn’t mean that that we understood the problem properly or had all the available information in the begining.  It’s important to appreciate that a critique of the end result is not a critque of our ability to reason through the problem.  

More often than not, our solution was valid given the available data at the time.  When the solution is questioned, we need to recognize that the data has changed and we need to re-evaluate our solution to the original problem.

As you can probably tell, I suffered through a bad demo today.  The reasons for the failures are legion, and some rest squarely in my lap.  There were two, however, that seemed the most avoidable:

• When an audience member tells you that a missing field is critical to the market, you do not tell them, in essense, to “Shut Up because I’m demoing what’s been done.”
• You do not schedule a demo and try to create theater around it like it’s some grand delivery from the engineering group.

Both of these failures were driven from the same mindset:  That the functionality being demo’d was some Promethean gift and that the mere mortals in attendance should not look that gift in the mouth.  Bad form.

There were many other lessons re-learned as well (know your audience, have a rough rehersal, etc) but those stuck out as the most  egregious because of the mindset they represeted.  Mindsets are tough to change, processes aren’t.

Semantics!

I’ve been spending the last week re-organization all the requirements that we’ve capture while building the new product.  Essentially, I started by just capturing the service documentation and the tagging the UI, BDD Scerarios, and Task estiamtes onto the end.  What started to happen was that as new work units came along that covered the save service workflow, documentation and requirements were starting to get duplicated and separated.  So my first realization was that Service Requirements and UI requirements were static things that should always be what the system is (or will be soon).  As different cards (Minimum Usable Features) came through the system, they would modify the Service and UI Requirements.  

So, in our MediaWiki I gave the Service Requirements a Category of Workflow, the UI requirements a Category of Form, and the Feature Card a Category of Story.

Next comes linking them together.  I had previously installed the Semantic MediaWiki Extension and had been finding ever more interesting ways of using it.  In this case, I found by linking the Story pages to the System and UI pages, I’d be able to do some good queries to get lists of Stories that had altered requirements and what parts of the system were going to be altered by cards in the pipeline.  For this I used the concept of “defines”, so that I had [[defines::form::UserLogon]] or [[defines::workflow::AuthenticateUser]].

After I’d worked this out, my Lean mind started looking upward and I realize there was an opportunity to look to the Marketable Features as well as the Minumum Usable Feature Set that we were currently working.  By this point, things were moving quickly; it was just a case of creating the “Feature Set” and “Feature” Categories and linking with a [[marketable-feature::Application Logon]] tag and adding a [[story::User Logon]] link to the feature page.

So I had:

MUFS

↓

[[marketable-feature::Application Logon]]

↓

[[story::User Logon]] 

↓

[[defines::form::UserLogon]]  |   [[defines::workflow::AuthenticateUser]]

This was great!  Now I have a high level view of the entire project and what parts of the application are going to be affected.    I added in some visualization tools so now I can generate MindMaps and HyperGraphs for the semantic data. Management likes it because they can see what all these Feature Cards on the Kan Ban mean in relation to the Big Features being requested and can get a firmer idea of how much is left to be done.

All in all, good times.

 

 

What’s the point of BDD again?

I recently sent out a link to Bob Martin’s post on how BDD is similar to finite state machines.  My main reason for doing this is because my office has a decent enough faction of Uncle Bob fanboys that I knew by doing that I’d keep them occupied for a while trying to resolve the cognitive dissonace of “BDD is hard, but Martin likes it” which would give me a window to work with the folks who were generally interested in it some extra coaching.

The unintended consequesce of that, however, was that some people who were having problems with verbalization latched on to the FSM idea and thought “If I just make FSM tables, I’m doing BDD too!”

The problem is, that’s horsefeathers.  The most important part of Behaviour Driven Development is the Behaviour part.  The aspect of having to think like the end user and communicate requirements in their terms is where the value comes from.  This is where Martin’s attempt acctual does more harm than good:  by attempting to relate BDD scenarios in terms that programers will feel comfortable with, he give license to developers to strip away the most valuable parts of it and continue on business-as-usual.

I can manage this issue, because the person in question isn’t typically responsible for generating scenarios or requirements.  But pay attention:  as soon as people start trying to strip away the behaviour to just define requirements, they are missing the entire point.  Only “Bad Things” can come down the development cycle as scenario by scenario the end user is removed from consideration once again.

Dreaming the impossible dream…

I’ve done something so stupid that it just might work.  Around the new year, I convinvinced my team to switch from Agile/TDD to Lean/BDD AND implemented a new wiki to use as the major documentation repository.  So yeah, I’ve taken on three major structural  initiatives at once.

This blog will serve to document the hillarity that ensues.