ustwo Thinks 3 – Agile War Stories
The third event in our ustwo Thinks series saw a familiar, but still controversial, debate land in our studio. The use of agile methods in product development is well-known, and common practice, for many in our industry but when it comes to working with larger clients we face particular challenges in adopting and adapting ways of working.
We tempted people away from one of the last warm summer evenings for a while with Moscow mules and Cauliflower pakora, amongst other goodies, from The Ginger Jar.
It wouldn’t have been right without a personal intro from Collin – the happiest man in agile – who chaired the rest of the debate. He told us of his experience working to implement a CRM system between 2000 and 2005 for a large financial services company. With a total spend of 120 million dollars the project was nevertheless cancelled at its final go live date. Because nobody would use it. A depressingly familiar scenario, but one that has become less common over the last 15 or so years.
A quick poll of the audience before things got underway established that most people had either been in, or were expecting to be in, a project to bring agile methods to a large organisation. Asked whether they'd had a good experience bringing in agile, a majority of people said yes – showing that despite the challenges discussed over the evening, people in general had seen what good looks like.
The panel opened with their topline view of agile – what it meant to them. Doug, relatively new to agile at Ford, felt it had “been a real eye-opener,” and particularly valued “the ability to make rapid decisions [and] to empower the team.” Emily identified two key things – communication and learning. Kirstin felt that “agile really means flexibility. You can take the elements that apply to the situation and context you’re working in.” For Sam, agile “is about feedback loops and learning. Embracing those unknowns and not trying to solve everything at the start.”
Collin introduced the idea of establishing certainty, a common sticking point with large projects, noting that large organisations tend to want – at the outset – some clarity about what they’re going to get, and when they’re going to get it. How do you get senior stakeholders on board with this? Sam’s approach was to – if you have a team on a project for 6 months or a year – have them deliver to production from the first week or even first day. In his opinion, building trust through delivering working software well ahead of full release is key.
Emily outlined the transition in thinking required, in a place like GDS, to move power out of government departments and to groups of people working to create things according to what users want. In terms of tying in to legacy systems and legacy bureaucracy, her experience was that bringing in small groups of people to work within the organisation, but trusted to challenge it, was one way forward.
Kirstin talked about meeting in the middle: Running agile on her own teams but working with existing, waterfall client teams and taking a sort of ‘wagile’ approach. Running workshops at the beginning to bring stakeholders on board, decoupling the the start of the project from delivery, helped to build confidence. Doug’s past experience with a car concept would be to have a well fleshed-out idea of what the vehicle would be, up to and including the business case – and then to take this to stakeholders in order to get funding. With agile methods there’s the potential to freak people out a little bit, when they’re used to hearing this, more waterfall, kind of proposition. Showing early user feedback and insight helps to reduce that.
Collin had the panel think about pace and quality, and how tension can creep in when teams are looking to release early. Sam’s approach was never to sacrifice user quality – even if there is ‘rubbish’ tech underneath. “You can always do less,” he said. “By taking scope off the table you can keep the quality of the smaller pieces that you have at the standard that you need.”
In considering how to balance iterative releases with pressures to work to a roadmap, Emily suggested that “if you can create a roadmap based on delivering needs rather than features, then you’re onto a winner.” Placing user needs front and centre of a project, a key part of ustwo's approach, came up again and again over the evening.
The discussion moved on to look at what the most difficult challenges for senior executives to deal with are.
Emily thought that if you're not “bringing them along then you can't expect them to know what you're doing.” Change is hard, and she recognised that you're asking a lot of some people to change their mindsets and ways of working – you need to understand that.
Agile and strong product owners
A question from the audience asked whether there is sometimes a value to a very strong product owner, perhaps a Steve Jobs-type, who ‘knows better’ than the user and does agile prevent that value coming through? Sam's take was that that sort of vision could help, if it's balanced with the opinions of users. Crucially, though, getting those opinions through simply asking a user isn't really enough – it's important to show people your proposition, or product, so that they're not simply talking about what they already know.
As a follow up to that, another audience member queried the ability of users to communicate what they want, and for agile to deliver the big picture. His experience was that after a long process of including different wants and needs relevant to each sprint, people only really used 20 per cent of those in the finished product. Kirstin identified the role of, and the strength of, a product owner to maintain a macro-level picture when it's easy to focus solely on things at the sprint level – perhaps resulting in additional, unwarranted complexity.
Towards the end of the discussion, Collin brought things around to consider the approach when working with an organisation who might have tried agile and rejected it – what do you do when agile is a ‘dirty word’? Doug outlined the importance of the ‘newness’ of a project – saying that if “you're using agile for something that is new, novel and unique” then you might well be given the leeway to try it.
As the event wrapped up, Emily gave her opinion on the difference between subjective opinion and real user feedback, and how agile can give its backing to the latter. Basing decisions on user's reactions means you can get closer to answering the question: Are you delivering the right thing?
Overall, the evening pointed towards a very positive future for agile, with a recognition that on both ‘sides’ of the debate people need to appreciate that change takes time. Effecting a transition to agile is not easy, and entrenched views and patterns of working can be a challenge. But as companies, large and small, increasingly put the user at the heart of what they're trying to achieve – it seems agile has an ever-increasing role to play.
With so many organisations still being in transformation, and senior stakeholders operating under endless pressures the uncertainties of Agile are still going to create discomfort – but at ustwo we still believe it's the most effective route to failing fast and, ultimately, delivering the product your customers wants.
The next ustwo Thinks event will be on the evening of Wednesday 20 January at the ustwo London studio – if you like to know more, please email Nanci at email@example.com.
You can hear the full audio of the evening's discussion on Soundcloud here.