Seven Subtle Stumbling Blocks to agile Development

Beyond the hype to sound critical thinking: truly inspecting and adapting

Projects that make their first moves to Agile development often suffer from Brook's "second system syndrome" by over-reacting to the problems of traditional development. This may be the reason that even advocates of some Agile techniques openly share that half of their projects fail. Years of experience with Agile false starts shows that there is a short list of commonly recurring root causes—errors that are easy to anticipate and, with discipline, to avoid.

Many projects—particularly those with a history of using traditional development—should adopt Agile practices gradually through local adaptation with feedback. In the long term, most projects will find that they can work most optimally with a combination of traditional techniques and techniques consciously designed to provide an "extreme" contrast to the wisdom of software engineering. Successful projects are agile in balancing these two.

This tutorial first looks at the top seven mistakes that projects make in being overly ambitious in adopting Agile approaches too quickly or in discarding good practices that work:

    • using Agile as a fix without knowing the problem;

    • feigning ignorance through YAGNI instead of planning;

    • creating incredible overhead with little benefit through overly granular unit testing;

    • using procedural testing as a design tool, which leads to hierarchical procedural designs;

    • being customer-centric instead of task- and context-centric, leading to unusable systems;

    • fascination with a single customer instead of planning for the success that comes with many customers;

    • being Agile instead of being adaptable.

We also take a summary look at Jeff Sutherland's Seven Ways to Fail with Scrum:

    • failure to meet the Nokia Test

    • product Owners not doing their job

    • sprint planning Failures

    • ineffective communication at the Daily Meeting

    • unfocused ScrumMaster

    • team failure points

    • sprint review Failure Points

    • management failure

Attendees will learn foundations that will enable them to decide which old practices should be phased out in favor of Agile practices and to sustain a balanced development program.