Adaptive Execution Part 2: The Art of “Being” adaptive rather than “Doing” Adaptive

Last week I posted an introductory piece about Agile, its manifesto and issues I have seen teams face while trying to adopt Agile. I plan to discuss 5 out of the many Agile principles in a total of 5 posts. This post is about the Agile principle that states,

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software"

Challenge faced by non-software project teams while interpreting this principle

Continuous delivery of software means, development is broken into modules/features that can be completed in a 2 week time period. This ensures that every 2 weeks some tangible feature of the software is released for consumption, instead of waiting for months for release of the full package. What does “Continuous Delivery” mean for non-software deliverables? Team members on such projects typically feel that their tasks (lab testing, product design, CAD model, etc.) are not at all similar to software and hence cannot be broken down into smaller chunks for "Continuous Delivery". They feel that even after being broken down into the smallest possible chunks, these tasks take longer for completion and there is no way these can be completed in smaller, 2 week intervals to demonstrate tangible progress. 

In the non Agile world of traditional Project Management, teams use work breakdown structure which strives for smallest possible chunks. Yet even these “broken down tasks” can look something like this:

Configuration & SIT of equipment: 6 weeks

Facility readiness: 12 weeks

I am sure many of the readers have seen such long duration line items on Gantt charts. Such tasks with longer duration have higher overall risk due to less transparency, less frequent review and potential negative impact on timing, quality and cost. This is especially true if the task is outsourced.

How does Adaptive Execution address this?

a) First and foremost, the word Agile, triggers images of a software related project.  Just the use of a different name, “Adaptive Execution” overcomes resistance to adoption for non-software projects.

b) Secondly, Adaptive Execution focuses on enabling a paradigm shift for non-software teams. This is enabled by working with teams, coaching them on migrating actual work projects from Waterfall to Adaptive Execution methodology by creating backlogs, guiding them through scrums and sprints till they can run on their own. The focus is on creating an organizational mindset and belief that teams CAN deliver tangible output in 2 weeks chunks, no matter what type of deliverable. Period. 

Outlining tangible deliverables even for such non-software projects on a daily, weekly and bi-weekly basis is the art and science involving estimation, self-organizing teams and continuous learning from past periods. Results achieved with Adaptive Execution on one particular project are listed below.

This level of breakdown to 2 week chunks and continuous focus on a daily, weekly and bi-weekly basis, to provide transparency and improve the ability to react to blockers; while deceptively simple and seemingly common sense, is something foreign to many non software projects and organizations. This is due to the difficulty of cultural change required for ensuring success of this methodology.

What is your experience in improving project execution at your organization? What success stories can you share?      

Atul is a Partner at CERTUS+ (CERTUS Management Consultants, LLC)

CERTUS+ will be presenting its paper on Adaptive Execution at the Project Management Institute (PMI), India, Research & Academic Conference at New Delhi, India, March 2nd to 4th

Connect with Atul Kalia on LinkedIn & follow on Twitter @_AtulKalia to stay in touch.