An operational, successful team is more than a set of interchangeable, anonymized skill sets, a fact the software industry is starting to realize. A cohesive team is far more than a room full of engineers. It’s a step toward maturation of the industry that is long overdue.
In some industries involvement of the “whole team” is almost assumed. Would you buy a car that had never been tested in a safety lab? How about try out a new instrument configuration on an airplane, knowing it had been redesigned by engineers and not pilots? Does it seem reasonable to build a house without hiring an architect? Each of these examples will more often lead to failure than success.
Yet the software industry, particularly the commercial industry (as compared to Military, for example) has been ploughing along without whole teams for decades—a trend that seems to be getting more and more negative attention. Recently evolving standards such as Extreme Programming, Agile methods, Scrum and the Rational Unified Process have all incorporated whole team concepts into their methodologies.
The Whole Team Approach
The term “Whole Team” defined: What is it and why is it so important?
The concept behind the “whole team” is that building a product without representation from every stakeholder is fundamentally flawed. It takes constant, comprehensive involvement through every aspect of the product life cycle in order to guarantee timely delivery of a well-designed product. For example, without a quality assurance organization’s involvement, it is almost certain that customers will discover incomplete requirements after delivery. If the user perspective is not considered early on, it’s very likely the product won’t be accepted or even usable until a second generation is built. Failing to involve software testing and configuration management means failure to deliver working code. And not involving program management, marketing and even financial oversight can lead to a host of problems in execution. All of these situations arise from lack of whole team involvement and can easily lead to a product stumbling out the gate or outright failing.
Creating a cohesive whole team means building a project team with representation from all stakeholders in the project. Doing so requires both defining the team and creating involvement. It also means creating a structure for involvement that does not slow the project down. Creating this environment of constant, informed involvement does not mean throwing everyone into long (and ultimately unproductive) meetings every day.
In some ways defining the team is the easy part: It’s answering the question “who cares about the outcome of this project?” Project analysts, business stakeholders (such as the project sponsor and someone that represents the financial investment), designers, usability analysts, quality assurance, development, software testing, configuration management are a few. Quite often some of these groups can be represented by a single person, as is often the case when it comes to marketing, finance and business interest.
Once the stakeholders are known creating an effective, productive environment can be quite a challenge. This is particularly true with large efforts—perhaps 50 people or more. The goal is to achieve higher bandwidth of communication between team members. In fact, achieving this goal has been documented (see Agile Software Development With Scrum, Schwaber, Beedle) to increase efficiency by an order of magnitude: Over 100% not just 10 or 20%. To achieve this, you must:
- Organize your projects around cross-functional teams—the core of the “whole team” concept. The team must represent the business and must contain analysts, developers, quality assurance and testers (as well as the related disciplines).
- Provide the team with the tools needed to create an effective collaboration across all functions.
- Foster an environment that creates an attitude of “I’ll do what it takes to exceed the goals of the project, on time, and with attention to quality,” not “I’ll do my small part in the overall life cycle.”
Small teams are almost self-organizing, but larger groups require more forethought. The project team must consist of analysts, developers, testers, quality assurance, a project manager, architects and so on. Once the project scope grows beyond what can be feasibly (and efficiently) organized into a single team we can organize into “teams of teams.” This means having an architecture team in charge of system architecture and deciding on the subsystems and how they interrelate. Then, a cross-functional team (including analysts, developers, testers, etc.) are in charge of each subsystem. The entire project is tied together with the management team, with representation from each of the subsystem teams, and through communication channels that must be free and open between all teams. (Several examples and case studies are cited in Agile Software Development With Scrum, among other sources).
An essential element of this process is open communication and information access. In order for each team to work closely within itself, and for it to work closely with other teams, they need access to information. Creating an environment that ensures access to requirements, design details, customer requests, business goals, defects, test plans and status, and so on is critical. Furthermore, communication must be unified. This means establishing an infrastructure for communication and setting it as the sole authoritative source for information. Invest in a document management system and an issue tracking system and develop the attitude that “if it isn’t in the system, it doesn’t exist.” Make sure there is a sole-source for information, and that email in particular does not become a “transient information store.”
Traditionally, at least in some cultures, functional organizations have evolved: All the analysts are in one group, all the designers are in another, all the quality assurance and testing in yet another. This silos information and creates a barrier to ownership that is almost impossible to overcome. Even more so in organizations that use matrix models—where, for example, an analyst works on several different projects at the same time. This leads to treating people like interchangeable components. It also generates a huge waste of effort and efficiency in context switching between projects.
In contrast, the whole team approach creates a vested interest and ownership in the project goals. Each team member develops a long-term investment in their contribution to the project. The ability to concentrate on a single goal creates focus. This is not only more efficient, but working as a team reinforces the sense of ownership between team members. Accountability is high, as is pride in work product. The team orientation avoids finger pointing and assertions such as “that wasn’t my job,” and “it works for me.” Everyone must share project responsibility and, as part of the small team dynamic, will work together to solve issues as they arise.
I think this paragraph, from The Rational Unified Process Made Easy (Booch, Jacobson, Rumbaugh), summarizes the goals quite well: “An iterative approach increases the need for working closely as a team. Avoid functional organizations, and instead use cross-functional teams of generalists, analysts, developers, and testers. Ensure that the tool infrastructure provides each team member with the right information and promotes synchornization and round-trip engineering of artifacts across disciplines. Finally, make sure that team members take joint ownership of the project results.”
Or, perhaps a bit more passionately (the “gang of three” books do tend a bit on the dry side), as Mike Beedle and Ken Schwaber wrote: “When we say Scrum provides higher productivity, we often mean several orders of magnitude higher i.e. several 100 percents higher. When we say higher adaptability we mean coping with radical change… we show through case studies that Scrum reduces risk and uncertainty by making everything visible early and often to all the people involved and by allowing adjustments to be made as early as possible.”
However, it is important to distinguish that Scrum in and of itself is not a complete process. As pointed out in Mike and Ken’s excellent book, Scrum wraps other processes and, in fact, we find that most processes tend toward artifacts that share a great deal in common with Scrum.
Processes such as Rational, spiral and traditional waterfall methods have a lot to offer when combined with agile methods, including Scrum.
Many of the traditional methods of monolithic software development also have a great deal to offer. Formal Software Configuration Management, Quality Assurance and Structured Software Testing are three such examples. Many agile methods focus so closely on rapid progress and lightweight process (or lack of process) that they verge dangerously close to unstructured chaos in and of themselves.
Finding the right balance between agile methods and heavy process is an ongoing decision—one that takes place on a per-project basis and sometimes changes over the life cycle of a project. The best we can hope to do is develop a solid foundation in good implementation principles, keep the best, and put the rest on the shelf for future reference. I’m sure whatever we’re doing in a couple of decades, it’s not going to look much like today’s practices. But I do know this: A whole team approach is one best practice that’s here to stay.