program selection system

Premise The ability of agile practices to scale to “large” software development efforts (more than three teams or 30 team members) has been widely debated in recent years. While a variety of inhibitors to scaling agile are frequently cited, this experience report describes how the primary challenge to scaling agile that we faced was finding the right people to build our agile tribe. The effective adoption of Agile requires passionate, motivated individuals who accept change, think like a business owner, operate willingly outside team walls, and identify and drive program issues. Finding such a large number of people with these qualities is much more difficult than establishing methods to support communications, progress tracking, and other agile practices. We conclude by describing the attributes of the type of person that we believe will thrive in a large-scale Agile shop.

About Us

• Division of Siemens Medical Solutions, Inc. USA - commercial software for the Medical Industry • ThoughtWorks was brought in to “jump start” the adoption process – provide developers and Scrum Masters experienced in Agile practices

Project History/Challenges

During this part of the discussion, we will identify two of the key project challenges we experienced. We will describe the processes and tools we put in place to address the challenge, but seek to illustrate how the root cause of the problem was individual adoption of Agile.

Integration & Dependency Management

While on Agile projects, one seeks to reduce external/cross dependencies as much as possible. A project of this scale, that is adopting a SOA strategy, still requires a significant amount of cross-team integration. We were particularly dependent on one core service provider throughout the project. We struggled with:

• Finding effective, lightweight methods for identifying and tracking dependencies and defining requirements and creating contracts

• Scheduling implementation and integration to limit blockages and reduce code decay We created solutions to these problems and, in specific instances, were able to effectively manage large-scale integration. However, we were unable to do so across the project due to individuals being unable to:

• Proactively seek out future integration points and potential challenges

• Stop using highly contractual, document-centric processes and sit down together to solve the problem quickly and efficiently

• Take ownership of the completed integration point and change individual team backlogs

Continuous Integration

•We were continuously challenged by the size and complexity of the build. “Getting to Green” has been a major endeavor, requiring extensive coordination and special tools (e.g. AntHillPro). To date, we’ve been able to create a build process that effectively manages our myriad dependencies and supports a total build of the application in a reasonable time. We were less successful in establishing the individual sense of responsibility for getting the total build to green.

Profile of an Exemplar Agile “Tribe Member”

We do not mean to say that we didn’t find resources who were effective in a large-scale Agile project. Quite the contrary: we were able to locate and recruit a number of people who met the criteria, and if we had a 100 of these people, we would be able to bring global peace, conquer world hunger, etc. What are these people like? Your basic Agilist, plus the ability to think like a Global Citizen or “Tribe Member.”

When you are in a small team, it’s much easier to be Agile. You are all focused on a common set of problems and it’s about making your team as efficient as possible. When you are part of a larger community, you also need to look at other people’s problems and sometimes sacrifice your efficiency for the sake of the program. At times, this may seem counter to Agile principles. To be successful, you must:

• Be comfortable thinking and operating outside your team (break down the team walls). You cannot let the “them versus us” mentality exist between teams. You have to want to move around, work with different people, change your focus and take on different responsibilities throughout the life of the project.

• Think like a Business Owner, not just a Product Owner. On a single team, the business and the team are easily aligned, but with multiple teams and product groups, you need to think about what would be the best overall result would be, even if that means individual product teams are sacrificed. You have to think about the end result, not just finishing what is on your plate.

• Be ready to raise issues you identify and fight aggressively for the program’s attention to them. In a small team, it’s much easier to communicate your concerns (e.g. in a stand-up), but in a large setting you will need to communicate to a broader audience and fight for priority against a host of competing issues. You have to be comfortable communicating uncomfortable truths, ready to debate issues in unfriendly forums, and persistent enough to drive issues to conclusion.

• Accept change. Sure, “embracing change” is the xP motto, but on a small project you have greater understanding of the drivers for that change. In a large project, many more factors might force change upon you that you might not want to adopt (e.g. employing specific testing methods to support another group’s requirements).

Finding Your “Tribespeople”

So the challenge is locating these people. It can be easy to find people who are interested in working on a big Agile project. It’s much more difficult finding people who you want on your big Agile project. Rule #1: Don’t base your decision on Agile experience! Agile is a mindset, not a skill set. Some people do this stuff intuitively, others spend years in an Agile environment and still don’t get it.