The Thumbtack and Hole Metrics...

Sometimes metrics can just appear in front of you very simplistically without any effort. I've discovered two new ones which I call the Thumbtack Metric and the Hole Metric.

The back story is that we use a corkboard to track our work. This is a high level view of the biggest priorities in VersionOne, our legacy ticket system, and any other queues of work we have. Because our one team supports all company operations AND does new product development, we have a hybrid balance of many different approaches. The board is our central view.

I attempted to force WIP limits onto the board so that it was a true Kanban board, but this simply didn't work in our environment for multiple reasons (nature of our work along with company culture). BUT, it has been very interesting for the team to start realizing when they are attempting to do too much. As the coach, this was something I used to pro-actively point out, but I'm learning that it is better for me to be reactive so that the team themselves can learn from experience. (Unfortunately, a child understands "hot" much better after being burned.)

This maturity and growth has led to many great conversations on the team. They start as individual discussions of philosophy between me and someone on the team, and then they become team discussions where we improve something in our process.

Through all of this, I've noticed a few things that the team now sees after it has been pointed out:

1. A problem item typically has many thumbtack holes in it (The Hole Metric). The "holier" the item, the more of a problem it is. What is the causation behind this correlation? Well, every week we scrub the board. Every few days rows get re-aligned. If an item is picked up on one day and finished the next... it has one or two holes in it. But if the item gets pushed around for days and lost under other stickies... then it get punched A LOT! So... we now have a metric that can be used to identify areas of improvement. When a "holy" item reaches DONE, it is a good topic for a quick review/mini-retrospective.
2. Every item on the board needs a thumbtack. We thumbtack stickies so that they don't get blown off while moving the board around (our board sits in a central visible area of the company and is carried into our dedicated standup meeting room every morning). Sometimes we group things with one thumbtack, but in general, there is a correlation between the amount of work on the board and the number of thumbtacks used. I haven't been successful at imposing WIP, but I have been successful in showing that when we run out of thumbtacks, we are in for trouble. This is the Thumbtack Metric. If you need more thumbtacks to stick things onto the board, you have a problem coming (or are already knee deep in it). Conversely, the CEO notices that too many unused thumbtacks might be a sign of available capacity (so I take thumbtacks off the board at times if needed ).
   

See... all those documents, white papers, conference sessions, etc you've read about metrics... they were overkill. There are simple metrics right in front of your team every day. AND, they are much easier to sell, explain, and use as an indicator moving forward.

So... what's your thumbtack metric?

A further experiment in ScrumBan…

I’ve recently evolved my company process to include WIP limits, but before I share this story, I must first provide the following background.

When I started at this company 2.5 years ago, there was a large divide. I was trained in PMI, was a CSM, and I was a staunch advocate of XP/Scrum by the book. On the other side of the divide, the company had little process, little documentation, no source control, and made minimal attempts to plan work a day or two in advance. One could say this was a recipe for disaster, but this is a startup… and the point of hiring me was to improve as they doubled the size of the company.

Several things have happened since then:

• retrospectives and weekly iterations were quickly adopted
• source control is now in place
• we put tools in place to manage our work (VersionOne)
• standups have become common for both teams and projects
• we’ve modified the 3 questions
• we now use a ScrumBan inspired board
• most importantly, I’ve learned that there is more to Agile than Scrum/XP… I’ve become an interested follower/borrower of Lean and Kanban practices. This is an important step for me as a coach since not all environments fit the Scrum/XP model. A mixed bag of tricks helps win the debate, especially when it is gamed against you!

So, what is the new problem of the day? I’ll call it the plan-to-budget problem. I’ve struggled for 2.5 years to find a way to get the company to plan work based on the available capacity. We’ve always had “BUT-we-need-to-do-ALL-of-it”-itis.

I’ve explained velocity and scrum, but this was viewed as too expensive to pursue. “Why should we estimate everything when we only care about certain parts of it meeting a specific deadline?” This is a good point. If only a small portion of our work is deadline driven, and the rest is “do as you can in this order”… then putting time into estimating and projecting everything might lead to waste. (Although this is contradictory to “I-want-all-of-it-by-next-month”-itis.)

