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 product. But a transformation from Waterfall to Agile requires more than a hallway conversation. Agile software development is not a methodology so much as a set of values which 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 which 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 will not alter their behavior without some 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 which offers a huge new market.
- Publicize management commitment to change. Have your VP – or higher – let everyone know that there is management support for Agile. Not only does executive management’s public support demonstrate the importance of your Agile transformation, but it also will increase your management’s commitment to change. Combined with a clear explanation of the reason to change, such an endorsement can focus and motivate everyone. Note that it is also important to repeat that commitment consistently – if it is 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 are done well. Are there plenty of people already in your organization who are 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 is important to agree on which variety of Agile you are planning to implement – Scrum, XP, Kanban, etc.
- Motivate the team. Since they will 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.) Communicate the reasons to change, clearly and consistently, in terms that address the needs of your team. You will 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 is not essential to change the manager to whom the team members report, but it is at least necessary for all the managers involved to agree on their expectations and standards. You probably will 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 the individual, 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. The team will now 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, and it is 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 backwards now and again. In particular, some members of your teams may initially be unwilling to share their knowledge for fear they will 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 that people work, it also requires changes to the way that 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 that 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 which does not 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 the team members’ jobs will evolve to include more skills, and expectations for new team members will be very different from what they would have been before the transformation. In order to recruit, train, support, and retain team members, the organization will need to re-define their job descriptions.
- Training programs may need to change. In addition to training programs in the new Agile values and processes, there may need to be changes in 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, the team members will expand their competence beyond their previous area of specialization. They become more valuable both to the organization and in the marketplace. Counselling may be needed for those who cannot or will not 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 that Agile is a journey, not a destination. Will you end up with perfect Agile development? No. There will still be politics, still conflicting priorities from different managers, and still cranky team members. But, you can make an enormous transformation in the way your employees interact, and increase both your quality and your speed to market. You will be able to adapt to changes in the business environment and to leverage the energy and wisdom of your employees.