Operating in Agile
I’ve been asked a lot about how a product copes at an operational level in a fast-paced environment where the service is built using agile principles. It’s a complicated question; the way we work is constantly changing, requiring us to think of new solutions on a regular basis. Solving operational problems in a digital product or service is very rewarding, and a business can greatly benefit from the speed in which a product can be launched using agile methodology. The challenge comes in ensuring that you have a viable operating model in place as your offering grows.
When there is a new product on the horizon, you look forward to the utopia of a fully automated system, which can eradicate human error and eliminate manual processes. In reality, a few compromises are made, and you may find yourself building up a body of manual processes and picking up the slack for what was originally promised to your business, your customer or the end user. This in itself isn’t necessarily a bad thing, but the journey to get to a more balanced state can be a long road.
As the product evolves, you’re likely to be faced with a series of choices about what truly is required from your tech team versus what is “nice to have”: do you really need weeks of development time spent on a feature, when perhaps a manual process would do the job? Ever-changing priorities will leave you needing to articulate feature requests in a clear way, spending time with software engineers to discuss potential solutions and coming up with the best outcome for the product in that moment. This means making compromises with the product team — alongside other stakeholders — to reach the best outcomes for the customer and the business as soon as possible. The main area of concern for Operations that Agile presents is technical debt: features de-scoped and intended to be visited at a later date are overlooked because new priorities have emerged. The test for us here is to ensure that these items are not overlooked completely, leading to growing pains as a product develops or as a suite of products expands. However, this not something that needs to be a defining negative.
To ensure that the product is delivered within set parameters and on time, some challenges may halt the development of features. This can present the opportunity to look elsewhere for bespoke and out of the box software solutions, clearly setting out your own needs and requirements and focussing on the operational needs. Working with third parties can allow you to develop advanced, easily managed agile support tools that meet the needs of the business. Using these digital tools can in fact enhance your service to both internal and external stakeholders, adding value and insight into product performance and exploring trends in user behaviour.
As a function, we can also learn a lot from the developers’ use of agile. As a service expands into new areas, there is more of a place for planning sessions and stand ups. These help to keep momentum whilst building out new processes, supporting the launch of new features, and overcoming existing hurdles. Focussed, clear and concise conversations can ensure informed decisions can be made quickly. Using Kanban boards ensures that workloads, development of new processes, and tackling ad-hoc challenges can be structured and managed using the same methods of prioritisation. This helps guarantee that outcomes are reached to satisfy the demands of the business, partners and customers alike.
As I’ve mentioned throughout, there are positives and negatives to the agile methodology for an operations team, but the key for me is this: if you want to be successful, you need to be able to adapt quickly or the market will leave you behind. Operationally, this means that we need to be flexible, at the same time as ensuring that the product teams understand what is sustainable in the long term. This will allow the product to be efficient for our customers, both now and in the future.
