Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

The Agility Quotient


The Agility Quotient

As the software development industry moves from traditional to more agile approaches, many experienced professionals struggle with fundamental questions about agility. What does it mean to be agile? How can you tell if someone else, perhaps someone you're interviewing for your team, is sufficiently agile? Is there more to agility than the four values defined by the Agile Alliance ? How agile are you?

That's Agile!

In many ways, agility is more of a philosophy than a methodology: People who want to become agile can learn the techniques over time, but even with a sturdy skill-set, a closed mind will find agility a challenge. Furthermore, agility is situational, and, like IQ, difficult to measure. To determine your AQ (agility quotient), examine your skills and attitudes, and rate yourself on each of these 11 factors (See "Determining Your AQ for scoring details):

1. Do you play well with others? Agile software development is cooperative and collaborative-the most important factor of success is how well people work together. Agile practitioners prefer collaborative techniques such as pair programming and model storming because they help to improve work quality and disseminate knowledge and skills quickly throughout the team.

2. Do you work closely with your stakeholders? Stakeholders must at least be integrated into your process; ideally, they should be integrated into your team. Stakeholders pay the bills, so they decide what should be built. To get this done, they must prioritize their requirements and provide information in a timely manner. Agile practitioners apply inclusive modeling techniques that use simple tools such as whiteboards and paper, as well as simple notations, to enable stakeholders to actively work on the project.

Determining Your AQ
Rate yourself honestly on a scale of 0 to 5 for each of the 11 agile factors. Zero means you completely disagree with the statement, while 5 means that you've "lived that philosophy for years. Add 10 points for thinking that a point- rating system isn't exactly agile.

Less than 10 points: Crusty traditionalist; hope you’re planning to retire soon.
11–20 points: Agile wannabe; you’re on the right track.
21–35 points: An open and curious mind; fertile soil for agility.
36–60 points: Agilist; you have a great future ahead of you.
61 and above: Raving agile genius; watch your back for disgruntled traditionalists.
3. Are you feedback driven? Without feedback, the requirements you're working on could be wrong and you wouldn't know it. The best way to elicit feedback is to work closely with others-instant feedback is the best. You can also ask someone to informally review your work after the fact: After you've sketched a design strategy on a whiteboard, for example, walk through your approach with an experienced team member. Or have a colleague test drive the working software that you've built to date.

4. Do you focus on creating working systems? The creation of a working system is the primary measure of success. Everything may look great on PowerPoint slides, in architecture documents and on whiteboard sketches, but you don't really know your stuff's got the goods until you prove it with code. Aim to deliver a working system that meets the highest-priority needs of your stakeholders in a timely and cost-efficient manner. Early in your project, you will have deployed only a partially working system into a shared demo environment, but this counts, too.

5. Are you change friendly? Your system's requirements change over time. As your stakeholders see you deliver working software, they may realize that they didn't understand their needs, or changes within their working environment may necessitate different system requirements. Agile practitioners understand and accept the fluid nature of the field and use requirement changes to improve the utility of their delivered systems.

6. Are you "test infected? Most agile practitioners prefer a test-driven development (TDD) approach, in which they iteratively write a small unit test before they write a bit of business code. TDD lets you demonstrate that your code works at any time because you've built up a complete regression test suite.

7. Are you "quality infected? Agile practitioners strive to develop the highest-quality product possible because it's easier to maintain and enhance something that's well built. They refactor their code mercilessly, making small changes to improve its design without changing its functionality, to ensure that their work is the highest quality possible at all times. They also adopt and follow development standards; coding standards are quite common, as are modeling standards.

8. Do you focus on value? Agile practitioners actively seek to maximize stakeholder investment by focusing on high-value activities, implementing the highest-priority requirements (as defined by their stakeholders first). One way to increase your return on investment is to travel light: Dump the extraneous documentation and create models and documents that are just barely good enough for the job at hand. Ensure that non-production products and tasks remain focused and as small as possible.

9. Do you actively seek to learn? Agile practitioners know that they don't know everything, that others can make valuable contributions, and that whenever they work with someone, they have an opportunity to learn something new. Furthermore, good agile practitioners read about new techniques, take training courses and are mentored whenever possible.

10. Is your approach flexible? You can't be agile if you have only one way of doing things. For example, some developers think their design through by sketching on a whiteboard before they code; others use a software-based modeling tool; still others dive right into the code. On a project team of 10 people, chances are good that at least one of each type is represented. To work with each person effectively, you must be prepared to accommodate your partner's work styles and preferences, just as he must change his approach to conform to your unique quirks.

11. Do you reflect on, and then adapt, your approach? Agile practitioners and the teams they work on analyze what they've done and how they've done it, so they can better identify what works well and what needs improvement.

That Ain't Agile

It isn't enough to understand what it means to be agile-you should also be aware of antipatterns that reveal you may not be as agile as you think. Common challenges include:

  • A predilection toward a serial process-agile practitioners work in an iterative and incremental manner.
  • An insistence on modeling everything in detail. You don't need to get all of the requirements down on paper first, nor get them right the first time. More importantly, your team, including stakeholders, must share a common vision and work cooperatively toward that goal.
  • An insistence on having a job title. If you're willing to only write code, only gather requirements, or only work on the database, you're nowhere near as effective as someone willing and able to do all three. In general, if anything is "fixed/baselined, it's a sure sign that you've needlessly constrained yourself. Notice that I haven't claimed that you need to have ¼ber-developers to succeed. Yes, your team does need people with basic development skills, but the true determinant of your agile potential is your philosophy and attitude toward software development.

Thanks to Brad Appleton, Philippe Back, Larry Brunelle, Steve Cohen, Steve Gordon, Mark Graybill, Kirk W. Knoernschild, Kent J. McDonald, Colin McDowell, Paul Oldfield, Scott W. Preece, Peter C. Ruth and Jianfei Yin for the input they provided regarding this issue.


Scott Ambler is a senior consultant with Ronin International Inc. His latest book is Agile Database Techniques from Wiley Publishing.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.