Agile Releases Creativity, Innovation and Productivity?

Posted by Kevin Brady on Fri 29th May 2009 at 12:39 AM, Filed in Software Dev Methodologies

    Related Articles

One of the key selling points behind the adoption of Agile is that unlike other methods it releases creativity, innovation and productivity through the removal of structure, rules and consistency. I have always considered this to be a myth unless applied to the world of line management. I argue this view more cogently in my post Taylor Vs Deming & Software Development

If you are not convinced by the Taylor Vs Deeming argument then perhaps music can convince you otherwise grin

I am sure you are asking what has music go to do with Agile ?

Well music is full of measurement, rules, structure and is consistently written. A quarter note is a quarter note regardless of where it appears in the music. Furthermore, a quarter note is a quarter note regardless of where it appears in the music script and has universal meaning. If music did not have this structure and rules it would be difficult for a musician to perform a piece of music and impossible for an orchestra to come together and play as a symphony.

All structure in music allows the composer to communicate to musicians how a piece should be played. Composers may speak in differing languages, but they communicate through one form of written music. Music by Wagner was written in his native German but is understood by musicians of all languages.

Written music contains measurement and symbols but you have to be trained to read and understand them. Composers don’t develop their own music symbols or standards. They are all trained to write and read music in the same way. It takes years to learn how to do this and accounts for how some wonderful music can be played all over the world by differing musicians and the music only differs in accordance with the skills, experience and abilities of the individual musicians.
In contrast most IT organisations do not standardize terminology or symbols for their documentation and software developers are renowned for their dislike of writing documentation because it takes them away from what they enjoy most which is cutting code. Perhaps this is one of the many reasons why we have persistent 70 % IT projects fail rates.
Agile supporters work round this issue by supporting increased communication between people in place of this poor or absent documentation. They believe verbal communication can really make up for documentation deficiencies and sell this to project sponsors by relating how much extra code generation you get for your money. If you have ever been to an American eat as mush as you can for $5 dinners then you will know only to well the relationship between cost and quality wink  . Architects know all this is bunkum and its why since ancient time architects always communicate with craftsmen using written documentation and never solely rely on verbal communication. This has taken 1000s of years of trial and error to evolve into this universally accepted approach to the building of complex building s and machines. Anything else would be the equivalent of trying to “reinvent the wheel”.

Communicating requirements without documentation only works in small groups of less than 4 people and it only works during short time durations.  Agile has its place and it’s in the realms of delivering small IT projects. It may be okay for a person doing a small home remodel project to rely on verbal communications instead of written blueprints. If things are not written down people tend to forget them in larger projects this can become a serious problem. For example the number of members of a group dictates how many communications paths exist :-

• If the group has 2 members, then there are two communication paths
• If the group has 4 members then the number of paths increases to 5
• If the group has 10 members then the number of paths increases to 45
• If the group increased to 100 then the number of paths increases to 5000

This illustrates how according to team size the complexity of project communication increases exponentially and communication errors can be magnified in a similar way to the Childs game of “Chinese Whispers”. Bearing in mind the introverted nature of many software developers this situation is only amplified further.

Comparing agile to music once more it is also important to note that music is written in an iterative fashion, but it is important to keep in mind that music is written by only one or two people at most. It is not written by large collective groups. Agile software development in contrast is based on collaborative requirements development among small to large groups of developers. I have to say becoming an expert these days on identifying websites designed by committee. If agile supporters were composers they would prefer to play by ear instead of sight-reading sheet music.

Agile supporters don’t get the fact that analysis documentation is just that. It is analysis documentation. It is how you figure out the problem and the solution. As I have mention in previous posts I am not sure agile supporters would like their houses built using Agile methods and there you have true depth of their belief in agile and its promises of increased productivity, creativity and innovation in the project environment.

This entry has been viewed 1049 times.


No comments yet.


Please feel free to submit relevant comments to this entry but note: inappropriate or purely promotional comments may be removed as will be personal abuse and defamatory remarks. Reasoned debate and substantiated critique on the topic in hand is encouraged and welcomed. Email addresses are never displayed, but they are required to confirm your comments.


Email address is required but will not appear publicly:

Add your comments below:

Remember my personal information for next time

Submit the word you see below:

20 + 2 =