Thus, I reduced focus and tried a top5 concept. Hey CEO, pick only 5 things that are important for this week, we’ll do our best with that set before touching other stuff. This worked well for a while since it forced us to admit we can’t get everything done and focused on fewer items. It reduced our “in flight” work… for a while. Two things derailed this approach.

1. The CEO found ways to assign work to people outside the top5 set (most people can’t say no to the CEO/founder when approached).
2. Not all items were the same size (scream together now: ESTIMATE!) so 1 large top5 item could clog the whole pipe.

We let go of this concept and evolved our breakdown further. I was happy to push for smaller stories and quicker closure. Appropriate sizing is a great stress reducer for the team, especially when you involve them in that process. But we slowly returned to our problem of demanding more work than we have capacity for.

This is where I started thinking about Kanban’s WIP limits. After all, this would fit our model well, and we already have the board in place. Unfortunately I knew that this would be bypassed just like the top5 limit. Our problem was a cultural problem, and I had to tackle it at the source.

So, we’ve started a new trial change in our process. After 3 hours of debate, I was able to convince management of the following (meaning they agree with these):

• Giving one person too many things at once will slow down throughput
• Swarming is a good way to get things done faster
• Saying we have to do everything doesn’t mean it will get done
• Not deciding on priority means it will get decided by the people doing the work
• Our biggest issue might be over-committing (actually, over-requesting since nobody was necessarily committing)

The solution? Headshots! I made little headshots of each team member. We plan the queue of work and then prioritize it. Then the CEO points at a card on the board and says “I want that first”. We put 1-N heads on it based on availability, capability, and size of work. The CEO keeps pointing at items until we run out of headshots. If he points at big things, he picks less stuff; if he points to small things, he can pick more (Budgeting to capacity!) When a person frees up, they move to something else on the board. Everyone on the team might have a few things assigned to them in VersionOne, but they KNOW which item is most important (the one with their head on it on the board). Everyone on the team focuses on helping each other finish these items before starting new things. All of this is clearly transparent on the board! It's not rigid like scrum velocity or Kanban column limits, but it is a place to start and a way to prove value (a door to further improvement).

Summary: We aren’t doing true scrum, but some of the pieces. We aren’t doing true Kanban or Lean, but some of the pieces. We aren’t truly self-empowered, self-managed… but somewhat. I would be the first to declare we aren’t “agile” as defined by most in the community. BUT, I’m getting to the point where I believe we have a system that works for us (2.5 years ago, we were a demand-and-control company led by the CEO). It’s a hybrid of many agile approaches, driven by my teaching of agile philosophies, allowing this company of ~70 work better together. Hopefully this new change will help us overcome our capacity/planning issues, only time will tell.

A kindergartener's Kanban board...

Literally, a Kanban board in a kindergarten room. David Anderson pulls through once again with yet another insight into Lean and Kanban.

I've been shifting my "work study" towards Kanban and Lean more and more recently. I'm really starting to like it more than Scrum. This example is amazing since it points out the simplicity of managing resources, availability, needs, etc. It does ignore the flow/process/sequence aspect of managing "real" work, but it is really interesting.

Estimation in Kanban?

Before I start, I should note that there is a lot going on in the Agile community related to Lean and Kanban. In case you've been in a cave, you might want to check out this great slide deck by Henrik Kniberg comparing and contrasting Kanban vs. Scrum, or check out Karl Scotland's blog on the topic.

That being said, Anna Forss blogged today about how estimates do or don't fit into Kanban. An excerpt:

The main reason for estimating tasks is to be able to decide on an appropriate work load during the sprint. During the sprint planning meeting, the team estimate how big tasks are and when the work load (estimated task sizes) matches the available resources, the team commits to the sprint backlog.

So, how about kanban?

Jump to her full post to see how she answers this question.

Here's my comment on the topic, even if it is a little open-ended:

I was under the impression that estimates aren’t needed as much in Kanban because items are supposed to be closer to being “of similar size”? Looking back to the original Toyota manufacturing process application, this would have been true.

Otherwise, a large item might hang in your work queue for weeks (because it is too large) while small items fly through. If several large items “get stuck” then it might clog the whole kanban system.

