Posts

Agile is not different words for the same thing

Image
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

Consultancy, an Agile Anti-Pattern?

Image
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

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

Image
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

Great leaders respond in adversity

Image
How many times have I seen a product about to launch when someone comes along and says, "What about X?" or "Has that been approved by Y?" The result is a delay, more work, high emotions and often a scapegoat that takes the blame for missed deadlines. When things go wrong management tends to respond in two ways: They hide away and hope the monsters won't be there when they peep over the covers. They stand up in the full light of day and say, "Right, what do we do right now to make it better?" Depending on the culture of the organisation, those in the first category may believe it's best to work from home, not reply to email, keep your head down. Another response is to start the Machiavellian machinations as the "heads must roll" politics begin. Some managers even start looking for a new job as soon as the project starts to fail.  All of these actions are based on self-preservation: recrimination - passing the blame to someone

The Empirical Manifesto - taking continuous improvement seriously

Image
Recently I have been using the scientific method in a small team in a large program. When I say using it I mean all the time. Previously I paid lip service to an empirical approach, but I decided to make it the base of everything the team do. In this I was quite lucky that the team I'm in were keen and immediate management didn't resist. I am working in an environment where we are a snow-plough for a whole program. We don't know what does work, wont work, how to do things, where to sit etc. May sound familiar.  Our response was to Guess, Test and Refine really rapidly. Scrum says Inspect and Adapt, but this is not enough, in fact it isn't science. This is one of the reasons I was not getting hard evidence for what I was doing and sometimes had to persuade stakeholders to go along with what the team were saying - "Just trust us, we've done this many times before". Clearly this is subjective and open to challenge and rightly so. It often means change 

In sprint cumulative flow in Jira

Image
I wanted to experiment using cumulative flow in Jira on a Scrum project. I tried it on my last 2 projects, the first time manually and the second time using Jira. We found it was a good addition to Burndown charts. I also found that it was a great predictor of completion. It also exposed work in progress (Inventory) and start to end time (throughput). In Sprint Cumulative Flow It is one of the tools that I use to reduce reliance on estimating. It was labour intensive when done manually, however it was zero effort to maintain in Jira, just a bit tricky, so here are the steps How to do it? You need to go to Board configuration Click on Configure then select Quick Filters and create this filter: Click the "Add" button then select your Agile Board and Select Reports: When you have done this select the Cumulative Flow report as follows: Now configure the report to set the start and end dates to match your current sprint as

Time to Think

Image
Don’t you sometimes feel you are so deep in what you are doing that you don’t have time to think? Being a contractor I sometimes get periods to myself where I am not working full time. I recently came off a stint of 18 months of back-to-back contracts. I didn’t have a day off sick and only took one day of holiday in all that time. Surprisingly, I wasn’t exhausted, but felt something was missing from my life. So during my current downtime I decided to renovate a property and catch-up on some learning. I finished the renovation, read some books, wrote some blogs, watched some TED talks. What I didn’t understand, until today, was how important this time has been to me; the hurly burly of project life often seems to preclude self inspection and improvement. My unconscious goal was to pursue neglected areas to be able to look at challenges in a new way. So I thought I would put down some things I’ve learnt about myself over the past few weeks including which techniques made my l