Six types of Agile Products

We're Agile now. We don't need a Project Plan any more, we're freed from deadlines and we don't have to work off predefined requirement lists any more. Yay, this is gonna rock!

Let's go for it!

Not so fast, young Padawan!

Agilists don't abolish processes or planning. When we say that we value adapting to change over following a plan, it doesn't mean we don't plan!

Agile projects might be even more rigorous than any traditional project you have ever worked on!

They are set up differently. Nobody went out to obtain a $100m funding up front, "be seeing you in 5 years with the results". (And nobody in their right mind should fund a project like that!)

Agile's "Inspect and Adapt" follows the decades-old acronym "WYSIWYG": you get what you see. 

This goes both ways. The project will not continue to receive funding when there are no more results!

So, before you go out on your next hackathon, be prepared to deliver as much as possible at any point in time.

Agile products grow over time. There are four primary growth stages of agile products:

Seed - "We know what we want to produce, but haven't really started"

Startup - "Here is what we're working on"

Initial - "Go ahead and use it - we know there's still lots of things we must work on"

Mature - "If you want more, you gotta pay for it!"

In the seed phase, the stakeholders come together and define the product vision. At this time, we may have a project homepage and a project team, but nothing to show for. As a newly formed venture, we might go to Kickstarter, but we need a compelling reason why anyone should fund us.

Actually, unless we have some proof that we can do what we've set out to, chances are we won't get this funding. So, we need to produce something to get an initial taste.

There are three things we can do, we don't need to do all but we should pick our options:

The Mock Prototype will give the stakeholders and future customers something to connect our vision with something more tangible. It will give them an impression of what may one day be - and it will give us an impression of whether we're aiming in the right direction!

In the mock prototype, we'll usually resort to mockups and we might want to spend as little resources on generating it as we can. If we build some code from the mock prototype, we might even salvage some of the code for the final project - although I wouldn't count on it and in many cases even advise against it.
We may borrow apply techniques such as Rapid Application Development to put out one or more prototypes and determine what the product could look like.
As prototypes are built to be disposed after they achieved their validation purpose, if you spend weeks on a single prototype, your project is probably already dead, so we need to do this in a cost-effective and highly disciplined manner.

We leave the prototyping phase once we have a validated understanding of what we actually want to build.

Once we know what we'll be building, we should produce a Walking Skeleton that features most of the end-to-end components of the final product. For instance, we might produce an application consisting of a webserver, a database and a web frontend. It's not going to do anything fancy, but that's not the point of the skeleton. We want to know if we have the right means to get the job done. Filling in the functionality is for later.
Let us use an example on this: If we are trying to build a data mining application, but already fail at the "store data" part because we can't maintain our data, we don't need to worry about building a nice user interface or tuning performance.

We leave the Walking Skeleton phase once we have a validated understanding of what resources and technologies help us build our product.

As soon as we have a reasonable amount of certainty that we can make our vision real, we should work on the Minimum Viable Product.
The MVP is a usable piece of software that does something in line with the product vision, so we are talking about working software produced using good engineering practices.
Because of this, the Product Owner has to make some seriously tough calls on what should be part of the MVP and what not. A good PO should never fall for the temptation to load the MVP with features - in this stage, less is more!

While A Walking Skeleton is a great basis for the MVP, there are often good reasons for building an MVP which doesn't even use any Walking Skeleton.

While we can "alchemize" on the Prototype and to some degree even the Walking Skeleton, we need to have some form or engineering framework in place to produce the MVP. As the product is just in the startup phase, Scrum is a perfect methodology to build up both the team and the product simultaneously.

At this point, take caution that effort was already invested, but you still have nothing to show. Even the value of the MVP is close to Zero, its value is in the learning rather than in the bottom line.
Because of this, the investment into an MVP must be minimized both in cost and time. Chances are if you take more than a few weeks on an MVP, you risk a lot in terms of "building the wrong thing".
For your own sake, if you can't see yourself reaching an MVP anytime soon, just let the project die!

You want to get into the "Initial Market" phase as fast as possible.

This phase determines everything for investors. A good product will start generating revenue in this phase, because you have a Minimum Marketable Product, something that you roll out "ready for use". You want people to actively use the MMP for more than some fiddling. If you can't get customers hooked to the MMP, you might want to cancel the project, because it will most likely be wasted effort!
The transition from MVP to MMP requires delivering the most critical items in your backlog as well as continuously staying in touch with the customer base in order to refine the backlog.
Techniques such as A-B testing will give you feedback on how customers like different approaches to new features.

If your engineering practices are still lacking in the MMP phase, you will most likely kill your product due to technical debt sooner or later.


Let's hope your project has survived the MMP phase and is sufficiently mature to enter a maintenance routine.

A mature product has an established customer base and should have generated sufficient ROI to make the investment meaningful. At this stage, the backlog no longer consists of any release-critical features and most things to be done are merely extensions of existing features. 

When there is nothing which must be added to the product, it is no longer essential to follow a rigorous short-term delivery routine such as the Scrum timeboxes. Also, when the criticality of further extensions is low, funding may be reduced.

Agile practice recommends shrinking the team(s) at this stage and moving on to more critical projects. The reduced team is mostly in "maintenance mode" and occasionally produces new features, so Kanban may become the team's preferred delivery framework.