Monday, November 10, 2014

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 probably resort to mockups and we might want to spend as little resources on shoving it out as possible. If we can salvage some code from the mock prototype for the final project - cool, but I wouldn't count on it.
We may borrow apply techniques such as Rapid Application Development to put out one or more prototypes and set the stage for the final product.
Spending more than a few man-weeks on a prototype is probably already the death of our project, so we need to do this in a cost-effective and highly disciplined manner.

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.

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.
The main purpose of the MVP is to obtain fast feedback from users about what we have built so far - and what we should be building next!
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 the Walking Skeleton is a great basis for the MVP, there are sometimes reasons for building an MVP which doesn't even meet Walking Skeleton functionality.

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 there is no measurable ROI for investors yet.
The value of the MVP is close to Zero.
Because of this, the startup phase must be minimized both in cost and time. Chances are if you take more than a few months to leave the startup phase, you require a lot of goodwill from your investors.
For your own sake, if you can't see yourself reaching the MVP anytime soon, rather 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 play. 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 stories 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 now fully matured.
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 critical features and most things to be done are merely extensions of existing features.
Since 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, since the criticality is low, funding may be reduced.
Agile practice recommends shrinking the team(s) at this stage and moving some resources 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.

The agile product lifecyle is mostly driven by value: You must always find fast ways to deliver more value. Every product type described above has different objectives, but all can help the team succeed.
Different aspects of agility become relevant in different stages of the lifecycle: Initially, XP practices determine "make or break" - during the bulk of the project, Scrum is a great framework and in later stages, Kanban comes to rise.
You should never be overly focused on a single agile framework. Always look out which approach helps you deliver more value. Be ready to transition!

No comments:

Post a Comment