Your Daily Standup Should be Boring

If you are a Lean/Agile team you probably have a daily standup / scrum that you are trying to complete in 15 minutes or less. You might even be “standing up” in that effort. You are most likely failing, and your average standup runs for half an hour or longer. And I’m not even counting the “meeting after the standup”.  You have tried various techniques the plethora agile books prescribe, and it does work for a week or two but then just falls back to the old pattern.

Have you wondered why?

The key is to first understand why you even need the standup in the first place. Then work assiduously to eliminate every single reason to have the standup, but not stop it.

You are then likely to find a couple of things:

· There’s not much to talk about at the standup. In fact, it’s probably boring
·   Your standups are getting done in 15 minutes or less

This is a great state to aspire – a non-eventful standup without drama.

How do you get to this stage?

Let’s first look at what’s happening in the standup today. What topics are being discussed? Very likely:

• Status
• Problems
• Solutions
• Decisions

So, that’s what’s eating time in the standup. The crucial question to ask is why is this coming up in the standup? Obvious answer – because people didn’t raise it earlier. Why didn’t they raise it earlier? Your team should be raising the issue when the event happened. Not wait till the standup.

Thus, the vital improvement to be implemented here is to raise issues when the event occurred. Not hold back till the standup which is usually a once a day event.

Why is this important?

If you are thinking that we are looking to save a few minutes at the standup – that’s not the driver. Although, that is desirable, that’s not the main goal. The real cost of an extended standup is not the extra minutes, but:

·        Disruption to the flow by not resolving issues soon as they occur
·        Cost of delay by waiting for the standup

And if you put in processes in place to resolve problems when they occur, empower people to make decisions quickly, there’s going to be very little to discuss at the standup. Your standup might be boring. A standup that’s boring for the right reasons is a good thing.

Work hard to make the standup boring. But don’t eliminate it. What remains to be discussed in the standup now is probably what should be discussed in the standup.

Why your company may need OKRs

OKR? What's that?

Glad you asked. It's a goal setting framework. It stands for "Objectives & Key Results". Here is an example:

Objective

Grow company revenues

Key Results

1. Hit global annual revenue of $150 million
2. Achieve 100% YOY sales growth in North America
3. Increase the average deal size by 25%

Notice how it has two key elements?

Objective: Your goal, your dream, your vision. Its What you want to get done

Key Result: A very specific, measurable way to show How you are going to get it done

That looks like an MBO! I've been doing them for a while and I don't think I like them. I'm outta here!

Wait. It is built on MBO's and KPI's but there are important differences. Tweaks really, but very key ones tuned to suit contemporary management and product development practices

But first, some history

OKR's were first implemented by Andy Grove at Intel. He built upon the concept of MBO (Management by Objectives). Then John Doerr, who watched Andy use it at Intel to great effect, introduced it at Google, and helped Google become Google. And that's how OKR's became famous. A lot of companies use them now. And Google still uses them.

So, how are OKR's different from MBO's? 

They differ fundamentally in three ways - Purpose, Transparency and Cadence.

	MBO	OKR
Purpose	A method for employers/supervisors to manage their subordinates by introducing a set of specific goals. The goals must be achieved 100%. Used to review/reward the employee during the performance review	A system to prioritize, communicate and get everybody to contribute to what matters most. The goals are stretch goals and employees are not penalized for not meeting them 100%. OKR's are typically not the basis for a performance appraisal
Transparency	MBO's are confidential. They are between the manager and the employee	OKR's are public. Everybody can and should see everyone else's OKR's
Cadence	Set yearly. Very waterfallish in nature	Set monthly/quarterly. Lean/agile in nature

Okay. Why should my company or team have OKRs?

Here are 10 Reasons:

