The following are my slides from my presentation at the Lean Software and Systems Conference last week.

This weekend I had the opportunity to mentor some of the teams at The Startup Center during the in50hrs event. The idea of the event was to conceptualize and build a minimum viable product within one weekend.

As a mentor, my role was to sit with teams and make sure that their product idea really was the “minimum viable product“. When you conceptualize a product, chances are you’ve got all these fancy use cases in your head. You’re thinking “Oh wouldn’t it be cool if we had this features” and “That feature would really be neat”. Before you know it, you’ve got a complicated product with many useless features.

Lets look at an example of how we can pare back the features into a minimum viable product.

Elevator Pitch

How often have you searched long and hard to find customer support numbers for companies? The numbers on many companies websites dont work (if you can find them) and Google is of no help. The idea is to build a site, with working customer support numbers for various companies. Users can add numbers they find and vote on other numbers whether it worked for them or not.

Initial Feature List

The initial feature list had a whole bunch of features for this product

• Search the database to find a company
• Allow users to submit companies to the database
• Group companies into categories
• Detect duplication of companies (eg: IBM vs International Business Machines)
• Separate numbers by city
• Get the user’s IP, determine the location and show numbers for the city closest to the user
• Upvote on numbers which work
• Downvote on numbers which aren’t working
• Allow businesses to add verified numbers
• Allow users to submit numbers to the database
• Have premium users who receive discounts from companies
• Premium users can login through facebook, twitter and google accounts
• Show users their vote if they have previously voted on a number

Wow, that’s a lot of features for the first release.

The Minimum Viable Product

Now how many of these are really central to the core problem being solved? My job was to cut away the extra features.

So we went through the list and thought about each feature in turn. Do we really need to categorise companies? Do we really need premium users? Do we even need authentication at all? Can everything be done by anonymous users?

Finally, we whittled it down to just these features

• Search the database to find a company
• Allow users to submit companies to the database
• Allow users to submit numbers to the database
• Upvote on numbers which work
• Downvote on numbers which aren’t working

That’s all you need for the MVP.

Think about your next product. Do you really need all those features for the first release?

A lot of emphasis in software development process is placed on project management – making a commitment, planning, and tracking everything so you ensure you don’t drift away from the plan. Funnily enough, many agile projects have also ended up with this ‘form’ of project management.

And don’t get me wrong, it is important not to screw up!

But, in the worry not to screw up, are we losing sight of the opportunity to get better? Do we understand what we are building? Do we know where our bottlenecks are? Are we best aligned to business needs?

So here we go – the showdown between Project Management and Project Intelligence:

One of the core goals of Enterprise Kanban is to effectively link business with development teams, and to do this across multiple teams, stakeholders and initiatives. This alignment is hard to do, and that is where bigger picture techniques come into play. Some of these techniques are

• Using Story Maps to effectively translate between high level activities/objectives to low level stories
• Using multi-tier kanban to manage feature flow at different levels of abstraction
• Using multi-team kanban to coordinate features that cut across different teams
• Using class of service to align development workflow with business needs
• Using a risk oriented view to manage backlogs (1, 2, 3)

Silver Stories is a product and portfolio management tool that enables you to apply these higher level concepts across multiple scrum or kanban teams.

Webinar

For this month’s webinar, we are going to do a free, early access demo that shows these concepts in action. Register for the Silver Stories demo here. The demo is on Wednesday, 23rd March at 10:30 PM IST (see time in other timezones)

The previous three posts talked about three dimensions of product risk:

• Product type: Commodity vs Market Risk vs Technical Risk
• Feature type: Basic Feature vs Linear Feature vs Differentiating Feature
• Cost of delay: Normal vs Fixed Date vs Expedite vs Intangible

Based on the category that a feature falls into, it makes sense to handle it differently. Kanban uses something called a Class of Service to abstract this idea. The concept can be applied in any project – Kanban or Scrum.

At a simple level, class of service is just a bucket or category that you can use to categorize the features. So you might have classes like

These seven classes encapsulate the three dimensions of risk that we talked about in the previous posts.

One advantage of class of service is that it can be coupled with policies to handle different classes in different ways. Policies can be designed in such a way that they are aligned to business expectations. For example, expedited items have a high cost of delay, and need to be deployed as soon as possible. A policy for the expedite class could be something like this:

Expedite

• Only for emergency bug fixes
• Moves to the head of backlog and all queues
• Can override work in progress limits
• Team members stop whatever they are working on and swarm to complete this work item

This policy ensures that expedited items are deployed as fast as possible. Similarly, policies can be designed for the other classes to align them with the business.

Class of service can be used to set schedule expectations. Measure the cycle time on work items for each class of service. You will then be able to visualize work items on a statistical process control chart and set expectations on the mean and upper bounds for items in that class. For example, you might find expedited items have a mean of 2 days and an upper bound of 5 days. Whereas the high value class may have a high mean and a more variation between the mean and upper bound. This is useful because it sets the expectation that there could be a lot of variation in certain classes, something that is not conveyed clearly when using single point estimates like days or story points.

