BY| February 24, 2011 | Agile
For long, we have heard complaints about Waterfall, CMMI, etc. The complaints vary from too much process to too much documentation to too much overhead, etc. The fact is that like everything else that has been around for a while, the spirit behind these standards/ certifications/ methodologies has been diluted over time. I know of instances where tons of backdated documentation is generated before the day of the CMMI audit! Much worse, we have all heard of instances where certificates are “bought” out.
However, if you leave aside the negatives that creep into anything that’s been around for some time and focus on the real principle of it, you will realize that the complaining is not so much about too much process/documentation, etc.; it is about being told to do something in a “disciplined” manner. Software is creative and good developers don’t like being told “This is our standard and you will only do it this way!” It is like telling my daughter who is solving her arithmetic problem to write all the steps. She thinks it is boring and a waste of time; I think it helps her from making careless mistakes. Now, reconcile! Today, few developers write their program blueprint on paper before they start hammering on a keyboard. Modern-day editors have discouraged the need for such time-tested practices.
Agile got lapped up because it was pitched as light weight methodology. The point it did not emphasize was – less documented process demands you (the developer) to be more disciplined. Unlike the Waterfall/CMMI methodologies that put a strong focus on review, feedback, corrective action, rework, etc., Agile focused on getting the job done (right) in short time buckets. So, everyone has to develop code as per the standard. Everyone has to be well trained. That is the only way to keep “technical debt” down. Is it easy? No…. it is a lot more difficult. Remember the open book exams in our colleges? I used to dread them compared to the regular exams!!
Now, we are talking about Lean, generally believed to be even lighter than SCRUM. Well, guess what… what is not being said is that it will need far greater levels of discipline on behalf of the development team. How else do you make sure that what everyone is pulling from the queue and working on will finally coexist together in the expected manner? The methodology does not highlight the benefit of “show early and often to get feedback from the customer”. So, a Project Manager now has to have the discipline to make frequent releases and solicit early feedback from the customer. The need does not go away just because the process did not highlight the need.
In summary, the lighter the tool and methodology, the greater is the (maturity and) discipline needed from the development team to be successful; else, it will not all come together when you want it to and in a manner you want it to.
A “part” solution to this desire (to get away from doing extra steps for the sake of process compliance or documentation) can be software engineering tools, ALM tools and development methodologies that help develop generate some of the documentation and structure in the background as the developer continues with his main work – development. Tools that help analyze code for memory leaks or code complexity or generate documentation fit that space. ALM tools, that build complete traceability from requirement to code without a developer going through a painful process to do so manually, fit that space. TDD methodology fits that space. A combination of all these, working coherently (which is far from anything in the space today), can really help focus the team on development and help partially reduce the demand on “developer discipline”. That is what the Development community will embrace.
Senior Vice President, Engineering and Services