Get certified - Transform your world of work today


How to and Not to Introduce an Agile Delivery Methodology Within an Organization

5 December 2012

The process organization at one of the largest global automobile giants delivers several hundred projects and manages several system change-and-upgrade activities, in addition to maintaining IT operations. The project delivery methodology employed was a hand-me-down version that came from the parent organization in Europe several years ago. The process had components that were still relevant, but others were dated and did not meet the current needs of the project delivery teams. The process was tedious and confusing, and it contributed to significant delays in delivering even three-day projects, leaving stakeholders angry and frustrated with every interaction.

Recognizing the need for a delivery process that would change these inefficiencies, the governance folks embarked on building a process that would eliminate current problems while allowing quick delivery of projects. The journey to bring change to the project delivery process transitioned through several change managers and finally landed with someone I will fondly refer to as "Mack."

Mack was ultimately able to finalize and implement the much-awaited project delivery process, but it was a tough job. What he inherited included thoughts and decisions lost during personnel transition. He did not evaluate or conduct a survey to validate the profile of the change characteristics, nor did he ensure a system for participative or consensus management (Burke, p.40).

In addition to maintaining continuity and ensuring minimal loss of progress made, Mack was to ensure that the change process addressed these issues:

  • Elimination of process ambiguity. Accelerated path to complete requirements.
  • Prescriptive assistance to project managers in setting up project plans, requiring review and approvals. Elimination of the need for the PMs to have to understand what everyone else in organization was doing.
  • Improved clarity about how to get a project initiated. Improved quality control, such as having deliverables reviewed/approved by the specialists most appropriate to do so.
  • Shorter project durations and better tracking to original budgets through an improved statement of requirements for vendors. Improved tracking of project funds resulting in a reduction of unspent project dollars.
  • Elimination of purchasing process delays for projects using the accelerated path. Improved clarity as to what was in an approved project portfolio.

Mack quickly learned that he was heading an initiative filled with obstacles. There were some things he did well: Using his his strong network within the company, Mack learned the reasons why the past change managers couldn't deliver the process, as well as the resistance they faced. Mack used this knowledge effectively (Weisbord, p. 204) by having the resisting members be a part of the team. He adopted a collaborative approach rather than a prescriptive approach to deliver the new process. He also made the important step of setting up a task force (Weisbord, p. 211), with leadership commitment and representation either directly or through a proxy.


Analysis of the change-management strategy

Mack created a stakeholder community from among the key players within the organization who could either support or derail his progress. He carefully chose personnel from groups that had the ability to influence their department heads and their peers. After several iterations with the team, the new project delivery process was finalized, approved, and implemented.

Mack implemented the new delivery process with a big-bang approach, because he felt there was a potential for confusion if the delivery process were phased out. He did not incorporate such strategies as systems thinking, enabling staff to experience the entire change rather than just their area of work (Weisbord, p. 312). In addition, he had to adjudicate projects in flight and also ensure that the support and governance teams knew how to evaluate and support a project if more than one approved delivery processes was in play. The process reflected Theory X (Weisbord, p. 5) — the process that had 17 steps now had 192 tasks to be completed.

Mack collected observations and information about behavior, as well as information about obstacles from past change-management initiatives. However, the data he collected lacked structure and was not based essentially on the change strategy; his sole agenda was to make sure that the stakeholder group would buy into the change strategy. He made an assumption that the inputs he collected would influence and shape his strategy for the future delivery process. He interpreted the collected data on his own and used it to build the transformation plan. The future plan lacked clarity, as metrics were not clearly communicated or quantified and were left ambiguous (Weisbord, p. 209).

Mack and his predecessors did not employ a formal change-management model. However, the process they went through can be mapped to the nuances of the Nadler-Tushman Congruence Model (Burke, p. 198). Mack had inputs ranging from environment, resources, history, and past strategies, but he did very little primary data collection or validation. He was implementing change that would transform the way projects would be delivered across the entire organization, and by missing the user group in deliberations, the predictability of acceptance of the outputs from the transformation process was diminished. Within the transformation process, while the organizational component and the informal organization components were addressed, task component and individual components (Burke, p. 201) were completely ignored and were off track.

Mack did not ensure direct participation of all impacted parties (Weisbord, p. 97) to validate accuracy of the collected data. In addition, there was not much evaluation of the implemented process except to reactively suggest a second release of the process delivery model that would bring back some of the components that had been advantageous but were omitted in the new delivery process. He failed to accurately judge the pain points and validate them. Conversations with Mack and the group that had to survive the delivery process change revealed that the entire change-management plan had several errors that are important to understand in order to recommend how the change could better have been implemented:

  • Tasks that actually worked well were removed from the delivery process, creating resistance.
  • There was an assumption of positive employee commitment.
  • Communication was infrequent and sometimes lost; there was no sense of urgency or importance.
  • Employees had a sluggish approach, as they had heard about this way too many times.
  • Few employees were ready for change, creating increased resistance to predictable change.
  • There was no proven model for a process that impacted projects worth millions.

Mack had to wade through the politics of the organization and the political resistance (Burke, p. 109) of self-interested groups. He handled the entire initiative with candor and tact. But the biggest mistake he made was to omit the primary consumers of the new delivery process from the get-go. The methodology was introduced, but it failed miserably, leaving a new set of frustrated individuals who were lost and had even less support from the stakeholder community.