1. It's a communication tool. It's a system to communicate what's important to the company (or team) and what's not. Now, if you are the CEO or leader of team, you know that effective communication is one of the hardest things to do. This helps. A lot
2. It promotes transparency. Ever wondered what matters to your CEO, company, a key executive or team? Now you know - because everyone's Objective, Key Results and grades are visible to all.
3. It empowers. Now that you can see everyone's OKR's, you can choose to help. Especially if it's in your area of expertize. Your objectives don't have to be handed down Top Down  anymore. You can add your own. And sometimes, your objectives are so cool, that they may become a department or company objective in the near future. How empowering is that? You just made a difference!
4. It's aspirational. OKR's are stretch goals. Achieving 65% of the impossible is better than 100% of the ordinary. Even if you fail on a stretch goal, you are bound to have learned something valuable. They are like little moon shots..
5. They promote innovation. Sure, you can have "business as usual" objectives. But you can have aspirational OKRs too. They give you permission to fail. And if you haven't failed recently, you haven't tried hard enough
6. It engages your team. How? Just like you can have individual OKR's, you can have team OKRs too
7. It sets direction. You can tell where your company is going. It's like a North Star, a beacon - constantly guiding you.
8. It prioritizes. You know what matters and what doesn't. Prioritization is key to execution.
9. It sets alignment. Now that you have direction and priorities, you can all work on the same thing. This leads to better outcomes
10. It's data. Good OKR's provide objective, quantifiable data points about what's being done and how well it's being done. If you are a Data Driven company, you wouldn't want to miss out on this key metric

And they solve world hunger. OK, now I'm exaggerating. But if we do want to solve hunger, we should start with OKRs. 

Seriously

Top 10 Kanban Practices

If you are a team that's been practicing Kanban for a few months, here are a few practices that will make your team more productive.

1. Stop starting, Start Finishing. Help your team get a story/feature done, rather than add a new one.
2. Follow WIP limits. Seeing “RED” on your board should cause discomfort and move the team to fixing it
3. Work from right to left. If you have the skills, pick the story on the right of  the board and help move it towards DONE. Remember, organizations make money when work is done
4. If a card is spending more time in a column than it should, offer to help . Do not wait for a manager / team lead to bring this up. Also, do not wait for a standup to bring this up. Define a policy in your team on what should happen if a card is spending more time in a column.
5. If a task/process is not adding value, eliminate it. Do not wait for the retrospective to bring it up.
6. Update the board to reflect the current state of work at any time (position on the board and who’s working on it). Do not wait for the standup to move a card. The board is a communication tool and it needs to communicate the true status at all times
7. The standup is not a “status report” - the board already conveys the status. Discuss roadblocks / improvement ideas rather than a routine discussion of cards on the board
8. Have team members take turns running the standup. This will cause them to pay attention to what's going on in the team.
9. Gradually, look to reducing the WIP limit, thus promoting more collaboration.
10. Celebrate what got done yesterday.

Why your company may need a Hackathon

A Hackathon is a creative problem solving / focused innovation exercise where people in your company will take a fixed time-out from regular work to solve problems or suggest new ideas. Participants will form small groups and code solutions (prototypes). At the end of the Hackathon teams will demonstrate  the solution they've "hacked" together.

Why does your company need a Hackathon?

The hackathon is a forum to unlock the creative potential in your team members.

If you are a knowledge based company - and who isn't nowadays - the ability to innovate is key to your future. The day to day tasks  probably keeps your teams focused on execution but don’t offer much opportunity to tap into their creativity. The idea is to give your teams the freedom to step outside the constraints for their day-to-day and see what they can come up with when the ball is in their court. They'll be working on projects they're excited about, not building something because that's what they've been told to do.

As many companies have discovered, it's pretty amazing what can done in a Hackathon. Often these implementations / ideas turn up to be new business opportunities. However, events like these are unpredictable.  There are no guarantees, with failures as likely as success. 

A hackathon is not a panacea but instead should be part of an overall strategy to spur innovation. 

The investment is small and the reward is potentially huge.

Other Benefits:

• It's a great team building exercise that also results in tangible outcomes for the company in terms of solutions and new business opportunities.
• It sends a clear message that you value innovation
• Creates positive energy and helps morale. It’s also a learning experience
• Unlocks the creative potential in our team members
• Helps retain talent. And even helps attract talent (with so many companies doing Hackathons not doing it makes us "uncool")

How it works

1. Employees suggest and brainstorm some ideas
2. Employees sign up for the short listed ideas and form small teams
3. Each group is given a fixed time to come up with working code
4. At the end of the Hackathon, every group demos their work to all participants as well as management

Some interesting links on Hackathons

http://www.wired.com/2012/02/ff_hackathons/all/1

http://mashable.com/2010/06/30/hackathons/

http://techcrunch.com/tag/hackathon/

The Feed Forward Loop - A learning process

The Feed Forward loop is a process to become a “Learning Organization”. Successful teams and eventually successful businesses are those that learn the most in the least time.

I call it the “Feed Forward Loop” because it’s purpose is to fuel the next cycle. It’s a forward looking cycle that aims to deliver scientific learning in every loop. Every initiative that an agile team starts must be targeted towards increasing learning in the shortest possible time. For example, you should aim to learn more about the customer, the business, the market, etc. As you know, learning is best accomplished by doing. The Feed Forward Loop facilitates that.

