The online writing of a friend set me thinking - and this article resulted.

A friend and work colleague of mine, John Rusk, recently wrote an article about Agile Development which set me to thinking.

There is plenty of anecdotal evidence that projects making good use of Agile methodologies tend to succeed. Moreover, while there are projects using agile methods that fail, the proportion of those seems to be lower than the industry as a whole.

Why is that?

Is it just that the Agile Methodologies themselves are so much better than what we as an industry have done in the past, or is there another factor?

I believe that there is another factor that directly contributes to the success of Agile projects - the people themselves. Let me explain.

Resistance to Change

Most people dislike change intensely. Given a choice, most people will continue with doing the same old things in the same old ways, and getting the same old results that they always have. Software developers are no different in this regard - most of them just want to get their current task finished and move onto the next one.

There are a few people, however, who embrace change. Not simply change for it’s own sake, but change for the better. These are the people who constantly strive to improve what they do, who aren’t content to keep making the same old mistakes, who give the real meaning to the word professional.

Agile methodologies are new - they aren’t well established. So the projects being run with Agile methodologies at present are those being developed by the early adopters. By definition, early adopters are keen on change, and I believe that many of them will be exactly those people who are the true professionals, constantly working to improve themselves and their teams.

Test First Development

Another significant factor is the emphasis in many Agile methods on test first development.

Test first development requires that a developer first write some tests (often just one) for code before writing the code itself. To do this requires both a high degree of understanding about the problem being solved, and an ability to create independent blocks that are easily testable.

If the developer doesn’t have a good understanding of at least part of the problem being solved, or if the developer is not skilled at isolating independent pieces of the problem, Test first development becomes prohibitively difficult. Even for a developer with moderate skills at decomposition, test first development requires a significant change in thinking.

Keys for Success

For a project to succeed using any new methodology, the members of the development team need to not only embrace the methodology, but implement it well. When introducing an Agile method, this requires a team that continually strives to improve what they do, and with sufficient skills and discipline to apply the required techniques.

I believe a significant factor in the success of current Agile projects is based in large part on two key observations:

That the Agile methods are attractive to those developers most motivated to improve what they do; and That the emphasis on Test first development has a “survival of the fittest” effect, eliminating developers who do not have sufficient skill and ability.

Or, to put it the another way, I believe that that a disproportionate number of the industries most talented and productive developers are working on projects using Agile methodologies - and that this is one significant reasons for the success of the approach.

I have had the pleasure of working for a few months with the Scrum approach for project management. I found it quite effective, especially in the way it focusses on getting obstacles out of the way of getting the job done. Our team also found that the visibility afforded by the velocity chart served to almost eliminate the worst nightmare of any Project Manager - the surprise.

Comments

blog comments powered by Disqus
Next Post
How important is assembly language  07 Feb 2004
Prior Post
Generics in .Net  28 Jan 2004
Related Posts
Browsers and WSL  31 Mar 2024
Factory methods and functions  05 Mar 2023
Using Constructors  27 Feb 2023
An Inconvenient API  18 Feb 2023
Method Archetypes  11 Sep 2022
A bash puzzle, solved  02 Jul 2022
A bash puzzle  25 Jun 2022
Improve your troubleshooting by aggregating errors  11 Jun 2022
Improve your troubleshooting by wrapping errors  28 May 2022
Keep your promises  14 May 2022
Archives
February 2004
2004