Agile and quality guru Bob Galen is a regular speaker at many industry conferences. At STAREAST 2011 he was one...
of the keynote speakers and led a half-day tutorial called, “A Test Leader’s Guide to Agile.” At Agile Development Practices West 2011, he will be conducting two half-day tutorials: “Essential Patterns of Mature Agile Teams,” and “Releasing Large-scale Agile Projects.” Galen is also the author of the book, “Scrum Product Ownership – Balancing Value from the Inside Out.” We discussed the topic of growing interest to enterprise development: large-scale Agile.
SSQ: Bob, you speak about a variety of Agile topics. Can you start by telling us your background and how you got involved in Agile development?
Bob Galen: I’ve been practicing agile methods since late 1999, 2000. I’ve had a consulting and training practice since then, but I’ve also had a variety of permanent, Agile-focused positions at a wide variety of companies. You can say that I try to keep grounded in the “real world” as a practitioner. Nowadays, most of my experience leans towards Scrum.
SSQ: What is your experience with large-scale Agile? How big were the projects and teams?
Galen: I’ve introduced Agile methods in large-scale companies such as Lucent and Teradata. I’ve also coached quite a bit at-scale in a variety of companies.
I think a key is to not get confused that large-scale Agile only implies teams of hundreds to thousands of people. I think at-scale challenges can occur across a small set of distributed teams, or when you have teams spread across a campus and not in close proximity.
Challenges can also occur when you have 3-4-5 plus Scrum teams all focusing on a single product development effort, and they’re struggling with cross-team collaboration, shared architecture, integration, and with dependency management. The key point is that “scaling” challenges are context based and you can encounter them in relatively small efforts.
SSQ: What do you think are the biggest challenges associated with large-scale Agile?
Galen: It really depends quite a bit on your context. Usually at scale you’re dealing with more distributed teams. So that’s the beginning of the challenge. Agile at its core is a small team, collaborative/close proximity sort of play. You’re counting on people working closely together, and that customers are readily available and close to the team. Members can pair often and have lots of face-to-face collaboration. Often in at-scale instances, this is simply not possible.
Tooling that supports Agile collaboration becomes quite important at scale. But it also introduces many risks associated with the teams considering the tools more important than basic collaboration patterns.
Another challenge is that at-scale Agile usually implies that it is replacing an existing set of processes at a large organizational level. For example, there might be a Project Management Office, a Testing Center of Excellence, various process groups in a CMMi instance, and so on, that will have a strong say in how Agile is “rolled out” and implemented. These need to be carefully replaced or morphed into their Agile equivalents.
SSQ: Do you recommend an organization experience success with small-scale Agile before tackling large-scale Agile?
Galen: Yes, I do. I have seen some organizations achieve success with a “whole hog” approach to Agile adoption. (Remember, I’m from North Carolina.) Now I’m not necessarily talking about running pilots here. Instead, I believe Agile experience needs to be gained in small-scale Agile teams -- real experience. Then this can be leveraged as the organization scales its adoption. There is no substitute for real Agile experience gained in your own organization. These folks can then seed your larger adoption, which is a much healthier approach.
SSQ: Many people use Agile and Scrum interchangeably. Do you believe Scrum is the right Agile methodology to be used for large-scale Agile development? Are there rituals or artifacts of Scrum that you think should be modified to have more success on large projects?
Galen: I consider Scrum a simple Agile wrapper for projects and, as such, the simplicity can be an advantage when you’re rolling it out to a large organization. It’s simple to teach, simple to implement, and simple to grok or understand. I also think the traditional Scrum ceremonies and practices work quite well for small teams.
As you scale though, I think Scrum needs assistance. For example, Alan Shalloway has been a leading proponent of augmenting Scrum practices with lean thinking and principles in at-scale organizational adoption. I think many would agree with Alan with respect to lean being a more organizationally focused play for Agile -- so complementary to Scrum.
It also approaches adoption with a more holistic approach, whereas as the simplicity of Scrum sometimes gets lost in larger adoption efforts.
SSQ: What do you think of hybrid methodologies?
Galen: I’m a little biased here because the majority of my personal experience has been using Scrum plus Extreme Programming practices -- so a hybrid approach. I’ve gotten great results from that combination and I include quite a bit of lean in the mix too.
I consider myself to be a pragmatist and practitioner and not an Agile purist, so I try to leverage bits of the various methods that work the best for me. For example, I like to use Crystal’s Blitz Planning for end-to-end release planning. That being said, I think you need more experience to do this well. So I often recommend that colleagues and clients stay with a pure base method until they have sufficient experience, before experimenting with hybrids.
SSQ: Can you tell us some examples of “large-scale extensions” that you recommend for Agile releases?
Galen: I’ll just share a quick list:
- Try to charter your agile projects in order to create a solid vision and mission for your project that your teams can respond to.
- Define a release tempo that includes requisite testing activity (hardening/stabilization) sprints as required.
- Be aware that cross-team dependencies are one of the largest challenges in Agile at-scale. Work hard to identify, coordinate and mitigate your dependencies.
- Do extensive release planning (Release or Blitz Planning and StoryMapping) to understand your integration points, dependencies, testing requirements and deployment requirements.
- Architect and integrate a thoughtful continuous integration strategy across your teams.
- Try to allocate features and major system components to teams (Feature Teams) to minimize dependencies and increase ownership.
SSQ: Can you tell us more about “blitz and iteration planning models” that will extend Agile testing across the enterprise?
Galen: The real key, and many teams miss this, is that there’s more to Agile planning than simply pulling together a backlog and sprinting for a finish line. You’ll want to gather your team and examine end-to-end responsibilities (user stories, tasks, dependencies, deployment actions, testing, etc.) that can often be missed when you’re taking a sprint-at-a-time view to your work.
Look-ahead is important. Setting milestones is important. Managing technical risk and technical and/or testing debt is important. Sometimes the only way to really make balanced investments is to consider the longer view.
Cockburn’s Crystal Blitz Planning and Patton’s StoryMapping are two techniques that you ought to investigate in at-scale Agile planning.
SSQ: What do you think are the must-have application lifecycle management (ALM) tools when developing large-scale Agile?
Galen: I’m going to “Plead the 5th” here. I’m not a strong proponent of tooling in general, although it does have application in at-scale instances. I’ll leave tooling as research for the reader.
SSQ: What would be your biggest pieces of advice to organizations preparing to run their first large-scale Agile development project?
Galen: First, go out and find yourself a qualified coach -- one that has experience in your application and business domain and matches your culture. I’d also look for pragmatists over purists. Those that allow for methods adjustments based on your contexts and not those that trivialize your real-world challenges.
Your leadership team needs to understand agility at a fundamental level. Sure, you can adopt Agile at a grass-roots technical level, but your leadership team will be an impediment until they truly understand the dynamics and requisite organization-wide changes implied by adopting Agile.
Finally, build up some team and organizational experience before scaling your adoption. There’s no substitute for home grown experience that can be seeded within your teams.