What are the top ways in which organizations fail to adopt or fully implement Scrum and/or Agile?
“It is difficult to get a person to understand something, when their salary depends on not understanding it.” – Upton Sinclair
First, let’s address the question. Agile is not something that we can implement, it is a characteristic that we try to achieve. So, we do not “do agile”, we practice techniques that help us become agile; that give us the ability to move gracefully and help us become adaptable and resourceful. Given this goal, why is it so elusive for many individuals and organizations?
Through my experience with clients and colleagues, I’ve distilled down several categories of individual and organizational dysfunction that leads to “fragile agile.” Ultimately, Agile and Scrum (which I use interchangeably in this article) are not about software; they are about people.
Work with an Experienced Agile/Scrum Coach
There can be tremendous trepidation for organizations dipping their toes in the Agile pool. Simply sending a few staff project managers to Scrum Master training is insufficient to foster the degree of change required to succeed. What’s needed are experienced coaches – seasoned professionals who have not only facilitated such a transition successfully, but understand the growing pains and trouble spots described herein.
In smaller organizations, a proper coach may be external out of necessity. This is a good time to engage an Agile/Scrum coach on a consulting basis to help get you started, or even back on track. For larger companies, you may have a coaching resource on staff to leverage.
Resistance to Reorganization is Dysfunctional
I once worked with an organization that wanted to “do Scrum” in order to accelerate delivery times. While this is a great reason to implement Scrum, there were some cultural and personality issues that stood in the way of success. At an executive level, there was little or no support for Scrum, not only due to skepticism of what was viewed as a “fad” methodology, but also an unwillingness to defer control to teams. This change in behavior would mean losing the “carrot and stick” with which the company was so used to using.
Middle management was also fearful of the type of change that Scrum required. Would managers become obsolete with self-organizing teams? Loss of livelihood is certainly a valid reason to fear change. There were a few managers who were on board with the change, and chose to upgrade their skills. A couple became Scrum Masters, and others used the change as an opportunity to go back to hands-on technical work. Unfortunately, there were some managers and executives who still wanted status meetings, reports, and requirements artifacts up front.
The development teams were, for the most part, very excited at the opportunity to embrace Scrum and move toward Agility. There is generally nothing more toxic to a developer’s productivity than meetings and other interruptions. Scrum was a way to make all that pain stop. However, the cure comes at a price – transparency. There were some development team members who prefered to hide behind a manager, and disliked the transparency into their daily activities that is required by Scrum. Sadly, a few folks quit, but that made room on the bus for new folks better suited for this type of work. Expect to lose people during this transition.
Unfortunately, I would classify this organization’s transition to Scrum as an abject failure. This was not a failure of Scrum; it was a failure of people. Nobody in the executive suite was willing to change their behavior. They simply wanted what they wanted, but faster. Not enough time? Work more. Not enough people? Work more. Can’t finish these features? Work more. Broken in production? Blame someone and fire them. Motivation through fear is in opposition to the level of sustainable productivity required for any team to succeed over time.
Scrum can’t cure personality disorders. The dysfunctional can’t become Agile.
Lack of Empowerment
Team empowerment is a fundamental precept of Scrum. A high-functioning agile organization will structure teams to manage and organize their work. After all, nobody knows better how the team works best but the team! With empowerment comes accountability. The team is in the driver’s seat, and management takes on a support role, removing obstacles for the team. As the team self-achieves, its sense of empowerment is strengthened.
I recently worked with an organization that practices Agile and Scrum with several teams, each of which in various stages of maturity. The poorest functioning team had one obvious weakness – the Product Owner. Her manager placed her in this position as a learning experience, presumably to improve her confidence and visibility in the organization – a noble enough gesture. However, she had very little actual product knowledge, and the project was high risk with a tight deadline. As a result, she became little more than a proxy for her functional manager, and a pushover to stakeholders. Empowerment cuts both ways. Make sure you put the right people in the right seats, or the bus will go off the road.
Getting Back on Track
Any event that provides an opportunity for inspection and adaptation can be considered a feedback loop. Unfortunately, many organizations fail to integrate critical feedback into its processes. Insodoing, they deny themselves increased levels of performance and flow.
The four basic events providing feedback loops in Scrum are: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. I’ve found that the Sprint Retrospective provides some of the most valuable, yet hardest to implement feedback. Here, the onus is on the Scrum Master to not only effectively facilitate the meeting, but to remove impediments for the team. Often, these impediments are not removed, even after repeated retrospectives. Ensure that your Scrum Master is not hand-tied, or worse, incompetent.
A cardinal sin I see repeatedly committed by ineffective Scrum Masters is a struggle to “get back on track.” An off-track team can be evaluated both objectively and subjectively. The former is evidenced in various metrics such as velocity, burndown, and bug severity and frequency. The latter is more clearly evident through direct observation of the team. Is the daily scrum occurring? Is the team working on tasks outside of the sprint backlog? The Scrum Master is the coach. When the team is struggling, look to the coach, not the team.
Scrum Masters are not Project Managers. Often a novice Scrum Master will try to manage the team instead of leading, coaching, and guiding the team. A command-and-control management style is antithetical to Scrum and Agile Methods. Any Scrum Master who assigns tasks and dictates effort is not only breaking the rules of Scrum, but will also poison your team. The best Scrum teams are self-organizing, with their Scrum Master functioning as a servant leader.
Selecting the Wrong Pilot Project (and People!)
Agile won’t meet everyone’s needs, and if it does, you won’t get it right immediately. So, minimize risk with a pilot project. Much of what drives success is enabling suspension of disbelief in what Scrum promises and the understanding that comes only in practice with an engaged team. Results drive perception and in turn perception drives results iteratively.
When forming a new Scrum Team, I would suggest that if the team don’t hand-pick themselves you need to sort out your hiring process before you go much further. This is not only the first step in self-organization, but also in the level of corporate cultural change necessary for success.
In new teams I repeatedly remind them to:
- Inspect and adapt
- What is done cannot be changed, how one adapts is more important
- Scrum will highlight problems quickly
- It’s hard to do Scrum well
- Failure should be seen as an opportunity to adapt
- We mitigate the impact of failure by timeboxing and frequent inspection
Keep in mind the stages of team formation as your pilot project proceeds. You can read up on Bruce Tuckman’s work on the subject, but the short version is that teams follow a predictable path on their way to high performance:
Forming → Storming → Norming → Performing
When something goes “wrong” early on, you can safely blame storming. When a high-performing team stops performing, you have a bigger problem than storming. Look to external factors throughout the organization first.
Notice I addressed the “people” part of the project before the actual project selected to pilot. Which project you select to pilot is far less critical than the team delivering its value. Whichever project you select, be sure that it’s difficult or presenting serious problems. This may seem counterintuitive and risky, but these are often the ideal projects in which the empirical nature of Scrum can quickly prove itself. Contrast this with a 12-month waterfall project, where failure is observed only at the end of the project, when all the time and money have been spent, and course corrections are impossible to make.
Remember, Scrum provides a framework in which to “fail fast.” Don’t expect miracles after one or two sprints.
For Training, Coaching, and Consulting engagements, please contact me for details on how I can help your organization.