There are four steps in the loop:

1. Hypothesize

State your assumption for the initiative that you are about to launch. What do you intend to achieve? What are your success/fail criteria?

2. Test

Devise a method to test the initiative. 

3. Measure

Measure the outcome of your test. Did it pass or fail? Did it validate your hypothesis?

4. Learn

This is the key to the initiative. Whether the initiative succeeds or fails, there’s always lessons to be learned. Use this learning to kick off the next cycle.

Kanban: Assets and Liabilities

The next time you look at a Kanban board, pretend to be an accountant. Look through the eyes of an accountant. You'll probably see two columns like most accountants do - Assets and Liabilities.

Don't see them? 

Work that is "Done" or "Released" is an Asset. Companies make money when work is done. You'll probably find this on the right side of the board.

Now look to the left. Those are your liabilities. All this work that's "In-Progress" - they are liabilities. You can be proud of them, but they are not making you money. In fact, it's quite the opposite - they are burning money.

So what do you do with this knowledge?

Start converting your liabilities into assets. Don't add new work (i.e. increase liabilities), instead create more assets (i.e. complete work). Work from the right side of the board.

Stop starting, Start Finishing.

The Daily Kanban Stand-up

Many teams transition to Kanban from other agile processes. And often,  they conduct the daily stand up just like they used to in their previous process. Since Kanban is an evolutionary method, in the beginning that's fine. However, very soon you'll find that changes are necessary.

Teams new to Kanban use the stand up like a status meeting - often taking turns to update the team on the status of  their "tickets".  Or, they keep it very Scrum like, typically answering the following questions, with some variation,  in a round robin format:

1.  What did I accomplish yesterday?
2.  What can I commit to doing today?
3.  What are the impediments in the way?

While that may have been appropriate for your past agile process, of the three questions, only the last one is relevant in a Kanban stand up.

(1) is unnecessary because the cards on the board tell the story. The WIP (Work in Progress) is visual.

(2) is irrelevant because work will take whatever time it will take to get done. Committing to accomplishing the work will not necessarily make it faster. Often, that leads to heroic effort. In addition, the focus on completing the work that has been "committed" to can actually come in the way of continuous improvement.

So,  what should we discuss in the stand up? I'd suggest:

1. Impediments: What's impeding us?
2. Flow: What's the flow like?
3. Kaizen - or "Continuous Improvement": What can we improve?

Let's take a deeper dive into these questions.

What's impeding us?

Impediments are in the way of getting work done. Impeded work items should be marked visually on the board - usually with a pink sticky on top of it. Team leads or managers should focus on getting these impediments removed as quickly as possible.

Note that you don't have to talk about which item is impeded - that's obvious from the board. The conversation should be around resolution.

What's the flow like?

Kanban looks at software engineering as a flow problem.  The board will show where the bottlenecks are and therefore what's preventing the team from accomplishing more. The conversation should be around smoothening the flow and what actions the team can take to relieve the bottlenecks.

What can we improve?

Kanban is an evolutionary method. It's success largely relies on a mindset that's looking to constantly improve. These do not have to be big changes and can be a series of small improvements. Having a brief conversation on this topic everyday will make it clear that it is everyone's responsibility to make the process better.  When suggestions for improvement come from the team (rather than from managers), there is greater ownership and more likelihood of success.

These are the core questions. Here are some additional practices for a successful standup:

Ensure the board is up to date before the stand up

Many teams also use electronic tools along with a board. It is important to keep the two synchronized. Before kicking off the stand up, ask the team if the board is synchronized.

Celebrate the small victories

The done column on  the board should ideally have two parts. Work done for the week (or an appropriate time period) and work done since the last stand up. You can now see what got done since yesterday. Call attention to what got done. Recognize the effort, if only for a moment. Bring your hands together. Yes - applaud and cheer.

Celebrate small victories and energize the team.  And move on.

Change facilitators

Encourage different team members to take on this responsibility. When you facilitate, you'll get a different perspective of the process. You'll also take more ownership and funnily enough, suggest more improvements.

End the stand up on a high note

 If you have a team song, team dance, a war cry - do it. It'll always elicit a laugh and keep good cheer.

 I'd encourage you to try these practices and improve on them. You should bring in your variations to the stand up around the core practices.

Remember - the goal is to continuously improve.