It seems that everyone is moving to an Agile approach in their product (or software) development lifecycle. Some move with great success, some with great fanfare and for some it’s one of the last moves their company and engineering organizations make before failing miserably and shutting doors permanently. As often as not, companies just move because they believe it will cure all of their problems. As we’ve written before, no new PDLC will cure all of your problems. Agile may in fact be best for you, but there are always tradeoffs.
We’ve compiled a top 5 misconceptions about Agile from our experience working with companies to solve problems. Be careful of these pitfalls as they can cause you to fail miserably in your efforts.
1) Agile is NOT a reason to NOT manage engineers or programmers
Engineering organizations measure themselves. In fact, many Agile methods include a number of metrics such as burn down charts to measure progress and velocity for measuring the rate at which teams deliver business value. As with any other engineering organization, you should seek to find meaningful metrics to understand and improve developer and organizational quality and productivity. Don’t let your team or your managers tell you not to do your job!
2) Agile is NOT a reason to have engineering alone make product decisions
You still have to run your business which means nesting the product vision to the vision of the company. More than likely you are paying business or product people to define what it is you need to do to fight and win in your market. Someone still has to set the broad strategic vision to which products will be developed. Engineers can and should contribute to this vision, and that’s where Agile methods can help.
3) Agile alone is NOT a cure for all of your product delivery problems
As we’ve blogged before, there simply are no silver bullets. With the right management and oversight, you can make any development lifecycle work. There are just cases where Agile methods work better. But don’t look to have a PDLC fix your business, people or management issues.
4) Agile is NOT an excuse to NOT put in the appropriate processes
There is nothing in the Agile manifesto that states that process is evil. In fact, it recognizes processes are important by stating that there is value within them. Agile simply believes that individuals and interactions are more important – a concept with which we completely agree. Don’t argue that all process is evil and cite Agile as the proof as so many organizations seem to do. Certain processes (e.g. code reviews) are necessary for hyper growth environments to be successful.
5) Agile is NOT an excuse not to create SOME documentation
Another often misinterpreted point is that Agile eliminates documentation. Not only is this not true, it is ridiculous. The Agile manifesto again recognizes the need for documentation and simply prefers working software over COMPREHENSIVE documentation. Go ahead and try to figure out how to use or troubleshoot something for the very first time without documentation and see how easy it is… Programming before designing coupled with not creating useful documentation makes one a hack instead of an engineer. Document – just don’t go overboard in doing it.