So… do you need to estimate to insure that items are small and closely equivalent? (maybe)

This also make the concept of MMF (minimal marketable feature) an important goal when writing stories!

Great stories...

If you haven't seen these great blog posts you should check them out:

Lean Team Software Process by Corey Ladas

snippet: An alternate metaphor for software value is a refined substance, like gasoline or ice cream. The raw material is customer requirements, domain knowledge, time, and energy; and this is transformed into manifest behavior of a computing system. This view suggests that software has no more customer value than the sum of the scenarios that it supports. Then there is no bright line that defines “complete”, there is only relatively more or less value delivered. When I fill up at the gas station, I need more than one gallon and less than 100 gallons, and when the pump tells me I have enough, I expect to pay the exact value of the utility I expect to receive from the product. Software can be delivered in this way: keep giving me more until I have enough, then stop and charge me for what I have consumed.

Metrics, Schmetrics II by Matthew @ Creative Chaos

snippet: All of those examples are fungible - a gallon of gas can be traded for any other gallon of gas. A penny saved is a penny earned. They are all the same.

Yet test cases, lines of code, these things are not the same. You can have a test case that takes two hours to set up, or a half-dozen similar ones you can run in thirty seconds.

Scrum vs. Kanban by Mike Cottmeyer (ignore the Idol intro and title at the beginning)

snippet: I think that in some ways Scrum is hitting a wall because some of us think that Scrum is the answer to everything. Is Kanban the new answer to everything? Is it going to replace Scrum and XP or DSDM or AUP or Crystal? I can't even imagine how we can have these conversations without understanding where and when is the best context to apply these principles. I feel like a broken record but there is a time and place for all these techniques.

Lean Kanban Conference...

There's some really good stuff coming out of the first day. I'm not there, but I'm following along on Twitter (#lk2009) and Mike Cottmeyer is doing summaries on his blog with every presentation!

Catch it while it's hot: http://www.leadingagile.com/

The Support Team...

An Agile LinkedIn group participant asked how to run an agile team focused on supporting a product that a different team built and delivered.

First thought... who decides which resources get the glory of working on the sprint team that creates and delivers features and business value each sprint vs. the hazing of working on the support team that fixes the crap. I really hope that if you decide it is necessary to split into these two groups, you at least flip flop the assignment or slowly rotate resources between teams to make it feel like one big team. Otherwise, the supporters will only be mad at the creators and you will fall into the typical us/them developer/QA turf war.

A sub-question was posted on how to handle "critical" issues. It was stated, these are the things that are more important than anything the sprint currently being worked. Several points here:

• If these critical issues are bugs or defects, and they happen often... then it's time to have some courage and discipline and go upstream and ask difficult questions. WHY are these things happening, and HOW can they be reduced in frequency? Instead of adapting to handle them, go to the source and stop them. If you can't because "they" are a different group under different management, then you aren't in an agile organization.
• If they don't happen very often, then this is a simple answer. Let the product owner decide whether the item is more important than items currently in the sprint. If it is, then it should be estimated and should displace a set of stories that are lower priority and of equal cumulative value.
• Work one week sprints. As a support team, you need the ability to be more flexible. Shorter sprints allow for quicker reaction and re-prioritization. Also, work can't stagnate without being noticed. Deployment is quicker (although you might deploy daily and not wait for the sprint end).
• Think about applying Kanban. Loosen the strict requirements of scrum and use Kanban to drive how many things you have in flight at a time. Use iterations as a measurement and assessment tool, and use Kanban to drive priority and work. Walking the board will put the daily focus on priorities.

I know that last bullet blows some of the Scrum rules out of the book, but his questions were Agile questions, not Scrum questions. So, I went with the blended solution approach.

Walking the Board...

Several weeks ago we changed our standup structure. At first I kept it to myself due to my fear of backlash from the agile police over blogging about it. But, this week's InfoQ post prompted me to bring it up since what we did was mentioned in the article.

Problem:
Our team was starting to drone in the standups. As more people swarmed on a story, there was a lack of self-management when communicating against the story goal. Translation: Person 2 in the circle would discuss Story B, and then person 3, 5, and 7 in the circle would wait for their turn to share their piece of the story work. It was if we had mulched our sprint backlog and put focus on people instead of delivered business value.

