When Agile software development was born in 2001, it defined a set of four principles:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
I have worked in several Agile teams where ‘responding to change over following a plan,’ often got misinterpreted to mean “don’t have a plan.” Those teams often find they waste time by adapting too much.
Lindsay McGregor and Neel Doshi discuss this in their current HBR article:
‘Agile processes go awry, because as companies strive for high performance, they either become too tactical (focusing too much on process and micromanagement) or too adaptive (avoiding long-term goals, timelines, or cross-functional collaboration). To avoid this, not only should ideas be formed for a strategic challenge, but they should also be executed with fast experiments aimed at learning just enough to know what works for customers. In other words, they should be maximizing their speed to truth.’
The key is balancing both tactical and adaptive performance.
Let’s balance Agile- with Architectural Thinking!