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.