26 Hints for Successful Agile Development

Keith Swenson, recently compiled a list of 26 hints for Agile software development. Keith suggested that he frequently collects nuggets of wisdom on various topics and the list is a distilled set of hints which really matter for Agile software development.

A comment on his post suggested that most of these hints may not be Agile specific and would be true for better software development and design. Keith responded that, for seasoned Agile practitioners many of these hints might sound routine but there is a larger audience out there who are agnostic to these practices. He added,

I am working with some teams in Japan that use a very strict waterfall model for development. To that team, about half of these are “surprising” and possibly even radical pieces of advice. Things like “write the test before the code” and “never implement before needed” are radical concepts to them. They pride themselves on “completeness” of implementation, to the point of inventing use cases which are not customer driven. The result is overbuilt code, another kind of waste. They wait 6 months sometimes to implement the tests. To those implementing in strict waterfall, the test is a “crutch” that should not be needed by developers doing their job correct. Surprising?

Some of the 'not so common', interesting hints suggested by Keith were,

• Get case 1 fully working before starting case 2. One of the big problems of software development is to start multiple things in parallel, which would inevitably lead to some work which needs to be discarded and hence wasted. The kitchen metaphor is : “Serve the current meal before starting to cook the next“.
• Don’t be afraid to make a decision; don’t be afraid to change an earlier decision. Delay the decision as much as possible and make it when necessary. As soon as new information arrives, don't be afraid to change an earlier decision.
• Measure, measure, measure. Agile development is help address the problem of uncertainty about the future, but there should be no uncertainty about the past.
• Design around people, not systems. Too often developers get sidetracked into designing for technical opportunities. Ultimate success of a software depends upon getting the people to collaborate effectively and add business value.
• Premature optimization is the root of all evil. Intuition of what is important for overall performance is almost always wrong when based only on a static understanding of the code. Instead, measure the behavior of the complete system and then identify the performance issues.
• Never overgeneralize functionality. This is also know as “YAGNI – You Aren’t Going to Need It” .
• Never ever measure code by counting lines. The number of lines needed to do a particular task varies greatly from programmer to programmer, and from style to style. Count the functional use cases
• Software is Plastic. Unlike physical manufacturing, software can be changed in significant ways very easily.
• Don’t invent new languages. The advent of XML is driving an unending chain of specialized custom “scripting languages” which are supposedly making the software development generic. The flaw in this reasoning is that the precise definition of the behavior of the operations almost never well defined outside of the context of a particular implementation

Read more through the complete list of hints and leave a note if you feel that an important one is missing.