Scrum Master or Agile coach

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? Lets start with Scrum…

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

Risk tolerance 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.

Feedback Requirements 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 …

Why you need WIP limits

Why is this crazy person telling me to limit my WIP? As an agile coach I often come across situations where I need to encourage teams to reduce the amount of work they have in progress. Even though it sounds and feels counter intuitive to do less work, the fact is your team will get more DONE by doing fewer things at the same time.

Activity != Progress
In our scrum teams we naturally tend towards keeping everybody busy. Developers working on development tasks, testers working on testing tasks. History has skewed our mental model of what people should do at work so that we feel like we should always be busy, always processing work. 
This is a good model for the mass production of widgets or the processing of mountains of paperwork BUT a bad model for the production of complex, functional, high quality software.
We use user stories to represent units of complex, functional, high quality software and in scrum the game is to finish a number of these units every sprint. This goal is often…

Super Stories .... Features to the rescue!

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? The  way I see it?  The…

Agile is a team game

Agile software development is a team sport. I see so many issues when working with software teams that I have also come across in a sports team context. Teams are collections of people and to get a collection of individuals motivated and organised to achieve a common goal is not easy. I am convinced there is much we can learn from  the sporting arena to help us perform better as software teams. One example is the concept of Individual efficiency vs group efficiency.
Individual v team efficiency
A lot of what is important for the success of sports teams is also valuable for software teams. We create teams with a view to the Team achieving more together than the individuals would on their own or because the task/ deadline before us is unachievable without extra man power. 
Example: Amazing footballers like Lionel Messi, Cristiano Ronaldo, Diego Maradona could not  achieve anything on their own, they need to operate within a team structure to achieve any great success

Often organisations are…