We just released a new video on using Silver Catalyst in a Kanban project. View it below:

One of the really nice things with physical cards is that you can easily annotate it with stickies and other things such that the story card conveys a huge amount of information right at a glance.

For instance, lets say that one feature requires having a conversation with Bill. This is not a formal task that you want to track, but its just a kind of ad-hoc reminder on something that needs to be done.

Doing this with physical cards is easy! Just take a small sticky, write “Talk to Bill” on it and slap it on the story card. Done!

You’ll never forget with the sticky right there on the card. When you’re done, take out the sticky, tear it up and throw it away.

This simple operation can become extremely complicated with an electronic tool.

That’s the kind of problem we always grapple with.

How can we make the board as simple, visible and flexible as a physical board, but retain all the functionality that electronic tools excel at?

Creating Ad-hoc notes in Silver Catalyst

So here is how you can create ad-hoc notes in Silver Catalyst and get them to display on the card in the board.

It’s very simple really.

Just go to the project settings and add a new custom field as shown below. Lets call this field ‘notes’. Set the type to text.

And…you’re done!

Now if you fill up this notes field, it will appear on the card on the board. Just like the image below.

Wasn’t that simple?

Over the last few months I’ve noticed one anti-pattern come up again and again. This anti-pattern is very common in the agile community, but now its jumped over to kanban as well. It’s the dreaded local optimization.

Here is how the pattern goes

• Someone in an organization learns about Kanban (assume its the test lead)
• The person gets excited and decides to apply it to her work
• She looks at her workflow and maps it out to columns
• Kanban is used to track the flow of work through the workflow

Assume that the kanban board looks something like this

The flow of work is mapped out, bottlenecks identified, the cycle time for testing is tracked and the process is improved.

All is good.

No! No! No!

This is a classic local optimization. All you’ve done is to optimise the testing process alone. But does that add value?

I recently has a problem with my laptop. The service guy came over to my office and replaced my hard disk. Took 15 minutes. Then he called up the service center and called another person to come to install the operating system. This person came a week later, and took another 15 minutes to install it.

So, whats the cycle time? To me, it was a week. That’s the time since they started fixing the problem to the time when it was actually fixed.

The way the company tracked it, the average cycle time per ticket is only 15 minutes. Service people are encouraged to cut the cycle time by scheduling more tickets of shorter duration each. Instead of taking 30 minutes and fixing everything, they preferred to have 2 tickets of 15 minutes scheduled a week apart. That’s because cycle time is tracked on ticket time, not value delivery. For the customer it means 1 week to get a problem fixed instead of 30 minutes.

Go a level higher

The Kanban board should represent the value stream, not workflow. Subtle difference: A value stream, represents the flow of value from when some value was requested to when the value was delivered. A workflow is just a sequence of steps.

If you don’t map out the whole value stream, you are likely to end up in local optimizations.

You’ll never identify this problem if the Kanban board just maps one tiny bit of the value stream. Maybe the problem is elsewhere and you’re just wasting your time optimizing something irrelevant. Worse, maybe your optimization is counterproductive to the actual value being delivered.

The solution is to go a level higher. This is a better board:

I’ve simplified the value stream to just 3 steps for the purpose of illustration. This board tracks from when a story is not started to when it was released. If it isn’t released, it hasn’t added value, simple as that. Teams that take a day to build and test a story, but release once a quarter have a cycle time of 3 months, not 1 day. Now you start to see the real picture.

This is a good start, but it’s not enough.

Go a level higher (again)

Building and releasing features is well and good, but are they delivering value? A team could efficiently deliver a stream of useless features with a one week cycle time and not add any value. From a stakeholder perspective feature are just features. Value is delivered only when a higher level goal is met – perhaps some strategic direction is enabled, or new sales are made, or new markets are opened. Having a great cycle time on feature delivery is nice, but its a local optimization.

Lets go a level higher:

Now we see the real picture. This is the real value stream (simplified of course). Now we can see bottlenecks in the whole process. Maybe the goal was not satisfied because we developed the wrong features. Maybe the marketing needs some tweaking. Maybe the first sales approach didn’t work and a new approach is needed. Whatever the case, the cycle time clock is ticking on until the value is delivered.

The real cycle time

• If it takes one hour to test a feature, but a year to deliver value to the business, the cycle time is one year
• If it takes one day to build and test a feature, but a year to deliver value to the business, the cycle time is one year
• If it takes one month to decide on a feature set, build and test the features, but a year to deliver value to the business, the cycle time is one year
• If it takes one quarter to make a release from start to end, but a year to deliver value to the business, the cycle time is one year
• If it takes six months to go from idea to released to marketing ready, but a year to deliver value to the business, the cycle time is one year
• If it takes a year to get from deciding on a goal to achieving it,the cycle time is one year

