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.
