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?

The Power of “done”

My agile scrumtastic friend Andrew Tsui invited me to join him for an evening meetup of Agile NYC led by the master of all scrum masters, Ken Schwaber. My primary takeaway from the session is the importance attached to the definition of “done”.

Too many software development teams move onto the next set of desired features before they have reached a full complete, tested, and shippable state on the current set of features. This creates an over-estimated sense of the velocity at which the development team is progressing. Unfortunately, it is not as simple as the team picking up where they left off and completing the unfinished pieces before a customer release. Leaving loose ends in each iteration (sprint) is actually a compounding problem.

A team that consistently falls short of “done” ends up with a required stabilization stage which lasts much longer than the sum of all the missing elements from each iteration. The problem is easily rectified by allowing the development team extra time per sprint (short-term) in order to dramatically reduce the stabilization stage and save time in the longer-term (release).

Another nice side effect of slower velocity and increased amount of “done” per iteration is that the code base staves off the complexity that naturally slows velocity over time. Thus velocity can be maintained at a higher rate over a longer period.

Customer Development

I am in the early stages of a new start-up idea so I am poking my head up to look around for the latest best practices before getting underway.   I was referred by some friends to Steve Blank’s  idea he calls Customer Development. It’s not brand new, but it is certainly far from mainstream yet.

Not only do I feel that Steve’s framework is right for my start-up, but I was also compelled to write a blog post.  During my research I found a post so well written that I knew it was better to link out rather than write a new one myself.  Therefore, I highly recommend Jussi Laakkonen‘s post called “Customer Development or why 9/10 startups fail“

Please note: just talking to your customers (focus groups) about their needs is NOT customer development.  You need to actually try selling to them and see what happens.  Steve suggests that selling should be brought as far forward as possible in the process.

I have begun forming my customer hypotheses.

1. I will test my hypotheses by talking to a variety of customers (not too many)
2. Building simple iterations and seeing if early adopters will use/buy
3. updating my hypotheses and iterations based on what is learned from early adoption
4. Developing a larger marketing push once adoption/return is clearly good enough.

Agile IT Methodology

Click on image for larger version

This post is all about IT.  There is no doubt that IT can have a tremendous impact on business, but if IT stuff makes your eyes glass over, might be best to select a different post.

Some Background:

“Waterfall” has been and is still the primary methodology for IT development.   It consists of a series of phases (eg. Strategy, Requirements, Design, Development, Testing) that are each completed in serial in order to reach a release.  The next phase in the series is not started until the previous one has completed and been “accepted”.  

Agile (in a nutshell) is an alternative that seeks to mash all the phases together and iterate through smaller blocks of functionality

Analysis:

Agile has been around since the mid-90′s.  Even with Google leading the charge with the concept of perpetually improving beta, we have not yet seen Agile take over as the de-facto standard.  If you ask the bulk of consultants at large IT shops like IBM or Accenture, they will tell you that they are primarily still using a waterfall methodology.   There are a few conclusions that may be drawn:

1. Agile is mis-used
2. Agile is inferior to waterfall
3. It is difficult to transition from waterfall to agile

re: #1.  I have come across MANY people who say they are using Agile methodology, when in fact they are involved in chaos with no clear direction.  Projects like this give the methodology a bad name.  Just because you are not building huge requirements documents does not mean you are “Agile”.  It just means you are not “Waterfall”. 

re: #2.  I have also come across many IT professionals whom I respect greatly that sing the praises of “Agile” and confirm that their teams are far more effective with that methodology.  That is just proof by example, but likely you can point to similar examples?

re: #3.  I think that adoption difficulties are the crux of the issue.  Agile sounds simple at its core, but to really get it right, requires a lot of attention, a lot of focus, and complete buy-in from the entire team that they are going to interact in different ways than they ever have before.  They have to be willing to open the kimono and let everyone see their issues at all times.   This is a change management challenge.  Teams need to be willing to improve upon the process with each new project and not give up along the journey.

What experiences have you had with Agile?  Why has it not seen wider/faster adoption?

This post was inspired by a phone call that I had with Shaheen Hossain.  He is an Agile/XP coach and a scrum master.

Some resources you might find useful

• A 68 slide deck on “Responsibilities and Challenges of the Agile Product Owner”
• A paper on “Usability investigations for Agile user centered designs”
• A very comprehensive blog post on “Agile Development is more Culture than Process”