When the term “agile” is used in reference to one’s development processes, it more often than not seems to be used in a monolithic way. It isn’t that many aren’t cognizant of the fact that people tend to use a subset, combination, or modified form of the main agile processes marketed today, but even in this recognition there seems to be a tendency to think about each variation in monolithic terms.
Which Process Do You Use?
If you’ve ever attended a local agile user group to hear various processes compared, you may have encountered the speaker asking for a show of hands to find out what various processes people are using. If you’ve been to one of these meetings, it might have gone a little like this:
Let’s see a show of hands of those in the room who are using Scrum. That’s quite a few of you. How about Scrum-ban? Nice. Now let see a show of hands for people using Extreme Programming or XP. Not as many of you guys here. Who’s using the Rational Unified Process or RUP? Anyone? Who isn’t currently using an agile process, but came here today to learn more about agile? Glad to have you guys here! I hope this session will be informative. So, is anyone using any other process we haven’t mentioned? Yes, you sir. What is your group using?
Um, we’ll, we use a process we call ‘Scrum-but’. We use Scrum, but we leave out some things. [a chuckle is heard from a few individuals].
While such a meeting generally turns to discussing the various attributes of different processes, usually hitting major highlights of Scrum such as iterations, stand-ups, planning meetings, user stories, retrospectives, etc., it still does so in terms of the attributes of different monolithic processes. The deficiency in this line of thinking is that it trains people to think in terms of what percentage of a name-brand agile process their team is adhering to, or should seek to adopt, rather than thinking about what problems these processes individually have evolved to solve. “Which Process Do You Use” is the wrong question.
Are you Agile?
Many teams like to say “We’re an agile development shop”. Now to be fair, when we want to convey to someone which common group of practices we follow, it can be useful to use labels such as Scrum, XP, Scrum-ban, etc. That said, there seems to be an awful lot of shops that say they are agile when what they mean is that they do “stand-ups” (i.e. a daily status meetings for keeping their managers informed about what their up to) and “iterate” (i.e. chunky waterfall) their way to a deadline that’s been handed down by upper management or a sales department.
What is Agile?
If you ask what agile is in a typical development shop today, you’ll more than likely find yourself in a conversation about Scrum or some other process than to talk about the actual meaning of the word. 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 <an agile dancer>
2: having a quick resourceful and adaptable character <an agile mind>
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 may have it’s 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.
Toward An Agile View of Process
It seems that many team’s first foray into agile processes is the selection of Scrum by their management. They’ve heard about this Scrum and how it can save them money, so they’ve sent the managers and Business Analysts off to Scrum Master training to outfit them with their Scrum-capes and Scrum-tights.
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 them 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.
A better approach is to first learn about the types of issues different agile practices seek to address and then consider how your team’s existing process can improve if each practice were applied individually. Rather than thinking of your team as “agile” or “not agile”, consider asking the following types of questions:
Is my team agile WITH RESPECT TO …
changes to the product’s desired features?
changes to the product’s code base?
changes to the team’s understanding of the domain?
changes to the team’s understanding of the technologies used?
changes to team member’s hours of availability?
changes to individuals on the team?
changes to skillsets within the team?
changes to the cost of materials and resources?
changes to the compatibility or availability of 3rd-party software?
Different agile practices address different kinds of problems, but to really become an agile team you need to learn how to identify problems and solutions on an ongoing basis, not just implement processes. Let’s stop thinking of ourselves as agile or not agile and start asking the question “What are we agile at?”