Showing posts from 2017

Agile is not different words for the same thing

A conversation today reminded me of a couple of years ago. We had the idea of having a "thought for the day" and I popped this one on a whiteboard:

"Thought for the day
A Product Manager is like a mother A Project Manager is like a foster parent"
They both care but you know it's different.

Today's question: "Surely agile is just the same as any other way of running project. Just different names for the same things"
Answer: "Well maybe not, lets take a step back and imagine there are no more projects, only product teams.

No project managers, no project framework, no approval through project gates, no project boards, no project directors, no PMO, no documents for project ceremonies.

No boundaries between people working between different parts of the same product, no reason to farm out work when peeks are high, no reason to move all the time, a time to work with the same people and become really good at what you do together. No silos of the delivery…

Consultancy, an Agile Anti-Pattern?

As part of looking for my last few opportunities, I became concerned about the number of “agile coach” roles that I saw advertised at consultancies. First of all a confession: I used to work for a consultancy, but recently I decided not work for one ever again. I was feeling pressure to act in a way that didn't align with being a Coach.

So I decided to jot down why I had reached this decision.

How Coaches and Consultants fit in A Consultant is great for:I don't think there is a problem per se with consultancies, they have a big part to play. Often where organisations don't have the specialist skills required to work on a particular problem, or where the problem is not their core business. In this case it seems reasonable to hire a consultancy, who bring in a team with the knowledge and experience required.
A Coach is great for:The coach role is quite different. These are individuals with the experience, knowledge and skill needed to bring out the best from others. Coaches w…

User Stories and Use Cases - a pair of agile red herrings

I would like to start a conversation around User Stories. I am finding their superficial adoption meaning there is more and more admin and less and less useful understanding in teams.
User Stories are a bit of a dead end. They were originally intended as provoking a conversation and the structure came later. They have become de-facto standards for documenting requirements without generating discussion and understanding.
With User Stories I find that people don't understand: the "As a" part whereas "Actor" is much clearerthe "So that" part and interpret this any way they wish
So they just fill those bits in any old how and describe the functionality in the middle. All the User Story mapping nonsense is just filling in the gaps between isolated conversations.
They get too big and then they are “Epics”; another term that needs to be described and de-bunked. “epics are themes” “no themes contain epics” "but stories have themes and are part of epic…