Creating Product Features Instead of Feature Elements — a Key Agile Environment Challenge

Ever have one of those situations where multiple events all pointed you in the same direction?   Recently this happened to me on the topic of “feature elements versus product features” in an Agile development environment.

First I had a discussion with a potential client, then a friend was lamenting about incomplete features in his company’s latest sprint, and then there was the presentation by David Hussman on this topic at the July meeting of the Agile Bazaar.   So this is what I learned…

One of the fundamental ideas behind the Agile development methodology is that your development process is divided into small cycles or sprints.  The idea is that each sprint is sufficiently well-defined to allow it to be delivered to your customers.  And then your next sprint could focus on refining previously completed or new capabilities — depending on what the market (and your customers) need.  In this way, your product is theoretically ready to go to market at the conclusion of any sprint, so you don’t have to wait until all of your “planned development” for a given release has been completed (and tested).

However, this approach doesn’t accommodate situations where your product must include a certain set of related features (we’ll call them “feature elements”)  which cannot be completed in a single sprint and which your product really must include.

For example, assume that you are creating a word processing application which will allow users to create, save, edit, format and print documents in a variety of ways.

Your product MUST have the ability to “create a new document”.  Likewise, without the ability to “save” your changes and then “load” or “open” a previously saved document — the value of your product will be minimal.   This is why, most applications that deal with “objects” provide feature elements for performing “CRUD” (Create, Read, Update, Delete) operations.

Yet, some of these feature elements are much more challenging to implement and thus take longer to complete — often requiring multiple sprints — which is at odds with the Agile concept of being able to deliver the results of any sprint to your customers.

A modified Agile approach known as Kanban appears to resolve this conflict, because the focus is on delivering complete product features and not just feature elements.  In essence, a sprint is not suitable for delivery to customers unless all of the key elements of a product feature are completed.   Thus, to return to our word processor example, you might implement “Create”, “Save”, and “Open” in different sprints, but your product would not be distributed to potential customers until all of these product feature elements had been completed.

This development approach seems nearly ideal to me — but few companies seem to be using it and some strong Agile proponents seem extremely reluctant to embrace it.

So what do you think?   Is Kanban simply too new for many people to have tried it?  Or is it better in theory than in practice? Or is it simply not “Agile enough” for you to consider?

Do you have any experience with Kanban or know of any companies that have used it?  If so, what did you (or they) learn?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: