Agile: are you hiding behind hybrid?


Alex Bigland Agile, Blog, Industry & Commerce...

Let's be clear on one thing, I really like the Agile approach and believe that if you get it right then your organisation will reap real benefits. But, if you don't take time to get the fundamentals in place then it might start to feel like a Dilbert comic strip.

I often hear organisations say 'We’ve implemented a hybrid version of Agile'. On the surface this sounds sensible - adapting or moulding the principles to fit the context of the host organisation. However, often, when you probe beyond the hybrid headline, what emerges is a number of fundamental contradictions that reveal a lack of understanding or alignment of approach across the organisation.

In an article I read from 2009, Agile was described as being an investment in software development where software is seen as a primary development in a company's future. This is as opposed to viewing the development as an expense that is time bound and tracked in the form of a project. In essence, funding a team rather than funding a project.

For some that’s a huge leap of faith. Others will say that they already do that in the annual budget round for a team of non FTEs. For me, when designing your hybrid version of Agile, this is perhaps the most important point that needs to be understood across the organisation, particularly between the Finance and Technology teams. If you were to ask me how much a team will cost between two points in time I can accurately and consistently tell you. If you ask me the same question about a project (let's say stage gates as opposed to dates) I'll still give you the estimate, but will include significantly more caveats about the level of accuracy. Does this mean I (and most of my peers) are bad at estimating or does it actually reflect the inherent difficulty of estimating effort of delivery in an often complex and uncertain environment?

If this isn’t aligned then you may end up with a Waterfall funding model that is trying to drive an Agile development approach. It’s no surprise when the development team ends up frustrated at the compromises it is forced to make in the hybrid world and the Finance team is frustrated by the vague estimates it gets for project deadlines.

Agile funding sends a message that the organisation is committed to investing in a primary aspect of future growth. There is need to fund a team year after year in order to deliver a never ending amount of development work. The criteria for success are concerned with functionality delivered over time. For some stakeholders, this can feel a bit 'California'. So, how does it work in the ‘real world’, where business deadlines exist and software development needs to be delivered in conjunction with physical or trading deadlines? For me, the answer is alignment across business sponsors.

If you’ve funded a team on the basis that there will always be software development then you need to put that work in a backlog, prioritise it, and then estimate and review within time boxed iterations. There needs to be a joined up view of the priority. The size of the development team is dictated by what the organisation can afford over the budgeted timeframe. You need to be able to flex the size based on the organisation’s economic outlook, whilst recognising that flexing up and down takes time so it’s vital to agree the priorities. I’ve seen teams fail not because the individual features were too difficult to develop but because the backlog of priorities weren’t aligned properly both at a micro and macro level. In effect, the organisation set itself up to fail. The problem with prioritising is that it needs difficult questions to be raised and often no-one is prepared to take on the harsh realities of finite resources. For me, it's ok to take a risk provided that there is a clear understanding that it has been taken and that if the objective was not achieved then it is not, by default, the failure of an individual or team.

So, if a real world deadline is aggressive, such as a peak trading opportunity or the physical opening of a new warehouse, then be equally aggressive with the alignment and prioritisation of the backlog so that the software development teams have the best chance of scheduling the delivery of the necessary features. If the backlog is not defined, recognise this as a risk for the organisation NOT the IT delivery. Agile requires an input from and the commitment of all stakeholders not just the development team.

Key to this is to have truly empowered Product Owners. Product Ownership is often seen as an administrative role with no effective empowerment to set priorities. All the sponsors want their backlog items as Priority 1. But if the tough decisions aren't taken then the available resources are either spread too thin or not aligned and so key business milestones can be missed or compromised.

And what about your suppliers? Where do they fit in to the hybrid model? In my experience suppliers crave stability. They want to understand the workload and then resource accordingly. If they have been working with you for a significant period on a T&M basis then what's in it for them? Are you clear on the level of dependency that you have on a supplier? You also need to be wary of the suppliers displaying their own ‘We Do Agile Here’ badge. How does their version of Agile align with yours?

Truly adopting Agile, or even designing a workable hybrid should not be seen as a leap of faith. However, without understanding the level of cultural change across the organisation and the associated level of support required to grow it, it will turn into a disjointed and often frustrating journey where the opportunity to make step changes will be missed. Ask yourself these key questions at the beginning: Is the organisation funding a team or a project? Are your business sponsors aligned? Is there a clear view of the backlog that you need delivered over time? Are you clear on the priorities you are setting? If these can’t be answered, then Agile – pure or hybrid - won't save you! That said, if you can answer these, then maybe you should begin the journey as you may well have a clearer path to success than your competitors.

By Tim Bradford


Tim Bradford is an IT and Change leader within the retail space. He has supported some of the largest retailers within the UK and China on improving efficiency in the delivery of technology change.

Former Head of IT Programmes, Asos
​Currently Interim Head of IT Transformation, Brighthouse 

If you're interersted in attending our breakfast event on the 12th May to hear more about Agile from Tim please get in contact -