The Agile Manifesto has defined the core spirit of agile methods since it was published in 2001. More recently, IBM has advanced a set of practices under the name "Disciplined Agile Delivery" (DAD) to help larger software development teams enjoy the same success that smaller teams have had with agile techniques over the past decade. Not that the existing, common agile methods are undisciplined; in fact, most agile methods require more discipline and rigor than traditional or ad hoc methods. However, there is not always guidance for dealing with the realities of large agile projects in complex enterprise environments.
DAD offers a hybrid framework that combines the best guidance from a variety of existing and proven agile methods such as Scrum, XP, Crystal, FDD and DSDM. Although each of those methods is valuable, each is incomplete in various ways because practitioners typically patch together techniques from different methods to obtain something that's relatively cohesive. Scott Ambler, IBM Chief Methodologist for Agile/Lean IT, has worked to bring together the best guidance from multiple methods, which resulted in the DAD framework. I have been very fortunate to have been able to work with Scott and to be able to use these practices for my own projects.
DAD also supplements common agile methods with enterprise guidance. For example, DAD shows teams how to take mainstream concepts, such as a backlog, to the next level and make them more suitable for larger scale enterprise environments. It helps you work with enterprise authorities beyond your immediate development team, such as enterprise architects or database administrators. Some developers mistakenly believe that, after you adopt agile methods, you no longer need to deal with those personalities and disciplines. This is not the case. Most agile teams have to look outside their team, especially when working with other projects and other authorities within the organization.
Based on my personal experience as a developer and team lead in a wide variety of agile projects, I offer the following advice to help you think through the issues of large-team management regarding projects guided by agile development principles. These are just a few of the considerations to take when you are organizing teams for an agile project with 20 or more developers, but they can get you on the right track.
Tip 1: Embrace the generalizing specialist
There's been a tendency with traditional methods to assume that a team of extremely specialized individuals leads to a better product for the customer down the road. In fact, we've found that it's actually the opposite. In many cases, the more specialized the people are on a project, the more they to try to produce perfect documents, perfect code, perfect models. In addition, inefficiencies can arise for a team that relies on specialists that have no skills outside their specialty. For example, if there is only one person on the team that understands databases, not only can the team's work be delayed but also the whole process of getting a working solution into the hands of the stakeholder.
DAD promotes the formation of teams with "generalizing specialists"; that is, people with a specialty, but also with general knowledge of multiple disciplines in the software development lifecycle. For example, an analyst might be a specialist in requirements but also have general knowledge about testing, and if a team is falling behind on testing, that analyst can roll up his or her sleeves and help.
With the project I'm working on right now, the developers are spending time outside their traditional specialty of writing code to help with building deployment and continuous integration scripting. As a result, they are all acquiring general knowledge about infrastructure and configuration management. Another example: testers are traditionally focused on the user interface and on how the software works from a black-box perspective. But increasingly, testers in the agile world need to become more technical and think in terms of what the developer does. They are more useful to the team if they are able to write their tests as code, rather than just testing functionality from the user interface.
Tip 2: Focus on collaborative skill more than brainpower
At times, teams of brilliant people fail to generate expected results. A collection of smart individuals does not necessarily make a good team. Success will only occur when those people work together towards a common goal. I've seen very smart people who don't want to work together; they prefer to work independently. There might be a role for such an individual in your organization, but probably not in the agile development and delivery team.
In addition, there is a reality that we can't staff every project team with superstars. We need to learn how to become productive and effective with people of average, predictable capabilities, not just super programmers. So, what I look for when I'm staffing a team are people who work well together while bringing competence and confidence to the table. They check their egos at the door because they realize that, realistically, they can't know it all and that they have something to learn from one another.
Tip 3: Create the right-sized team for the project at hand
DAD describes three different team levels: the classic small team, the medium-sized team and the large team. Of course, DAD is primarily geared for medium to large teams. For larger teams that potentially have a number of sub-projects going simultaneously with shared components, it's important to consider how groups of people and their various team leads all work together. The point is that classic agile theory suggests small, self-sufficient teams, assuming they should be able to deliver the complete solution themselves. But as we scale upward, we need to reach beyond the team to bring in other people externally with specialized skills.
For example, in my current project, we have a dozen different technologies that are being pooled together to deliver a very large system. We definitely apply the principle of "generalizing specialists," but it's simply not realistic for everybody on the team to be able to know everything about all those 12 different technologies. So we supplement our team with some infrastructure people, such as Linux experts, a couple of database gurus and security and firewall specialists.
On larger projects like this, as you move into the production environment, you will have to work with, for example, your DevOps teams or your enterprise modernization teams. In other words, your system doesn't exist in isolation. The project that I'm currently working on is going to integrate with an existing system. Everything to be moved into production is very tightly controlled by a strict change-control process, so we regularly interact with those people external to the team to get these things right.
DAD also includes guidance for doing some initial planning as part of starting up a project, which can be very helpful as different teams work together. For non-trivial projects, you need an initial vision of what business problem needs to be solved and what the solution should be. This vision could include a high-level overview of the business case, the proposed technical architecture, a summary of the risks and various other summary information needed to obtain stakeholder consensus that the project actually makes sense.
Tip 4: Understand agile leadership principles and team organization and be flexible for the project at hand
Small-team agile methods such as Scrum address the fact that, in software development, the command and control style of leadership, in which managers create detailed work breakdown structures, assign tasks to the team and tell them how long each of these tasks should take, is problematic. Agile method practitioners recognize that people who are actually doing the work are the best people to make such decisions. Developers identify their tasks, they do their estimates, they volunteer for tasks and they share the load among themselves. Essentially they work as a well-functioning, self-organizing team without a role explicitly defined as a project manager. Instead, the team designates someone as the team lead to help to facilitate the whole process.
DAD uses the concept of a product owner, which is taken directly from Scrum; DAD doesn't change this role really at all. The product owner is responsible for determining the scope of the effort, the priorities and clarifying requirements for the work that needs to be done. As product owner, they own the product vision for the solution. However, those of us who practice DAD recognize that for larger, more complex projects, it can be necessary to add domain experts to the team to assist the product owner.
DAD has another role similar to the product owner, called an architecture owner. It's nice to have a team with talented developers, but it's also important to have someone "own" the architectural vision for delivering the solution and be accountable for the key technical decisions. The architecture owner may also collaborate outside the team with key authorities, such as the enterprise DBA or the enterprise architect, to ensure that the decisions the development team is making do not contradict with the standards and guidelines of the enterprise as a whole. He or she is the project's technical expert, working with these stakeholders regularly.
As a team lead myself, I rely greatly on the architecture owner. In my current situation, I'm in one room with 25 people. This is a larger team than you'd have in a classic agile project, but this is a good example of scaling a project as a DAD project. On my direct left is the architecture owner, so that I can always ask questions, such as:
- Do we have the right people working on the right tasks?
- Have we mitigated our technical risks?
- Which team members need help? Should we pair them up with somebody so that they can get help with their tasks?
- Are there existing technical assets or patterns in the enterprise that we could use?
As team lead, especially on a larger team like this, it's difficult for me to be intimately aware of how each of the developers is doing. So I rely on my architecture owner as my partner in helping the team to be effective.
The architecture owner is important in another way. Architecture is a huge potential source of project risk, given the dependencies beyond the project boundaries, such as production environment, business needs, legacy data, older systems and more. The architecture owner determines what work items to implement in the early iterations to mitigate those risks as early as possible. This DAD practice is called the "risk value lifecycle," which distinguishes it from other agile methods that only prioritize work according to business value. The architecture owner helps the team understand the critical technical risks and what requirements must be captured and met to mitigate those risks, which could become extremely difficult and costly to fix late in the project.
Tip 5: Be wary of self organizing teams, especially if your team lacks experience
Self-organizing teams are a wonderful agile concept. Team members know best how to customize their processes to be most effective. They can collaborate because they have learned how to work together. For example, Hal knows whether he can send Julie an email or whether he needs to have a face-to-face discussion to be more productive. Ideally, teams have the essential skills to fulfill their mission to build software that they need to build. In practice, self-organizing teams work well for those who are technically strong, have a good understanding of best practices in software development and have some knowledge of agile methods.
With newer teams or younger teams, those ingredients might not be there. They might not understand how to model solutions for architecture or for requirements. Or, more fundamentally, they might be new to agile methods and not understand the different practices.
Therefore, there is a skills and experience component that you need to consider when you let teams self organize. A lack of skills and experience can lead to chaos and an undisciplined team environment. There's also a personality component. Some team members aren't comfortable deciding what tasks they should be performing or in what order. Some might actually prefer to be directed in a more traditional manner. If you're a team lead, you must be sensitive to these attitudes and habits and understand when somebody needs to be nudged or directed regarding their daily activities.
The essential message here is that self-organizing teams can work, but the degree to which a team lead lets their team manage themselves depends on the maturity and capabilities of the team. A good team lead doesn't simply trust the team with carte blanche authority to do anything they want. Rather, a good team lead should be aware of what the team is doing and watch pretty closely to make sure that they stay on track.
Mainstream agile theory provides a solid foundation for delivering software with high business value to customers, but it can tend to be a bit idealistic. It doesn't always represent the kinds of experiences that Scott Ambler and I both see every day on larger projects. Our goal is not to overturn the apple cart and reinvent agile methods because, implemented properly, they work. But there are certain gaps we're trying to fill in.
With DAD, we are certainly not trying to be prescriptive. For example, although we prefer to represent requirements in our work item list with user stories, if you want to instead apply use case scenarios, that's up to you. DAD is a framework. You should choose the techniques from it that best suit the needs of your agile projects.
DAD can help large software development teams succeed in their agile development projects. The combination of the best guidance from a variety of existing and proven agile methods into a framework, DAD supplements common agile methods with enterprise guidance. As a result, it can help organizations with project teams of more than 20 people get the most out of agile development methodologies. When assembling teams for DAD, keep these tips in mind: embrace generalizing specialists, focus on collaboration skills, create teams that are the right size for your project, understand agile team principles and team organization but be flexible and be careful with self-organizing teams.