More Than A Process
Imagine being tasked with learning to play jazz. Working the scales. Memorizing songs. Over time you would develop a level of talent regardless of passion. You would probably even get good enough for gigs with a local bar. This would probably be good enough to fulfill the task of learning jazz. It wouldn’t get you to the level of Louis Armstrong though.
Attempting to move your team to Agile is the same. Put the proper processes in place. Follow the rules. Over time a new pattern of work develops, one that is more Agile-like than the previous one. This new paradigm plateaus. It’s probably different enough than what was done before that everyone looks and says “yep, we’re Agile now.”
Over time the management that wanted the team to go Agile is going to get frustrated though. This new paradigm, it’s not what she wanted. She was promised continuous improvement. She thought the team would become high-performing. She was expecting to have a product to market more quickly, and more relevant to that market when it arrived. Something went wrong.
This is not a process problem. In fact, evaluating the teams process against the rules of Scrum, Kanban, SAFe, or whatever agile process was chosen is likely to result in their process passing with flying colors. The problem is that Agile is more than just a process.
All of the current popular Agile methods can trace their inception back to a single meeting. A single point in time where the concept of what we now think of as Agile was born. This meeting was focused on software development and the people there likely had no idea just what their ideas would turn into. This meeting is where the Manifesto for Agile Software Development was born.
The problem with many disappointing and failing attempts to convert teams to Agile are due to the focus on process. Think of Scrum for a minute,since it is the most popular vehicle for an Agile transformation. There is a defined framework for the team to base their work around. There are defined meetings, a suggested rhythm, specified roles. A company will often implement this exactly as stated and then start tracking how well the team adheres to this framework. They will focus on making sure they follow the process. Often the former Project Manager is made the Scrum Master (since there is no PM in scrum) and put in charge of the process. They then become the primary driving force for the team.
This is something most PM’s feel they can jump right into. Maybe they even take a three-day course to learn the Scrum process, another tool in the PM belt. They then go about setting the framework up and ensuring everybody gets to every meeting they are supposed to. They religiously update the progress board every day, drilling the team for progress reports at the daily stand-up to get the information they need. They present that progress to upper management every week. They make sure that everyone knows what they are supposed to do for the sprint at each sprint meeting. It all looks right on the surface, but things haven’t really changed.
Sure, the meeting schedule has changed. The speed of delivery might even change. The process is definitely different, but it isn’t Agile. It’s really just another form of what was happening before.
The problem is that they haven’t embraced the idea of an Agile process. They just changed from their former process to Scrum, but kept focusing on the Process and not the People. They made an initial jump to the new framework, but now are more concerned with following the framework than doing the best work they can as a team.
Making a transition to Agile isn’t just about the process used to accomplish work anymore than being a great musician is about pushing notes out properly. There is something more needed. The team, just as the musician, has to believe in what they are doing. They have to be invested in it on a personal level. If all they do is follow a new process nothing will change.
Is your Agile transformation stalled? Maybe you need to stop training the rules of the process in place and consider having everyone step back and define how the rules represent the manifesto, and how the rules might need to change. Then support them as they experiment with changing them.
