Developing products and services often requires learning through rapid experimentation. It also requires people with diverse skills and expertise to work together. This in turn requires an environment that supports collaboration. Survival in this digital age also relies heavily on teams that are driven by goals they care about, and motivated to make a positive impact. In a highly competitive marketplace, the ability of an organization to implement the above, while controlling risk and reducing Time-To-Market, is a true competitive advantage.
Agile development, especially Scrum, has become a very popular way to accomplish this, and in VersionOne's annual global survey 2022, more than 80% of respondents reported using Scrum or a hybrid that includes Scrum.
However, more than 28% of respondents who have adopted agile development say they are not satisfied with the results. Some of the most cited reasons for this lack of success are:
- Not enough leadership participation, 42%
- Not enough knowledge about Agile, 40%
- General organizational resistance to change, 40%
- Lack of management support, 38%
While these issues are not easy to address, others have faced them before and there is much to be learned from their experiences.
**Organizational structure and culture**
Organizations are structured to support their existing culture, processes, and objectives. Especially in larger organizations, the ability to innovate with flexibility and speed is rarely a Top Priority from the start.
If you try to change the way your team works, the existing structure and culture will fundamentally get in the way. Without organizational adaptation, the benefits of Scrum will be limited, and the initial structure will often pull the team back to the old way of doing things. Let's see what that can look like with two real-life examples.
Example #1: A cross-functional Scrum Team has a common and sole Product Goal and a Sprint Goal in each sprint. In a traditional organization, however, these goals coexist with goals defined for each department and individual. When the latter are used to evaluate people's performance, the common objectives of the Scrum team become secondary and the work within the Scrum team tends to remain siloed.
Example #2: Scrum encourages Team to "start with what they have," learn as they go, and be transparent to stakeholders about what they learn as they make progress. This approach to solving complex problems is at the core of Scrum. However, traditional organizations unfamiliar with agile development tend to view every new learning from the team as evidence of poor planning and insufficient preparation. Seeing how problematic it can be to be transparent about new realizations during the course of a project, teams begin to withhold information and stop doing anything without a detailed plan.
**Start small, keeping the big picture in mind**
But that doesn't mean you shouldn't set up cross-functional, self-managed teams until you've completely rethought your company's structure or culture. On the contrary, I believe that Scrum should be started small as much as possible. From there, try to gradually improve the product, the team developing that product, and the organization as a whole.
At the same time, it is important for management and leaders to be aware of what they are up against if they are going to work on implementating Scrum. Scrum is not about making minor changes to the way people work. Rather, Scrum implementation is a radical change that requires effort - especially in larger organizations.
**Explore the hard questions. Be brutally honest**
It is important for organizations to align on why they have decided to change the way they work. However, it is not enough to write superficial, feel-good reasons on a PowerPoint slide, such as "To become more customer-focused" or "To leverage the power of digital". Unfortunately, I have seen many of these shiny documents. Instead, I encourage teams and their leaders to explore tougher questions, such as
- What are we willing to give up in order to increase agility?
- Who is responsible for making it happen?
- What are some things we like (or are simply used to) about our current organizational structure, work style, or culture, that could go away? Are we okay with that?
- What are bad thing that could possibly happen? What can we do to prevent them from happening? Are we OK if they happen anyways?
- How will we know we are on the right tracks? What would red flags look like?
- Who else needs to act in order to make Scrum/Agile work here, but is not yet involved? HR, Compliance, Finance, Marketing, etc.
I try to have these conversations when I am asked to support an organization. And more than once. Like product development with Scrum, Scrum implementation itself is an iterative process that requires transparency, inspection, and adaptation. For such conversations, I often try to leverage Liberating Structures. Liberating Structures are collaboration techniques for engaging and unleashing everyone's unique perspectives. They are especially effective in situations where there is value not only in the conclusion or decision reached at the end, but also in the conversations along the way. The Inception Deck popularized via the book The Agile Samurai can also help generate necessary conversations.
**Involve leaders and various departments**
I have been involved in multiple Scrum and Agile implementations. In some cases the sponsor would be the CEO, in other cases the sponsor would be the CIO/CTO/COO, and for smaller companies the sponsor would sometimes be a single engineering manager.
Depending on who the sponsor of the initiative is, the difference in the results can be staggering. Again, Scrum is not about changing the way developers work, it is much more fundamental. Therefore, there is only so much that can be accomplished without CEO sponsorship.
For example, without the cooperation from the Finance department, it is difficult to change the budget allocation process. It is also difficult to make a team cross-functional end-to-end without the support of e.g. the Marketing department, the Sales departments, or the Compliance team.
This does not mean that everyone has to be an advocate and active supporter from the start. It is common for people to be skeptical. In fact, I think a fair amount of skepticism is healthy, and helpful in avoiding the all too common cargo cult agile. But a willingness to try new things, and see what happens, is at least necessary.
The importance of aligning the entire organization and the difficulty of doing so is another good reason to start small. Then, as the initial Scrum Teams make incremental progress and begin to make a positive impact on the organization, you become better equipped to engage with the more skeptical or reluctant stakeholders.
**Learn continuously**
There is a lot that goes into making a Scrum/Agile introduction successful. What successful means here will vary greatly depending on the team and its organization, but it includes "in such a way that it contributes to the achievement of the goals of the organization, the customers, the employees, etc.". So to be clear, we are not talking about superficial manifestations of Scrum adoption such as the number of appointed Scrum Masters or the frequency of your Daily Scrums.
In any case, if you want to maximize your organization's chances of success, try to learn and gain insights from books, trainings, case studies, or individuals you trust. As one possible place to start, I can recommend the following resources:
- If you like learning from books, you can go with "The Professional Agile Leader" (Kurt Bittner, Laurens Bonnema, Ron Eringa) or "97 Things Every Scrum Practitioner Should Know".
- If you prefer learning via training courses, consider joining a "Professional Scrum Master" class (English, Japanese) or a "Professional Agile Leadership Essentials" class (English).
- If you enjoy learning from direct interactions with people, consider joining communities of practitionners and conferences.
Best of luck on your journey and let me know if I can help.