6th March 2019

Agile creep

Reading Time: 2 minutes

In the not so distant past I worked as a consultant Solutions Architect for a large housing association. The role was rather mis-sold to me and rather than leaning on my main Infrastructure-focused skillset I found myself working on a software project, essentially leading the work to develop a new tenancy management platform.

While that isn’t the point of the article, it did give me an opportunity to take a more central role in the delivery of agile and scrum – our efforts were genuinely focused towards taking iterative steps with regular customer feedback. While buying a set of agile estimation cards from Amazon won’t go down in history as a proud moment I left the project with a new perspective on delivery.

Fast forward to today and I find myself considering how best to champion a wholesale end-user computing improvement scheme. The issue is mired in tangible and intangible issues, hyperbole and contradiction.

If you’d have spoken to me a few years ago, I’d have immediately started to query the need for detailed functional and non-functional requirements. I’d probably have wanted to group the users by role and analysed their requirements in terms of hardware, software and configuration and would have set about the process of designing the solution to satisfy those requirements.

Today I find myself wondering if I ask the users themselves whether or not I’d be able to garner accurate feedback in that up front way. Would putting the users under the sort of pressure where they feel it necessary to lay everything out on the table in absolute detail be a one so traumatic that the list of requirements may be over-egged to the point whereby it becomes useless? Quite possibly – in which case it’s likely that I’ll need to iterate towards the end of the project anyway and I can already hear the project manager talking about the over-spend.

In terms of how I’m going to approach it, I’m not sure at this stage – but as with most things, striking the balance is going to be important and as I sit here today I can envisage a situation whereby I gather enough information to start the process but rely on an unquantifiable period of iteration to get things right.

Sure, documentation is going to be a bit more chaotic and retrospective – but I value a well put together, functional solution over comprehensive documentation any day of the week.