A program is a large team composed of two or more sub-teams (also called squads). Some of the sub-teams may be external to your organization, working for partner firms or service providers. The purpose of program management is to coordinate the efforts of the sub-teams to ensure they work together effectively towards the common goal of producing a consumable solution for their stakeholders. In some ways “program coordination” is a more accurate term than “program management,” but “program management” is the commonly accepted term.
There are several potential reasons why large teams exist:
- Some endeavours are inherently big. Sometimes an organization will decide to take on a complex effort, such as building an office tower, an air traffic control system, or a financial transaction processing system.
- Overly-specialized staff promote larger teams. When staff are narrowly focused it requires many people to work, at least part time, on a team so that the team has sufficient skills to get the job done. When people are generalizing specialists your teams become much smaller and more collaborative.
- Overly bureaucratic processes promote larger teams. Sometimes the systemic bureaucracy in an organization requires large numbers of people to address that bureaucracy. We once assessed an eighty-person project team who were doing work that only required between ten and fifteen people to do the “real work” and everyone else to conform to the overhead of their traditional CMMI-compliant process. Sadly, they didn’t rework the team and failed to produce anything after three years and many millions of dollars of investment. As an aside, it is possible and highly desirable to effectively combine CMMI and disciplined agile approaches, but you need to overcome the cultural dissonance of the two paradigms. Similarly, we’ve seen teams misjudge and adopt a scaling framework such as SAFe® when their situation didn’t warrant it – this motivated them to create a much larger team than they actually needed.
- Working on large teams can lead to greater rewards. Similarly, someone is “empire building” and purposefully creates a large team so that they will be rewarded for doing so. We have worked in two organizations where, before their agile transformation, the pay grade of a manager was determined by the number of people the person managed. Worse yet, in one organization the people on the larger teams tended to get better bonuses, and quicker promotions, than people on smaller teams regardless of the actual ability of the team to deliver value to the organization.
In our opinion, the only valid reason for building a large team is because your endeavor is inherently big. The other reasons reflect aspects of organizational cultures that need to be fixed in time. Luckily, there are several strategies that you can employ to reduce the size of a team:
- Reorganize the problem into a collection of smaller problems. Disaggregation of a large problem is performed through a combination of agile envisioning and agile business analysis. This is a key responsibility of your product management efforts: to feed reasonably-sized portions, called minimum business increments (MBIs), of work to your teams.
- Reduce the problem. Sometimes a large problem can be shrunk down through pruning features out of the vision, or at least by deferring them until later.
- Address your organization’s culture. As we discussed earlier, most of the reasons that organizations build large teams are the result of cultural challenges. We suggest that you fix the real problem by adopting a Disciplined Agile® Mindset and evolving your way of working (WoW), thereby motivating an evolution of your culture.
- Organize the large team into a collection of smaller teams. In other words, create a program.
- Adopt a Disciplined Agile approach. Enable your teams, regardless of size, to choose their own way of working (WoW) and thus have a process that addresses the needs of the situation that they face. Some people call this process right-sizing, de-scaling, or process disaggregation – we simply call it pragmatic.
When you find yourself in a situation where you need a large team, and those situations do exist in many organizations, and you can’t find a way to reduce the size of the team, then you will need to adopt strategies to coordinate that team. This process blade will help you to do exactly that.