Anatomy of an Agile Transformation: Part 1 - The Idea and Assessment
About a 9-minute read
Using an Agile mindset to complete projects or any other kind of work does not need to be a scary proposition. Agile is not the antagonist of a horror movie. Yet, adapting to Agile thinking and bringing Agile practices into the day-to-day norm can strike fear in those within the scope of such a change. Bringing Agile into an organization, therefore, requires strong people-first change management. Through this, Agile can truly be transformative. I am going to use this, and subsequent posts, to examine the process I went through in guiding an Agile transformation for an organization rooted in traditional and familiar project management practices that impacted, often negatively, the thinking and approach in handling the most minute task up through how executive leaders approached strategic priority. This journey will encompass identifying the opportunity of bringing in Agile practices and the potential benefits, establishing transformation objectives, identifying organizational Agile readiness, Agile “implementation”, and tackling the challenges along with lessons learned.
For years, the organization I was part of followed a set project methodology. It was a structure of the organization’s own creation based upon waterfall project management. As the organization grew, the number of projects ballooned, and the work became more complex, all flexibility and imagination around project management disappeared. Team managers were heavily involved in project decision-making and prioritization, and the project methodology was bastardized into a way to gatekeep work in order to balance multiple projects “progressing” simultaneously, where project progress could be considered holding a check-in meeting once a month – there was little to no actual work being completed on projects stuck here. Eventually, leadership realized there had to be a better way to get the right work through the pipeline, and this led to investigating “design thinking”. This is the point where I was officially tied to what would eventually become the organization’s Agile transformation.
As a first foray into exploring different ways of working projects, I was tasked with learning more about design thinking and how it may fit and be applied at the organization. So, what better way to learn than to go full immersion and dive into the world of design thinking at a dedicated conference. I was not familiar with the in-depth application of design thinking but had done some reading and use case study in order to understand the practice’s broad strokes. While at the conference, my eyes were opened to the passion and specialized focus of those who lived “design thinking” and helped others on their journey. There are required skillsets and approaches necessary for design thinking that someone accustomed to straightforward project management would likely not look to apply in their typical daily work. Essentially, design thinking aims to create a pure solution for an idea, question, or problem, where a “pure solution” is one that has undergone multiple iterations of prototyping and customer vetting to ensure it meets all present needs and the potential future ones uncovered through the prototyping and vetting process. Dedicated design thinking practitioners likely have a better description or may scoff that my description is too limited, but I am merely stating my takeaways.
The basics of design thinking stood out to me in having a foundation of common sense. Taking the time to interact with customers and study the workflows and needs surrounding their asks, and then iteratively following up with solution options that homed in on an ideal final result, seemed so perfectly logical that it was astounding there had to be a vehicle like design thinking to allow such an approach to occur. When I stepped back and examined how design thinking could work at my organization, however, I realized design thinking required the ability to work iteratively and focus, and those were two pieces that could not exist in my organization’s current project work environment.
When I reported back to my leadership team, I shared what design thinking was and what I viewed as the potential positive outcomes from utilizing design thinking practices, but I placed greater emphasis on the need to be nimbler in our approach to projects and how they moved through the pipeline – we needed to be more agile. Here, it was important to differentiate from what leaders saw as the organization’s current agile qualities and what Agile could bring to the table if properly introduced and supported. Many leaders saw the ability to pivot from one project to another if priorities shifted as all the agility that was needed. Since projects were seldom terminated, however, this meant shifting from one project to another would potentially add hundreds of new hours of work that was in perpetual competition with work that was already in progress and costing hundreds of hours, sometimes thousands, and the project backlog would, therefore, continue to grow.
If you are breaking down in your head how this becomes a significant issue, there are only so many options by which to try accommodate an ever-growing list of active projects: adding personnel, having existing personnel do more, or accepting that projects will slow significantly as expanding work tries to move through a fixed bandwidth. On many projects, all three of these options were true – teams were expanded with additional personnel, but since the amount of work continued growing, people juggled multiple projects while working extra hours, in many cases to ensure they did not let down the various teams across all their responsibilities. As plain as one can state, this way of working is unsustainable. Adding more people to a project quickly creates diminishing returns due to the fixed resources for those individuals to utilize. Having people work beyond their capacity will kill motivation and eventually decrease their overall productivity. And, when project work bogs down, projects that should be completed in one to three months are now taking a year or more to finish.
Understanding there was a need to do something different, where we could build upon what the organization did well, did we look at Agile as the end-all solution for the project woes? No, because Agile does not inherently fix those aforementioned problems. If anything, Agile was going to dig into the pain points and make them worse, showing us where we needed to fix our approach while providing a pathway to begin doing so. Getting our heads above water in the project space would require an overhaul of project intake, prioritization, and alignment, which was a battle for another day.
With a mountain of needs ahead and a long road to travel just to get to the mountain, where did we begin? First, the subset of executive leadership overseeing the project space, along with a group of internal advisors, committed to exploring Agile, which included learning more about Agile practices and determining if the organization possessed the capabilities to adopt and succeed with Agile. To accomplish this, we looked for outside expertise, partners who could align a core group of individuals, dubbed the “Transformation Team”, on Agile basics around mindset and a couple basic frameworks. These partners would also be asked to conduct a readiness assessment that would thoroughly review organizational structure, processes, and philosophy.
The Transformation Team consisted of key stakeholders from the departments directly involved with project work, and the team’s purpose was to provide expertise into the departments’ respective workflows and roles related to project execution. As future information and guidance would need to be disseminated across these departments, the team members would serve as liaisons to those groups and the transformation’s leadership.
The readiness assessment’s output would attempt to quantify strengths and weaknesses in categories like leadership support, culture, and project lifecycles. These were not the only subjects of the assessment, but their respective foci are vital to any transformation. Examining these categories more closely, any organizational change, especially one with the potential to uproot decades’ worth of ingrained mentalities and approaches to work would require staunch leadership buy-in, or else the transformation would sink at the dock. Organizational culture can be an overlooked facet of change management. Do employees have the liberty to act in the best interest of their work and development? Can team members freely share ideas and bring forth better ways of working? Or, is a command-and-control approach seen as the only way to work and individuals seldom show initiative or interest beyond the confines of what is placed directly before them? Obviously, this last organizational “culture” is generally not conducive to Agile. Yes, the organization may end up working in an Agile framework, but in the absence of the appropriate mindset and self-management, Agile does not truly exist. Then, project lifecycles indicate the type of work being done, the environment in which it is done, and how projects are approached for intake and priority. Many projects deserve a traditional project management treatment and will not gain anything from Agile. So, the assessment would explore if there was work within the organization that would benefit significantly enough from Agile to warrant undergoing the change. Additionally, it was vital to understand if the project environment would allow for iterative development and strict prioritization that allowed clarity and focus for the teams.
With a partner in place and the Transformation Team assembled, the assessment could commence. For several weeks, the partners and team were sequestered in a conference room conducting in-depth interviews and general conversations across myriad topics that peeled back layer upon layer in the aforementioned themes of leadership support, culture, and project lifecycles. This process was beneficial not only for the partners to compile the assessment’s results, but it provided those on the Transformation Team insights into what other areas saw as obstacles or what they took for granted. Even if the assessment came to show the organization was not suited for a full move toward Agile, the participants acquired a greater understanding of others’ jobs and priorities.
Upon the assessment’s conclusion, the partners came back with a thorough report on each of the investigated categories, highlighting aspects that would align with Agile practices and those that could create hurdles in adopting Agile. This was presented to leadership, and then, the decision to move forward with Agile was left to internal discussions. As a believer in the benefits of an Agile mindset and seeing the potential benefits to the organization, I had to act, somewhat, as salesperson and establish a foundation of trust in the organization’s capabilities to adopt Agile and my ability to oversee it. I had no intention of selling snake oil, however, and truly felt that when the pros, cons, and vision were presented, leadership and my peers would clearly see the innumerable benefits and that the organization was already behind the curve in its Agile adoption.
Enough of this ideal state came to pass to greenlight the Agile transformation. There was even a high degree of excitement for the potential of what could be. While the mountain remained far in the distance, we were finally able to begin heading down the road. It was a monumental step that was relatively small compared to what was to come, but being able to pursue Agile was an accomplishment worth celebrating. In coming posts, I will examine how we got the transformation off the ground from the earliest training to setting up the first Agile teams and products.