Working in hands on Agile environments since 2004 I've coached software teams from inside & outside. I believe that the great work coaches and scrum masters do inside their teams is often lost to the inefficiencies of the larger enterprise (the machine!). This blog talks about issues of enterprise agility, local v global efficiency and emergent/ organic delivery models
The MVP Onion
I've been in some workshops recently where confusion arose around what is MVP in practice.
Its seems like there are many different interpretations of MVP and often that interpretation is determined by :
1. Risk tolerance
2. Type of feedback required
The ruthless MVP of a fledgling startup company might be far too precarious for a traditional financial company. They may not be able to launch a streamline MVP that doesn't satisfy compliance or regulatory standards. When these requirements become part of your "minimum" then your delivery grows beyond basic VIABILITY.
If you're launching a new product, you need feedback that tells you if customers need the product, do they want the product, will they use the product, will they like the product.
Sometimes you might be using a new technology stack or trying to build something that hasn't been built before. In this case you need system feedback . Do the minimum you can that will prove you can build the product. It might be too rough and ready to launch but tackles your technical risks first. If you cant build it then there's no point in thinking about what will delight the end users.
Different Layers of MVP
This probably won't satisfy the purists but what i came up with was an MVP onion (nod to Simon Powers of Adventures with Agile - this onion is a homage to his Agile Onion!)
I found that this really helped people who were trying to reduce the scope of their initiatives to something that was more like an MVP but couldn't quite fit to a ruthless MVP due to organisational constraints.
I've also include the good old "Walking Skeleton", which is possibly even a subset of the leanest MVP. The minimum you can do to hang your product together functionally.
At all times remember that you should build your product up from these principles, iteratively.
You don't have to release your walking skeleton, but you should build it first. you don't have to release your MVP but you should build it, and then you have options around whether you should add more or not
After seeing yet another "Agile coach bashing" thread on LinkedIn I felt the need to blog my perspective. As a former Scrum Master, I now call myself an Agile coach. Here is my two cents. Who's bad? The trend I see is for some Scrum Masters to paint anyone with the title "Agile coach" as greedy, money grabbing consultants that don't know what they are doing. They only exist to suck money from large organisations who don't know any better. They label themselves as "Agile coaches" so they can charge out at a much increased day rate. They are the bad guys, while the paragons of virtue are the scrum masters battling away in the trenches, refusing to sell out & change their job title for the sake of a few extra bucks a day. Let's start with some basic logic. Bad agile coaches exist. This doesn't mean all agile coaches are bad. Bad scrum masters exist. This doesn't mean all Scrum Masters are bad. Whats in a title? L
Many moons ago i wrote a post about the use of epics. How to visualise them and use them as a starting point for large project decomposition ( read it here ). The world has moved on a bit since then but still I see people I work with struggling with some of the same issues. How to break big projects down into small, valuable, usable chunks that can be delivered quickly by development teams. In my previous post you can see how the epic user story is a stepping stone to reaching smaller, valuable user stories. These days I seem to be discussing Features a lot more with people. Epics v Features To begin with I find there is confusion around Epics v Features. Note: The Epic I refer to here is the original Epic user story, before SAFe decided an Epic was a different thing altogether What are they & Whats the difference? How are they different to user stories? What size are they? Let start with addressing these questions What are they & what's the difference?