Agile: shared experiences

Something I heard the other day: "Deadlines are oppressive and we should never commit to them". That got me thinking about some of my experience and I instinctively didn't like the over-simplification of this statement. We should always remember that things that worked for businesses in the past, but are frowned upon in the approach you are using, may still be valid for your business and team. I don't think it is healthy for us to think we now know everything, after all, rather like advice on what to eat, sometimes old things that we stopped doing turn out to be good for us. Some of this may be against the current flow of thinking, but I think people should always question every hypothesis presented. Here I try to make the case for and against deadlines in the hope that people open their mind and continue to try new and old things. The case against deadlines Let's face it deadlines are not the flavour of the month, well century! Waterfall style developm

One of the keys questions facing teams developing customer facing application is how to avoid developing something only to find that it isn't needed. A 'traditional' backlog often fails in this regard as it is a list and as such is: Hard to visualise individual features not related to a customer journey or goal. Can lead to a waterfall style analysis with little testing of ideas Leads to the highest paid person in the room dominating what should be done next Does not engage with people effectively A training exercise to build an ecommerce site - Could we use this approach in the 'real world' Recently I was asked to help with a project as a Product Owner and I wanted to use a new, rapid and iterative approach to design. I had experimented with Customer Centred Design for some time and wanted to run a follow up experiment. My hypothesis was base on some training I did with teams unfamiliar with developing a product in an iterative way.  The trainin

One of the biggest issues with backlogs is deciding what to keep in and what to take out. If you say to your customer something like "imagine this is the last sprint, what would you choose?" the business sponsors tend to know, in the back of their minds, that this is, usually, not true. Therefore they don't really make hard choices. I recently completed a couple of projects where we used different approaches to this problem. Both of these focussed on discovering a minimum viable product and a set of releasable customer journeys. The snake approach The first technique was based on the backlog snake idea. This is where you print out the backlog and make a long line around the room. The key part of this is to establish various key points along the line. I have a nice video of this here: Another technique I used here was to use self organisation to maximise the sorting. Here I give an objective to achieve and don't say how to go about it. The

A while ago I was looking at prioritisation of the backlog for a client. There was an issue with quantifying value and I was getting the sponsors to start thinking about it. I had done this a number of times and it usually went like this. Me: "Please sequence the backlog in the order  you (the business sponsor usually) would do first." The first question is usually "is this one bigger than this one, because if it is we will put the smaller one first."  That made me think of return on investment, after all that is what we are delivering. I was planning for a prioritisation session and wanted to visualise how I explain the trade off between value and effort. So I drew a chart (see picture), one for each channel web and voice. I could imagine using this chart for a quick assessment of a new channel perhaps comparing a Facebook page with a web re-design, if the graph is shallow, all the better; if steeper then perhaps develop later, if at all. Also I c