How agile are we?

"Hey, we're doing Agile now!" - "We too, but it doesn't work".
How often do we hear this? Too often.

Not everyone who has put the term "Agile" on their IT strategy is doing the same things. More precisely: Everyone understands something else under the term "Agile".

As others have pointed out, "Agile" requires more education than a 2-day training course for prospective Product owners and Scrum masters can provide.


Here is my suggestion for an Agile Maturity Model of Implementation (AMMI).

Agile performers

You can't really predict what their practices are, and frankly, they don't even care so much about specific practices or processes. What they care about is: Valuable software and happy customers. Everything else is subject to that and negotiable.
The main thing they have in common: They thoroughly understand the reasons why their processes and organizations look the way they do.
These performers are the reason why the Agile Manifesto is so short.
They follow, what could be called a "Scientific truth" (credit: Paul Oldfield). They experimented, adjusted and have gained confidence that their current approach is the best way at the current time. Gaining evidence that other approaches will yield better results, they will quickly move on.

Agile transitioners

When getting into a transitioning company, you can most likely predict their processes and organization based on subject literature. You could update the "Scrum Primer" accurately by taking pictures of their ceremonies. They're seriously trying, and probably seeing some improvements over their old methods of working.

Most likely, the way they are doing things is highly imperfect, but hey - empiricism means learning by doing!

What transitioners often have in common is that they lack deeper understanding of how to optimize their agile practices. 

They follow, what could be called a "Political truth" (credit: Paul Oldfield). They were convinced by someone that their current approach is the best choice.

Agile cargoists

"Man, we've been Agile for a year now and nothing has improved! We're doing everything exactly how Spotify is doing it, but ROI hasn't improved!" - Agile cargoists religiously follow prescribed patterns in hope of results. Unfortunately, these never turn up. 

Cargiosts, at first glance, look like transitioners. The big difference is that their Continuous Improvement Process is either political in nature (i.e. the team is not empowered to change) or fad-driven, i.e. researching what others do. 

They follow, what could be called a "Religious truth" (credit: Paul Oldfield). A reputable source claims that this approach is the best, hence it must be so.

Non-Agile

The entire spectrum between "Don't know about it", "Read about it, but it's not for us" and "Tried it, didn't work, we're back to classic project management". 

Agile by Name Only

Get into an ABNO and you will find tons of Project Managers dressed up as Scrum Masters and Business Analysts / Architects vested as Product Owner. 

Most likely, projects start with a Feasibility Study, Requirement Documentation, Budget Planning and Detailed Design before ever involving an "Agile developer". 

The "Agile transition" in these companies was fast and painless: Managers were sent to a 2-day training course, the titles on business cards were adjusted and voilá: A new agile all-star is born!
Agile culture are at best random elements, but not the norm.
ABNO's usually blame Agile for being ineffective and give the entire approach a bad name.
Transitioning an ABNO into an agile organization is probably harder than teaching a granite block how to swim.
The best thing about ABNO's is that they will return to the Non-Agile department sooner or later: Most likely after firing most of their "ineffective developers". At least, they'll have plenty of managers left.

Slicing and dicing user stories

To really understand the effect that the Product Owner has on the success of Agile development, it is vital to understand the art of creating good user stories to deliver results.

As was mentioned in a previous post, a poorly chosen user story will make it tough for the team to deliver, wasting time and potentially effort with poor control over the investment. On the other hand, a well chosen user story will support the early delivery of valuable results.

The creation of good user stories depends on a technique called "Slicing", i.e. preparing user stories in a fashion that they become immediately useful once completed.

Horizontal slicing is bad

A poor approach to slicing is cutting a huge story into horizontal slices. Let us use our "World Hunger" example to explain this approach:

We may want to resolve World Hunger in the following manner:

1. Obtain enough food to feed the entire world
2. Gather enough volunteers to distribute this food in the entire world
3. Establish the logistics to accomplish the distribution process
4. Obtain political support (permission, visa, military/police protection) for the distribution

Let us just assume that we had successfully completed steps 1,2 and 3 - but we don't get permission!

We have everything in place, yet there's a bunch of nuts sitting in well-furnished offices who block results for whatever reason or maybe for no reason at all.

While we gind our teeth in frustration and our supplies spoil, people continue to starve. 

A whole lot of resources were wasted, a lot of time was spent - yet there is no visible result!

What happened? Dependent layers were built, and all activities on one layer depend on another layer for success. We can't even know whether our concept works until all layers have been completed, well - at least to some extent. But until all layers are achieved, there is always this looming sense of failure.

(When this happens in the corporate world, you would find some CxO closing divisions, cutting funding and whatnotever that is bad for your career.)

