AGILE must be destroyed, once and for all

Interesting comment by Tim Anderson on Erik Meijer's outspoken words.

Happy to discuss.

MVP...MMF.... seriously good way to get new software out there, and realising business benefit quickly.

So far, so good. But... I have seen these terms being abused quite severely.

Minimum Viable Product, does not mean, "Cut corners and just get it out as quickly as possible".

It is not "Minimum Quality Product". It is not "Minimum Coding Standards".

It may be the minimum set of features to start delivering business benefit, but there is no point in delivering something that cannot grow, and scale without major rewrites. You want to see if the product is worth further investment, but you won't get that by shipping sh*t as this blog points out. 

Decisions, Decisions...

Had a bit of fun with the team today, playing this game from TastyCupCakes.org.

A group of celebrities are trapped on a sinking ship. The team can only rescue one at a time. They must decide, what order to rescue them in.

It's good fun, and it touches on a number of interesting points about how we prioritise. This applies, not just to sprint planning, but also how we work as individuals.

The team quickly realised that they needed to identify the "must haves", and soon after that, the lowest priorities. The most time was probably spent on the in-between.

In practice, we can get started rescuing the top few, and make a decision later on the middle few once we know a bit more. If that goes well, we might even save a "z lister".

Justin Bieber didn't make it I'm afraid.

Tell me the Problem, Not the Fix

An interesting take from Rick Austin, on providing teams with enough context, so that they can meet the business need. As opposed to Product Owners defining solutions...

"When we create new products or add new capabilities to an existing product, we typically do so in an effort to solve a problem. These product updates may often happen by delivery teams being told to go build these features without a clear understanding of the problem being solved. "

More here: Do you know where you are headed?

Thanks to Kelly Waters for flagging that one

The Myth of Certainty

I've posted before about "uncertainty" as an indicator for estimation. I have also been reading some blogs & tweets on how estimation is pretty useless. Check out #NoEstimates or have a look at Vasco Duarte's blog.

I can certainly sympathise with the views being discussed. People have an overwhelming desire for certainty. It makes us comfortable. But, what does certainty look like? Some of my colleagues, past and present find that only dates and numbers provide that comfort, in as much as they insist on seeing the number of story points for a project up front.

This is pretty useless in reality, as we are pinning our hopes on something that is not particularly reliable. The first thing Ken Schwaber said at my Scrum training back in 2005, was that "estimates are always wrong".
"So", ask the #NoEstimates tweets, "why do we still do estimation?"

If it is certainty that we crave, we should be looking for predictability. Team velocity was one way the Agile community tried to increase predictability, but that wraps an artificial concept (i.e. points)around measuring output. There seems to be some momentum around doing away with story points altogether.

If a team is focused on delivering value, they should always be giving the customer what they need nice and early. Agreeing the MVP or MMF is a good start. Then the team should be breaking down their stories into chunks that they know they can deliver within a predictable time-frame e.g. 1 day. Because they do this, they know that they can deliver, say, 10 stories a week. It is proven, and predictable.

I am going to watch this debate with interest.

Test Early and Test Earlier...

Where does the testing process start? It is quite a change in mindset to get away from the concept of testers as "Defect Police. I've had a good few battles and it can take a long time to alter behaviours.

My mind is drawn to a conversation I had about writing test plans before development started. The QA in question looked shocked. "If the developers know what's going to be tested, they'll just write code to pass those tests. How will I catch them out?" It was then my turn to look shocked.

To me the role of a testing is way broader than catching out software engineers. If anything, they are the guardians of the product. Nothing should adversely affect the product, be that defects, or badly thought out requirements.

We do story analysis "just in time", rather than spending hours in painful and (I would argue) less than effective planning sessions. However, that does not mean that we should rush things.

It is important that we QA the story itself, before we start thinking about how to implement it. Testers have the expertise in finding the cracks. Looking for the edge cases, asking "What if..?". They should be looking at stories and asking the difficult questions, so that Product Owners are confident that their needs are being met, that there is a likely ROI, and developers are getting requirements with clear aims and without ambiguities.

London Lean Kanban Day March 2013 Part 5

I've already spoken to folks about the way Spotify work with teams, but Anders Iversson added a little depth to what I'd already read.
You can download a similar presentation from here.

This then segued in to the keynote speech from David J Anderson.
The talk generally centred around the ideas in this earlier presentation
Not that I like the idea of measuring how Kanban we are, but you could get team members to identify where we are in our journey, and compare notes to see where we need to strengthen.