9 Agile Tips for creating successful Customer Journeys

I first encountered Agile in 2000 when I implemented the DSDM methodology on a project for a large multinational computer manufacturer. My experience since then has invariably been that whilst many large organisations claim to be agile, the truth is that they almost certainly aren't and I see the same behaviours repeated over and over. Agile is not just a develpoment framework, agile is a way of thinking, it's an ethos, a state of mind. I often wonder how many agile practitioners are truly familiar with the Agile manifesto. I wanted to write down a few tips just as food for thought. I'm sure that some of you can improve these so please do.

1. Don’t expect fully leveraged Agile results if you can’t commit 100%
   
   There’s no such thing as being ‘a bit pregnant’ and there’s no such thing as being ‘a bit agile’. Agile needs commitment from the very top to fully deliver on its promise. Organizations that claim to have a ‘semi-agile methodology’ usually lose all the benefits of their agility by losing their ability to embrace change.
   
   
2. Design with the Customer in mind
   
   First and foremost you are building a product that your customer finds useful and that will hopefully surprise and delight them. This means harnessing customer insight from day one and continuously feeding it back into journey design. Understand all your customer’s needs and design/build accordingly. Don’t obsess with alignment to existing core capabilities but remember it’s good to challenge existing perceptions. Henry Ford said “If I had asked people what they wanted, they would have said faster horses.”
   
   
3. Don’t boil the ocean
   
   Don’t try and cram everything into the first product release. The more loaded the release the greater the risk. Apple thoroughly proved the technique of releasing a Minimum Viable Product. We do what we can, given what we know. The impossible we do tomorrow. Build iteratively and always use MoSCoW to establish priority and groom the backlog
   
   
4. Build a Facade
   
   Design should be UX driven and clickable prototypes should be used to establish what the product looks like to gather initial feedback. Let colleagues and select customers use the prototype early and drive out problems upfront. Don’t rely on paper designs to drive out key questions and assumptions. Giving somebody a deck of cards won’t help them understand the rules of poker.
   
   
5. Don’t incorporate any technical or system constraints when initially designing customer journeys.
   
   Everybody needs to clearly understand the intended design, the value it delivers and its ethos. The organization can’t collectively understand what you are trying to achieve if they are presented with what you think you can build as opposed to what you would like to build. Integration is a lot easier if the integrators can see the interface they are integrating.
   
   
6. Don’t obsess on sprint duration
   
   Two weeks is not a mandatory sprint duration. There is no rule that says that a sprint can’t last a month. Longer sprints may be needed to knock off some of the bigger/riskier pieces of work up-front. Once the backlog is better defined and more granular you may wish to think about reducing sprint times to two weeks or even a week. 
   
   
7. Don’t give in to waterfall development
   
   Agile is all about providing ‘just enough’ information to let coders code. That doesn’t mean providing detailed field descriptions or signed off specs. There are plenty of collaboration tools out there to maintain a dialogue between product owner, developers and testers. If your developers and testers aren’t comfortable with this then some retraiing would probably be in order.
   
   
8. Remember, the Agile has to be sustainable
   
   Agile isn’t an excuse to cut corners. If it looks as though quality is dropping then it’s absolutely vital that the backlog is effectively managed and kept at the correct level of granularity to ensure deferred functionality makes it back into sprint. Sprints have to deliver shippable product that means working screens….not PowerPoint with screenshots
   
   
9. Make retrospectives count
   
   Don’t waste time identifying shortfalls in your approach if you aren’t going to do something about them, Once a problem is identified it should be permanently dealt with and not greeted as a familiar friend every time it re-appears. Build quality in and waste out by pro-actively addressing obstacles.