Finally, it encourages a risk profile oriented view of the project. If you have too many High Uncertainty work items, then that could be an indication that you might be taking on too much risk. Similarly, you probably want a mix of Basic features with one or two High Value features that tie in with the business’ market strategy.

Webinar

I’ll be expanding on this idea further in an upcoming webinar on Using Class of Service to Manage Risk. The webinar will happen on the 16th of February, 9:30 PM IST (See time in other timezones). Sign up for the webinar to join the discussion.

When it comes to backlog prioritization, there are many factors to consider. One factor is the “cost of delay” of the feature.

What is cost of delay? And why is it important?

Cost of delay is a model to examine the cost to the business if a particular feature is delayed. This can help product owners understand the time sensitivity of a feature and aid in prioritizing it appropriately. In this blog post, I’ll take a look at four typical cost of delay curves.

Normal

Normal features have a linear cost of delay. If you deliver earlier, you can start getting the business benefits earlier. If you deliver later, then it costs the business more or less proportional to the time it was postponed.

Expedite

Expedited features have a constant, high cost of delay. They are typically emergencies that have to be implemented immediately.  Emergency production bug fixes might fall into this category.

Fixed Date

Some features have a fixed date by when the feature is ready. Some typical cases are to meet a regulatory deadline or to launch a feature at a conference. These types of features have no cost of delay upto the deadline. There is no benefit to be gained by completing the feature early. If the deadline is missed though, then it becomes really costly.

Intangible

Intangible features are long term features that have no immediate need to be implemented, but are required for the long term competitiveness of the project. For instance, upgrading the build or changing the architecture are features that fall into this category.

Once you know which bucket a feature falls into, then it makes prioritization decisions much easier. Obviously expedite features have to go to the top of the backlog. Fixed date features should be done as late as possible, but with a buffer to ensure that they don’t miss the deadline. Normal features fill in the other parts of the backlog and intangibles are scheduled such that they are worked on during periods of downtime.

Webinar

I’ll be expanding on this idea further in an upcoming webinar on Using Class of Service to Manage Risk. The webinar will happen on the 16th of February, 9:30 PM IST (See time in other timezones). Sign up for the webinar to join the discussion.

One of the big mistakes that an agile team can make is to create a backlog of features and then treat every feature in exactly the same way. From a business point of view, features are not all equal. Some features are very important to the success of the project, whereas others are extremely unimportant. I’m not talking about business value – you can have unimportant features which have a high business value, for example. How? Read on.

The three types of features

A useful model for analyzing your product backlog is the Kano model.

The Kano model can be used to categorise feature into three buckets (actually five, but I am going to focus on three):

• Basic features: Basic features are features that are absolutely must-have, but do not add to customer excitement. This sounds like a contradiction, so lets take an example. Most web applications require you to login. This is a must have feature – users cannot use your application if they can’t login. At the same time, no one is going to purchase your application based on the quality of the login functionality. In other words, you need to have the feature, but once its there, there is no point wasting more time in refining it.
• Linear features (also called performance feature): Linear features are features which fall into the “more is better” category. If you have more linear features, the customer feels proportionately better. For example, the number of camera file formats that are supported by a photo editing application are linear. If one app supports 10 camera models and another supports 20 models, it adds to the customer excitement, but only a little.
• Differentiating features (also called excitement feature): These features are high excitement features that set you apart from the competition. A few differentiating features can offset the absence of many linear features, because they generate excitement for the customer. Marketing campaigns and product positioning may be based on these features.

It helps to know the composition of the backlog based on these three categories. If you know that, then you can apply different strategies to each type of feature.

For example, basic features are not worth spending too much time on. Implement it, make sure it works, then move on.

Differentiating features, on the other hand, are worth spending a lot more time to get it right. You may want to call in some expert users to try it out during development, or run it through a couple of iterations of user experience trials before development starts.

Linear features might fall somewhere in between.

In other words, the process used for developing the feature should vary based on the kind of feature you are dealing with. If you treat every feature on the backlog through the exact same development process, then you are likely doing your stakeholders a disservice – either wasting too much time on basic features, or spending too little time on differentiating features (or both).

Webinar

I’ll be expanding on this idea further in an upcoming webinar on Using Class of Service to Manage Risk. The webinar will happen on the 16th of February, 9:30 PM IST (See time in other timezones). Sign up for the webinar to join the discussion.

I often meet Product Owners who don’t really understand the product they are building. This is sad because it means the product is doomed for failure right at the start. This is a single point of failure. All the benefits of agile software development and agile project management rest on one critical assumption – that the product owner understands what is being built. If the product owner doesn’t do a good job with managing the backlog, then it doesn’t matter if you have a the best agile team doing continuous deployments and one week sprints – you’re just doing to deliver the wrong product faster to market.

“What kind of product risk are you dealing with?”

This is the first question I ask when talking to a product owner. If you don’t understand this, then the project is in deep trouble right from the start.

Essentially, there are two types of product risk: Market risk and Technology risk

• Market Risk is when you deliver a feature, but you aren’t sure whether the feature will be accepted or wanted by your customers.
• Technology Risk is when there is a big question mark whether you will be able to build the technology in the first place.

Steve Blank has a great writeup about these two types of risk.

