There's more to agility than following the four values defined by the Agile Alliance. Take a test of these 11 factors to determine your agile potential. How do you measure up?

January 01, 2005
URL:http://www.drdobbs.com/the-agility-quotient/184415255

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.

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.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.