Speak to an Advisor
AU
EU
IE
UAE
UK
USA
SA
SG
Agile is here and has been here since the end of the dot-com bust in 2001. It is touted as a competitive advantage and culture-changing. All organisations are on the Agile-implementation spectrum—somewhere between “heard of it” and being an Agile enterprise. It could be a “buzz” word people use for political gain or it could be the core way your people work together. The common question for all organisations: “is this right for us?”
If you say, “yes,” then how are you going to implement it? Getting lots of people certified in Scrum or Lean is a common starting point. After that, some projects will succeed while using Agile and momentum could grow. If successful, then all business owners will demand that their projects be Agile. At this point, your organisation has a twofold problem: 1) shortfall in people who can run and spread Agile-based delivery and 2) no means to govern Agile projects, which can follow many different, non-traditional delivery paths. The shortfall in Agile people is usually solved through either hiring or deciding only limited projects “get to use” an Agile approach. The governance is a bigger challenge—dealing with your organisation’s culture.
My company, an $8B retailer, first considered Agile in 2010, didn’t act on it or train people until 2016, and had its first “Agile” success in 2017. That first “Agile” project followed about three of the twelve Agile principles and called every major work effort a “sprint.” This is what launched Agile at my company and drove multiple other projects to be approved for “Agile.” Most have succeeded and momentum is growing, but problem 2) lack of governance, became prominent as project sponsors wanted speed, company focus, and funding, with little oversight.
The Army and Air Force Exchange Service (The Exchange) is a Department of Defense (DoD) retailer founded in 1895. Being in the DoD, the Exchange is subject to many Federal laws and regulations and has a bent toward military command and control. Accordingly, some want a regulation or commander or expert to tell us how to govern Agile projects. That is partly a desire for a quick fix to the many symptoms of a lack of governance. One symptom, as a VP put it, was “I feel like you’re asking for a blank cheque every time someone asks for approval of an Agile project.”
There is no universal approach to Agile governance, but there is an approach that can work for your organisation, and it is likely different from but similar to others’ approaches and based on Disciplined Agile. At its core, it needs to be based on your organisation’s culture and environment. It needs to be based on a non-prescriptive toolkit that offers the right approach for your situation today and the ability to adapt at your organisation’s pace of change. The following approach may work for you or be a starting point for you.
Proposing change is easy; leading change is hard. A project manager (PM) has to exhibit leadership in the many roles the PM does. Implementing Agile in your company should be approached as a project that employs all Project Management Institute (PMI®) processes and knowledge areas. Additionally, your mindset cannot be “all-or-nothing.” The available tools can be deployed in parts or in many different combinations. The point is to learn fast and apply the right tool for the situation6.
A foundational activity to any project is the stakeholder analysis that happens during the initiating process and continues to the end of the project. It is a means to connect project outcomes with business priorities and get a sense of stakeholders’ opinions on the project. Without the stakeholder analysis, a project team has no-to-little insight into its project’s supporters and detractors. It is the document that tallies who supports the project, who is neutral toward it, and most importantly, who opposes it. It forces the team to strategise ways to convert detractors to a neutral or supporting position1. It is sometimes a closely held document available only to the sponsor and team.
A few months after earning my Project Management Professional (PMP®) in 2005, Jason, a colleague of mine, asked me to discuss a new engagement he recently won since it had some overlap with a client of mine. For about ten minutes we discussed a number of influencers and decision makers who would interact with his engagement. At that point, I said, “It looks like you’ve got a good start to your stakeholder analysis and communication plan.” Surprising me, he furled his brow and said, “I spent all that time earning my PMP® over a year ago and I’m not even using the tools. I’m really not ready to go over this with you yet. I need to do some ‘homework’ and then I’d like to get back with you.” Jason was not using tools readily available to him. As a leader, he recognised his shortfall, stopped the meeting, and did his work first. As you lead a project, make sure you do your work first.
After assessing the stakeholders, it becomes a matter of determining how to affect the change. One approach to that is “The ADKAR Model. Awareness of the need for change. Desire to support and participate in the change. Knowledge of how to change. Ability to implement required skills and behaviours. Reinforcement to sustain the change”4.
PMs likely do not have access to every stakeholder but sometimes they do have access to executives and team members directly involved in the project. PMs also have influence with their bosses and often with other influencers in their respective offices or across their companies. The place to start is locally with the PM’s boss. S/he has access to information and relationships the PM does not and can give a different, if not broader perspective on the acceptability of the proposed change.
At the Exchange, awareness for Agile was in place via a major deliverable that was key to the company’s reputation and future. Desire followed the awareness in that every sponsor wanted the same “freedom” and company support the successful “Agile” project had received prior to its November 2017 launch. The knowledge stage was trickier since the primary exposure people had to the successful “Agile” project was meetings to approve scope and sprint acceptance. In general, the executives thought Agile was something the coding team in IT did instead of realising that the regular executive-to-delivery-team communication at the sprint planning sessions and sprint reviews was a major contributor to the project’s success.
To increase the company’s knowledge of how to convert to Agile my boss and I made a point to cover executive Agile responsibilities during the launch of another major project. The project’s steering committee was composed of the company president, COO, CFO, and CIO, about a quarter of the company’s executive members. Additionally, we met one-on-one with other executive-level stakeholders and while going over the main points of the project, added that an Agile approach requires scheduled, regular face-to-face interaction between executives and the project team members.
The ability portion of ADKAR required more research “homework.” That included documenting the informal rules that the company’s governance committee used for projects, as outlined in PMI®’s governance framework implementation guide8. Some major rules were in the company’s formal documents, but there were other unpublished rules the company used. As part of Lean’s emphasis on visibility12, we had to discern and distil both sets of rules into a summary governance document. We used Deloitte’s recommended components of governance3. Our focus was on the Oversight Responsibilities layer since the other layers are specified in Department of Defense regulations or are controlled by human resources.
The reinforce portion primarily depends on the post-implementation review process, which usually occurs in batches of projects. To date, no Agile project has had a formal one, but the process includes reviewing results of Agile releases no later than six months after go-live. Similar to Agile retrospectives, the point of the review is to assess the effect of the release compared to its goals, determine root causes of both successes and failures, and learn fast to adjust the governance, processes, or tools.
The ADKAR Model provides a simple, comprehensive approach for affecting change that can work for any organisation. Prior to applying it, the project team needs to do its “homework,” especially the stakeholder analysis. This requires extensive use of soft skills (relationship management, facilitation, probing) and some hard skills across PMI’s® ten knowledge areas to prepare a thorough proposal. Bosses, peers, and team members are great sources of multi-perspective feedback to tune it to the organisational culture in preparation for and during the introduction of the change.
Given that no “silver bullet” solution exists that will work in every culture, this Disciplined-Agile solution is one tailored to a specific organisational culture with a particular mission, vision, competitor set, customer base, and governing rules. It is available as a model or starting point for other organisations.
To set the stage and provide a reference point for comparison, the Exchange established its first PMO in IT in 2004 with no PMPs®. By 2010 it had about 30 PMPs®, was wrestling with establishing an executive PMO to govern its many business unit PMOs, and first considered but did not implement Agile. In 2011 it published a waterfall-based (traditional) process and template set for project management. In 2016 Agile made its first appearance without a certified scrum master (CSM) at the helm of the project. In 2017 the Exchange sent about 15 PMPs® to become CSMs. In 2018 the Exchange started facing a challenge—how to govern a growing number of Agile projects.
The 2011 process was based on PMI’s® five process groups9 and tailored to the Exchange organisation’s context and culture. Figure 2: Traditional-Based Project Process, below, shows the parallels between the PMI® and the Exchange’s processes. The PMI® activities also have the attitude or feeling in parentheses.
The longer I have been a PMP® it has become apparent that audiences, large and small, executives and team members, understand the project process better with descriptive feelings for the processes. For example, during 1. Initiate, a sponsor has a dream that will solve a huge company problem and just needs the right PM to figure out how to do it. A little while later the PM comes back with a 2. Plan that seems to be the cost and time necessary to deliver the dream. The sponsor usually cuts the budget and schedule and tells the PM to deliver. As the PM 3. Executes the project, the sponsor often reams and screams at the PM for letting the project run over cost and be late. To relieve any 4. Monitor & Control pressure possible, the PM then schemes on ways to transfer costs and shorten the schedule. After delivery, everyone forgets to 5. Close as they want to avoid the administrative work and join the next big dream. That is what a project feels like as you manage it. For the Exchange’s 2011 process, we included the reason for each stage below each chevron, so everyone knows what gets approved at the executive gates.
The main challenge that arose for Agile projects is that Agile principles do not include gates that often can stall project delivery. The results of the 2011 traditional process included numerous cost overruns, delivery timeframes up to six years, and a couple of cancellations that became full write-offs against the bottom line with little to no value. In contrast, an Agile-based process results in faster, more customer-focused delivery and produces smaller, minimal benefit increments (MBI) that persist even after the organisation ends the project based on the market. That bolsters the bottom line in two ways: happier customers who buy more and fewer write-offs. At this point, the organisation was succeeding locally in that it could run Agile projects but struggling globally for lack of appropriate governance.
The Agile community offers frameworks such as Scalable Agile Framework (SAFe®) but SAFe® appeared to require more overhead processes than the organisation would be open to given that it was already facing four gates and 60+ templates. The stakeholder analysis suggested that it would be hard for the organisation to adopt a framework where “[t]he number of roles in SAFe® is unusually high for an Agile framework. It is a bit overwhelming initially to understand all of the roles”11. Accordingly, the solution required a more flexible, tools-based approach that offered less overhead and combinations that fit today’s culture and would adapt as the Agile approach matured. A Disciplined-Agile-(DA)-based approach seemed best.
The Exchange solution offers two processes, one for the near term and another for the long term. The solution also includes a summary of the governance roles and responsibilities and criteria set for determining if a project qualifies for the Agile process. These tools and options allow the Exchange to take interim steps and adjust as necessary on its path to becoming fully Agile for qualifying projects.
The interim step, sometimes called “Wagile” (Waterfall+Agile) or “Tragile” (Traditional+Agile), includes features of a traditional-based process combined with features of the new, Agile-based process. It is not intended to persist, but if it does it still offers an improved project management process and later should be considered as a steppingstone towards a more Agile-based process, not as an endpoint.
Under the Exchange’s traditional-based process (Figure 2: Traditional-Based Project Process on page 5), the executives get “four bites at the apple” when it comes to project approval. Specifically, they are Gate 1: approving the why10, Gate 2: approving the what, Gate 3: approving the best solution, and Gate 4: approving how to deliver it. These four gates have been in place for about eleven years, are part of the project management culture, and are a valuable organisational process asset. To get to Agile or to be more Agile, some of the gates have to change to enable faster delivery that is more customer focused and market driven—establishing an Agile process, the first component of transitioning to Agile governance. Getting to Agile will also rely on the oversight responsibilities adapted to Agile.
The interim, Wagile, process (Figure 3: Interim Wagile PM Process, above) makes the following changes to migrate towards Agile, it 1) eliminates one executive gate by delegating some executive authority and responsibility to the project steering committee (PSC), 2) releases (delivers) functionality to the market sooner, and 3) gets feedback on the releases sooner. The eliminated gate is 4) how to deliver. By eliminating Gate 4 and delegating to the PSC the process requires the project team to interact directly with the PSC to determine the how and when to deliver based on the PSC’s assessment of the market. Prior to every sprint, the PSC assesses the market and determines which requirements best fit the market. During the sprint (produces at least one minimal business increment) and release (delivers at least one MBI to the live, customer-facing platform) planning the PSC works with the product owner and tells the project management team what to build based on market demand.
This is a broader, more interactive, and more demanding role for the PSC members. For that investment, the organisation receives faster delivery and reduces risk. By delegating some additional roles and responsibilities to the PSC, the executive team not only creates capacity for themselves to run their business units, it also creates a grooming ground for VPs to work on strategic projects with executive oversight. That oversight comes in the form of executive value checks on the projects. When the executive committee approves a project for planning and execution it sets budget and time constraints. The duration is usually six months (Soukath Ali, 2016, p. Kindle Location 1002). A project running out of budget prior to the scheduled value check triggers a value check. Depending on the sponsor’s project teams’ past performance, the executive committee may decide to shorten or lengthen the time between value checks. In the same way that the sponsor makes the case to the PSC for the next sprint, the sponsor makes the case to the executive committee for another allotment of budget and time. The sponsor’s case primarily focuses on the market’s response to deliveries to date and need for more deliveries.
The second change the Wagile process implements is faster delivery to the market and reduction of write-off risk. It does this by delegating approval authority to the PSC to approve both priorities and delivery timing based on the PSC’s assessment of the market (either external or internal customers). This happens in the new “Planning and Execution” stage and results in products “hitting the market” sooner and being better tied to market expectations. Eventually, the market will not demand more functionality from this project and the PSC will recommend defining the project as complete. A major benefit of the Wagile process is that it delivers product to the market prior to end of the project or to the project being divested. In traditional project management, no product usually is delivered until the go-live date at the end of the execution stage. Not only is that often years after initiating the project, it also exposes the company to “write-off” risk. When a traditional project is being considered for cancellation, sunk cost carries considerable decision weight since the company will take a write-off “hit” against its bottom line. This is a cost-of-project cancellation—a capital expense that would have been depreciated over time converts to a current-year expense. The change to Agile gives decision-makers more flexibility and protects the bottom line since making decisions based on sunk cost should be avoided (Kahneman, 2011, p. 345).
The third change the Wagile process affects is the post-implementation review (PIR) in two ways: 1) it requires a PIR after each release to assess how the market responded and determine if more releases are necessary and 2) it shortens the break in time between the release go live and the PIR by fifty percent, bringing it down from twelve months to six. The PSC can shorten the period prior to the PIR if the PSC and sponsor’s business case expects the market to respond sooner. The point is to assess how the intended customers responded to the release and then determine if more releases are required. If not, the PSC recommends cancelling the project to free up people and capital for higher priorities while the company still benefits (sales, efficiencies, etc.) from the functionality already released to and used by the market.
The interim, Wagile, project management process is a large step towards adopting the Agile mindset, but it is not the end state. The end state is an environment where the governance enables both traditional and Agile projects as well as combinations of them. The environment needs processes for each, roles and responsibilities for each, and a criteria set that identifies which projects are candidates for the Agile process.
The Agile project management process (Figure 2: Traditional-Based Project Process, above) eliminates two more gates and requires the sponsor to have the why, what (high level), and best team (internal, external, mix, outsourced) for approval at the first, single gate. A contractual action may be required after the gate; to support that action, the sponsor presents alternatives and a recommendation to the executive committee. Once the executive committee approves the budget and time allotments for the value checks, the PSC determines the content for the first sprint and release, and the project team starts delivering.
One of the tests for this governance was if it permitted the most successful Agile project to continue. Discussing this governance with the IT lead for that project confirmed his project would be able to operate under this governance and that its “Agile” approach had matured. As he was going over the details of the project’s success he said, “Do you remember how the business units always were ‘on us’ for being late? I got tired of that and set a goal of stopping that complaint on this project. We got down to a three-week sprint cycle…and you know what…the business unit asked us to slow down.” Job done—courtesy of an Agile mindset!
Defence, the Pentagon-level AAFES Board, the Investment & Evaluation Committees (IC/EC), which is internal to the Exchange, Human Resources, and Information Technology already govern or specify the structure, talent and culture, and infrastructure layers of Deloitte’s governance operating model (Deloitte, 2013, p. 3), the focus of the Exchange’s project management governance is on the oversight responsibilities. Each role can see its Agile and Traditional Responsibilities, Authorities, and to whom it is Accountable. While many details are listed in the table, the IC/EC is familiar with them, and the three bold items indicate the new Agile-related responsibilities and authorities. It is a single slide that summarises and reinforces the executive committee’s responsibilities regarding projects.
A criteria set for determining if a project qualifies for the Agile process is the final component. Sponsors push to have their projects on the Agile track due to the many benefits of the Agile mindset. Not every project will qualify for the Agile process, but projects can follow the Wagile process (Figure 3: Interim Wagile PM Process on page 7) and can request a reassessment if the project meets the Agile criteria at a later point. Additionally, the governance permits both Agile and traditional work streams within a single project to accelerate delivery.
The Agile criteria set shapes the company’s expectations for which projects are Agile eligible. The criteria range from MBI to Requiring flexibility (CPrime, n.d.) to Realising value fast to Having the infrastructure in place. The MBI requirement ensures the project only plans to deliver what the market demands and what the project can get feedback on. The flexibility confirms the project is tied so closely to the market that thorough preplanning may cause the project to miss the market. Requiring a fast realisation of value makes the project form a business case that shows impact to the bottom line or internal efficiencies—this received additional emphasis after the Covid-19 cash constraints. Finally, having the infrastructure in place indicates that the project can start immediately to meet market demand. These criteria give the executives an objective standard for determining which projects qualify for Agile-based governance. Additionally, using a Disciplined-Agile-based process gives the executives options for changing how they govern Agile projects as the culture changes. Options are good.
Disciplined Agile gives scores of tools to position organisations to succeed by applying an Agile mindset. The governance components reflected in this paper are a combination that fits the Exchange’s culture, environment, and stakeholders (Project Management Institute, 2017, pp. 37-39). It may work for your organisation or serve as a springboard for your Agile journey.
*The views presented in this paper are those of the author and do not necessarily represent the views of the U.S. Department of Defense or its Components.
References
Explore our Courses
Upcoming Course Dates
Corporate Training
Partnership
Certification Overview
IPM Certification
IPMA Certification
PMI Certification
PRINCE2® Certification
IPM Membership
Events
Mentorship
Articles
Expert Insights
Ebooks & Toolkits
Publish Your Writing
The Institute
Faculty
Global Advisory Board
Apply to Lecture or Volunteer
Apply to Intern or Campus Ambassador
