With rain lashing down and the November wind yowling around the streets of the City of London, intrepid Agile Managers and Leaders gathered together in the warmth of Code Node in search of greater certainty about uncertainty – and unicorns.
Following some restorative pizza and beer, the meetup began with IndigoBlue’s Head of Innovation, Stan Wade, providing a practitioner’s guide to Uncertainty Management.
Uncertainty Management: A Practitioner’s Guide
In the beginning, he began, was The Plan. And The Plan was good. Or so it seemed. Businesses craved certainty before they would invest in projects, and so people were obliged to produce The Plan with time and cost estimates at a point when they had limited knowledge about the work. This required big assumptions to be made in order to produce a heavyweight design up front. Once the project began, changes to The Plan were needed from day one.
The Agile revolution tipped the scales in the other direction. The best way to reject heavyweight up-front design appeared to be to do no up-front design at all – everything would be worked out during delivery.
However, design is still important – it’s just that a balance has to be struck. And that’s why Agile projects require Uncertainty Management.
Stan explained that there are three causes of project variance: risk (e.g. market/competitor movement), change (e.g. new business requirements) and uncertainty. Uncertainty is the set of “known unknowns”, to paraphrase Donald Rumsfeld. At the start of a project, there are lots of questions that you know need to be answered – but you don’t have to answer them all up front. You need to answer those questions that will allow you to get going and keep going – and then you can resolve the remaining uncertainty during delivery.
However, the uncertainty won’t magically resolve itself and you need an uncertainty strategy and plan, which will take into account:
- uncertainties requiring up-front resolution (e.g. choice of platform)
- factoring uncertainty into the stories in your product backlog and their associated estimates
- factoring uncertainty into your project plan (e.g. when to schedule staff training on a new application)
- changes required in the way you work (e.g. Stan referenced Hiive, a professional network for the creative industries, in which ways of working were adapted in order to prioritise the creative design of the site’s look and feel)
Stan explained that one way of managing uncertainty was to make pessimistic and optimistic estimates for those stories with higher levels of uncertainty; this provokes useful conversations with stakeholders, encouraging them to provide the additional certainty required to inform a more robust estimate. The business quite reasonably requires a commitment from the engineering team around delivery, but it must play an on-going role in making that commitment possible and achievable.
Other ways of managing uncertainty during delivery include research and development, experimentation and feedback, and a ‘spike’. None of these are free – all required the team’s time – and that’s why IndigoBlue believes an uncertainty strategy and plan to be essential to any Agile project.
The Unicorn that fell
Kelvin Clibbon then took to the floor to tell the story and the lessons he learned from the fall of a ‘unicorn’ (i.e. a privately held startup valued at over $1bn) – Powa Technologies.
Kelvin is now CTO at Ecrebo, a tech startup providing point of sale software which allows retailers to enhance customer engagement at checkout. He explained that his earlier career in the RAF and then as a Research Scientist were good preparation for his CTO roles, developing his skills in analysis and people management. As a CTO, you wear multiple hats, from day-to-day management of the engineering teams, through to working with other departmental heads across the business, up to reporting to the executive team and the Board.
In order to judge his own performance, collect his thoughts, measure progress and track the “authority/responsibility seesaw”, Kelvin uses the 4 Ps Framework:
Using this framework, he told the story of the fall of the unicorn that was Powa Technologies.
Powa built its proposition around commerce, e-commerce and mobile commerce services. Founded in 2007 and becoming a PLC in 2012, Powa raised sufficient investment to be valued at $2.7bn in 2014, prompting former Prime Minister David Cameron to state, “’I am delighted that Powa is further contributing [to the recovery of the economy]’”. In a little over 18 months from then, the company went into administration in February 2016.
On the People front, Kelvin joined Powa as CTO and expected to be able to build his team gradually. However, he explained that this turned out not to be the culture at Powa – the engineering division was on a different floor to the business and engineering staff were not allowed upstairs without wearing a suit.
‘Teamicide’ was committed from on high by the business, with Kelvin’s team being fired and a third-party payment product being bought, rather than building one in-house. As Kelvin rebuilt his team for this new context, he strove to ‘near-shore’; while London engineers tended to be too expensive, in Kelvin’s experience it was still best to build teams as geographically close to the business as possible.
In relation to the Product, Kelvin’s engineering team had good engineering Processes – taking an Agile approach from the start and factoring ‘compliance by design’ into their DevOps ways of working – and they had a good plan in place. However, in his view the business lacked a strong business strategy and exit plan, i.e. whether the aim was to sell the business, seek more investment, etc. – all of which shapes how you develop a product.
In addition, there was no domain knowledge in the business – he explained that when he joined, no one at Powa had knowledge of banking or compliance. And in relation to buying in software rather than building it in-house, he felt that there had been insufficient due diligence – it’s vital to understand in detail what you’re buying, all the way from the big question of who owns the IP to the fine detail of code quality.
In terms of the Platform, Kelvin explained that it was vital to think about scaling horizontally when deploying in the cloud – you need to achieve the elasticity of just-in-time scaling to meet peaks in demand. Outages don’t just damage your reputation, you start to pay heavy fines. Regarding technical debt, Kelvin found at Powa that some of his engineers were using it to pursue pet projects. He insisted that the resolution of technical debt required an objective in order to focus his team on the business value to be delivered, rather than engineering perfection.
In response to a question from the group about the best way of managing technical debt, Kelvin said that it was important to make it visible as stories. If it’s visible, you can discuss it as a team, define its value and prioritise it.
Asked about the challenge of exerting your influence in a new leadership role, Kelvin explained that, despite his role, he had no authority at Powa; he learnt that authority has to be earned. In order to be successful in a new role, you have to establish yourself and understand who the people are that you need to have on-side. He recommended reading The First 90 Days.
Join the group
We run Agile Managers and Leaders meetups in London regularly and you can keep up to date by joining the group here:
Join the Agile Managers and Leaders group