Many software companies are adopting Agile methods at an exponential rate - whether the adopting company is a software service or a product development firm or whether the work is on retail domain or avionics. This article covers the challenges that organizations may face and also recommends possible solutions that could help in quickly adopting Agile. The article is based on my experiences while adopting Agile at Valtech India. I've also had the privilege of working with one of the important thought leaders in this field, Craig Larman, Chief scientist at Valtech. Without his constant guidance and coaching, we could never have come so far on the pathway of Agile.
Introducing Agile in an Organization
A typical software services company can be viewed to be made of three layers of people with a varying degree of authority (see Figure 1).
Over the past five years, I have personally conducted more than fifteen training programs about Agile - both at Valtech and other companies where I have been invited. Developers and project managers form the majority of attendees. During my interactions with them I've realized that it is these people who:
- Subscribe to Agile blogs;
- Actively pore through many popular Agile mailing lists; and
- Have the most passion in implementing Agile.
These people are {sidebar id=1} eager to learn Agile and look forward to implementing it in their projects. This kind of strategy is known as quot;bottom-upquot; Agile adoption.
While this strategy may work in the short run, this is a non-sustainable model of Agile implementation. I am not saying that the developers do a lousy job in implementation - it is simply that they lack active support from the sponsors.
In a top-down Agile adoption strategy, the sponsors take the initiative and encourage (not push) the teams to adopt Agile methods. Some of the Agile practices need investment for procuring tools, changing the physical environment, organizing training for the developers, having a coach, etc. Such decisions are typically taken by the sponsors.
Some of the advantages of top-down adoption include:
- Higher visibility - everybody observe the changes happening in the work place and culture.
- Confidence - teams can experiment with new practices and tools since they have the firm backing of the sponsors.
- Transparency - teams have the opportunity to correct mistakes during initial stages.
- Consistency - the practices have a higher chance of being consistent with the company vision.
The Need for Top-down Agile Adoption
Agile is all about people, trust, communication, flexibility, and feedback. These values need a lot of nurturing at all levels in the organization. First and foremost, the sponsors must believe in these values for effective Agile adoption.
In a bottom-up Agile adoption strategy, many of these values cannot bubble up easily when compared to the top-down strategy. The challenges are:
- Lack of buy-in when ideas come internally (versus given by an external neutral party).
- Generally more difficult and time consuming to convince sponsors by the developers.
- Requires lots of sponsor time and good communication skills by the developer passionate about implementing Agile.
Categories of Changes
Figure 2 shows the changes needed during Agile adoption. Each type of change is discussed in detail below.
Changes needed
| Requirement from sponsors
|
Change in thinking patterns and culture | Encouragement, motivation |
Investment in new tools | Capital |
Sustained support for Agility | Encouragement, motivation and commitment |
Change in Thinking Patterns and Culture
This is one of the most difficult things to achieve. We, as human beings, resist change and hold on to our old beliefs and thoughts that are close to our heart.
The following thinking/culture changes are necessary for Agile adoption
- Building trust
- Getting rid of command and control
- Improving communication and collaboration
Building Trust
In an Agile training program, a team was discussing about the usage of Post-Its to display project information. A project manager posed this question:
What should I do if my team members remove post-its without my knowledge?
This is a clear sign of lack of trust within the project team. In this case, the manager was sent to attend Agile training and implement his experiences on project. But, such managers who lack trust—a fundamental value of Agile—will be ineffective in implementing Agile practices. Management should keep observing the teams, identify issues that crop up (they will!), and coach them accordingly. In fact, it is healthy to see lots of issues in this stage - this implies that the system is gearing up for the new philosophy.
The sponsors should encourage an environment for learning for continued Agile adoption. Valtech has taken the following steps in this regard:
- Getting help from experts (e.g., Craig Larman spent five months coaching the India team).
- Forming an Agile Mentoring team (we have four members at Valtech).
- Sponsoring CSM certifications.
The Agile principle quot;Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job donequot; clearly emphasizes the importance of trust.[i]
Prime Directive and Trust
Here is the "Prime Directive [ii] which is commonly used during retrospective sessions:
Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.
The Prime Directive just redefines what trust is all about.
A team practicing Agile methods might work collaboratively, trusting each other, but if the customer or sponsors don't trust the development team or vice versa, the foundation of Agile becomes weak.
Getting Rid of a Command and Control Culture
A command and control system is created due to fear and lack of trust. Employees in the traditional organizations are quot;controlledquot; through a set of processes. For example, a developer working in a service organization is expected to gather all requirements upfront. The stakeholders create a plan and the developers are expected to stick with the plan and deliver the product as per the deadline. The developers' lives are controlled through a predefined plan written on Gantt charts.
Traditional organizations also create and track various types of metrics. Even though many metrics may be useful, some of them are misused for controlling individuals and teams. Some metrics are also used as a weapon during performance appraisals. (Does this ring a bell to you?)
In a command and control environment:
- The Project manager creates all estimates and assigns tasks to the development team.
- An Architect handing off his plans to designers and developers.
- Developers are restricted from communicating directly with the customers.
Agile organizations, on the other hand, discourage usage of such metrics and encourage only those metrics that adds value to the customers. These include burn down charts and velocity metrics.
In an Agile environment, self organizing teams make the necessary decisions on a project, as opposed to one person making all decisions (as in traditional projects). A single person in control leads to lot of subjectivity and personal bias.
The culture of one person in charge and making decisions for project needs to be dismantled. This can be done only with the support from the sponsors- otherwise self organizing teams cannot emerge.
Improving Communication and Collaboration (C &; C)
In traditional systems, the customer's role begins by validating and signing off on the requirements. Later, the customer may participate in periodic reviews done during milestones and monitor project progress. We can equate this behavior to a fire and forget culture, and one that leads to inadequate communication and collaboration.
Software development is inherently a complex process which requires frequent inspect and adapt cycles. This demands strong communication and collaboration -between the customer and the development team and within the team itself.
Developers and customers working together with a commitment to achieve common goals is real collaboration.
The Agile principle, "Business people and developers must work together daily throughout the project" brings out the importance of collaboration.[iii]
Some practices in an Agile method like Scrum that exemplify this principle are:
- Release Planning
- Requirement workshops during each iteration
- Iteration planning meetings
- Retrospective session
- Iteration Review, etc
At Valtech, we implemented a number of changes to improve communication amongst the team members including:
- Removing cubicle boundaries, thus allowing the team to sit together.
- Encouraging the Project Managers to sit with the team.
- Using of simple tools.
Investing in New Tools; Willing to Get Rid of Old Tools
Agile adoption definitely leads to a position where old tools will have to be discarded and new ones should be introduced. At Valtech, we discarded usage of Microsoft Project Plan and significantly reduced usage of Microsoft Word.
We started using tools like Web Cameras, Confluence Wiki, Digital Cameras, Audio/Video conferencing tools like Interwise, and WebEx, and encouraged dual monitor usage. We also took advantage of whiteboards, cling-on sheets, flip charts, Post-Its, markers, and Red-Green lamps to serve as information radiators (see Figures 3 and 4).
Conclusion
After considering the various challenges and solutions during Agile adoption, we have found that Agile adoption is much smoother with continued support from the sponsors. I firmly believe that any organization will succeed in Agile adoption with the right mixture of both top-down and bottom-up strategies.
[i] See http://agilemanifesto.org.
[ii] See "Project Retrospectives: A Handbook for Team Reviews" Norman Kerth, Dorset House Publishing Company, 2001.
[iii] See http://agilemanifesto.org.
