By: Kristen Ardito | September 7, 2022 | PMO & Project Management | Agile Transformation | Change Management
Opening Observations
Why do so many organizations struggle to gain adoption for Agile? Why do so many “transformations” feel like another exhausting exercise that takes teams away from doing “real” work? It shouldn’t be so hard right? I mean, a methodology built on the promise of servant leadership, “just enough” documentation, inspect and adapt and incremental delivery should be a no-brainer right?
I’ve slowly and painfully come to the conclusion that while Agile is a good methodology and certainly better than Waterfall, it isn’t perfect.
Sure, with Agile, the months of lengthy upfront planning - usually done with minimal input from the team, are gone. With Agile, teams no longer need to read volumes of documentation that could easily have been condensed. Done right, Agile teams can deliver incrementally and strike the right balance of delivering quality code, addressing tech debt and work on new feature development. But done wrong, Agile can be used as a shield to protect mediocrity and lead to a lack of predictability in the larger ecosystem.
The Struggle to Scale
I’ve seen plenty of organizations go through Agile transformations only to struggle with longer lead times, issues addressing reliability at scale and burned out teams who can never catch a break. In time, finger pointing and distrust can become rampant.
Before you know it, Scrum-fall or Watered down Agile starts to creep in - in the worst case scenario, a new management team is hired to lay down the law and whip everyone into shape. My experience has shown that this approach may result in short term gains to the long term loss of top talent who won’t work under those circumstances.
Small organizations who experience success when team sizes are small and autonomous must not blame teams when there is a growth in complexity (more people, more code, more processes, more applications, etc.) leading to delays and bottlenecks and increased dependencies.
Organizations that are growing will begin to experience delays due to code complexity that wasn’t the case when there were only a handful of engineers. Infrastructure can become a constraint as loads increase and transactions exponentially multiply. Testing is sometimes left to the very end, which is costly and risky.
Often there is a tension that between product leaders (who would prefer to prioritize new feature development) and engineering leaders (who never get a chance to address mounting tech debt).
This is not the fault of the teams and simply demanding they work longer hours to address these issues without help is only going to lead to burnout. To add insult to injury, as the delays mount, more processes, meetings and demands are often thrown at the teams in an effort to speed things up. And you guessed it, these processes often have the opposite effect.
Intention and Change Management
There is another factor at play that may impact the success of Agile at organizations. The intention of the leaders who are tasked with implementing Agile at any organization matters. Intention is defined as: “a thing intended; an aim or plan”.
What does this mean?
If Agile is implemented by leaders who are looking to hold on to or to gain control over teams, then the framework will be distrusted. I’ve also witnessed leaders hiring outside the organization to implement Agile and everything is done behind closed doors. Teams don’t really understand what is going on and often have no say.
I have witnessed a growing trend of leaders who say they believe in Agile, and even use many of the language from the Agile manifesto, but their actions undermine their words.
This can manifest in misaligned expectations and confusion as teams struggle to understand why they are being asked to meet date driven deadlines, with fixed scope for example.
Another trend I’ve observed: Some technology leaders are so desperate to attract qualified candidates in a competitive job market that they proudly tout their “Agile framework” while privately becoming paranoid that deadlines are not being met, workers are unmotivated and that without being told explicitly to innovate that teams are losing their edge.
I’ve seen this manifest in roadmaps that were so jammed with features and ideas that the leadership and business teams wanted that there was no room for the teams to innovate even if they wanted to! I found myself playing a balancing act between the product and engineering teams and the executive/business teams.
There is a growing realization that in order to bring the spirit of Agile with the need for some planning and reporting, change management techniques should be used to build awareness and support for the framework.
My experience has taught me that even one or two resistant people can undermine a lot of goodwill. It’s important to listen.
Change Management is a growing and endlessly fascinating field of study and I won’t go into the details here, but at a very high level, I want to acknowledge that almost all the organizations I’ve worked with struggled with this. To foster a spirit of inclusiveness, and garner advocates for the change, organizations must prepare for the change. This means cracking open the closed doors a little and inviting individuals into the conversations.
This also means having crisp and concise goals and objectives for the change, as well as a vision for what the change will bring to the organization - BEFORE starting to implement the change.
Why Hybrid Won’t Work
The word Hybrid is used a lot, and has been used for quite some time now, but it doesn’t quite mean anything.
When I hear a leader say “we want a hybrid framework”, I cringe. I know what they are really saying is: “we want Waterfall but can’t afford to say that because we don’t want to freak people out”.
The end goal is to instantiate tools and processes that will force teams to commit to dates, take away parts of their autonomy, and govern by auditing and tracking. Does this work? Yeah, sure, sometimes. But oftentimes it leads to resistance, a build up of resentment and distrust. Over time, this distrust becomes the culture. Whispers of micromanagement become louder and spread. Glass Door reviews start reflecting the pent up frustration.
So what can be done? What are some of the best ways to handle the contradiction of meeting deadlines, and orchestrating the sequencing between dependencies vs. shorter delivery cycles? Is there really such a thing as speed AND quality? Are complexities inherently bad?
Lightweight Solutions to Scale
At the root of the issue is that organizations today are often up against cut throat competitors, fast paced innovations coming quickly and furiously from all angles and a perception that at any moment they can be “disrupted”. The reaction is understandable: we must move faster. However, moving faster is not always the prudent choice.
Tools:
There are many tools out there to choose from. My experience is that skimping on tools to manage dependencies and roadmaps can lead to frustration and chaos, no matter what the methodology. The most important tool you can invest in is a reliable reporting and dashboarding service that can easily spot delays, provide accurate forecasts for delivery of a product or service and align the work teams are doing to strategy. The key here is to automate as much as possible.
Processes:
It’s inevitable for a growing company who wants to stay nimble (hey, it’s gotten us this far!) to rebel against process, but it doesn’t mean that it’s a sound decision to ignore the need for process. Lightweight, scalable processes will end up helping everyone in the end. I would compare the process in an organization to the process in a small town that is growing. Suddenly traffic starts to increase and at first you put up a stop sign to ease congestion. Phew! That helps for a while and traffic eases a bit however as the town grows even more it becomes evident that stop lights are needed. While you may not need traffic lights at every intersection, having them at major ones helps prevent accidents and eases the flow of traffic. The same applies for processes. As the organization grows, so does the competition for resources, making the likelihood of congestion and bottlenecks inevitable. Some examples I’ve seen work well are: instituting Scaled Agile, carving out time during the quarter for tech debt and doing just enough upfront planning in small batches to enable senior leaders to plan the business, make commitments and reduce customer/client frustration.
Resources:
There is something to be said for running lean. I’m a big fan of running as lean as possible for as long as possible and being scrappy wherever possible. It can prevent waste in the system, save money and potentially reduce silos. However, it’s important to know when it's time to invest in a few seasoned Technical Program Managers who can help take the pressure off of teams for complex and large initiatives. These types of efforts take some time in the beginning, but end up paying off in the end. Not all companies need a PMO, but many will benefit from a seasoned technical program manager.
I believe the suggestions above can help most small to medium size businesses succeed where others fail. As the organization grows (and hopefully flourishes), there may be more advanced techniques to use which I will cover in future pieces. If you have found this content useful, let me know. I’d love to hear from you.
At Gravitas Consulting, we are passionate about helping companies achieve results through knowledge gained through seasoned professionals who have seen it all and believe there is always a better way.
About the Author
Kristen Ardito is a Partner at Gravitas Consulting. She is an accomplished leader in Enterprise Agility and Program Management. She has delivered a diverse portfolio of projects spanning the hospitality, QSR, retail, and media industries. Kristen believes that the success of any endeavor begins with effective change management strategies. Kristen has built her career on finding the right toolkit for each organization to unlock its potential in an ever-changing and disruptive world. Kristen is based in Florida.
Get in touch with Kristen
About us
Gravitas Consulting is a Toronto-based firm founded in 2021. We focus on strategy, operations, and technology. That as our guiding beacon, we set out on the journey with Gravitas Consulting. Our team of experienced consultants has been associated with top-tier global management consulting firms and has advised a diverse array of clients, ranging from Fortune 100 companies to non-profit organizations. We tailor our solutions to your needs, we flex, and we strive to get you the desired outcomes.
Traditional PMOs can be heavy touch and can slow down the flow of work. To solve that problem, we have launched Laminar, a PMO as-a-service offering with in-built best practices of Fortune 500 clients. We offer a complete solution to manage the 3Ps - portfolios, programs, and projects. Laminar is a pure plug-and-play solution that can be configured in less than a week and sits atop your current project management tools - purposefully designed to be low-maintenance and fully automated so that you can focus on running the business.
Visit us at www.gravitasconsulting.com/laminar to learn more and schedule a demo.
Sign-up for a free three months pass at www.gravitasconsulting.com/laminarbeta
Follow us for careers and updates on LinkedIn
Visit us online at www.gravitasconsulting.com