Vince Lombardi, one of, if not the greatest coach in football history, once said, “Practice does not make perfect. Only perfect practice makes perfect”.

A misnomer is labeling a practice a “best” practice"; a practice is only best in the specific context in which it exists.

My working definition of “practice” is: A practice is a common and adaptive approach for doing something with a specific purpose in mind. When “being” agile and applying a practice we are focused on value-added not the means.

Figure 1.0 depicts candidate practices applicable to “being” agile.

Figure 1.0 - Candidate Practices

When a team is “being” agile, one of the things they will do is self-organize self-direct around practices; selecting one or more practice to apply to an iteration/sprint.

The benefits of which are:

• Iterative incremental adoption of “being” agile
• Gives team a context and narrow focus to rally around
• Provides a non-threatening easy way for team to learn together, “be” agile, apply an iterative and incremental approach, and get better at what they we do

So, let’s take a closer look at two of these practices.

Practice - Mastering the Iteration

Figure 2.0, Figure 3.0 and Figure 4.0 depict an iterative and incremental cycle.

Figure 2.0 – William Deming’s Plan, Do, Check/Study, Act –

Quality Improvement Cycle

 Figure 3.0

Figure 4.0 – Scrum Framework

In all actuality William Deming’s quality improvement cycle of Plan, Do, Check/Study, Act is embodied in Scrum.

When “being” agile, we work in sprints/iterations developing and delivering commercial or operational value incrementally. Iterative and incremental is time-specific/activity-based and product-specific/value-based. The term iteration is time-specific and activity-based while the term increment is product-specific and value-based.

Being agile and applying iterative and incremental development puts the Product Owner (the business or customer representative) in the driver’s seat; communicating and collaborating with the team “what” is to be developed, delivered and deployed, with the Product Backlog serving as their steering wheel.

This approach also puts the Development Team in the driver’s seat. While the Product Owner is responsible for “what” is to be developed the development team is self-directing and self-organizing around “how” to develop the system-software product; with the Iteration/Sprint Backlog serving as their steering wheel.

Applying an iterative and incremental cycle is all about increasing the feedback loop, reducing waste, effectively and efficiently responding to change and delivering often, commercial or operational value.

The bottom line: delivering commercial or operational value early and often, giving ourselves the best opportunity to beat the competition to market, realize revenue and discover insights that we can use to help us improve.

Practice - Three level planning

About the Author
Russell Pannone is the Founder of We Be Agile and the Agile Lean Phoenix User Group, as well as the Agile-Lean Adoption Lead. With almost 30 years of system-software development and delivery experience, my focus is on working side-by-side with folks on real projects helping them deliver valuable system-software to production early and often, giving those I collaborate with the best opportunity to beat the competition to market, realize revenue and discover insights that we can use to help us improve.