Are you Agile?


agileNearly everyone these days has heard the term “Agile” when talking about business processes, especially as it relates to software development. Because Agile processes are enjoying so much well deserved popularity these days, one of the most common questions I hear asked of any organization is “Are you Agile?”. There are, of course, a wide variety of ways to answer this question.  Who you are and how you define the term "Agile" can play a big part in the answer.  I say this because, while the principles behind Agile processes are deceptively simple, implementing a successful Agile process can be devilishly complicated. The number of opinions on what constitutes a "good" Agile process are innumerable  There’s no way to cover all the details that need to be considered when implementing an agile process but its certainly not hard to cover the basic principles so nearly anyone, technical or not, can confidently answer the basic question. That's what this short article will aim to do.  First. let’s take a high level look at what it means to be “Agile”.

Getting it “Done”

In reality, the concepts behind an agile process have been around for decades, they just didn't have a specific name. A former co-worker of mine once put it very succinctly when he stated: “Back when this company was a start-up  we had a process I called the GSD process and GSD simply stood for Getting S--- Done”. Agile is, to a great extent, a formalization of that rather blunt statement. Its about 2 fundamental things: team collaboration around a prioritized set of work so that the most valuable things done first and incremental delivery of your product so everyone involved can see where things stand and adjust course as needed.  Looked at from that perspective, it doesn't matter if you’re following a strict implementation of Agile (XP, Scrum, Kanban, etc) or cooked up your own variation of the principles, you’re still “Agile”.

The Agile Manifesto

The Agile manifesto states the following:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Look at that and think about what it really says. Fundamentally, all it says is that the team should adopt a mentality of constant collaboration with everyone involved in a project so that the most important things are always bubbled to the top and worked on first. Its also says the focus is on getting things done vs clinging to rigorous process and or tools that don’t directly help with the primary goal (getting the right things done). Given that, I would make one tweak to my former co-worker’s statement and say his GSD process was actually the GRSD process where the “R” stands for “the Right”. That’s what Agile is all about, delivering the right things to the customer as quickly as possible so that they understand what they are getting and how its going to help them.  It also gives them ample opportunity to change course before the end product is deemed “Done”

Back to "Are you Agile?"

So, back to the original question. Are you Agile?

If your team is:

  • Working to insure that the highest impact work is at the top of the stack
  • Maintaining constant contact with the business and/or customer so you know what the high impact items are
  • Doing work in an iterative way so that course corrections are easy to make

If you’re doing each of these items then you can certainly say you are Agile.

Really? Its that simple?

Unfortunately, the answer is Yes and No. The principles of Agile really are that simple. However, in practice, implementing an Agile process can be quite challenging. Agile is not a case of just doing whatever seems important with no thought toward design, documentation, tools or compliance. Its focus is on getting things done with the minimum required amount of design, documentation, tools, etc. It is not an excuse to eliminate those things altogether and allow anarchy to reign. Finding the balance between nimble/fast work and the appropriate amount of controls is absolutely crucial and usually not an easy balance to strike.

I've been building and leading Agile teams for well over a decade and have yet to see an organization that cannot benefit from some form of coaching on Agile principles and best practices. Some are trapped in a true waterfall process and need help understanding how to move away from that model. Others are nominally Agile but could use help understanding how to gain more efficiency. Still others can be called “Agile” but would benefit greatly from moving to a more structured Agile methodology (E.G. Scrum).

If you want to learn more, contact me anytime, I’d love to talk.