The road to Agile

agile_development_logo2Over the last five years I’ve been part of an IT team that’s gone through a period of expansion in line with the explosive growth of the business. Originally part of a team of two, between us we ran IT Support, and delivered various software development tasks to increase or improve the capabilities of the business. There was no concept of prioritisation, forward planning or even robust requirements gathering – we didn’t need it, we just got on with the task, and it worked. It was a symptom of a then small business, needing to adapt and react quickly to improve.

Since 2011, incredible growth of the business led to two relocations, and an IT team of 2 becoming a team of 13 with the overall headcount growing from 30 to over 250 in the same time. As the company changed, so did the management structure; two business principles became a board of directors and a senior team below this. The number of stakeholders, each with their own unique set of demands from IT increased exponentially.

My role changed from support, to developer, to team lead, to manager and ultimately, I’ve been charged with delivering change to bring our department in line with the expectations of a business of this size, providing better visibility, better prioritisation and better management of expectations. The real challenge is going to be delivering this whilst still supporting the business in maintaining it’s biggest competitive edge – continual improvement and quick reaction to changing needs.

The challenge has become putting forward the right blend of requirements gathering, rigorous specifications and test plans whilst still being able to quickly get tasks off the ground and delivered in a timely manner.

Researching the various Software Development methodologies led me to Agile, adopted successfully by thousands across the world, it was clear this was something we should look at. Full Agile / Scrum would require fundamental changes to the way we work and the way we interact with the business, and I don’t think they’d respond well to ‘shock and awe’. Getting a better understanding of User Stories and Acceptance Criteria showed me that this is where we’d get the greatest impact, whilst maintaining our strong working relationship with the stakeholders. User Stories, whilst simplistic in nature, were an incredibly easy way to convey the intent and overall goal of any task.

I once read that they key to Agile was making it work for you, there were no right or wrong, nor hard and fast rules – Agile is a collective ideal, and so I felt comfortable in not putting forward adopting the full workflow.

With Management briefed, and a new work request system currently under construction, only time will tell if this yields the results I’ve been tasked to achieve…

No Comments

Post a reply

Copyright © James Coleman-Powell, 2016