Agile: Bits vs. Atoms?

Building on the frustrations now evident at the basis for the Agile Manifesto’s creation, where did the current project management best practices seem to go “off-rails,” when this previously venerated philosophy had worked so well in the heavy construction, civil engineering, and physical product development environments? The answer to this question lies in understanding one of the causes for such an alarmingly high rate of failure when IT projects are attempted using this previously universal form of project management philosophy.

The themes or indications of application for Agile methods illustrate a point that seems to have been missed by many project management thinkers and philosophers when understanding why so many IT projects fail. For proof of this statement, check out the Standish Group’s often quoted project failure studies of 2003 and 2009.

As mentioned previously, a strong basis for the project management “current best practices” of stringently defining requirements with copious amounts of documentation had their roots in the construction industry of the 1930-1960’s when humans were doing some of the most complex building projects outside the ancient projects of antiquity. Software development, however, is an entirely different endeavor from hard construction, and to apply concepts involving the creation of physical artifacts to the construction of computer applications appears to be a fundamental misunderstanding of the core difference between these types of projects, and that is:

The physicality of the deliverables, where hard construction delivers physical artifacts (atoms), and software projects deliver non-physical artifacts (bits).

The 17 signatories of the 2001 Agile Manifesto were software engineers attempting to deal with the frustration, overhead, strict, and probably inappropriate nature of normal project management methods when applied to the computer software development environment. The need to define requirements when producing ‘atoms’ overly constrained the software project where deliverables are ‘bits.’ Agile style methods appear to solve the problems of managing work product when the deliverable is not physical or analog, but digital in nature.

This difference in deliverable physicality is at the heart of the current Agile revolution where software project management is finding its own voice in managing “bits” to a successful outcome requires very different methods than managing or producing “atoms.”

With an understanding of Agile, its values, and principles as a foundation, the next discovery phase needs to uncover the move of Agile concepts into the larger realm of general, or non-IT project management. This leads to the question:

What is Agile Project Management (APM)?

Is APM an attempt to apply the values and principles of the Agile philosophy to the problems of “atoms-oriented” project management? Can these values and principles hold up when the deliverable is not “bits,” but atoms in varying shapes and sizes?

To put a finer point on it: could the Millau Viaduct in France have been built using the values, principles, and practices of Agile?

Are the values and principles of APM different from those of the Agile Manifesto?

What is common amongst most of the practitioners of the Agile philosophy of project management is that is works well in certain areas of application, but there have been few case studies of application when the deliverables are “atoms” and not “bits.” The project management blogosphere has had significant discussions on the use of Agile-based methods for large projects such as the Boeing 787 Dreamliner, the new third lane of the Panama Canal, and the previously mentioned, Millau Viaduct in France.

Research and discussions on applying Agile-style methodologies to large, more complex projects are continuing with some early results showing that regardless of the task, the most effective team size for an agile type project is 7 +/- 2. This is also known as the “two pizza rule,” a phrase coined by Jeff Bezos, Amazon’s Founder, when describing when a team size was too large.

The aspect of Agile’s appropriateness to general project management endeavors still seems stalled at the physicality boundary. Agile has a recent history of applicability in small, very contained project teams where the primary tenets of the Agile philosophy as embodied in such methodologies as Scrum can play out in a supported environment. Scrum has emerged as the predominant implementation of the Agile philosophy and it has some basic rules or guidelines that should be met when using an Agile/Scrum style of project management:

• Team size: 7 +/- 2
• Project/Product Owner: on site and intimately involved with Scrum team
• Daily Stand-ups: 1-3 15 minute meetings where team members inform on their progress, expectations, and potential problems
• Iterations: delivery of working components frequently and demonstrable
• Use of white boards and sticky tags for work-product progress
• Mutation of requirements over time with Project Owner able to change requirements often and sometimes in a significant manner.

While these practices of Agile/Scrum appear to be quite appropriate for software deliverables (bits), they do not seem appropriate when the deliverable requires a physical artifact or product prototype. For example, once the machinist has milled the spindle down to 4.3 cm +/- 0.5mm, a change in requirements to 4.8 cm +/- 0.5mm would require rework and waste accumulation. This is the point concerning the difference between the physicality of the software project and the physicality of the non-software project: bits can be altered without waste.

Stay tuned for Paul’s next blog installment on the differences between Agile and traditional project management’s workable practices and don’t miss his presentation at ACQUIRE on June 9, 2016 at 12:15 p.m. on the show floor.