How well can the organization go from goal creation to goal satisfaction? That’s when value is delivered. That’s the real cycle time.

If you are not mapping out the real, end-to-end value stream, chances are high that you are optimizing locally!

One of the slides from my talk at LSSC was about multiple projects being developed in parallel. (Slide 15)

Background

This was when I was working at Innvo Systems, around 2004-05. The company had got one round of venture capital financing and we were about 20 people strong with one acquired product. We were looking for another round of funding and the pitch was to use the money to scale fast, update the current product to latest standards and complement it with a complete suite of products (3 in all). The pitch worked, we got funded and the race started to scale as fast as possible and build up the suite.

Within a few months, the company scaled from 20 people to a peak of about 50. Around 30 were to be involved with the new product development roadmap, and were split into three teams.

Work on each of the products proceeded in parallel.

What we expected

When we first started out, the plan was that each of the products would be completed in about 12 months. So we would then have a complete suite ready to take to market.

What actually happened

What actually happened was that we were too few people to build three major products from scratch. With three teams, each of the teams ended up being understaffed. In addition, all the experienced folks were divided up among the teams, leaving each team with predominantly the new hires. A substantial portion of time of the experienced folk was spent getting new hires up to speed on the specialized domain.

The end result was that all three teams limped along and it took a lot longer than expected for the complete suite to be finished.

Lessons learned

Instead of working on all products in parallel, it would have made more sense in committing all efforts to one product. When it was complete, the team could have moved on to the second product and later the third product.

By doing this we would have got one complete product out much sooner. We could then take this product out to market and start booking revenue right then, without having to wait for the other products.

Further, it would have made more sense to have one solid team, rather than four understaffed teams. One team of about 15 might have worked out better than three teams of 10. A bonus would be that we could then put all the experienced people in this one team and thereby reduce the ratio of new hires to experienced people. This would have reduced the ramp up time before the team got productive.

Silver Stories has an Enterprise Kanban board to track the flow of MMFs from the story tree. In this screencast we explore the functionality of this board. In the process we show how Silver Catalyst can be linked up to execute upon the backlog created in Silver Stories, and the expand-collapse pattern for enterprise kanban boards.

Silver Stories allows you to create flexible team configurations. Have multiple initiatives that are executed by the same team? Have one initiative that is executed by multiple teams?

Check out this video to see how you can handle this in Silver Stories

In a previous post I introduced the Story Tree functionality of Silver Stories. Here is a video that shows how you can go about creating such story trees.

We had three goals when developing the interaction interface for story trees:

• Support different feature hierarchies: The video shows how we can use the Story Tree functionality to build a user story map, but you can create any other feature hierarchy too. You use a Theme->Epic->MMF structure? Or Goal->Feature->Story? You can model those too.
• Keep it visual: We are big believers in visual management, especially in the 10 foot, 3 second rule. We could have shown trees using the regular collapsible tree structure, but you lose all the context as you drill down or roll up the tree. By visually depicting the entire tree at once, you can always view your operations in the context of the entire story tree.
• Make it fluid: If the story tree is to support collaboration, the interaction had to be fluid. You should be able to create cards and move them around as if you were on a card wall. You can get remote stakeholders on skype conference call, share your desktop, and collaboratively build up the tree in real time as the conversations are happening. You can see that fluidity in action in the video above as we build up a small story tree in only three minutes.

So what do you think of the story tree functionality? We would love to hear your comments below.

Here is a question for you: How long does it take to identify that you have a problem with your process? A month? A week? A day?

Ideally, you want this information in near real time. A well designed Kanban board can do this if you design it with the 10 foot, 3 second rule in mind.

The 10 foot, 3 second rule

The rule says that a person should be able to look at the Kanban board from 10 feet away, and should be able to understand what is going on within 3 seconds.

Kanban uses visual management to achieve this. Humans are well evolved to quickly make sense of shapes, patterns and colors. We can leverage this to design boards that convey more information within seconds. Here are some ideas:

1. Using color
   1. Mark blocked work items prominently with red tape
   2. Use colored stickers to indicate states, eg: code review complete
   3. Highlight columns that are above the work in process limit
2. Using shape
   1. Look at the shape created by the cards in each column. This gives a quick indication of the flow of work items
   2. Look at columns where cards are piling up to identify bottlenecks
3. Using patterns
   1. Use colored cards to depict work item type or class of service. Quickly identify the type of work in the system by looking at the color across the board
   2. Use a colored sticker or a small picture to indicate who is working on each work item. Then glance around the board to quickly identify who is working on what

