Odds are good that you’re familiar with the classic 3-question agile standup.  Have you ever wondered what a lean standup might look like?  Because it’s lean it’ll just be faster, right?  That’s what lean is really about, isn’t it?  Maybe we can do it in 2 questions if we’re leaner?  By looking at the standup (something we know) from a lean perspective, we’ll gain a better understanding of what lean really is.  We’ll get a better sense of how it compliments agile.  We’ll also begin to see how lean is different, but doesn’t conflict with agile.  

As a basis, we’ll need to know about lean standards.  Feel free to check this out if you’d like a quick introduction or refresher.  Knowing that, let’s look at our standup.

In Case You’re Unfamiliar

If you don’t know what a stand-up is, or you don’t know what the “3 questions” are, then this section is for you.

Imagine arriving at work every morning and among the first things you do is get in a circle with the rest of your team members.  Everyone then takes turns answering the following 3 questions.

What did I do yesterday?
What am I going to do today?
Do I have any impediments?

This will give everyone a sense of what everyone is doing.  It’ll give us a sense of whether we’re on track.  It’ll give us a chance to ask for and hopefully receive help.

After this is over, we disband and go about doing the things we said we were going to do for the day.

Stand ups & Standards & Visual Management

When arriving at a stand-up, the first thing I want is a visual indicator of where we are against the standard.  I don’t want to ask 3 questions.  I don’t want to ask 2 questions.  I should not have to ask any questions.  I want to see where we are against the standard right now.

The best thing I’m likely to have is a burn down chart with an ideal line.  This shows me the current state (how much is left to do as of now), the standard (how much should we have left to do as of now), and I can compare them.

If my burn down is at or below the ideal line (our standard), I’m good.

If my burn down is above the ideal, I’m out of standard.  I have more work to do than I should at this point in the plan.  I have a problem.   I have an opportunity for kaizen in order to return the system to the standard.  Our standup can be exactly the forum for that conversation.

I look at the burn down and I see we are out of standard; we are behind schedule for this sprint.  What are we going to do today to fix this? 

What other questions are necessary?  Are any questions necessary if we are within the standard?

What Don’t I See?

One important question you could ask at this point may be,

Is there anything you know, but is not reflected in the burn-down and may disrupt our plan?

That would be useful to know.  If anything ever comes up then you have a kaizen opportunity.  However, it’s not likely the kaizen opportunity you’re thinking of.  If there is a problem that someone knows about that is not visible in our visual management system (our burn-down), then we have a problem.  Why can’t I see the problem?  Why are we hiding it?

Perhaps it is not work you must do, but a blocker or risk of some kind.  A server needed for testing is unavailable, work another team was doing for you was not deployed on schedule, etc.  No matter what these are, they deserve visibility, too.  Unlike manufacturing or other environments where the job itself provides visibility, in a knowledge industry the problems are things we know.  It is up to us to make them visible.  

Either on your burn-down or on the board next to it, any impediments should also be made visible.  More than just having the space, people must be willing to take action to make problems visible (putting them on that board) so that they can be fixed.  This way, anyone looking at this information can see that there are problems.  If we can all see the problem, then we can see the kaizen opportunity and can bring our skills to the table in getting things back on track.

Continuous PDCA

A good perspective on the standup is that it is a continuous planning meeting; a way to reevaluate ourselves against the plan and make adjustments as necessary.

The three question standup seems to serve the same purpose, but it gives a script rather than guidance as to the purpose.  Worse, the script ignores the use of visual standards to indicate a problem; this makes it easy to hide problems by just not saying them aloud.  When talking is the objective, we’ve set a meaningless goal that is easily achieved.  When we set our objective as looking for problems and making any corrections needed to get back on track, then we have a reason to invest the time.  Now the trick becomes setting ourselves up for success, so that we can do these things.  Visual management with a burn down provides a very useful method for fulfilling this purpose.

This also provides a great argument for breaking backlog items into tasks and estimating hours.  It is not that the plan itself (the tasks) have much value, but by building that plan we’ve built ourselves an ideal target and can visually inspect our progress toward our goal as best as we know it today.  This also shifts the perspective of the estimate.  It is much less about how long I think this will take, but rather I think that if I haven’t solved this in 6 hours I should be asking for help.  I’ve given myself a time-box and I’ve given my teammates a visual indicator to know that I need help even if I don’t say it out loud.  If we leave our work as just the backlog items we’re working on, we have no way to inspect and adapt.  We can just make sure we’re busy.

If we think of our daily cycle as a PDCA loop (plan, do, check, adjust) then 3 of these activities take place in the standup, making it a critically important function.  We CHECK our current progress against the sprint goal.  If there is a problem, we ADJUST.  We PLAN how today will keep us on track.  The rest of the day, we DO as planned.  Tomorrow, we’ll CHECK how we did with today’s plan.  Without a plan, we have nothing to check, and won’t know when to adjust.  We just do, and then we’re back to mere busyness.

Stand-ups for Kaizen, Kaizen for Building Human Capability

The objective is not to use a burn-down versus a build-up versus any other sort of sprint tracking tool  The key is having the discipline to do something and make it visual.  

There should be a PLAN that we can see before going into the sprint.  For every day in our stand up, there should be a standard.  

In our standup we should CHECK our progress against the standard.  If there is a problem, we should ADJUST.  We should PLAN a day that will keep us on track DOing the most valuable things we can.  We repeat this paragraph every day, creating a visually managed PDCA loop that makes use of a standard and kaizen. 

It may feel slow and not be sexy.  But, if done deliberately it will build capabilities that are needed to become a highly successful and predictable software delivery team.   That, after all, should be the goal of a ritual like the stand up.  It isn’t just keeping us on track today.  It’s teaching us disciplined execution.  It teaches us to work with our eyes open and to be honest.  It teaches us to help each other.  It creates an environment where problems will abound.  Each problem is an opportunity for kaizen.  Each kaizen event is a chance to build the skills of our team members that go beyond just designing, coding and testing.  That is really the end game; creating a system for building better software by building the skills of our people every day.

The ideal lean organization is a learning organization.  The daily stand-up is a venue for highlighting more problems than any other in agile.  Because it will surface the most problems, it is the ceremony that offers the most learning.  However, it will only do this if you let it.  You must make sure that it’s meaningful.  You must make sure you can see the things you need to see.  You must make sure that everyone is bringing to light all the things they know, since that is the only way we can become aware of a problem in a knowledge industry.

It takes time to do this and it will feel slow.  Don’t be afraid to be deliberate and go slow; it’s the only way to go fast.

Challenge

In your stand-ups, is everyone actively engaged or is everyone just waiting for their turn to talk?  How many cell phones are in use?

Right now, can you see the current status of your team in reaching your sprint or release objectives?

Do you deeply understand what you’re looking at?  Do you trust what you’re seeing?

Can everyone on the team see the status and do they all know how to interpret what they are seeing?  Do they trust it?

Are problem solving opportunities found in the standup handled like explicit learning opportunities for team members?

Do the leaders monitor how the problem was solved to make sure that people were being deliberate and learning rather than just patching and running?