Delivering with vertical slices

As previously discussed, a vertical slice is intended to deliver fast, with limited scope.
"Feed one person for one day" is a limited task, it produces visible, measurable results and permits scaling.
The result from "feed 1 person for one day" is visible and can be subjected to Continous Improvement. Each day, each person contributes to success and regardless of how far we get, the feeling of accomplishment stays with us.

Once 1 person has been supplied, we can enlarge the process to feed 2, then 5, then 10.
All of a sudden, we will see that we are more efficient by centralizing the supply process, so we set up a user story like "As food distributor, I would like a central place where I can always pick up the food baskets so that I save time in getting food to the Needy."
Once we reach 100 people fed, we may get into stories like "As charity, we need media coverage, so that we can obtain funding to feed another 1000 people"
These stories are again, limited in scope, provide a good measure of success and can be completed in a limited amount of time.

Maybe we need to rework our former approach (by Refactoring) but maybe we can just continue doing things as before.

Summary

Lean identifies multiple types of "Waste". One of these types is producing stuff which we can not use yet ("Inventory"). Another type is producing stuff which may never be used ("Overproduction").

Well-sliced stories which resolve (or even better: eliminate) dependencies on other activities serve the team in reducing the risk of delivering features which are not useful for a long time in the future, or - potentially never.

Good Story slicing positively contributes to the visibility and value of results and negatively, eliminates waste.

Therefore, the Product Owner is a key player in enabling team success.

Making stories manageable

As a Human Being, I want to end World Hunger so that there is no more hunger.
Wow, I've written my first user story and it's even correct based on the template. Now my team can get going and because they are Agile, we will have a solution in no time!

What? You have some feedback proposal? ... mmh, okay. :(

Well, poor stories are often "World Hunger Projects" and this one is no different: It's just being a bit more straightforward to realize.

Too many times, in projects I see stories like this one: As a user, I would like to see my data so that I can see what I have to do next.
And the poor developers are stuck with a mess and can't deliver at sprint's end!

Let's take the example of the World Hunger Story to practice a little bit of slicing:

User Roles

Human Being - hmm, that looks pretty big scope. What is your role in all of this?
Are you a human being who is in the fortunate situation of having excess wealth and want to share it? If so, you are a "potential donor".
You maybe the founder of a charitable organization dedicated to actively do something about hunger.
Are you "afflicted by hunger" and need food for yourself? In that case, your perspective is different.
Or maybe you're a "homicidal maniac" and propose dropping a few nuclear missiles on hunger hotspots. (Hmm, maybe as a PO I would pass on that story.)

By identifying different user roles, it becomes significantly easier to focus on what actually needs to be implemented.

Specific goal

Before we get into the What, we must be clear on Why we want something to be realized.
Well, "that there is no more hunger" sounds cool, but it's not all too clear. How can we tackle this?
Let's put ourselves into the seats of a charity organization.
We have a whole bunch of problems, to name a few:

• We need to have something to give to the hungering people of the world:
• Do we want them to have food for the moment?
• Do we want to help them obtain their own food?
• Do we want to resolve a specific crisis?
• We need to obtain funding
• How do we raise our funds?
• How do we manage our funds?
• How do we spend the money wisely?
• We need people with whom we collaborate:
• Do we need speakers?
• Do we need celebrity sponsors?
• Do we need skilled workers who are willing to go into the region?

Each of these is a specific objective to tackle - and even these may still be too big to tackle with just one team and within a limited amount of time, so we may want to get even more specific!
But let's just stick to one goal now.

Specific approach

So, now we are the charity who want go give food to the Needy.
A whole bunch of ideas may come to mind:

• Food baskets for the neighbour in need
• Soup kitchen in the metropoles of the world
• Shipments of wheat/flour/rice to central Africa

Putting it all together to deliver

Now we may create a much more focused story card:
"As a charity, we want to give food baskets to the neighbour in need so that nobody who lives in our community would have to go to bed with an empty stomach".

It won't really solve the entire problem of World Hunger, but it's a step, and you can have visible results in no time.
The team can brainstorm on the contents of the food basket, identify a needy neighbour - and maybe it can be delivered on this very day, working with real user feedback ("Thanks so much for the milk, but I'm lactose intolerant") and improve their strategy from there.

Summary

A good user story helps the team deliver visible results in a very short time without falling into the trap of missing the mark, running into Analysis-Paralysis and many other problems.
Good stories help the team deliver, motivate the team, enable Continous Improvement, allow the PO to check the direction of the implementation and adjust.
And most of all, they provide real value at a limited investment.

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.