As organizations attempt to “be Agile” in IT, the PMO, and the business, they’re discovering that becoming an “Agile Organization” is not that simple. There are lots of questions on what actually needs to happen to become Agile, and how to implement what Agile produces.
Don Harrison, developer of the AIM change management methodology, recently led a provocative and substantive webinar on the topic of Agile. In it, he uses his “tell-it-like-it-is” style to answer some of the many questions he’s received about implementing Agile. Here are a just a few of the questions he’s received, and his responses:
Q & A with Don Harrison
Q: What kinds of controls need to be set up by the PMO for Agile?
A: In most organizations, the average shelf-life of a PMO is about three years. Typically, the culprit is that the PMO lacks the same focus as Senior Sponsors. In other words, PMO’s aren’t sufficiently focused on the business results (most usually, financially speaking) of the organization.
In an Agile environment, every project must focus on delivering business value. The Project Management Office becomes a “Portfolio Management Office.” The PMO needs a bird’s eye view of the organization, with less of the traditional control mentality, and more of a problem-solving mentality. The PMO should not be looking at the technical metrics of an initiative; Project Teams should be equipped to handle that on their own. Instead, the PMO needs to be much more focused on the strategic view of generating business value, project team development, and equipping teams with a whole new skillset that Agile requires.
Q: You say that Agile isn’t suited for Transformational Change. Why not?
A: Agile is a continuous improvement process. It’s the constant iteration of the cycle in the organization. By definition, the goal of Agile is not to look at the end result. Instead, it’s designed to focus on continuous short sprints of plan, design, develop, test, deploy and monitor. Agile builds constantly on the existing Frame of Reference. Transformation is inherently different. It’s about breaking down the current Frame of Reference, and creating something entirely new. You have to break down, before you can break through. There are just simply better techniques out there to do this than Agile.
But here’s the paradox: Agile is a transformational change itself! And that means it needs to be implemented in a way that is entirely different from the traditional implementation approaches used in the past.
Q: How do you manage resistance within the project team in going Agile?
A: There is almost always going to be resistance within a team. If you keep revisiting the same decisions time and time again, that’s resistance! This type of resistance can be extremely dangerous, because if the resistance leaks out from the team into the organization, it’s like giving the business a license to resist!
Every project team construct must include structural and process measures within it to manage resistance. One suggestion: go around the room at every project team meeting and check in with each team member. “What are your struggles?” “What are your frustrations?” And most importantly, “What can we do together to offset or manage these issues?” This will help surface resistance and allow you to manage it effectively.
Q: How do you shift leader behavior to support Agile?
A: As with any business transformation, you must have a cascade of visible, active Sponsors at all levels who Express, Model, and Reinforce their personal commitment to becoming Agile. It’s the public and private commitment, level by level, that’s the most critical success factor in ensuring whether or not you’re successful. So, what do you do when Sponsors aren’t doing what they need to do?
First, you have to be certain the Change Agent that you assign to work with the Sponsor has the right relationship with that Sponsor. Trust and transparency are absolutely crucial. Then, that Change Agent will need to use Sponsor Contracting to get commitment to action. The “contract” is an exchange of offers, wants, and needs that ensures Sponsors are clear on what is expected of them at critical points in the project lifecycle. I’ve often said, “Every failed project can be traced back to poor contracting.” Many times, it’s because Change Agents are talking about “change management” when the Sponsor is looking for faster delivery, at quality, and at the lowest cost possible. I spend a lot of time teaching Sponsor Contracting in our AIM Accreditation Program. In my experience, it’s the most important skill a Change Agent needs to have.
Agile’s broad appeal as a way to drive speed and innovation is easy to understand. The business rationale is clear. But achieving full system optimization for Agile projects requires a new mindset for IT, the PMO, and the business. What questions do you have on implementing Agile? Comment below or send us an email at email@example.com and we’ll get you answers, too.