Why Agile? The degradation of requirements
Do you ever wonder why we’re talking about agile in recent years but operated in a completely different model for decades before that? It’s a reflection of the speed of change.
Pace of Change
In the previous century things were changing but the rate of change was slower. Products in the early 70s were developed in a marketplace that was more stable. Over the 80s and 90s the pace of technological advancement was growing at an exponential rate. The classic waterfall development model took on average 12-18 months from planning to production. In the 70s it was possible that requirements imagined in the beginning of a project were still valid at the end. However as we get to the 90s cracks begin to emerge. The world is changing at a rapid rate, it was no longer a safe assumption that requirements developed at the beginning of a project were still valid even 6 months later. We began to see projects regularly miss expected launch dates and complex change control systems emerge to try to limit the amount of change. As digital transformation took over the marketplace through the early part of this century the life span of a requirement continued to shrink. A new methodology was necessary.
Agile introduces shorter delivery cycles
Agile changed the classic model by adopting incremental value delivery approach. Instead of a long planning>dev>deployment cycle taking 18months, agile committed to smaller slices of scope delivering value every few days or weeks. This allowed for faster learning cycles enabling the product to better meet customer needs. As technology continues to accelerate the recommended commitment interval has shortened over the years. In the early 2000s sprints typically were 2-6 weeks. Today it’s common guidance that sprints are best sized at 2 or less weeks. I expect to see move toward lean Kanban in the future enabling a constant flow of value further reducing batch size.