Agile: shared experiences

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: Being in a Product vs Project mindset  " 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 an

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. Helping teams and the business as a whole perform better A Coach is great for: The coach role is quite different. These are individuals with the exper

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 clearer the "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 an