Brainstorm:
Ditch the 3 questions! What? Yeah, I said it, ditch the 3 questions. Actually, wait... keep the questions. Ditch the person rotation. Yeah... that's the answer.

Solution:
Our pseudo-Kanban board (I say pseudo since it is not by the book) is already prioritized from top to bottom by the CEO/product owner. Now, instead of going around the room by person, we work from top to bottom. I play the role of scrum master, so I point at each card. The team speaks about what they did yesterday, what they will do today, and what is blocking them.

Outcome:
Suddenly the room is lit up with energy. Instead of having people discuss their slice of the work, the team is speaking about the whole story. They talk towards the goal of delivery and business value. Cross-communication is triggered (and taken offline as needed). I'll admit that this didn't happen at first (at first they talked to the guy pointing at the card on the board), but it has happened over time with my coaching. There's more interest in moving the card since there is immediate clarity on where we stand with it. Nobody later in the circle is going to surprise us on a prior topic.

Now... you could easily argue that this is stupid. A mature team would be smart enough to speak at the right time and not just in turn. I agree. Look at it a different way though... we are talking through our board in order of importance to the business. The most energy and focus is on the right stuff. Our conversation is less about the who, and more about the what.

Turns out, David Anderson calls this "walking the board". I propose that it's a good alternative and we are proving it!

Infusing Some Kanban (follow-up)...

A week ago, I posted about infusing a few Kanban concepts into our team process and making other tweaks to our standing meetings. Here is a follow-up for those of you who are interested in how it turned out.

In parallel to the previous bullets:

• our cards on the wall have not been restricted to 5. BUT, the good news is that every time we go over 5 the team yells penalty at the CEO (the product owner) and requests that we swarm on existing cards before moving to new ones. The intention is there. (improvement!)
• the CEO is doing a better job of throwing things into the queue as we pull instead of having a weekend brainstorm and puking out a whole new set of priorities on Monday morning (improvement!)
  
• Our standups are more efficient and effective. At first I thought we were missing things because less was said and we ended early, but I'm slowly growing confidence that we are simply focusing on the correct things, consolidating topics into single threads, and reducing the noise. (improvement!)

Also:

• We are definitely focused on the "what" now instead of the "who".
• Standups are easier to follow for outsiders (if desired)
• It is easier to see where things are getting delayed

I will also say that it has become easier for me to coach. Instead of focusing on all the things I am trying to understand and piece together, it is easier for me to keep an ear for anti-patterns and push the team a little more.

So far, a success. I guess I am now a heretic for morphing the standing meeting away from the 3 questions per person. I can live with that.

Infusing some Kanban...

The team I am working with was starting to have a few issues. We had too much on our plates, lots of noise, and the CEO was raising concerns that we weren't focused on the right things. We also had a feeling that the sprint end and begin was a magical flurry of stressful activity.

So we've implemented some changes:

• Our cards on a wall board is now restricted. Only 5 things can be in flight at a time. Everything is still in VersionOne; but only the top 5 get the explicit visibility of being important enough to be covered every single day.
• The CEO (highest level product owner) is responsible for filling and prioritizing the +5 queue whenever there is an opening. These are the next 5 things expected to move into flight.
• Our standups are no longer going to be asking the 3 questions going around the circle in the sequence we lined up around the room. Instead we are going to first talk through the top5, and then use the time remaining to discuss other notables as people need to. The team is responsible for taking their turn by importance and not going in sequence.
  

Our hope:

• This will shift focus from what "I am working on" to what "the team is delivering for the company".
• We might not get to every topic since not everyone will have an explicit turn, but we guarantee that we are talking about the right things.
• Outsiders can attend the standing meeting and easily see certain items and their status as opposed to hearing about an item across people throughout the meeting.
• We force the business to shift from magically identifying 5 things every Friday (1 week sprints) to constantly filling a pipe of work every day as we empty it.
• It is easier to see if our commitments of date and cost are at risk and communicate that to stakeholders because the topic is covered at once. (Our commitments are more safely limited to the top5.)
  

We see how it goes... (like many issues, we'll implement changes and slowly snap back to a happy medium as we learn and grow)