Agility mis-applied Thursday 2nd January
I have been working with a client who has recently taken a decision to embrace the Agile way of working. While they have made what I feel is good progress in implementing many positive areas of Agile including daily stand-ups, demos, retrospectives and planning, a recent project threw up an interesting conundrum.
The project involved the production of an online reporting system to enable customer service agents to field enquiries from customers. Rather unusually for Agile, the Business Analyst had produced User Stories up front that were 90% complete. In Sprint 0 planning sessions, the Product Owner was asked to prioritise these User Stories. The reply provided was that they were “all as important as each other” since “all of them need to be done otherwise we don’t have a Product”. We were then informed that this project also had a fixed delivery date.
At this point, I questioned whether this project, with known requirements and a fixed delivery date, really lent itself to being done under an Agile process but was told that “we are an Agile organisation”. We then proceeded to spend many hours in planning sessions attempting to decompose the User Stories in such a way that they could be tackled in a multi-Sprint framework. Subsequently, the project team struggled to complete many of these individual User Stories within a single Sprint so we spent a great deal of time in each planning session moving incomplete tasks from one Sprint to the next.
What seems to have been lost in this particular organisation is that Agile should be regarded as one tool in the Project Management toolbox and is not a “one-size fits all” solution that works for all projects. In the rush to become an Agile organisation, it’s important not to throw away all the old proven processes merely because they are “not Agile”.