All about transformation
Nowadays, the words Agile transformation
are the scariest words executives and management can hear. This article will resonate with those who have been through or assisted with "transformation" initiatives, large or small. As Agile professionals, there is only one important question to always ask before starting an Agile transformation, and to ask it three times: Why? (I would say use the five Whys
, but five seemed a bit excessive.)
Leadership must have a clear understanding of why they want to incorporate Agile values into their company. The biggest misconception about Agile is about the end result that it tries to achieve. Many think that Agile is another way for a department or company to conform to producing better, faster, and more collaborative results (and that is somewhat true). However, Agile is ultimately about trusting people and letting them do what you hired them to do.
When teams conform
On one hand, we have Company A, which wants to implement Agile because it hears it will be able to complete twice the work in half the time. It sees all the other companies doing it and feels that it will fall behind if it doesn't adopt Agile. So it gets a group of program managers together with an executive sponsor to establish a funding plan to recruit coaches, ScrumMasters, and Agile tooling administrators. After several weeks, it has a portfolio and a budget for recruiting the Agile experts necessary to lay out a transformation plan. Company A's only request to the group of coaches is that they use Scrum, because everyone else is doing it. People still log their hours instead of story points because they want people to self-organize, but the reality is that they make sure their teams still work 40 hours per week.
After a month of collaboration to create a transformation plan, the coaches communicate to the program managers that there isn't a good team space for setting up Agile. So the program managers ask for a larger budget to find team spaces and procure collaboration software for their offsite team members. After a couple of weeks, the coaches and program managers set up three-day boot camps, one a week, until the team members adopting Agile are trained on what Agile is and what Scrum is. Meanwhile, the software tool administrators work with the coaches to set up work flows, processes, and reporting for their new and shiny tool to assist their Agile execution and planning.
So after four weeks of Agile 101 training, new application training, setup of new team spaces and people with the roles of ScrumMaster and product owner, Company A is relieved that they are finally Agile! Coaches depart for their next assignment, ScrumMasters facilitate the established processes, and the team members attempt to throw random numbers at scope and have the tool dictate the work.
A few sprints later, project or program managers are frustrated that their transformation to Agile didn't produce the results they wanted. So, a few of the teams are told to revert to the old processes and "just get the work done." Stand-ups become status meetings, grooming sessions become requirement kickoff meetings, and retrospectives become application and database request-approval updates. Eventually, whispers get out that Agile is horrible and slowing the company down, and everyone abandons ship. Leadership points fingers, people get frustrated, and nobody understands why they failed. Leadership changes, new people come in, and the new leadership says, "Why aren't we doing Agile?"
When teams are empowered
Company B wants to adopt Agile because they realize that they have tons of overhead in management, confusion over projects, and a tendency to throw money at their problems when projects are overdue or they are lacking skills. They hear that Agile can help with their delivery, execution, and planning, but they ultimately want self-organizing teams because their culture lacks motivation for working and communicating among themselves. Unsure of how to approach a large-scale Agile transformation, Company B hires an Agile consulting company that recommends two coaches to come and explain different avenues and how Agile affects the company.
After understanding the huge cultural impact Agile has on the coaches, Company B decides to establish a couple of pilot teams to understand the impact and dynamics to the teams
. The coaches offer a three-day boot camp to team members so that they understand Agile, but Company B already understands how much this affects the culture and dynamics of the company. So Company B decides to put leaders through the boot camp, in addition to the team members, so they can fully understand what's going on. Training sessions are attended by everyone, from the director of operations to the junior developer who just started a month ago.
After a few weeks of planning and putting together a pilot team, with the guidance of the coaches, Company B decides to do a dry run of Scrum and collect feedback from the teams to see if it makes sense in the context of how they operate. Company B understands how big a change this is for the company and the impact it has on the employees and contractors. They didn't want to invest in a tool yet, because they didn't understand what they were doing, but they have offsite team members. Company B decides to go with a simple, free tool that drives the concepts and asks the coaches to help set up some work flows. So the team conducts a few sprints, goes through the ceremonies, and begins to finally understand the concepts that support Scrum.
After a few sprints, the leadership team sits with the Scrum teams and does a company retrospective in addition to the team retrospective. The team is semi-introverted, so the leadership team makes it fun and interactive by having them write on sticky notes and post on the wall what they love, struggle with, and wish they had. This generates discussion, and the team eventually spills all the beans. After several more company retrospectives, Company B's leadership has a good idea of how Agile is going and helps remove the impediments, steers the change, and decides that they can start scaling their success.
In short, they continue this cycle, buy an application life cycle management tool based on the teams' needs, and slowly roll out more and more teams with training, role clarity, and retrospective feedback with leadership. Company B is confused by whether they are actually "Agile," but at this point they don't really care. They see a huge increase in team members actually knowing each other and people innovating, they and hear and see laughter in the work areas. Company B concludes that Agile is really just the start of their journey to continuously improve themselves and eliminate waste while investing in trust.
Sounds like a fairy tale for Company B, doesn't it? It doesn't have to be a fairy tale. The Agile journey really is what you make of it. On my personal career journey thus far, the most successful transformations were in organizations in which team members felt empowered to improve and be heard. Naturally, leadership is critical to that success, because people look to figures of a higher stance for direction. It is leadership's job to understand that the old methods of fear, heavy process, and factory coding are things of the past.
Company A and B scenarios are only two of many. But I want to see what the community thinks and whether this is helpful in understanding different approaches and methods behind the adoption of Agile. If helpful, I plan to write more company scenarios!