Agile, it isn’t about “I’ll do what I want and you have to like it because that’s Agile!”

For my first post I wanted to discuss Agile, I’ve worked with several businesses that believe they have an “Agile” approach, and for the most part, this has been a decision largely lead by the developers or technical team, because it felt like a better way of working.

My partner works within a large financial institution, and has been on the management side of listening to folks talk about Agile, and after chatting with her a few times about the experiences she’s had and her understanding, I started to feel a lot of crossover in the places I’ve used agile before, and an interesting perspective on how it could be viewed.

As a developer, we don’t like to feel constrained to tight deadlines, we’ve been conditioned over the years to expect the unexpected, hoping for the holy grail of a bug and change free release, though usually met with changes from the users, or finding that the original design did not cover scenario X, which happens once a year and no one thought it was worth mentioning because Bob over in accounts used to just manually change the figures, but Bob is gone now and the system is being re-written, and what Bob was doing was probably illegal anyway, who knows where Bob really went, maybe it was prison? Naturally we get a bit anxious when we’re told in no uncertain terms, that feature X has to be production ready by next week, and so we add caveats to testing outcomes and the design plan being followed to protect ourselves, and in the world of waterfalls this causes a problem.

So we take up the torch for Agile, and so often I’ve seen it brandished threateningly by an anxious developer, like a cornered cat, as a tool to try and protect themselves and their work from a premature release. This is what management will see, and the rest of the business, and my partner in her role has actually had a developer come along and say “We can’t do the change you want, because we’re agile and that’s now how it works”, this kind of reaction reads as “I don’t want to do that work”.

What Agile is at it’s heart, is common sense, it isn’t about having no documentation, or not having a longer term plan. You can still have documentation and a plan, and guess what, you can follow that plan and have a longer term roadmap. However, what Agile allows us to do, is say that those things, are not the most important, I mean, let’s be real, why are we making this system, to improve the business process or to allow us to do something in a better/faster/simpler way, we’re not Bob, we care about the business we work for and want to get it right. If, along the way, we realise there is a better way of doing feature X, and we can adapt to that change, then why shouldn’t we, we need to be able to shift things around in the plan so that we can deliver the right solution for the business, not continue blindly charging down the wrong path because that’s what we agreed.

In order to make any of this happen in the right way, the businesses we work with have to understand that the deadlines for projects can shift, if the project itself changes over time. If the date has to be fixed and cannot possibly move because otherwise the auditors will find out what Bob did and then everyone’s going to prison, then Agile probably isn’t the right approach, maybe you’re fortunate enough to be writing software for a rocket launch, there aren’t many critical drop deadlines that cannot shift, they are mostly there because that’s how the business is planning it’s strategy. We can still produce documentation if it provides benefit, but we should be prioritizing delivering a working solution over that, and not spending all our time writing detailed breakdowns and specifications for software that we know will change over the course of delivery and make all that hard work out of date. In addition to this, you can spend all the time in the world writing specifications for a system, and still end up with someone like Bob who doesn’t feel comfortable talking to this strange project manager or IT guy who’s just started yet, Agile can help with that, because meeting with stakeholders regularly you’ll find out a lot more about what they do and why they do it.

Agile isn’t a weapon to be brandished, it’s a tool, if you use it in the right way you’ll wonder how you ever managed without it, and with time you’ll become quite skilled in it’s use, and what seemed difficult when you started becomes easier. Just like a tool, you can use it wrong, using a hammer to put a screw in the wall instead of a nail is possible, but it’s not going to end well for you or the wall.

The biggest issue I’ve seen in the new world of Agile, has been the understanding of what that means within a business, everyone adds their own flavour, processes and tools and calls it Agile, yet quite often when the wider business discusses work and strategic planning, they run into a roadblock. If you’re adopting Agile or already have it, the businesses and clients you work with should understand why you’re doing it, at a fundamental level, and that conversation shouldn’t feel like you’re defending a processes and it’s a David and Goliath of developers vs users, it should feel like you’re doing what’s best for the business, and streamlining the delivery of software over cumbersome administrative overheads.

Whatever you’re process and technique, there is a set of principles upon which you should be building, and however you take Agile on, you need to remember them, and ensure the people you work with understand them too. Read more on these at the Agile Manifesto page.

In my next post I’ll discuss specifically how I’ve found Agile to work best, and how to make it a positive and rewarding methodology for the business and users.


P.S. Hope you’re ok Bob.