Is "Agile Methodology" an Oxymoron?

• done--is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Practices
A practice, as depicted in Figure-1, is a common approach for doing something with a specific purpose in mind. There are no best practices—only adequate practices in context.

Figure-1 – Candidate Practices

 Since so-called best practices are ‘best,’ they also inhibit a “challenge everything” culture and continuous improvement—a pillar of lean thinking. Why would people challenge ‘best’? Mary Poppendieck, coauthor of Lean Software Development, reiterates this point and draws the historical connection from best practices to Taylorism:

Frederick Winslow Taylor wrote “The Principles of Scientific Management” in 1911. In it, he proposed that manufacturing should be broken down into very small steps, and then industrial engineers should determine the ‘one best way’ to do each step. This ushered in the era of mass production, with ‘experts’ telling workers the ‘one best way’ to do their jobs. The Toyota Production System is founded on the principles of the Scientific Method, instead of Scientific Management.

The idea is that no matter how good a process is, it can always be improved, and that the workers doing the job are the best people to figure out how to do it better… Moreover, even where a practice does apply, it can and should always be improved upon. There are certainly underlying principles that do not change. These principles will develop into different practices in different domains...” ^[3]

In Conclusion
Look at a set of agile-lean product (system-software) development norms as musicians do sheet music. Recognizing, the more familiar the musicians are with the musical score and the more experience they have playing together, the less dependent the musicians are on the sheet music; except when introducing new musicians to the musical ensemble. This metaphor is applicable to an agile-lean product (system-software) development team and your set of norms.

We need to though be keenly aware norms should not be rigid or prescriptive and should evolve through collaboration between self-organizing and self-directing cross-functional teams based on reality.

Norm setting can only work if the team is truly able to arrive at consensus. Norms won’t stick if members have reservations about them. However, once consensus is reached, the team is equipped with a guide that can serve to strengthen positive practices. A set of norms can serve as a common reference if contrary behaviors arise. Finally, written norms are handy for potential members and newcomers who want to quickly get a sense of the team’s adoption of being agile.

Starting with a simple, clear and concise set of norms in hand, based on reality, a team can move forward inspired and motivated to uphold the team’s agile-lean product (system-software) development approach, continuously improve and confident in the security such guidance provides.

Given the changing world and the many lessons learned over the past decade we have unofficially refined the meaning of agile software development through trials, tribulations and countless successful (and unsuccessful) agile system-software development projects.

Just like in 2001, when the seventeen like-minded individuals collaborated on creating the four values and twelve principles of the Manifesto for Agile Software Development, and defined the foundational philosophy of present day agile, perhaps the time has come for an official update to the Agile Software Development Manifesto, “The New Agile Product (System-Software) Development Manifesto.” 

We are headed in the right direction by de-emphasizing agile software development processes and methodologies and by elevating the level-of-awareness of system-software development craftsmanship with the likes of the Manifesto for