James W. Grenning

Agile transformations often start with good intent but are flawed in the approach. Your development people have been working under the waterfall and a manufacturing mindset for years. Now you want to iterate and do Sprints. They hear the word “Sprint” and think of the Olympics.

You have seen the sprinters after the big race. You don’t expect them to hop up off the ground and start running another sprint, although we expect that with our Agile teams. Developers are told to go to a Daily Scrum or stand-up meeting, which feels like micromanagement. They hear the title Scrum Master and think they are subordinates. They feel they are being rushed. They don’t see the rat race coming to an end. To development, the initial reaction to the two-week cycle is that quality does not matter. All that matters is getting the feature out.

I’ve seen this pattern over and over again. The cause of the pain comes from starting incremental management without investing in incremental engineering and development skills. There are visible problems you will likely see when introducing incremental management without incremental development. You will see that developers do not complete their work in the iteration more often than they do. You will see the bug list grow, shortcuts taken, the code degraded and developer morale going down the tubes.

This pain can be avoided by investing in your development people. Help them grow their incremental development knowledge, understanding, and skill. The skills needed to be successful at incrementally developing a successful product are not a secret. Kent Beck cataloged them in 1999 in his book Extreme Programming Explained (Addison-Wesley Professional, 1999). Extreme Programming (XP), along with continual learning of design, works for incremental development. You will likely see more of your planned content delivered on time. You will likely see a smaller or nonexistent bug list, higher-quality code, and higher developer morale.

Incremental management practice without incremental development skill is a recipe for pain. Great things can and will happen when you combine incremental management with incremental development. Scrum does not prescribe what your development practices should be. However, Scrum does require you to have them in place; as such, standards and agreements are essential in transparency and empiricism.

My advice: start growing awareness, knowledge, understanding, and skill in incremental development. The fact that traditional development does not fit into an incremental management approach is more than a development problem—it is a system problem.