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.