10 Critical Culture Change Elements in Agile Transformation
Lots of companies are hopping on the Agile bandwagon these days. They want the promised benefits of more flexible planning, quicker time to market and higher-quality products. But a transformation from Waterfall to Agile requires more than a hallway conversation. Agile software development is not a methodology as much as a set of values that drive methodology and process. Therefore, for an enterprise to move from Waterfall to Agile, the entire corporate culture must shift.
Agile values include willingness to adjust to changes in requirements, collaboration with customers, interaction within the development teams, and frequent and incremental delivery. These are in stark contrast to traditional values of negotiated and elaborate fixed requirements, silos of closely controlled processes, and infrequent delivery of major changes of functionality. A change of this magnitude is highly disruptive and can be intimidating for those involved.
Here are some suggestions that can improve your probability of success:
- Have a compelling reason to change. This is the single most important item: Everyone in the organization needs to understand why they should change the way they do their jobs. They must make an emotional commitment to the change and respond with more excitement and determination than fear. Learning takes work, and most people won't alter their behavior without a good reason relevant to themselves — someone else’s bonus is more likely to discourage than to motivate them. Most often, large-scale change will occur in response to a clearly perceived threat, but it can also occur in order to accomplish an exciting goal, such as mastering new technology that offers a huge new market.
- Publicize management commitment to change. Have your vice president — or higher — let everyone know there's management support for Agile. Not only does executive management’s public support demonstrate the importance of your Agile transformation, but it also leads to increased management commitment to change.
Combined with a clear explanation of the reason to change, such an endorsement can focus and motivate everyone. Note that it's also important to repeat that commitment consistently — if it's seen as management’s “flavor-of-the-month” brainchild, people will simply tune it out and wait for the next month’s flavor.
- Draw on expertise. It’s easier to adopt new behaviors if someone can demonstrate them and can recognize and applaud when they're done well. Are plenty of people in your organization already familiar with Agile processes? If not, perhaps you need to bring in some outside expertise to advise and train the rest of your staff. Additionally, it's important to agree on which variety of Agile you're planning to implement — Scrum, XP, Kanban, etc.
- Motivate the team. Since they'll actually be doing the work, the development team members must commit to the change. (It’s even more effective if they lead the change effort.) Clearly and consistently communicate the reasons to change in terms that address the needs of your team. You'll probably have some team members who are more skeptical or cynical than others. Success is the single best argument to convince them, so do all you can to provide some “quick wins.”
- Reorganize for team structure. Since the work will now be completed in teams, the organizational structure may need to change from functional silos to product-based, cross-functional teams. It's not essential to change the manager to whom the team members report, but it's at least necessary for all of the managers involved to agree on their expectations and standards. You'll probably want to reorganize physical space as well to provide easier communication among team members.
- Redefine accountability. Once the work has been assigned to teams, management will need to hold the team, rather than individuals, accountable for its success. Previously, they may have relied on the networking guru, for example, or on the two testers who knew every function in the system. In order to move from thinking and working as individuals to thinking and working as cross-functional teams, everyone in the organization will need a fundamental shift in perception. The guru and the testers will be assigned to teams, and not only they but everyone else will need to stop expecting them to carry the whole load. That way, the team will be able to make progress even when the guru takes a vacation or a maternity leave or comes down with the flu.
- Expect and support culture change. For most organizations making a transition to Agile, the change will require new structures to support the changes in thought and behavior. Look at existing reward programs and patterns of behavior. Do your programs support teamwork or competition? Sharing or hoarding information? Direct or indirect communication? Managers and coaches will need to start modeling collaborative, energetic, customer-focused behavior and revising formal policies to support Agile values.
- Allow for a learning curve. New behaviors become easier with time. It's unreasonable to expect everyone to adapt immediately and perfectly. You can expect to repeat your values and the reason for change many times before they truly sink in. Allow for some initial awkwardness and for a few steps backward now and again. In particular, some members of your teams may initially be unwilling to share their knowledge for fear they'll make themselves redundant, and it will take time and positive experiences to persuade them to trust the team or the process.
- Don’t forget human resources. Because an Agile transformation involves changing the way people work, it also requires changes to the way people are managed. Both the structures and processes of employment may need to adapt.
- Measurement of progress and achievement may need to shift. It’s very likely your pre-transformation performance appraisal forms are designed to consider individual effort, not team results. But, for successful Agile processes, you want individuals pitching in to help one another. Don’t undermine that behavior by blaming or rewarding an individual to encourage behavior that doesn't support the team.
- Job descriptions may need to change. As cross-functional teamwork improves, several team members may help with the testing, testers may help with functional definition, and back-end developers may learn more about layout and visual consistency. Eventually, all of the team members’ jobs will evolve to include more skills, and expectations for new team members will be very different from what they were before the transformation. In order to recruit, train, support and retain team members, the organization will need to redefine their job descriptions.
- Training programs may need to change. In addition to training programs in the new Agile values and processes, the organization may need to change training for job evaluation, coaching and feedback, peer-to-peer interaction and other interpersonal skills.
- Compensation may need to change. As a team becomes more successfully cross-functional, team members will expand their competence beyond their previous area of specialization. They'll become more valuable both to the organization and in the marketplace. Counseling may be needed for those who can't or won't change. Change is hard, and not everyone will be able or willing to make a transformation to Agile values and processes. Others may need help adjusting their attitudes to the change.
- Remember Agile is a journey, not a destination. Will you end up with perfect Agile development? No. There will still be politics, conflicting priorities from different managers, and cranky team members. But, you can make an enormous transformation in the way your employees interact and increase both your quality and speed to market. You'll be able to adapt to changes in the business environment and to leverage the energy and wisdom of your employees.