During last week’s Agile-in-a-Day workshop in the Netherlands, I participated in an interesting discussion with the group of 25+ current and future Agile practitioners – on the impact of Agile methodologies on well established corporate processes and culture.
In particular, on the question of moving Corporate IT to Agile and how that means changing the traditional way that IT projects get approved and funded. The group felt that breaking the traditional cycle of detailed requirements documents, mandatory project deliverables and change requests would impact the entire project approval/funding and management processes – and yes, successful transition to an Agile model would require corporate IT to educate their business owners and stakeholders on the Agile approach. However, the workshop participants all agreed that making this change would definitely be a challenge.
One of the strategies we discussed was shifting the focus of the procurement process from detailed requirements to defining the amount of functionality to be delivered. We shared the OutSystems’ approach of using user stories and patterns to set a high level scope of functionality to be delivered and made the case that function points could be used as the measure of functionality – since this would allow the delivery team the necessary freedom to adjust the requirements during the project while still meeting a target deliverable.
This seems to be a recurring theme that I’m hearing from IT teams who want to embrace Agile. If you have faced this challenge and succeeded (or failed) – what do you think of the above approach and how does your IT team get its Agile projects approved and funded?