Agile delivery is very much in vogue, referred to as the latest must-have fashion accessory for your IT department, but far too many organisations are treating just like that, as if it is something that can be bought and installed, like a new shiny server with flashing lights that everyone can look at and say “Oooooh”. Having seen it, the business then drifts away and leave the infrastructure dept to do their thing and we all go back to doing what we did before that moment of excitement.
If you have a small project then it is reasonably credible to have a crack team work with the business to deliver something quickly, try it out and then improve on it. The delivery is small, the budget is probably similarly small and the whole initiative flies pretty low on the governance radar. This is where Agile started and excels.
Now think about a larger project, a more significant technological improvement or something with significant business impact. Now before this gets to any of those techie code writers, this initiative will be thought about… Target operating models refined, strategies penned, there might be process flows, visions, objectives and benefit realisation plans created. This work is vital, most of it falls under the Management Consulting area and for most companies this is taking place outside of the IT arena and therefore away from the shiny new Agile toy.
The business – having done all their thinking then speaks to the IT department and explains the wonderful plan, “we’ve done all the strategy work, you build it and then we’ll implement it”.
“But we’re Agile” the IT department responds, “In Agile we work out the requirements as we go and”….
“Yes but we’ve done most of that already – we’re not going to ask you to define all the work up front because we now know you don’t do that any more with your new shiny Agile, but we go live at the end of the year so work towards that, now off you go”.
At this point there is either a big fight and the company rethinks and there is a fundamental culture change to take Agile principles into the heart of business strategy or, which is far more likely, you have IT setting up an ‘Agile’ project with pretty fixed deliverables and a defined implementation date a long way in the future.
Because the scope of the work is probably significant, and the deliverables reasonably well understood there is a temptation to start large, multiple teams, maybe straight into one of those much misunderstood scaled frameworks. Teams are working away delivering chunks of software under Scrum governance which are connected together in some ever growing test environment, desperately trying to get through enough functionality before the predefined implementation date.
Because this is so realistic for large organisations it is very easy to see this as normal and hence perfectly acceptable, we are lulled along the path comfortable in what is familiar.
THIS IS NOT AGILE. THIS IS WATERFALL
- The requirements have been roughly designed up front
- You are now building it against a deadline
- Then you are going to perform some kind of holistic testing at the end (unit testing continually but end to end user journey / business process lifecycle testing and performance testing often at the end)
- A pile of tests build up for the end, because with no users there is no urgency to fix them
- Then you are going to implement it at the end– with associated Change Management
What in that is Agile? – well you have what looks like Scrum governance (or Kanban or similar) during that build phase. So there might be sprints and burndowns and backlogs, but take a step back. Go back to first principles:
DO YOU HAVE WORKING SOFTWARE? – NO.
This is what I refer to as AGILE AT THE BUILD PHASE.
This is a very dangerous place to be and the issue is one of risk. IT projects are de-risked in one of two ways.
- Work out everything up front, consider all of the options and then don’t change anything
- Only deliver a little bit, check it works in the real world and then improve it
‘Agile at the build phase’ skips the detailed requirements gathering but also has a traditional waterfall implementation big bang end so you don’t get the continual real work assurance of the iterative implementation either – basically you carry all the risk of the project from start to finish with little mitigation.
Not all risks become issues, maybe the software does work – hurrah – and you get away with it, but sometimes it doesn’t, some integration fails, some data migration is not as expected or the system does what it was designed to do but not what is really needed – and now you have a massive problem – missed dates, huge loss of face and the possibility of a complete write off. It happens, I have witnessed it, and if you haven’t just Google Agile failures and look to see the number of agile builds with few deployments.
Agile isn’t something you do, it isn’t a process and it isn’t limited to the IT department. Agile is a culture, a principle, a set of behaviours. It is something that an organisation IS.
For an organisation to embrace the benefits of Agile then it needs to manifest those principles inside the earliest discussions and right through an iterative delivery – not just leave it as a shiny toy for IT.
Credit to Dan North for the underlying theme of Principles over Process.
Comments welcome, #philagiledesign on twitter.
At the very least, if you start down an Agile delivery then at least change the release plan to deliver something early, and by deliver I mean into production to a real user, it is the wait to the end implementation plan that will kill you.