By Ramesh R. Donnipadu, Bala Kishore, Pete Deemer
Abstract
The ability to deliver business value earlier and more often, increase productivity, and improve employee morale is compelling many organizations to embrace Agile approaches to software development. There is a wide array of training courses, consultants, and books available to help teams learn the basics of agile development, but these often focus on the team-level challenges, and overlook some of the larger organizational issues that may either help or hinder the transition to this new way of thinking and working. This article attempts to outline areas where many organizations encounter difficulties in their embrace of Agile, in hopes that others can be better prepared to meet these challenges.
Checklist
Depending on the size of the organization and current processes followed, different organizations may face different challenges in their Agile adoption. This section lists the most common difficulties that your organization may encounter in the early days of embracing agile development. Some of these items are not even related to Agile per se; they‟re just sound Engineering or Management principles, which any smart organization normally follows. But, these are not so obvious until you get into the thick of the things. Regardless, not attending to these issues at the outset could lead to frustration for the organizations getting into agile development.
This Checklist is expected to help you evaluate the preparedness of your organization to these new challenges.
Management
1. Do you have Management’s support?
Among the challenges a team may face in the early stages of adopting Agile, the most important one is winning the confidence and support of top management. If you do not have a genuine commitment to change from your top executives, you are not likely to be successful. Win their confidence support before you set out your journey. Be upfront with them on the roadblocks you may face and lay out your plans on how you intend to overcome them.
In some cases, the senior executives and junior technical staff may be enthusiastic to “go Agile,” but there may be a lot of skeptics in middle management. This could be due to the fear of losing control over their teams or inability to distinguish Agile development from “cowboy coding” or apprehension on the quality of the product or lack of documentation. You need to allay their fears by showing concrete examples.
What if your leadership fails to agree with you? You can still go ahead with Agile, but you are on your own in dealing with the challenges.
2. Is Proper Training Provided to the Organization?
The industry-standard training for Scrum teams is the Certified ScrumMaster (CSM) training course, conducted by a Scrum Alliance Certified Scrum Trainer, and we strongly recommend that this training be provided not only to ScrumMasters but also to team members, managers, and others in the organization that will be interacting with the Scrum teams. In addition, it's imperative that Product Owners complete Certified Scrum Product Owner training. If great results are to be achieved, everyone needs to understand how to “play the game” well.
This training in the fundamentals of Agile is just the foundation for success, though, and to be successful, there are other new skills that will have to be learned. First, Agile development quickly makes visible any deficiencies in teams‟ ability to work together closely and produce high quality functionality in the span of an iteration. Many teams require training to learn better coding and testing practices, whether in the basics of test automation, refactoring techniques, or in practices such as Test-Driven Development. In many organizations, team members have highly specialized skill sets, and often have difficulty working closely together as part of a cross-functional team; they may require coaching in how to do this successfully. Often, the most effective way to retrain the team in cross-functional behaviors is to “seed” the team with one or more members who are experienced in this way of working.
Another good way of accelerating learning is to start a study group that meets periodically to discuss various aspects of Agile development before the training takes place. During this period the team can read literature available on the Internet, starting with the Scrum Alliance website [www.scrumalliance.org]. We found these meetings are extremely helpful to come onboard quickly in terms of understanding the new practices and mindset, and adopt it to our environment.
In addition to new technical skills, teams may also require more education in their product domain. In Agile, developers are not “software robots,” blindly implementing software specifications; rather, we want them to be full partners in the development effort, helping the Product Owner achieve maximum business value. For this to occur, they need to have a working understanding of the business and technology context for the work they are doing.
Many organizations make a solid investment in training in Agile technical practices, but overlook training in the soft skills needed to really get the most from those practices. ScrumMasters, Product Owners, functional managers, and executives should receive training in facilitation skills, Agile retrospective techniques, dispute resolution, root cause analysis, and systems thinking. All of these are practical necessities for skillfully coping with the myriad dysfunctions that Agile development will quickly surface.
3. Did you train your Product Owners?
Strong product ownership is a key to the success of Agile development, since it is this group that bridges the gap between the end customers, management and IT. A very thorough understanding of the responsibilities of the Product Owner, how to work with customers, the team and stakeholders to achieve maximum ROI, and how to be effective with the essential practices are required.
When faced with large-scale development effort, it is often recommended that all teams work from a single, project-wide Product Backlog, as opposed to having multiple, team-specific Product Backlogs; this will help reduce the duplication, redundancies, and conflicting directions that can often result from the latter.
Unless your Product Owners are equipped with these skills, you are not going to see the big wins from Agile adoption.
4. Do you have enough space?
Agile principles emphasize face-to-face communication wherever possible. If the individual members of your Agile team sit at different locations, the overhead of communication reduces their effectiveness. It is mandatory to rearrange their seating so that it improves informal communication within the Scrum teams. Get the teams co-located into their individual team spaces even if you have to convince your facilities, HR, VP or CEO.
You also need to ensure that they have enough free space for informal gathering around a computer for a quick walk-through, their daily stand-up meetings etc. Also, ensure that the teams have adequate wall space, white boards, flip charts and writing material.
5. Are all your support teams on board?
Organizations make all efforts to train the teams that are adopting Scrum. But, often they ignore the need to familiarize other support teams. If the development team is going to be successful with Scrum, they need to have full support of any specialists who provide support but are not members of the team, for example, DBAs, Sys Admins, or the Configuration Management team. Unless they know the constraints and limitations of your Scrum teams, you are not likely to receive their deliverables and meet your Sprint commitments.
Get at least one representative from each of these departments enrolled in the Scrum training. Try to get these specialists included in your Scrum teams, ideally as full-time members of the team, or at least in the role of consultant.
6. How quickly to scale?
Often, large organizations attempt to roll out Scrum across several teams simultaneously; what some people call the “Big Bang” approach to change. Tempting though this may be, the risk of such an approach is that systemic or large-scale dysfunctions (which afflict many teams across the organization) will be surfaced by many teams simultaneously, and will have to be resolved quickly and for many teams at once. This is both very challenging and very chaotic. It may be easier to begin Scrum with a small number of teams, try different solutions to solving these baseline dysfunctions, and be able to provide best practices to later teams that follow in their adoption of Scrum. As the organization gains confidence and competence in Scrum, more teams can start practicing it.
7. Is an appropriate attrition strategy in place?
This may not be an important item in difficult economic times, but for organizations susceptible to high attrition, dealing with this problem could be very challenging. Unlike in traditional models, Scrum believes in tightly gelled teams of individuals with a core competency and multiple cross-functional skills. As Scrum teams are smaller, losing a single member could prove to be a significant setback for a team. Even if you find a quick, equivalent replacement, it will take some time for the new hire to get up to speed, bond with the team and start delivering.
Scrum provides the benefit of teams, but also makes more visible the disruption when teams are broken or changed.
Have a trained pool of engineers available, who could substitute an unexpected departure in your team.
8. Can your engineers appreciate the purpose behind a user story?
A competent technical team can convert a user story into database tables, Controllers, tags and Form elements fairly quickly. But some teams may have difficulties in comprehending the motivation or ROI behind a feature they are implementing. For Agile to be successful, it is critical that all members of the development team (developers, testers, etc.) “get into the Product Owner‟s head” and appreciate the rationale behind a user story. They should keep questioning the objective of major decisions and suggest alternative implementations where possible.
Otherwise, one risks ending up with brilliant technical implementations that fail to meet the business goals.
9. Module assignment to teams
If you are planning to assign different software modules to different Scrum teams and you expect them to have exclusive check in privileges on their modules, you need to be very cautious. While it is a good idea to let individual Scrum Teams master specific software components, if you implement a user story that requires multiple Scrum teams to work on it, all hell breaks loose. The interface design, hand off, and integration between multiple teams introduce a lot of waste.
Also, avoid restricting teams from touching other modules based on their ownership. You can better enforce the code ownership with good code reviews and refactoring policies.
Code
10. How tightly coupled is your system?
If your code base consists of tightly coupled modules, and you have a large number of Scrum teams, chances are that they will be stepping on each others‟ toes constantly. The problem will be more acute if the Sprint or release cadences of the teams don‟t align.
If possible, spend some time re-organizing your code base to minimize the inter-module dependencies. This exercise is well worth the effort as the code will be more modular and less tightly coupled, which in turn will create better „code‟ conditions for the Scrum Teams to do their job, and enable the teams to more quickly produce more business value.
11. Do you have good Unit/Automation test coverage?
At the heart of Scrum is the delivery of potentially shippable software at the end of each Sprint. For this to happen, test automation is a must. If you do not have a comprehensive set of automated unit tests that are tied to your build system, you are likely to spend more time in testing and debugging than necessary, and it will be difficult to end each Sprint with a fully tested (and fixed) system. In addition, automated tests give the team confidence in making changes; they know that if the change breaks other parts of the code, it will be immediately visible.
Strengthen the foundations of your code base by adding as many unit tests and automation tests as possible. Teach your developers the art of Refactoring, if they don't already know it. Tools like Emma, Jester and Cobertura will help you measure the coverage of unit tests.
Tools
12. Do you have good collaboration tools?
This item is critical for the geographically distributed teams. Agile requires a close interaction among team members, so you need to ensure your team has all it needs for effective communication. Use video conferencing, telephones, emails, instant messaging, and Skype as much as possible. VNC, WebEx, Sococo are other useful tools for the team collaboration. If you are planning to introduce a tool such a Rally, VersionOne, or ScrumWorks, make sure the teams themselves have an opportunity to evaluate them fully before making a decision.
13. Do you have a source code repository replication system?
This item is more relevant for multi-location teams. Nothing can be more frustrating for your remote teams than accessing the repository on a slower network. Due to shorter release cycles, your teams would be doing more frequent checkins, checkouts, branching, merging than they normally would if they were using traditional methodologies. Make sure you have a fast, reliable repository replication solution in place before you roll out Scrum.
14. Is your build and deployment system fully automated?
It is difficult to imagine a modern software development organization not wanting to automate their build and deployment activities. Design your build and deployment processes to be completed in a short time, say, 30 minutes. This should include executing the test cases and certifying the build. It is even more preferred to have a continuous integration (CI) policy before you move to Scrum. The CI will highlight the build/integration issues and help the teams identify and fix the issues quickly. When the teams are working in short time-boxed iterations, any time gained in their iterations will be valuable.
Alternately, if you require a lot of manual intervention in the build and deployment, your teams‟ velocity is going to be affected.
Others
15. Do you have adequate Dev and Test environments?
If you would like to have dedicated Dev and QA environments for individual (or groups of) Scrum Teams, you need to plan them in advance. You also need to ensure you have enough hardware, software licenses, and IT support staff to build or maintain those environments. Since budgeting, getting approvals, ordering, hiring, and training take a while, you need to plan this well in advance.
16. Do you have enough monitoring/health-check systems in place?
If you are working with a large number of environments and each of these environments has multiple servers, databases, networks and other third party components, you need to have a robust monitoring system in place. Zabbix and Hobbit are a couple of good tools you could consider for monitoring the health of your systems.
Conclusion
Due to the wide philosophical differences between traditional and Agile methodologies, a few organizations are facing challenges and getting frustrated with their results while adopting Agile. A lot of these challenges can be met effectively with decent preparation. This article presented a checklist of items to be considered along with a mind map for the benefit of teams getting into Agile.
References
- Scaling Lean & Agile Development, Thinking and Organizational tools for Large-scale Scrum,Craig Larman, Bas Vodde, Addison Wessley 2009
- Scrum & XP from Trenches, Henrik Kniberg
- 10 ways to screw up despite Agile and XP, Henrick Kniberg at Agile 2008, Toronto
- Art of Agile Development, James Shore, Shane Warden, O‟Reilly Media 2008
- Agile Testing: A practical guide for Testers and Agile Teams, Lisa Crispin and Janet Gregory