While the new project delivery process has been in play for the past quarter, what Mack or any change manager could have done differently was to follow a proven transformation process model to ensure sustenance. Mack should have ensured that the impacted staff could let go of their current inhibitions, understand and be willing to adopt the change, and be in the mode of using the new process as mapped to unfreezing, changing, and refreezing (Burke, pp. 165, 166, 167). I would recommend using John P. Kotter's eight-step transformation process (Kotter, pp. 96-103) and performing change using the steps detailed below:

Step 1: Establish a sense of urgency.

  • Include key staff as stakeholders.
  • Create awareness by underlying the thrust toward the new project delivery process.
  • Change perception of past failures of the new project delivery process initiative.
  • Promote a sense of urgency by leveraging leadership staff whenever possible.



Step 2: Form a powerful guiding coalition.

  • Create a coalition with a substantial number of powerful members from the user community.
  • Use the powerful coalition to maintain the momentum for change.
  • Ensure unanimity within the coalition, or it will be the strongest obstacle.



Step 3: Create a vision.

  • Overcome impediments within the coalition early, or they can become stronger with time.
  • Collaborate with the coalition to develop a shared vision of the future project delivery process.
  • Prepare the coalition to influence the remaining staff needed to adopt the vision.



Step 4: Communicate the vision.

  • Create convincing communication for staff that makes them embrace the transformation.
  • Communicate the vision frequently, using credible sources and every vehicle possible.
  • Capitalize on the fact that the majority of the staff will make sacrifices if change is articulated with long-term efficiency gains.



Step 5: Empower others to act on the vision.

  • Resistance to project delivery changes is based on several reasons, including self-interest, the fear that critically successful components are being abandoned in the new process, and blind resistance (Burke, p. 109). These concerns must be removed early on.
  • The coalition then must empower others to take action appropriate to their levels and remove any additional obstacles that prevent them from accomplishing the vision. Mack should have played the role of an executive coach, or had someone else in that role. Coaching for performance would show that peoples' roles and the metrics on which they would be measured would change along with the changes in project delivery.



Step 6: Plan for and create short-term wins.

  • Delivery staff will adopt a change if they are convinced it will outlive at least one of their projects. A pilot project or a project from a willing PM could be used to adopt and showcase success from using the new process.
  • This success could be celebrated to reinforce that the change is for the better and is here to stay.



Step 7: Consolidate improvements and produce still more change.

  • Monitor for components of the prior process still in play within the new process. Take corrective steps to ensure that the right components are employed, even though it may take time. Mack should have instituted multi-rater (Burke, p. 89) feedback to ensure that the final delivery process met the purpose.
  • Ensure that the momentum for the new process change is sustained into the future. The organization must develop and promote employees who can influence implementation of the desired change.



Step 8: Institutionalize new approaches.

  • Continually demonstrate to new and existing staff the effectiveness of the new process.
  • Ensure that changing leadership is aware of the reasons for and success of the change.

By adopting the Kotter's model and fostering a climate for change, the linear nature of the process, together with commitment from leadership, will ensure that the process of implementing changes and particularly delivery methodologies is not derailed, that momentum is maintained, and that everything is implemented to ensure continued success. This process can be adopted within any organization looking to adopt an Agile approach to solution delivery.





Burke WW. Organization Change: Theory and Practice (third ed.). Thousand Oaks: Sage Publications. 2011.



Kotter JP. Leading change: Why transformation efforts fail. Harvard Business Review, reprint R0701J. Boston: Harvard Business School Publishing. 2007.


Weisbord MR. Productive Workplaces Revisited: Dignity, Meaning, and Community in the Twenty-First Century. San Francisco: Jossey-Bass. 2004.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 0 (0 ratings)


Tom Mellor, CST,CSP,CSM,CSPO,REP, 12/5/2012 8:55:58 AM
Tom DeMarco said it well on page 181 of his book, "Slack": "The term 'change management' has always struck me as almost touchingly optomistic. It suggests that you manage change pretty much the way you manage the mail room or the Southwest Regional Office. Would that it were so!" He goes on to offer that change is managed like one might desire to do "cancer management" and he does so to suggest that, while change is often desired and needed, the uncertainty of its outcome and the almost impossibility of steering it places it beyond the means of "controlling" it.

Traditional views about change management procoess (e.g. ADKAR, etc.) are well intended but insinuate that the process is almost purely unemotional and mechanical: "if we only do these 8 steps, then the change will certainly occur as we desire." This is naive and ignores that people essentially have a choice to accept change or not accept it. They can even be coy and claim they do accept it, even when they might not only not accept it, but might actively resist it, even if surreptitiously.

Better reads such as many of Jerry Weinberg's books (starting with his classic, "Anticipating Change") and incorporating thoughts from Robert Quinn ("Change the World: How Ordinary People Can Achieve Extraordinary Results," "Deep Change," and "Diagnosing and Changing Organizational Culture: Based on the Competing Values Framework.") Jerry worked with Virginia Satir to apply her Satir family change model to organization change and one would probably benefit more from advanced degrees in psychology than from an MBA in this matter.

I commend Biju on his article - stories (as Steve Demming insists) are compelling ways to convey thoughts and principles. However, organizational change is a complex and uncertain realm, frought with risk, uncertainty and fears. To really understand it, one must effectively become a student of the study of it. I hope this article spurs others to investigate it further.

Tom Mellor, CST
Tejasvi B K, CSM, 12/19/2012 1:23:28 AM
Change is always resistive but the approach to embrace this change is vital for acceptance across the Org. A very good methodical approach to introduce a new Delivery Methodology - In true Agile style.
Yi Xu, CSP,CSM, 12/20/2012 1:57:35 AM
just want to second what Tom Meller said :-)

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up