So what is agile?
That seems to depend on your perspective! For CIO’s generally it seems to be about making sure IT can respond to the business (not that they have not been trying to do this before) and how to become an efficient service driven organisation. For the architecture community it is about trying to do even more with less, a new urgency on transforming business and application silos, modularisation and compatibility across people, process and technology and a focus on business understanding. For development and testing it is about new or enhanced ways of delivering, developing and testing software on time while adapting to changing needs of the stakeholders. For infrastructure and operations it is about changing the organisation from being inherently reactive and risk adverse to accepting a bit more risk where appropriate and delivering useable services that have demand. Breaking an infrastructure program into smaller milestone decision points to show progress and return to the business.
What is the point of agile?
To deliver something concrete – preferably working software at the end of each sprint. Many times we see the transition of traditional Waterfall to Agile which to me seems to create the worst of both, little delivered until the end while governance goes out the window or, over governed agile delivery which again, delivers little. It really is no good if your backlog is growing with business deliverables while sprints are delivering mainly IT ones and documentation. Sprint reviews are useful but spending a whole day at the end of the 4 or 6 week sprint could be indulgent – let’s say 10 people at an average of $150 per hour fully loaded, in a review for 7 hours = $10,500 and, this happens 9 times per year, this is $94,500 per year! What else could the business do with this money on the project?
The other part of agile, when not practised properly, is the lack of strategic direction. Customer needs and user stories do not live in a vacuum; they live in the context of the organisation from which they were derived and within the either overt or covert business strategy and goals. Often Agile seems to be practised with the short term view of the organisation or even more often, the project view. This leads to shortcuts and removal of items that are beneficial to the organisation going forward but, are harder for the project to justify on its own. This may seem like the view of an enterprise architect bemoaning the lack of strategy and direction in organisations but, talking to business colleagues rather than IT this seems to be a somewhat consistent view.
What can IT do about this?
Delivering something concrete
Deliver things the business can see and preferably use at the end of each sprint
Keep introspection and sprint review to the minimum necessary
Bring the wider stakeholders into the change process. It is very easy for people on the periphery to undermine your efforts as they have not had the communications or explanation
Don’t start with a large project if your organisation has not done Agile before. Start small, be seen to deliver value then build, under promise and over deliver!
Keeping an eye on the big picture
- Are you building ‘debt’ (technical, process, organisational) into the project? Have a review with your friendly Enterprise Architect or Application Architect from outside the project.
- Make sure you understand and can communicate the end to end process from the customer perspective and what the project is doing within that process
- Be prepared to push back on short cuts or deferment of backlog items
