What Does it Mean to Be Agile?
What does it mean to be Agile? Agile comes in many different flavors, and a lot of ALM tools vendors are marketing the heck out of agile. Certainly for myself I had a much different view of what it means to fully adopt an agile practice after reading Ken Schwaber and also becoming ScrumMaster Certified. Agile can come across as pretty wild and crazy at first, especially when you get into the specific flavors. For example in eXtreme Programming (XP) there's paired programming where 2 developers share one computer when writing code; a little odd for many people. And Agile practices have all sorts of new ideas on team compositions and dynamics, like no more project managers. PMP's need not apply at a Scrum shop...well maybe, it depends who you ask and how each shop or team adopts agile.

Principles vs practices: understanding the difference
The Agile Manifesto is the right place to start to find a good baseline definition for answering the question, what is Agile; although this doesn't relate to actual practices but more to a philosophy which can bullet out into a set of principles when most people think of actual practices first. What I hear from most the developers I talk to is that Agile is about short development cycles, daily stand up meetings, improved customer collaboration, burndown reports and empowering developers to make decisions with the last of these being the most known ;) and these are correct aspects of agile, just not good definitions.

There is a lot more to agile aspects as well, not as frequently mentioned. Did you know that agile also recommends working at a sustained pace, like a strict 8 hour work day? Agile recommends face-to-face conversation as opposed to email or phone, simplifying whenever possible, reflection at regular intervals and attention to work environment. To define agile you have to start with the philosophy and principles that are intended to then go on and govern how your team practices agile. So to directly answer the question, what is agile, it is a philosophy governed by certain principles, these principles are then put into practice by different flavors of agile each with its own specific, often overlapping, rules and methods.

Too many flavors? Get the essence
These are basic principles to live by when diving into agile, individuals are more important than process's. The team itself should be able to define, and continuously improve upon, process and methodology: process must be subject to change. Spend time building software instead of excessively writing documentation and create working software. Work with customers during the project’s lifespan, let them see and demo the software increments and be prepared to respond to change at all times even late in the projects life. With this understanding of agile in mind it is easy to see how it can be interpreted in a broad sense and practiced in a variety of ways.

How Can a Tool Help Me Get Agile?
Now that I've spent some time defining agile let's dive into ALM tools and how they fit into the entire agile software development process.

Does Agile need tools anyway?
First, just what is an ALM tool? Like the term 'agile' this phrase can have different interoperations. But we can say in a generic way that it has come to mean a tool, or combination of tools, that plays a major role in the software development lifecycle. Usually there is something for requirements, planning, coding, testing or tracking...and has come to mean any combination of these things.

Where current tools differ (and why some fail)
What exactly makes an ALM tool 'agile'? This is an interesting question to me and my own views go back to the long explanation of what agile means in the first half of this paper.  For me an ALM tool is only agile if helps users adopt and execute agile practices, the ones based on the agile principles, and well known methodologies such as Scrum, XP, Crystal.

There should be something specific to agile in there that goes beyond simple reports. What’s needed is a way to facilitate agile practices like maintaining backlogs, planning iterations, managing common objects like tasks and user story's so that the tool will  go a step further to support  agile practices and not simply promoting good software development habits which should be in all ALM tools.

Don’t be fooled: what to look for when evaluating a tool
ALM tools in the market today are a lot like the development teams I work with, there is a lot of variety in how developers effect software change, and I mean process and workflow of the SDLC.  The degrees of Agile adaptation also vary. Where one team might have gone full blown XP another team might only use a few practices from Scrum. The differences in how you work as a team will impact the effectiveness of your ALM tool. For example a tool with very few agile specific features might be more beneficial to that team which only adopts a few agile practices and vice-versa. Let's go into detail about this by looking at two different ends of the ALM market.

In some popular ALM applications there are really not many agile specific features, least not for someone doing - for example - a full Scrum workflow.

When the decision is made to get deep into Agile then using ALM tools specifically designed for agile practices can have a very positive effect on first adapting to agile practices and second to team collaboration within an agile workflow.  Going all-out agile can come with a bit of culture shock and a definite learning curve and ALM tools geared towards agile can help point the team in the right direction during the those difficult first steps.  Additionally, these types of tools usually have different ways to adopt an agile workflow, because even agile teams with a full adoption can have a process that varies a lot. This is actually a normal feature of agile practice since to be agile is more about following the principles then the specific practices, so what happens is you get a lot of variety in the practices department. I have seen some products describe this type of flexibility in different ways such as Agile-Hybrid. I like to use the term Agile-Flexible to describe tools that can support varying styles or degrees of agile practice but still support all the main principles of agile and many of the common elements in the different methodologies like XP and Scrum (such as stories, task priority and sprint planning, features that are designed for specific agile practices).

I think it is also important to watch out for older legacy products rebranding their features and capabilities as agile. Parallel development is a great asset for any software development team and this is true with many features both agile and legacy in dev tools; features like code reviews, continuous integration or task-based development. This is where I see a lot of creative marketing in ALM tools with their agile claims, taking legacy features and applying them to agile practices, so someone shopping for an ALM tool should first take into account just how agile you want to go, and if you want to go all the way into one of the agile practices make sure to look for specific agile terminology for ALM vendors you research. Words like sprint planning, iteration, user story, story board and other terms specific for the type of agile workflow you want to adopt. A good source for an ALM overview can be found in the CM Crossroads article Behaviorally Speaking - ALM Tools and Techniques.

An outlook: expect solutions to get better at agile
There were many people in my industry who wondered if Agile was going to be something like the Atkins diet. That is to say it would get very popular very fast, and then people would get bored of it and move onto something else, like the South Beach Diet. Agile is very likely to be here to stay, it has seen a lot of success and is still growing. One complication of agile adoption, especially on enterprise scales, will be discerning the truly agile ALM tools from the legacy rebranded ones.

One thing is for certain. Makers of ALM tools, developer tools in general, are paying attention to the trends. A study recently done by Forrester on ALM developer tools that showed 35% of the respondents claimed to be using an Agile workflow, just 13% using waterfall.  Just 'how' Agile is everyone, pretty agile it turns out. As a result ALM tool makers will continue to provide more and more agile specific capabilities and in turn will make it easier for development teams to adopt agile practices. Expect like minded firms to develop strategic partnerships provide more well rounded ALM solutions that share a common Agile vision. As a result,  agile teams can find tools geared specifically to their needs that provide better alternatives than current legacy solutions.

Trackback(0)

TrackBack URI for this entry

Comments (1)

Subscribe to this comment's feed

Justine Bailey said:

... I believe an agile tool should enable business agility, i.e. responding to change not only using the backlog and future sprints to re-prioritize items but also be able to make a quick change to the working application to demonstrate (even if only on a prototype level) a tangible example to business stakeholders. We find often the business doesn't know what they want until they see a working application. For ALM, I believe a free lightweight tool to replace/enhance whiteboards/xls files is the best option, versus heavyweight costly tools which do not integrate at the application level. One example is http://sprintr.com/.

report abuse vote down vote up

May 24, 2011
Votes: -1

Write comment