Adaptive Software Development

I will start by declaring that we have entered the post-agile era for software development methods. There are other software developers who have already said something to this effect, and there's no doubt that the agile movement has left its mark. Many of the premises and principles in the agile development process have been very helpful and useful, but many have been less than useful—and in some cases have been downright damaging.

I will declare further that we are entering an era of “adaptive” software development. The difference between agile and adaptive is a matter of definitions and first principles, but it is also a question of what works and what doesn't. I employ the term “adaptive” somewhat arbitrarily, but it pulls out what is still useful from the agile movement: responsiveness to the realities of the market.

Perhaps the biggest problem with the agile software movement was the tendency to jump in and start coding without doing enough thinking and planning in advance. Agile has become an excuse for skipping the hard work of thinking and planning in advance of doing. The operating assumption in agile is that “we learn more by doing than by writing and reading documents.” I fully embrace the learn-by-doing approach, especially when we are doing experiments, but these can also inadvertently create intractable consequences. The biggest problems occur when half-baked development efforts are put into place as “production code,” and then we build around them.

The most useful aspect of agile methods is that it adapts to changing conditions. With agile we can “adapt” as we learn. We can iterate on ideas until they become useful. This is why I think of the new era as the adaptive era. Adaptation to new information is a crucial aspect of building useful software. But here's where agile has let us all down. It became a reason to leap before we looked. We need to return to an era where we take the time to think through what we're going to do before we do it. We must resist the business pressure to “start coding.” We need to start off with a combination of design thinking and technical planning, in advance of software development.

There are some software professionals who would say in defense of agile that what I'm saying can be applied to agile as it exists today. And certainly this is true. But the fact is that we don’t apply this. The real-world problem is that agile has become infected with the assumptions of “get busy coding now and think later.” Software projects then become mired in their early, half-baked efforts and they carry around that baggage of incomplete and non-integrated code until they can’t move forward any longer.

The adaptive era will include a greater focus on understanding business needs and spending the time to design solutions to well-defined problems. We will spend more time initially talking to users, designers and software architects. We will make sure we have identified the hard problems that connect us all together. We will never get it right the first time, and we don't want to spend so much time thinking in advance of doing, that we never start. We will always adapt and adjust as we learn from the market, but I would prefer to adapt to something that's 80% right at the start, than from something that's 20% right.

‍