That's not real Agile!

That’s not real Agile!

I have heard and read this a few times recently in various contexts, including that of my own day-to-day work and it bothers me. It’s usually been in the context of some transgression of the rules of some methodology or another. An example that comes to mind is choosing to delay the start of a sprint for a day in order to deliver an item that didn’t make it all the way to “done” within its sprint.  The team took the decision, in the interest of meeting a specific business need. There are lots of other small examples, many of which are responses to various “real life” business scenarios. We accommodate the various levels of maturity, (in terms of Agility) across our organisation, because, hey, for now, that’s just how it needs to be.

Does this make us not Agile? We use the scrum guide as a framework for the way we work, but we don’t do everything exactly as it describes. Does this make us not a scrum team?

If you’ll bear with me, I’d like to try to unpack my thinking about this a little.

The first thing that comes to mind is that this is a symptom of our immaturity as an Agile organisation. Yes, we (the dev team) have sprinted together 23 times; yes, we have learned, we have inspected and adapted and we continue to do so. But it’s slow; the changes are fundamental and have impacted every aspect of how we do our jobs – we are still trying to find our sweet spot. Over time the changes to the development process have percolated through the organisation and are forcing change in other areas. This has been very much the case recently, as we move into a trying to cater for a dev-ops scenario. I suspect that the extent to which changes to the development process have impacted the wider company are a bit of a surprise to many, and it’s not necessarily a welcomed one.

From that perspective I would argue that it doesn’t matter, we will get there. This assumes that “there” is some place where we follow a set of rules perfectly and that this is a desirable end point. However I’m not really sure that this “means-to-ends” thinking is actually what it’s all about and I can’t help but wonder whether striving for adherence to the rules is a bit of a red herring.

When I look at what we do from the perspective of the values described by the Agile manifesto I’m not so worried…

Planning to accommodate the needs of an operations team – who definitely have not made a conscious choice to change their approach to an Agile one – seems to align quite nicely with the value of individuals and interactions over processes and tools, as does working with marketing and PR in the same way. Each time we do this, we get a little closer to aligning our perspectives. Isn’t this what iteration is really all about?  Working together with the business is not just about collaborating on the direction of our product, but is just as much about understanding that being totally transparent about our progress – the bad as well as the good – can be really quite scary for a management team. Especially when in the past they were never really exposed to the messy reality of the software development except when it was too late and had already gone horribly wrong.

Being willing to adjust, accommodate, listen and respond in a way that the rest of business can deal with is very much about responding to change. Forcing the change in order to follow our plan to become agile doesn’t sit so well. The same applies to seeing the business as our customer – being willing to collaborate rather than trying force a negotiation on our terms.

Agile is a philosophy based on values, not a methodology based on rules.  So, if everything you do is underpinned by Agile values, that makes you Agile, the rules don’t matter all that much.