small refactr logo
At refactr we believe in the value of connection, the utility of agile processes, and the power of great ideas. We are creating the next generation of software for people who expect more from their web applications.
refactr
« Help! Google stole my data | Software is hard. It’s a pain in the process. »


You call that Agile?


Many companies are throwing around the term agile when defining who they are and what they can offer but, as the Agile In Action blog points out, many may not be practicing what they preach.

In this post I have collected some of the telltale signs for use when determining if a company is truly agile:

“Notice the characteristics of communications with the company. One of the things I notice are the amount of red-tape involved in setting up any meetings. The more paperwork the worse it is likely to be. Long company email signatures can be the first clue.

Companies with dress down Friday who display a large cardboard cut-out of what garments constitute casual wear want drones and probably don’t encourage new ideas. Motivational posters decking the walls could be a hint that the management team is clueless.

Companies with very swish offices tend not to understand the need for developer messy thinking tools such as whiteboards. Conversly, companies whose offices look in a poor state of repair are probably also neglecting their computing infrastructure so developers will have a hard time setting up development environments, etc.

A clue that teams may be open to new ideas can be books (fiction or technical) and newspapers around. Personalised team environments can hint that the team are trusted and allowed to make changes in their space. Seeing developers talking to each other around a whiteboard or screen rather than with headphones on can also hint that they are open to reviewing ideas with their peers.”

[Rachel Davies]

“It‘s difficult to characterize an entire organisation as ‘Agile’ without working with them for a while either as a partner or as a member of staff - you need to assemble some tacit knowledge about that companies’ culture and decision making process.

It‘s much easier to analyze a specific product development team as you can look at their environment, team identity, output etc. There are a couple of properties one can extrapolate from such a team to it‘s surrounding company - is the team empowered to perform its function? is there respect between the team and the company? does the team have a clear project charter and product owner? You can get a pretty good feel for what the company is like from these kind of indicators.

It‘s also good to look at the relationship the company has with its partners and suppliers - do they enter into mutual benefit partnerships and work proactively with suppliers to improve both companies’ positions? Essentially you’re trying to determine how much trust exists in these relationships - it‘s not the only indicator but it is a useful one - it allures to the underlying culture of an organisation.

Structurally I would expect an Agile organisation to be ‘wide and not deep’; management hierarchy and bureaucracy is kept to a minimum with workers being aligned along product streams rather than into functional hierarchies such as ‘technology’ and ‘hr’.”

[Gus from JavaShed]

“If Agile means responsive to change then I would compare their company literature from today and five years ago. Are they selling the same products with the same features that they were in 2001? A comparison of product features and product mix over time might hint at their ability to change direction quickly.

If Agile means lean then I would get a feel for their levels of waste. If it costs them $1000 to put up a $100 whiteboard, then they’re probably not Agile in that sense.

If Agile means self-organising then I would get a feel for their levels of bureaucracy. How much discretion does the most junior person have in the execution of their responsibilities? Can the receptionist order more pencils when she needs them, or must it go through purchasing and be approved in writing by her line manager’s line manager’s line manager?”

[Jason Gorman]

Here are a few of my own:

  • Email the CEO, President, or other bigwig and see how long it takes to get a response and, also in what form that response comes (form letter sent by a receptionist, etc.). Agile companies won’t send form letters or take more than a couple days to respond.
  • How long does it take the company to pay its vendors? Do terms such as net30 get brought into the conversation? In an agile company bills are simply paid.
  • How long does it take to get to a working prototype? Can you see the progress after the first week? Month? Agile teams can show you software in days and weeks, not months or more.
  • Call the company. Do you get to a person right away? If there is a phone system (bad sign); is the menu clear? Can you get to a person within a minute? Agile companies answer the phone and simplify communication processes.
  • Is the company’s website organized in a clear and concise manner that allows you to easily understand what it is they do or does it look like it was developed by committee to serve internal interests? When was the last time it was updated? Agile companies are customer-centric and seek to provide you what you need in a timely manner.
  • Do they use an RFP process for vendor work? How detailed do they get in the information they seek? How long does the process go on before a meeting is scheduled? Agile companies can schedule meetings efficiently and do not require unneeded paperwork and data collection.
  • Ask 3 different people what the company does, or what its primary goals are and see how much variance you get in responses. In an agile company everyone on the team should be able to speak to overarching goals of the company in similar ways.

It is important to note, that all these things are simply the trimmings that come with being agile. Even the idea of “being agile” is a bit slippery. While doing these things does not make a company agile, they could indicate agile values. The values of the agile philosophy: Individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan and putting those values into practice is what being agile is all about.

This entry was posted by Ben Edwards on Monday, January 29th, 2007 at 4:10 pm and is filed under Agile Processes, Business. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Further Discussion (One Response so far. Add yours)

  1. Ben Edwards said...
    Man, how did I miss this great post: The Smells of Agile, in which Coté at Redmonk describes 9 distinct ways to determine if a group is agile. My favorites:

    4. An Agile organization values putting off a decision for as long as possible, but, still makes many decisions.

    and

    9. An Agile organization operates on trust, respect, and
    delegation instead of command and control.

    Nice work, and nice site.

Join the Discussion