There are also two types of projects

• Strategic projects are projects that have a key impact on the business strategy of the company. Most strategic projects have an unknown element to them.
• Commodity projects are well understood, and are implemented to cut costs or increase efficiency, but do not have a direct impact on business strategy. Many enterprise software fall into this category, eg: Payroll systems or human resource management systems.

Strategic projects are generally exposed to either market or technology risk. In markets like Web 2.0, you mostly have market risk. There is no breakthrough invention or R&D you need to get the project out the door – most of the risk is whether you build the right product for your market or not. Other projects may have obvious markets and customer demand, but may involve a lot of technology invention and IP creation – these have primarily technology risk.

On the other hand, commodity projects are mostly well understood, have been implemented many times before, and have neither of these risks.

The reason product owners need to understand this is because it determines the base strategy for the release plan.

In commodity projects, the base strategy is to order the backlog based on business value. In fact, if you look at most scrum literature, this is the strategy that is usually described – put the highest business value items on top and the lowest at the bottom. Then all you need to do is to work through the backlog and build the software incrementally, making a release every sprint.

On the other hand, when the project is exposed to market or technology risk, then the primary focus should be on risk mitigation. In this case, the focus should be on learning and validation.

• For market risk, you’ll want to build out cheap prototypes of core features and get potential users to use it and get their feedback.
• For technology risk, you’ll want to focus on spikes that explore the solution space in a quest to understand how the product can be built.

In both cases, iterations are more important – you want to get the cycle time really short so that you can iterate on the right solution. The early backlog will have a lot of spikes. Quality is secondary. There is no point taking extra time to build a better quality prototype using test driven development or write a whole lot of automated functional tests, because there is a high probability that you will need to throw away many parts of the solution and start over again. Similarly, don’t get stuck up on the fact that you haven’t delivered end user business value for a few weeks, because thats not the point here.

Once you are confident that you have the risk covered, then the strategy can be switched over to a more conventional business value focused backlog. The interesting point here is how the process itself changes as the project goes along.

Webinar

I’ll be expanding on this idea further in an upcoming webinar on Using Class of Service to Manage Risk. The webinar will happen on the 16th of February, 9:30 PM IST (See time in other timezones). Sign up for the webinar to join the discussion.

Over the past couple of weeks I’ve been posting on business agility and enterprise kanban.

Today, I’ll be doing a free, 45 minute webinar on the topic which will expand on the series of blog posts.

Join the webinar here: Leveraging Enterprise Kanban

And for those of you who missed some posts, here are is the complete series:

1. The need for enterprise Kanban
2. How queues impact business agility
3. Multi-tier Kanban
4. Using the enterprise kanban board to coordinate multiple teams

Most of the time it takes multiple teams from across the organization to deliver an “Epic” (See this post on multi-tier kanban for more on Epics). In this post, I’ll take a look at using enterprise kanban boards to coordinate these teams.

When you think about it, multiple teams are the norm, and its really rare for one team to deliver the whole business value. Here are some examples of how multiple teams may be involved

• The development team builds a feature. Once its deployed, the website team needs to create a page on the website. The marketing team has to update marketing materials and promote the epic with press releases and newsletters. Only when all of these happen can the epic be considered done.
• A product is supported in multiple editions, for example SaaS and onsite editions, which involve different teams.
• A feature is to be added to both the current and previous version of a product. Each version is developed by a different team.
• Teams are divided by platform, for example Windows Platform Team and Linux Platform Team. Each of these teams may develop platform specific versions of multiple products.

As a product company with both SaaS and onsite editions, we regularly encounter the first two types of coordination. It’s easy for these cross team coordination to fall through the cracks. For example, deploying a feature without the follow up marketing means that the feature is still in-progress, as the business value won’t be realised until it is complete end-to-end. Without visibility into this, it’s easy to miss out and find that you have a lot of features that are elaborated, but not developed, or developed but not integrated into marketing, and so on.

An enterprise kanban board gives visibility into these kinds of bottlenecks.

The Scenario

So here is a scenario that we’ll try to visualize using the enterprise board. Lets say that you have an epic that consists of two features. Each feature will be worked on by a different team. After both the features are deployed, the web team needs to update some pages on the website.

To start with, take a look at the blog post on multi-tier kanban as I’ll be building on that post.

What we do is to define epics that cut across all the work that needs to be done.

We can then flow the appropriate stories on the respective team board

Once both the stories are complete, the epic moves to the next column, and the web team stories are moved to the web kanban board.

Once the web team is done, the Epic is also moved to the done column.

Now, if both features are not completed, the Epic remains in the dev column on the enterprise board, highlighting that something else needs to be done. Or if the development is done, but the website work is stalled, then the Epic will remain in the Marketing column. By tracking bigger features on an enterprise board, bottlenecks and coordination issues become visible, and you can take action to resolve the bottleneck.

Webinar on Leveraging Enterprise Kanban

I’ll be expanding on these ideas in a free, one hour webinar on Leveraging Enterprise Kanban. The webinar will happen on the 19th of January, 9:30 PM IST (see time in other timezones). Sign up for the webinar to join the discussion.