How AGILE are you?

December 13, 2012

To be agile means to be flexible. As simple as that may sound; the Agile framework is little more than an effective way to create business flexibility. Even though the basic Agile concepts are easily understood, one needs high levels of commitment, patience and openness to become a true champion of the Agile philosophy. Some people are inherently agile; they prefer people over technology, believe in doing rather than planning for what has to be done, and have more faith in values than official papers and documentation. Companies see the advantage of having such people in their organizations to promote the Agile culture. In Agile, the two extremes of “planners” and “doers” mutually influence each other; the planners begin to successfully work according to their plans and the doers learn to plan successfully before mindlessly “doing” things.  When Agile people form a team, the project is sure to fly, but all companies or teams are not endowed with such people. So, how can a project manager figure out if his or her team members are Agile enough?

If you are that project manager, the first step towards this quest is to find out how Agile you are you. In other words, do you practice the basic principle of Agile? Do you deliver business value consistently while efficiently adjusting to a changing and dynamic business environment? There is no hurry to answer this question with a simple yes or no. Rather, let us look at a scenario and see how Agile you are in handling it. While in the middle of an Agile project, the customer makes a huge change in the most important requirement. You have several responses to choose from. You may decide to start afresh and postpone the release dates. You may spend time planning how to work the change and still be on time. You make seek experts outside the team to handle the situation. Or you may be already prepared to handle the sudden change in requirement and make adjustments to deliver within the stipulated time. If you are inclined towards the last reaction, you are Agile or very close to it.

There is no specific, objective test or assessment which can conclusively determine whether you are Agile or not. However, there are several tests available online which can indicate if you or your team is in line with Agile practices. Even with the tests, there will always be a grey area, because agile is more of an approach or philosophy than a scientifically defined methodology to make your project related problems vanish overnight. Here are a few points that you can consider to gain a better understanding of how Agile you are:

Have the right focus: If you list items according to their importance in a descending order, you will be able to focus on first things first. This will ensure value for the customer. When you have to choose between items from the list to be a part of the release, there’s a fair chance that you’ll choose the right ones that will benefit the client’s business.
Focus on aspects that are under your control: It is good to think of the whole business, but trying to get involved in the entire working of the system may not prove to be helpful. It may dilute focus from your core responsibilities, affecting your work at hand. It is best to channel your attention to things that are within your scope or things that you can control. This way you can work efficiently and also find fixes quickly, if things go wrong at some point.
Improve your efforts: If you are currently working on a project, identify barriers that are preventing the team from the “release.” You will soon be able to find ways to improve your efforts and increase the project’s productivity. You may also be able to understand how team interaction is impacting the project; whether the team members are cooperating with one another or not. In order to achieve optimum results it is important for product managers to constantly communicate with the developers, who in turn have to be in constant touch with the “quality guys.” Good collaboration among members indicates the health of the project. Another idea that you could get from this exercise is that more releases will lead to more feedback. Consequently, your next area of focus can be derived from the feedback.

Apart from studying Agile methodology and implementing it on a software development project, it is quite interesting to understand the degree to which you are Agile. This understanding cascades to the team, where you can find out how much Agile the team is. If you are practicing Agile in your business, it is evident that you know the concepts in it. Practicing the Agile philosophy will help you to build an effective Agile team, which will be a much valued asset to your business. Retrospection, taking action on changes, learning from errors and re-evaluating the learning are attributes of a true Agile team.


Tags: , ,

2 Responses to How AGILE are you?

  1. garland
    November 26, 2013 at 11:54 AM

    Terrific work! That is the type of info that are supposed to be shared across
    the internet. Shame on Google for no longer positioning this submit higher!
    Come on over andd talk over with my site . Thanks =)

  2. February 4, 2013 at 1:41 PM

    One of the common misocnceptions that I encounter with documentation of all kinds (requirements, design, etc.) is the lack of understanding of the real purpose of the documentation, i.e., to communicate effectively. The numbers vary in case studies, but the overall trends seem to indicate that while most people will get it from a picture, there are a significant number who need the textual explanation.From my own experience, I find that using diagrams to illustrate the big picture coupled with supporting text that goes into the details provides the best coverage for all audiences. The ones that only want to get the big picture look at the diagram and the ones that need the details dig into the text.One of the fallacies associated with the use of UML (or any other picture-only representation) is that it is a lingua franca that provides all things to all audiences, a fact that is demonstrably untrue (and for the record, I like and use UML daily). However, it seems that most shops either opt for one approach or the other based on the perception that it’s too much additional work with little return and requires a lot of work to maintain. While I can attest to the rapid pace of change in software development, in really large systems forgoing proper documentation leads to cost and schedule overruns due to things simply being missed because they were not visible.Smaller systems that lend themselves well to agile development should still make some effort to keep things documented. There’s nothing more aggravating to all parties than getting a fair piece down the road and not remembering why that particular path was chosen. I would suggest that while tempo is important, moving too fast is just as bad as moving to slowly.

Leave a Reply

Your email address will not be published. Required fields are marked *


− 1 = seven


Follow Us On

Post-Plugin Library missing