7 Things That Contribute to Agility

There’s some debate about what, exactly, “Agile” means and how to measure it. Agile is the new Quality: everyone wants it, it’s multi-dimensional, and it’s impossible to pin a single one-size-fits-all definition on it. So I’m going to sidestep the issue of how to define or measure Agility and instead suggest some things that contribute to it.

Collaborate. Collaborating means working together, interactively, on a shared deliverable or goal. Pairing is a form of collaboration. Brainstorming is another form of collaboration. Collaborators support each other. They blend their efforts into a cohesive whole. They tear down barriers, complement each other’s strengths, and produce better work as a team than they would if they worked individually. What’s not collaborative? A linear process in which the software passes through a series of phases gated by entry criteria and in which a different group is responsible for the activity during the phase. In a linear process, the interaction is limited to the hand-offs, and the team misses out on the possibility that another group could have contributed tremendously at an earlier stage.

Communicate. Use every channel available to you: face-to-face, video conference, telephone, email, chat, wikis, intranets, big visible charts, tracking systems. Actively seek out and share information. If you have information you think other team members might find useful, share it even if they haven’t asked for it. If you think someone else has information you need, don’t wait for them to offer it: ask for it. For project-level information (goals, key dates, progress reports, test reports, decisions), post the information in one centralized location where everyone can refer back to it.

Create Visibility. At any moment of any day, anyone working on the project should be able to find out, in five minutes or less, the current status including what’s been done so far, what’s left to be done, and what’s getting in the way. Anyone with an interest should be able to see the state of the build (lava lamps anyone?) or the latest test results. Unless you’re working on a high-security project, anyone on the project should be able to look at any project artifact at any time. Tools can help create visibility, but flip charts, cards, and post-its can work well too.

Seek Feedback. Check in frequently with stakeholders to make sure that the emerging system still matches what they thought they asked for. Test. Test early and test often. Test assumptions. Test requirements. Test design decisions. Ask questions. Show whatever you have as often as you can. Don’t wait until you think something is “good enough” to show, or you may discover that your good enough is overkill in some areas and not nearly good enough in others. Ask people what they think and act on the information they share with you.

Reduce Waste. Waste in software can include half done features that are ripped out prior to release, unneeded features, excessive or unmaintained internal documentation, rework such as bug fixes/patches, invalidated test results (such as results for an invalid configuration or data set), and time spent waiting. Waste sucks up resources without adding value for the customer. Want more ideas on reducing waste? See the Poppendieck’s Lean Software Development.

Deliver Frequently. The more often you deliver, the more practice you have at delivering, the easier it becomes to deliver, and the more often you can do it. If you only roll out new software once every 18 months, everyone has forgotten all the steps to rolling out software by the time the software is ready for the next roll out. Don’t let your rollout skills become rusty. Practice rolling out new software often. Even if the users or customers aren’t ready for a new version, make one available. The customers can always choose not to take the latest and greatest. But at least they have a choice.

Adapt. Set aside time every few weeks to reflect, as a team, on how things are done in your organization and how you might do things differently. Consider how your practices support collaboration, communication, visibility, feedback, efficiency, and frequent delivery, and find ways to improve. Consider also how changes in other areas of the organization–changing market conditions, for example–may be affecting the team. Make sure your practices are still appropriate in your current context. Do an honest self-appraisal and find at least three things the team is doing right that should be celebrated. Then find at least three ways in which the current set of practices could be tweaked to make them that much better.


Subscribe to our e-mail newsletter to receive updates.

One Response to 7 Things That Contribute to Agility

  1. Matthew Heusser November 16, 2006 at 6:37 am #

    I’m pretty sure that Mary P. once recommended two metrics for software: Work-In-Process Inventory and Cycle time, and that’s it. Now I’m going to pop out a not-compeltely-formed thought … take this with a grain of salt, but: It strikes me that trying to measure the agile-ness of a project or team is a very modern concept, and the agile movement is inherently post-modern. It’s like a peanut butter and fish sandwich; it just doesn’t work. It’s like asking “How much does a tear cost?” – If we can reach even a semi-satisfying philosophical answer (which I think is what you are going for), I think we should be content.