Part 3 of 3: Don’t Let Agile Steal Your Future Like Santa Stole Mine
To this day, I can tell you the one toy that Santa never brought me despite my pleas – the Fisher-Price 3-In-1 Tournament Table. That baby wasn’t just a tiny billiards table; it was also a ping-pong table and an air-hockey table that (wait for it…) even glowed in the dark! To me, this wasn’t a “toy” but a window into my future. With that 3-in-1 Tournament Table, all the kids in the neighborhood would want to be my friend, and I’d be the most popular kid in school. That table would be the first piece of furniture I’d move into my future house where I’d meet my future husband over a game of air hockey, and everyone would know me as “that rad chick with the bomb 3-in-1 Tournament Table!” But alas, that would not be my future. Thanks, Santa…
So, what was it about that silly toy that had me so enthralled? Looking back, I believe I was convinced that with so much versatility in one toy, the entertainment would last indefinitely. Had it been just a billiards table, or just a ping-pong table, or just an air-hockey table, I wouldn’t have given that thing a second look. Ask anyone in marketing — it’s not basic functionality that excites people. Fully developed products with all the extra bells and whistles are what people want and expect.
Agile environments, however, depend on employees adopting a beta version, or a “Minimally Viable Product (MVP),” which is unnatural for most people. Through research performed by sociologist Everett Rogers, we know that only a small percentage of people want to be “early adopters” when it comes to new technology. This means that the vast majority of people prefer to receive products that have been fully tested, proven to work, and that glow in the dark – okay, that last one might have been about the 3-in-1 Tournament Table… To get people to shift this inherent mindset is something that needs a lot of support regardless of project scope or release impacts.
Unfortunately, many Change Managers find themselves only focused on the impacts of individual releases and not the overall change in mindset that is needed for employees who are moving to a more mature rapid release model. When this happens, a company can expect more than just a frustrated organization, they can also end up down one of the many common pitfalls that have plagued companies over the last two decades.
Common Pitfalls of Companies Adopting a Rapid Release Culture
- Unknown Expectations: If employees are new to Agile, then they are likely going to still expect a fully developed product for which they will get training on and will expect to be told well in advance how their jobs will be changing. Certain leaders are also likely to expect that decision making and prioritization will be up to them. But with agile, none of these things may occur, and when stakeholders have unmet expectations, resentment and resistance can set in — putting adoption at risk. Therefore, educating the entire company on the rapid release methodology, and their role in it, needs to be a continuous effort.
- Unclear Goals: This issue can manifest itself in a few different ways depending on which group is unclear on the goals. For end-users, unclear goals can lead to a lack of adoption and improper use of the product during development iterations. This is a critical issue because rapid release methodologies depend on learnings that come from each release. So, if users aren’t adopting the changes at the beginning, the development team won’t learn what needs to be adjusted along the way, and, as a result, won’t end up creating the product to its full potential. Alternatively, when project teams are even slightly unclear on the goals, the wrong product can be developed. Where “directionally correct” may be ok in a waterfall environment, in a rapid release environment, it is critical that leaders and project teams are aligned to the same goal before any work is completed. Even if people have similar ideas of the goal and how it will be measured, lots of small steps towards “directionally correct” can lead you further and further off course. This is even more critical when multiple teams are working on different parts of the same goal and often the reason why a rapid release project may go through a “reset” or “reboot.”
- Minimal Governance: Establishing agreed upon governance is also critical. No matter what kind of rapid release initiative is occurring, stakeholders should expect to receive certain information. This is particularly true for leadership and change managers who might not participate in daily huddles or grooming meetings but need to know status, as well as how a change will affect the organization and its people.
Luckily, there are a few activities and strategies that a change manager can adopt to combat these issues, which will help to better support the company through its rapid release maturity.
Activities and Deliverables to Support Rapid Release Maturity
- Define what Rapid Release looks like at your organization at different timeframes and maturity levels (e.g., 1-year, 3-years, 5-years)
- Advertise goals and repeat them over and over again
- Create visible progress charts
- Create organizational-wide awareness and training on rapid release principles
- Determine “What’s in it for me?” for your users when developing a minimal viable product with rapid feature implementation
- Implement pulse surveys to determine level of understanding of the process
- Define roles, responsibilities, and decision-making authority
- Define cultural and behavioral norms – for example:
- What does it mean to “fail fast?”
- What does it mean to embrace “ambiguity” and “constant flux?”
- How can employees not directly working on a rapid release project demonstrate agility?
- What are some of the unintended culture and behavioral shifts that can happen as a result?
Ultimately, there are many positive aspects of rapid releases that surpass waterfall style projects, but in order to realize those advantages, proper change management is critical. And while we’ve established that we can’t rely on Santa to bring us what we want, a good change manager, who can look at all aspects of how rapid releases affect your organization, will guarantee you get what you need.
For more fun thoughts on “Why Change Managers Are Failing in Agile Environments,” check out the other two blogs in this series:
