Sorry, I can’t do that, I’m not agile
Inviqa’s dev days are always excellent events with a high level of content quality. One particular talk stood out for me at today’s event, which was Stephen McNairn talking about his take on the agile manifesto and how he’s seen Inviqa’s approach to agile develop over the years that he’s been with the company. One particular point really struck a chord with me, and that was that we might not always be as agile as we would like to think. What follows is my take on what Stephen said, and the majority of the text is only my interpretation of his original point.
Who’s not agile?
We too often reject a request because it is not ‘agile’, but that very action of inflexibility suggests that we are not being agile ourselves. What Stephen’s talk really reminded me today is that agile is not Scrum, nor is it Kanban. It’s not a project management methodology, nor is it a development tool. I know that I have certainly been guilty more than once of a negative reaction to a client’s request because it doesn’t fit into the Scrum framework. Instead of immediately jumping to a defensive position, I should be more empathic and explore the driving factors behind the client’s request.
The first line of the agile manifesto states that “we have come to value individuals and interactions over processes and tools”. That’s not to say that processes and tools are valueless, far from it. Without known processes we would struggle to give estimations, manage our workload or deliver valuable software. Without tools we would take longer to achieve tasks, or even be unable to achieve at all. It is by having a good understanding of our processes and tools that we are able to move beyond developing mundane solutions into delivering truly valuable software.
What is more important though, is that we do not let those tools or processes hinder our ability to interact with others. Through interactions we can identify areas where our processes and tools are preventing us from delivering as much value as we can, and in those cases we need to be flexible enough to make changes to how we are working. We need to embrace change, not shy away from it because new requirements don’t fit well into whatever project management methodology we’ve currently adopted, or what vision we have for a project.
Drawing inspiration from others
The importance of this flexibility was illustrated to me in a hallway conversation with another of our team leads. His client requires extreme responsiveness, and despite reducing their sprint length to one week the client was dissatisfied with fixing scope for that long and the team were suffering because changing priorities during the sprint made them feel that they not ‘doing agile the right way’. His team are now going to drop Scrum completely and try to apply Kanban to the problem.
Such a thing is not undertaken lightly, because it represents a significant disruption to the team, and will initially slow delivery as the team adjusts to the new process. I’m hopeful though, that with the right work in progress limits the team should be able to respond to change faster and satisfy the client, but more than that I’m hopeful that if their new approach does not work they will work to find a better process through interactions with all the individuals involved. Because they’re an agile team.
