Listening to the episode I began to realize that people doing Agile value being able to make quick course corrections. They also value being able to change implementations on the fly and to respond to new requests. The speakers mention that working without a plan allowed them to “take advantage of low hanging fruit.”
A light bulb went off over my head. These folks are equating any planning with the problems of waterfall and big-up-front-design. No wonder they think that architecture and planning are the opposite of Agile.
It’s strange too, because in every other meaningful endeavor in life, it’s obvious that a bit of planning pays off. It’s as if big-up-front-design has burned them so bad that they now think any planning is the problem.
I call this the “Agile Planning False Equivalency.”
One of the life changing events for me was when I took the “Architect Master Class” offered by iDesign and taught by Juval Lowy. Lowy shows how to architect projects with simplicity. He calls his method for architecture, “The Method.” One of the brilliant innovations of “The Method” is that there are only a few diagram types and even fewer document types. He’s scrapped UML in favor of simple boxes and lines. It’s light weight. Software architects have used “The Method” on thousands of enterprise projects. Unfortunately, only the alumni of his class are familiar with the practice.
Lacking this training, Agile practitioners create a false equivalency. They equate having architectural plans with big-up-front-design. Nothing could be further from the truth.
In fact, a “Method” informed architecture is like a travel itinerary and guidebook for your vacation. The itinerary and guidebook allow you to coordinate with travel companions and to know what to expect when you arrive.
Just like with the itinerary and guidebook, a “Method” informed architecture does not lock you in to one direction. If you decide to change your plans, now you have a place to start. Who hasn’t called the airlines or travel agent and said, “I’d like to change my itinerary.” If you had to start each call by explaining your entire travel plans, the chance for error would sky rocket. Changes would take a long time.
Ignore the false equivalency. The most Agile thing you can do is to create a project plan. As changes come up, adjust the plan. Keep the forecasting and resource insights, and toss the big-up-front-design.