Agile Thoughts

Why would something that would seem so obvious to an uninitiated observer get so much attention? Bob Martin’s proposal is being discussed here and in other blogs listed below

http://gojko.net/2008/08/08/the-fifth-element-of-the-agile-manifesto/

http://www.infoq.com/news/2008/08/manifesto-fifth-craftsmanship

 The reason why this proposed element in the manifesto receives so much attention reflects on the state of code being written and the lack of quality thereof. Almost every one in the keynote audience at Agile2008 conference where Bob Martin dramatized this proposal by flicking a card high up in the air had faced the problem of code quality.

There are three agile principles apparently in contradiction with each other. “Build quality in” – which expects the developers to get it right the first time. “Re-factor vigorously and continually” which  allows them to write code that needs improvement and “Build fast before the requirements change” which puts time pressure. A good developer should strike balance between these opposing forces. Agile practitioners are advised not to use the license to re-factor as a reason not to get the right code quality the first time. Though all three principles make sense to me and seem worth practicing; its easier said than done.

 When we write code we don’t want to have the pressure of getting it right the first time . We want to deliver working code quickly before the requirements change. We feel better if we have the freedom to do something “quick and dirty” now which can be re-factored later. May be this “later” never happens and the patchy code remains waiting forever for some one to find the time to re factor it. Time is more precious in a time boxed iteration; and one can understand why the “plan to re-factor” remains just that – a plan ; embedded as “to do” comments in the code at best and in the concerned developer’s head at worst.

 That’s probably why Bob Martin proposed the fifth agile manifesto in his keynote address at Agile2008 international conference at Toronto. He proposed that agile should value “Craftsmanship over Crap”. Good clean code is the order of the day. Our customers would not tolerate any more “crap’ delivered as “working code”. Here are a some suggestions for developers to follow.

1)      Write less code: Its found that 67% of the features are never used and 13% of them are rarely used.  So its our job to diligently go to the root of the real customer value we are trying to deliver before we start coding.

2)      Follow design patterns: Good coding practices have been embodied in design patterns – so try to analyze the problem enough till you find a suitable standard design pattern that you can apply.

3)      Review code: Spend more time reading code than writing. Study of code smells and anti-patterns will improve your ability to detect flaws. You can also use automated tools like Find bugs or PMD.

4)      Integrate frequently: Don’t assume that others will understand and use your code the way you expect them to. Gaps in understanding will surface when you integrate your code with others’ code. Frequent integration by regularly checking in and building the code will reduce this gap.

Posted by Vinayak at 07:08 AM | Permalink | Comments (0) | TrackBacks (0)

I  haven’t yet read the book titled “Wisdom of Crowds” written by James Surowecki – but I had the opportunity to listen to his keynote address at the Agile 2008 conference at  Toronto this year. I am convinced about his theory that if a crowd of people having enough background or context is consulted – often their “average guess” is more accurate than that of a subject matter expert. Nothing can be more true than this when it comes to “software product requirements” – the crowd consisting of end users can more accurately tell what is required than the “Product Manager” who in this case is the subject matter expert.
 
 We are perpetually waiting for requirements that seem to take ages to get documented. The concerned business analyst or product manager is always too busy to find time to write down the requirements. This bottleneck is too expensive as a whole lot of resources downstream are simply waiting for the requirements. This eventually results in cost over runs or worst still “half baked requirements”. It is observed that 67% or errors happen due to faulty requirements. There is no data available on how much of this is due to “half baked requirements written under time pressure”, but I am sure it must be significant enough to take note of.
 
To resolve or at least partially address this issue can we not have a mechanism to get the end users involved in the process right from the beginning. Let us give “early access” to our users by having the description of the use cases and pages and forms we are planning to build go up at a public URL which can be accessed  by all. This would serve as an “unofficial requirements page” for users, product managers and all others interested in improving the end product.
 
Here’s a sample screenshot of such a page.

Posted by Vinayak at 12:44 AM | Permalink | Comments (0) | TrackBacks (0)

 T & M has certain intrinsic inefficiencies listed in the myths below. It works better for outsourcing work to “body-shops” than to the tech savvy providers of product development service. It is possible to do agile development in the fixed bid model using the first iteration to elaborate requirements and estimate costs. DSDM ( www.dsdm.org ) which is one of the agile methodologies prescribes this too.

Nothing can be more untrue than this. Most of the customers and product managers know most of what they want when they decide to approach the developer. Many of them have elaborate requirements document covering most of the core functionality to be delivered. The developer can estimate and submit a fixed bid on the basis of such a document. Its true that requirements change later and estimates need to be revised and the requirements document becomes outdated. But having an outdated document and an initial estimate is better than not having any document or estimate.

Agile gives more importance to people over processes and working code over documents. But relying on people as the only way of holding IP is dangerous particularly when you are using off shore teams where factors such as attrition and low loyalty and low experience need to be accounted for. Teams must maintain documents that give insight into the code being developed or else it will be difficult to induct new members into the team.

Design documents not only record what is going to be delivered in the code but also help developers organize their thoughts. Similarly not having a plan with milestones and completion dates is not a good idea. Over all management and cost control would be difficult without a plan. Design and plan documents provide the basis of comparison to estimate extra efforts required when the requirements change.

Myth 5 – Delays happen mainly due to the phenomenon of “requirements creep”; hence customers must allow teams to postpone part of the time-boxed deliverables to the next sprint – in other words, customers pay for the delay.

Developers should share the risk of such delays too. Its the developers’ responsibility to extract requirements in the first iteration by asking the right questions. Time boxing prescribed by the agile model is possible only when enough effort has been taken on elaborating the requirements. Leniency on what is delivered in each sprint leads to inefficient utilization of development resources and hence it should be avoided.

Posted by hemant at 09:33 AM | Permalink | Comments (0) | TrackBacks (0)