This post is spurred by a few articles I’ve read recently which have only served to reinforce some similar thoughts I’ve been having for a while now on the constant, competitively toned comparisons between agile and traditional development methodologies.
As I read article after article extolling the wonders of these new methodologies against the weaknesses of the traditional methods, I begin to wonder if the emphasis isn’t too much on agile methodologies over agile principles.
One of my favorite quotes on “agile” is from Alistair Cockburn’s Agile Software Development. He states,
The question for using agile methodologies is not to ask, “Can an agile methodology be used in this situation” but “How can we remain agile in this situation?” A 40-person team won’t be as agile as a six person collocated team. However, each can maximize its use of the agile methodology principles, and run as light and fast as they can creatively make their circumstances allow.
Just as a recent example, take the article Agile and waterfall neck and neck as business side fails to engage. In it we read that agile isn’t being adopted more widely because business executives aren’t involved enough in the process. A couple paragraphs later, we read employing agile methodologies requires a higher skill-set and smarter people.
Of course, I read that and think “what methodology wouldn’t be successful with more business involvement and higher-skilled workers?” Sure, in many cases, the business stakeholders just aren’t invested enough in the success of a project once they’ve sent their order to the kitchen. But by the same token, I’ve known many a business stakeholder that wishes s/he could spend more time on the project and would were it for the fact that proximity, other responsibilities, or any other number of perfectly understandable obstacles keep that business owner from ever being able to reasonably participate in a “daily scrum meeting”
What about the rest of us?
What to do for companies with large, distributed development groups with business stakeholders that, for whatever reason can’t be as engaged as is called for in some of the agile methodologies? What about in the case of companies with workers that aren’t sufficiently skilled or “smart enough” to do all of the tricks required of an agile methodology?
I realize that software is business; people want to sell books, trainers want to sell training on the hot new tools and methods, and consultants are always going want to sell their clients the next big thing, but I think that there is quite a bit of value in just understanding the high-level principles of agile, such as those stated in the manifesto, and looking for opportunities to apply them in sensible ways in your current environment, whatever it may be.
Transformational change might not be affordable or even practical given the current economic environment. I think that the first, and perhaps most productive question we can ask of ourselves is not “what methodology should we use so we can benefit from agile principles?” but, “how can we apply agile principles to what we do today to make it more efficient/effective?
To expand on Cockburn’s notion of applying agile principles, here are a few of my thoughts/hypothetical questions that can be applied to making any methodology more agile:
Individuals and interactions over processes and tools
If meeting with the business on a daily basis isn’t feasible, then what is? Let’s make arrangements to do what is feasible.
How can we get better at communicating with business owners throughout the course of the project?
How can we help the business understand the importance of regular, quality interaction and its importance to the success of the project?
Let’s examine the value stream of our current processes so we can understand what components add value, and which do not. Then, let’s focus on the parts that add value, and cut down or eliminate the aspects that don’t. Any process that has been around for a while has some administrative baggage that can be cut loose. Trust me.
Working software over comprehensive documentation
Are there ways we can focus less on big-thick-documents and the litany of “system shalls” without fundamentally changing how we requirements?
As business analysts, how can we make more effective use of requirements modeling and definition tools and good practices to better serve our downstream customers?
How can we be more iterative and incremental and still complete our deliverables and meet traditional project milestones?
How can we make sure that someone is waiting on and needs the documentation we produce, and not just produce it to complete a task on a Gantt chart?
Customer collaboration over contract negotiation
Can we remove the notion of “throwing deliverables over the wall” that inevitably leads to the analysis-paralysis that so weighs down traditional waterfall methodologies? How can we do things in a more incremental and iterative way?
How can we foster a “team” environment where all members – business owner, user, analyst, designer, architect, develop, QA – are vested in and have a sense of ownership regarding the success of each project aspect or phase?
Responding to change over following a plan
How can we get better at accepting and embracing that we don’t, and probably can’t know everything up front?
Once we’ve done that, how can we get better at incorporating change into our current processes?
I do have just one other comment on agile methodologies with regard to “following a plan” point of the agile manifesto. It seems as some of the methodologies are becoming more mainstream they are becoming more formalized and standard, which, in the end, could make them just as rigid as the traditional methodologies. Take this quote from the above mentioned article:
If you do it all — do every step of the agile process — it works well and is balanced. If you cherry-pick and only do things that makes sense to you and your business execs, the value drops off rapidly. You’ve got to have smarter people to do agile, people who can take the broader view.
Doesn’t that sound suspiciously like “following a plan?” It will be interesting as more companies climb aboard the agile express to watch if/how divisions arise between the agile purists and those that end up using scrum, XP, TDD as just another formal methodology with all the formal boxes to be checked, etc. In other words, how long will “agile” remain agile?
Now that I’ve said all that…
I don’t want to come off sounding like I have anything against the agile methodologies. I absolutely do not. As a business analyst in the 21st century, I think it is beneficial to understand the positives and negatives of all the various ways of delivering software. I think that these methodologies have arisen because the software engineering market had a need that demanded them. They fill a very important niche and help address some problems that have been around for a very long time.
I know that I’ve learned a great deal in my readings and discussions about the various agile methodologies, and, although I’ve never used them formally, I’ve seen my team employ agile principles in order to become “more agile” even though our we operate in more of a spiral model environment.
What are your thoughts on the distinction between agile methodologies and agile principles? I’d be especially interested to hear of ways that you may have made your traditional methodology more agile. How agile do you think a more traditional methodology can reasonably be?
Other articles that may be of interest
Below are a few articles on agile adoption and comparison with other methods written by others that I’ve bookmarked. That’s not to say that I agree with all of the points being expressed, but I did find each article of interest and thought a some of you might also. Oh – one or two of these links might require registration.
Comments