Agile methodologies are becoming an increasing number of well-liked nowadays, specifically for little startup groups. Though I’m sure you can find considerably bigger organizations that have achieved success with its technique I can see smaller projects jumping on it much quicker.
To the project team itself agile strategies may look excellent, but convincing management and people that talk enterprise sense it really is an excellent thing is frequently a considerably harder process. I find this fascinating because among the major focuses of agile would be to location the top quality of software over every thing else. As a primary metric, agile and agile meta models (Scrum as an example), focus on making maximum business sense or providing maximum organization value at the end of each iteration.
Ok, so agile makes it a standing point to deliver on what the customer wants at the end of every iteration, but what are the other motivating elements behind pushing agile as a model for delivering actual enterprise value.
An improved feedback and control loop
Agile gives its customers with frequent opportunities to present feedback at the end of an iteration. With this, they can further direct the project in an incremental fashion, driving the next iteration with their enterprise sense, asking questions like “What is of most company value to me proper now?” This iterative feedback from both the client and project team lead to benefits that would otherwise not be available, jumping on new and upcoming technologies and developments to spearhead the next iteration.
These changes and developments have the effect of spearheading the project towards success and an overall greater product. In some cases, it can provide improved return on investment by allowing the product to be deployed a lot earlier. Remember, an iteration focuses on delivering probably the most business value it can. If there is sufficient of that value there, enough to make this enterprise sense just that, it really is worth deploying early to start recouping on costs just before the product has even reached the end of its development life cycle. By the time the project has come to completion, you might properly have recouped half of your initial investment.
It is frequent for a project to be tracking well and suddenly fall behind at a late stage in development. Why? Standard software development life cycle models locate it much harder to judge the correctness and completeness of up front analysis and design. This lack of info at times leads to overly optimistic views which don’t manifest until considerably later inside the project when it’s too late to do anything about it. Do you cut your losses and get out? Or take the risk? Nicely, another strategy to look at it could be to prevent this risk altogether. And by stay away from, we really mean circumvent. As an iterative model, agile performs short bursts of analysis, design and implementation frequently. This gives rise to much more tracking information prior to entering the next iteration to re-evaluate where the project is at and if it is still on track.
The only four variables we truly have control over in software development are: time, scope, cost and good quality. Having the benefit of a model closely tied to these variables typically and appropriate throughout the projects life cycle is a large risk mitigator.
A focus on good quality
This is actually a main location of agile models and comes back to core concepts called the agile manifesto. It is basically saying; focus on top quality software that translates into real business value for the customer each and every step of the way. Deliver this value at the end of each and every iteration, even if it means much less formal practices and documentation is kept. Use customer collaboration as an improvement mechanism and embrace any change that could be coming.
Like extreme programming agile also adopts the practice of pair programming. No discussion on “What makes great business value?” or “What brings very good return on investment?” would be total with out talking about it. It’s usually hard convincing management that making use of two individuals on 1 task is advantageous. The productivity of having two people on one task is slightly lower than every working individually (I’m not going to create up any fancy statistics here:)). So this would raise the argument that pair programming truly costs more! What you can’t as easily measure even so will be the boost in high quality pair programming brings.
Agile promotes information sharing
All info is shared amongst team members, typically with the activities being shared to: analysis, design and implementation (pair programming in the course of development as an example). This info loop routinely filters by means of to the customer too. After all, that’s why they are there, to supply input going into the next iteration.
Agile development however is not necessarily nicely suited to all kinds of projects. Often no matter how tough you try you just can not come up having a excellent enough enterprise reason to justify the model. That’s fine, agile doesn’t suit each and every sort of project modest and big. Just recognize when you may be able to gain the flexibility and momentum it presents.