Dr Steve Hodgkinson’s Post

Hi Steve, who’s your audience? Those who have already adopted the platform + agile mindset or those holding onto the ‘old norm’. For the first cohort I think this is a useful illustration of the pathway for building maturity and performance. As for the second group, I’m note sure that confidence in agile or platform maturity is what’s holding them back. Fear is a great motivator but can also impact quality of decision making. So with all the bad press about IT project failures it’s hardly surprising that some are clinging to the promise of certainty of determining all your requirements up front and locking in a vendor on a fixed price contract. Of course as you point out this a furphy. Unlike agile, waterfall is not inherently designed to deal with uncertainty, rather it seeks to remove it from the equation altogether. Often at a time where we don’t have enough insight or stakeholder engagement to do so with any real confidence. Thankfully, with the weight of delivery success and speed to value being demonstrated, adopting platform + agile no longer requires a leap of faith. Add in useful tools like this on how to navigate the journey and we may just have a new norm.

Steve, My belief is that Agile in the IT Department is like the tail wagging the dog. Where the "dog" is the organisation. If we think of Agile as aligning to outcomes then we need the entire organisation aligned to outcomes and not to vertical silos. Otherwise the dog will just have an annoying wagging tail which it mostly ignores. With total alignment the decision criteria is based on what will deliver the best outcome, not what does my silo need. BTW I believe that your platform+agile, or something like that, will be shown to be the best approach in this aligned environment. I recently presented at an Agile Project Managers Meetup about Agile for the entire organisation. The slide they related to was one where they felt like an Agile team being pulled apart by the silos on top of them.

A good read Steve Hodgkinson; My thoughts are that a Procurement + Waterfall approach is traditional in nature because most solutions where commonly fully custom. In these circumstances and in my opinion it makes scenes from a budgeting and delivery perspective to utilize a waterfall approach. However this is now becoming redundant because instead of fully custom solutions, vendors can utilize frameworks and integration's to bring a tailored solution and with this agile makes a lot of sense. There is less risk in the fundamental solution, and custom components are lighter and can be changed easier than if a full custom solution was in train.

Good to read this Steve! I want to add that Agile’s increments can be waterfalls i.e requirements > solution on a page or a picture> development > test > deployment in each sprint. Can also apply to infrastructure projects since it’s become a code in cloud.

It is always very difficult to illustrate a complex 3 dimensional issue in a 2 dimensional plane.... This is a great way to start to have the discussion and education. I have seen too many procurements that are still in the "big bang, single product" replacement mentality and the organisation then tries to implement it in an agile manner.... They then convince themselves it is an agile project... From my mindset all that is smaller stage breaks in an old fashion system replacement. We need organisations to ensure they have the base artefact of a Business Capability Model in place and then adopt a platform approach to solving their most immediate business problems... in an agile manner...

Always great to explain the concept with a one-page diagram Steve Hodgkinson This is very clear thinking. You could take this a step further and develop the idea around vertical platforms whereby you create a single logical platform to service an industry segment, like for example State Government. Regards Greg Twemlow

I am interested in how this approach is a form of intelligence built upon a platform of knowledge (organisationally). Does it always apply? Are there some systems that need to be developed in other ways than agile? What can be learnt in a way we can confidently know and share?

This looks good Steve Hodgkinson - and I think it would make sense when discussing with your colleagues. The next challenge is how to develop staff in their understanding of what agile really means - for the IT project but more-so for how they'll experience it during rollout and day-to-day. Applying an agile approach is not only a good way to operate when it comes to technology - it makes a lot of sense for the public purse - having an agile mindset is also highly valuable for the way the public service operates. From recent experience, I'd suggest this is going to be a much harder sell (even if initially aiming to just have staff understand an agile technology rollout, let alone how they might apply it to their work).

True agility can be achieved via an integration platform, a flexible opex funding/procurement model and a managed service to continuously improve through strategic platform growth. Not an easy sell to government unfortunately, though highly desirable, in my humble opinion, from all viewpoints.

As ever, Steve, very thought provoking. I think it is a reasonable consideration for the private sector, too. Need to think this one through. Does this imply that waterfall is always ‘bad’? (i.e. the y-axis could also have high and low “confidence in waterfall” added to run 180 degrees opposite to your Agile labels?). I suspect the hardest part for agile procurement processes in government is the need for transparency and “good” governance. This is harder to do with Agile because you are buying capability rather than, as with waterfall, buying specific deliverables and defined outcomes. Even if the latter are wrong, they are easier to audit. :-)