Product Development – Iterating by Color

Agile development has shown itself to be a superior approach over waterfall in many cases.   But, what I don’t see talked about much is the fact that each feature you pull off your backlog could be developed with a variety of complexities.  If the business owner tells me that she needs to get from point A to point B, I could build her a Yugo or I could build her a Rolls Royce.  I am sure she would prefer the Rolls Royce, but if you factor in the time to build it and the cost, she might prefer the Yugo or something in-between.

The first time you attempt something brand new, you can involve the stakeholders in the design/development, but you are never 100% sure how they are going to react once it is launched.  So, it is best to build that feature relatively simply and then improve over time.

We use colors to denote the amount of resources that we are willing to dedicate to designing and developing a feature, process, or application.

Yellow is the lowest level.  It represents our first attempt at something and it is usually a minimum viable product.  We just want to solve the pain point so we can learn from it.  Often it is very manually intensive to run a yellow feature because elements that could be improved via technology are not.

Green is the next level.  At this point we want to build something that will not tax the operational team.  A solution should be able to run at this color for a year or so without causing any major stress to the system.  We are able to take what we learned from the yellow version to inform how the green system is designed/built.  Occasionally we go straight to green, but only when we feel there are no workable yellow solutions.

Blue systems are designed to last for several years.  They should be scalable, easy to manage, well-architected, and most of all, they should only be built after one has learned from earlier implementations of the feature.  We sometimes go from yellow straight to blue, but we never build something at a blue level first.

This coloring approach is not nirvana.  There are challenges

  • How do you split your resources among the different colored projects?
  • How do you decide to prioritize a blue version of something existing against a new yellow feature that is desired by stakeholders?
  • How do you merge yellow, green, and blue staged elements into the same system (will they always plug and play)?

Anybody tried something similar?  What worked and didn’t work for you?


2 responses to “Product Development – Iterating by Color

  1. Interesting idea. What does it look like in practice? Are these the colors of the post-it stories on your wall? Cool is that you begin to introduce some kanban constraints with WIP just by the color of the story. Lots of yellows, a few greens and one blue.

  2. In practice, “yellow” items are not even meant to require significant developer attention or planning- these often entirely manual, scotch tape and bubble gum (sometimes literally!) implementations of concepts. once an idea “graduates” to green, a slightly higher fidelity implementation is produced- if its produced within the context of an existing “blue” solution, then it would get added as a standard “v1” user story to that solutions wall. If it’s the first story in the first epic of a yet-undefined blue solution, then it would probably be the start of it’s own wall.

    the notion of tracking every story is interesting, but would likely get pretty overwhelming- many of the yellow solutions die on the vine, and would never reach a stage to justify the tracking overhead (even in an agile environment).

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