With a single board, you can now answer questions such as:

• Are work items flowing smoothly through the system?
• Where are the bottlenecks?
• What kind of work items are we working on?
• Who is working on what?
• Are too many items waiting in queues?
• What is the next action required to move a work item forward?
• How many work items are blocked? Why? Do we need to investigate for root causes?

Are you spending hours searching, filtering and mining around a messy spreadsheet or database to answer these questions? By making things visual, you can get all the answers in a few seconds.

Support for visual management in Silver Catalyst

Visual management techniques are a core part of the way Silver Catalyst is designed. Each screen of the tool uses color, shape and patterns so that you can quickly identify multiple trends in a few seconds. Try taking the taskboard in Silver Catalyst and projecting it on to a wall to quickly enable the 10 foot 3 second rule.

Don Reinertsen gave a wonderful keynote at the Lean Software and Systems conference today. He brought in a lot of new ideas (and many old ones too!) with many insights. I especially liked how he looked at flow as an independent concept from lean. A lot of the talk resonated with what we are trying to do with Silver Stories, so that was a timely talk in more ways than one.

One of the great advantages of being in a startup is that it teaches you to appreciate both the technical and business points of views. Here are some of my observations on the talk.

Lean is just the first peak

A nice analogy by Don was likening Lean to the first peak in a range. Mountain climbers often experience this when they climb the tallest peak they can see and find a taller peak beyond that and another one and another one. Lean is just the first peak in the range, a waypoint on the journey. Lean has some good ideas, but also some ideas that don’t work in product development. We need to look beyond lean and also see other domains that we can learn from. Most of the talk was looking at flow with an Internet packet switching analogy, though Don mentioned some other potential areas to look and learn from.

An economic view of projects and features

One of the highlights of the talk is the way Don linked everything to the economics of running a business. This is something that I feel is really needed in the agile community (in fact this is the primary goal of Silver Stories), so there was a good resonance with the idea. A lot of agile processes talk in terms of development, like burndowns and stories and velocity. We need to translate things into business terms before we can make business decisions on them. A great example is prioritization: How do we prioritize features? Do we use gut instinct? Don proposed (about 20 yrs ago, but its only now coming into the agile community) looking at factors like cost of delay and risk factors to analytically make prioritization decisions.

An assumption here though, it that we have the data to make the quantitative decisions. For instance, we rarely know a-priori what the cost of delay graph for a particular feature is going to be exactly. We can broadly classify them as emergency, or linear cost, or fixed cost and such, but we rarely know what the exact numbers (Do we need to know?). The only way to find out is to actually delay and see what the cost it. Once we have enough numbers we can plot the cost vs time. This seems to be infeasible in certain cases (for little benefit?).

Killing sacred cows

Along the way Don had the audience in splits as he went about killing some sacred cows. One of the examples was about operating an emergency room in a hospital that uses FIFO ordering. In this setup, a person with an ear ache gets treated while a person with a heart attack is waiting. The argument was a bit of a strawman, because I don’t think anyone really does a strict FIFO in software. There is almost always a method to expedite urgent items, and most teams triage at some level. But analysis stops at urgent/not-urgent coupled with a gut feel, when in fact there are many axes to consider. Kanban methods promote a risk based prioritization method based on class of service, which is a big step forward. (Did I mention that this is one of the focus areas of Silver Stories? No? ) So although the examples Don presented were to make a funny point, there is quite a kernel of truth behind them.

Points on variance

Don spent some time talking about variance, and whether it is good or bad. Don pointed out that high variance is good for product development. If you don’t have variance then you aren’t taking the risks needed to generate learning. The maximum amount of information is generated when you fail 50% of the time. I want to point out that we should be clear on the causation: taking risks leads to variation, but just because you have variation doesn’t mean you are doing something right – you could just have an unreliable process.

Don had an interesting tweet on variance – “If two runners have identical mean race times the runner with the greatest variance will win more races”. This is true, but it slightly misleading since most runners try to increase the mean rather than increase the variance. There is something to be said for consistency too – the great sportsmen for example are consistently good over a period of time (higher mean), not one-shot wonders (higher variance). Perhaps venture capitalists are the only group that I can think of that intentinally try to maximize variance.

Another interesting comment came during the audience question on the difference between product variance and process variance. Product variance is variance on high level strategy decisions – which product and feature ideas to pursue, and so on, and the associated variation in the outcome of those decisions. I can see that variation at this level is good – that’s what generates learning on “building the right software”. This is usually an area of high uncertainty so variation is an outcome of that. Process variation is the variation in actually “building the software right”. I would imagine that variation here would be a lot smaller as it is generally much better understood. There are lots of pieces of uncertainty for sure, but a lot less than at the high level.

Standardizing the process

A very insightful comment from Don was during the Q&A when a question came up on standardizing the process. Don mentioned that most organizations tend to standardize at the top of the process. A better way would be to standardize the bottom. With a standard alphabet and a standard grammar, we can generate an infinity variety of proper sentences. Don suggested a similar method to “building” a process for each project using a standardized set of building blocks. Doing so allows you to create and infinite variety of processes to suit each situation. This is a very insightful idea, especially in the current backlash against scrum as being too prescriptive, but I want to note that languages have a well defined grammar that tells us how to put blocks together.  Without the grammar, you could make an infinite variety of illegal sentences. So whats the grammar for a software process to prevent an infinite number of bad processes? I think that is still an open question.

The Internet as a metaphor for flow

Don used the Internet as a metaphor for flow. This was a very interesting analogy. One of the main points was how we break up packets, route them independently, then reassemble them at the destination. This leads to much better throughput, and superior error handling. A very nice analogy which brought out the benefits of small batch sizes. The other point was about calculating the correct batch size. We don’t use single byte packets because the overhead is too much. So we need to find the point where we balance the transaction cost with the need for small batches. Don also pointed out the benefits of sliding window throttling to control traffic. We don’t want to wait until we are at full capacity since this leaves us open to congestion collapse when a bursty stream comes in. In terms of software development, this would translate to dynamically adjusted work in progress limits.

Don also mentioned how the Internet is a “best effort” delivery network. The idea is not to prevent errors, but to simply re-request when an error is found. It turns out that re-requesting is a lot cheaper than setting up a guaranteed delivery system (like circuit switching). This ties back to the discussion on economic benefits when sometimes it is simpler to rework than to put in a lot of effort to prevent the rework.

Although it sounds new, I would say that a large part of agile rests on this principle. In agile terms, we would say its cheaper to deliver, collect feedback and iterate rather than spending a huge amount of time up front getting the requirements perfect before starting. In many cases it is cheaper to prevent the error, so this doesn’t mean you shouldn’t prevent the error, it means you shouldn’t blindly focus on preventing errors alone.

My thoughts: In packet routing, none of the routers process the information in the packets, so its easy to do it independently. In the case of work routing, each workcell does process information and that requires context. So for example, its not easy to do half a feature in California, decide there is congestion there, and send the other half to Bangalore. You lose the context for the work. You see this situation for example in load balancing networks when state is stored on the server, which dictates that all requests for a particular session must always route to the same server. Similarly, it seems to me that work item routing can only be done at a much higher level of granularity – possibly at the MMF level. (Another one of the problems we are looking to solve with Silver Stories!)

Don also brought up the point about people and work not always being fungible. I would think specializing generalists help for this kind of situation.

That’s a wrap of my notes. Really looking forward to seeing the talk again when the video is uploaded. This is one that is worth watching multiple times and get something new each time.

Were you in the session today? Let me know your thoughts in the comments below. And do link up your blog posts too.

We recently announced Silver Stories, a tool for agile portfolio management. In this post, I explain some of the problems that we hope to solve with Silver Stories. Click here for the entire series of posts on Silver Stories.

Losing sight of the big picture

Agile processes advocate breaking stories into small (and in some cases absolutely tiny) chunks of functionality and putting them on the backlog. This is a good idea for enabling frequent deliveries, but it’s terrible for retaining the big picture.

Once you have a backlog, its difficult to go and reconstruct it to see exactly where you stand on the overall project. (Jeff Patton highlights this problem well in this blog post on user story maps.)

The product or release level burndown, which is the preferred way in Scrum, is completely inadequate for this. If the burndown shows 20% done, it could be 20% across the product which means its crappy but you have a walking skeleton, or it could be 100% on one goal and 0% on the rest, which means that the software isn’t usable yet. There is a big difference between the two. You can figure out where you stand only if you retain the big picture.

For all these reasons, a list of user stories is inadequate.

How does Silver Stories help?

In Silver Stories, you’ll be able to create a big picture map (it could be a user story map, or an Epic->Feature->Story breakdown or any hierarchy that you want) and break it down into a backlog of stories. The development team will be able to work on this backlog, and the stakeholders will be able to visualize progress on the map. Are we 20% done across the project?  Are we spending too much time on one theme? Do we have a walking skeleton? The map will tell you the answers.

Does this feature excite you? Help us build the features you want by participating in this 10 minute survey.