When the term “agile” is used in reference to development processes, many seem to use the term to refer to some degree of adoption of a given agile framework such as Scrum, Extreme Programming, etc. rather than using the term to refer to the degree to which their teams are able to adapt to frequent types of changes that tend to hinder the success of projects.  Some may argue that this distinction is merely one of precision of speech rather than of meaning, but the extent I’ve encountered nominal adoption of agile practices seems to argue to the contrary.

What is Agile?

It seems that many team’s first foray into agile processes is the selection of Scrum or other framework by their management teams who’ve heard that a given system can help them improve upon their processes.  As a result, they send the managers and Business Analysts off to a few days of training for the selected framework.  While there is certainly nothing wrong with this avenue, it’s part and parcel of the agile-process-as-commodity mentality that I believe tends to lead to poor adoption.

Introducing a process like Scrum (or whatever portions of Scrum a company’s existing  process will tolerate) will sometimes improve upon matters, but only insofar as one’s cargo-cult emulation of the prescribed practices happen to match up with the problems for which they were conceived.  Unfortunately this approach to adopting agile processes often seems to lead to a bunch of people going through the motions without really understanding what the purpose is.  Worse, when the local Scrum training consultants sell management on the fact that they don’t really have to give up things like deadlines, using business analysts to gather all the requirements, or otherwise restructuring their organization, they generally end up with some empty shell of a process which is really nothing more than their old waterfall process with more micro-management.

Rather than defining agile in terms frameworks, let’s actually go back and look at the definition:

ag·ile –  adjective \?a-j?l, -?j?(-?)l\

1:  marked by ready ability to move with quick easy grace

2:  having a quick resourceful and adaptable character

Based on this definition from Merriam-Webster’s dictionary, being agile is “an ability to change, or adapt to change, quickly”.  While communicating that you adhere to a given agile process does have its usefulness at times, thinking of your process in this monolithic way doesn’t promote the kind of thinking that leads to continuous improvement.  Rather than thinking in terms of which process we use, we should think in terms of what aspects of change our processes help us adapt to.

Nominal Adoption

Many teams consider themselves to be agile based on a declared adoption of a given framework such as Scrum, or they may think of their organizations in terms of what percentage of a given framework they’ve adopted, but often have only adopted only some poor imitation of what the framework prescribes.  One example that seems frequent is the practice of pseudo-iterations.

Many organizations claiming to have adopted Scrum still follow a process where a fixed goal is initially established and the features perceived to meet the needs of the end goal are developed and tested in a series of time blocks until the product is released.  Such teams may consider themselves agile, but should they finally deliver the product into the hands of real customers after a year of development only to find that the needs of the industry have changed, can they really say they are agile with respect to changes to the product’s desired features?  Of course, there are some products whose minimal viable product is too complex for short iterations, necessitating some form of internal feedback loop (e.g. self-driving cars, space shuttles, etc.), but generally with software systems, what is considered to be a minimal viable product is far from the smallest increment that can provide meaningful functionality to the end user.

How Are You Agile?

Rather than thinking of your team as “agile” or “not agile”, consider asking the following types of questions: How well does our team adapt to changes in requirements?  How well does our code base adapt to changes in features, frameworks, and libraries?  How well does our team adapt to the loss or addition of new team members?  How well does our team adapt to changes in the distribution of knowledge and skill sets on the team? 

In order for teams to really become agile, they need to understand the common factors which hinder adapting to changes in the landscape of their market, their teams, and their code base.  They need to be able to identify both when some aspect of their process isn’t resilient to change as well as when a given process is not necessary.  Let’s stop thinking in binary terms of whether we are or are’t agile and begin continually reflecting upon how we might improve upon our processes to better adapt to the changes that affect our success.