Transforming to an agile software delivery model is filled with lots of challenges, especially when you are talking about solutions delivered in an organization of a large scale. In these large organizations, one of the most common practices to achieve perceived efficiency is to build an organization of specialists. Every specialist knows how to get their specific tasks done very efficiently. Additionally, large companies typically have very large and complex software architectures for their systems. Between the specialists and the complex architectures, the job of getting the entire solution delivered is actually very inefficient since it “takes a village” (often a very big village) to get anything delivered. The most intrusive inefficiency with these organizational models is that they are not designed with support for natural delivery flow.
So, when faced with transforming from these challenges to a scaled agile model, there are some guiding principles that can help determine the best organizational design to make your move to agility most effective – i.e., getting the most business value delivered.
Those agile organizational design principles (in priority order) are:
- Organize around flow – Flow starts where the business intent is generated. So, you need to first figure out where the empowered decision makers in your business are living. Generally, if you are in a large company, there will be many “Business Intent Generators” (or BIG’s) to identify. True flow in your solution delivery will most readily break out if you connect the BIG’s directly with the team members with the skills and knowledge needed to build the solutions that meet the business intent. By connecting the BIG’s with the right team members, you maximize collaboration with the business and reduce information needing to take hops across teams in the company.
- 7 +/- 2 teams – There are numerous writings about the benefits of moving to delivery teams that are small, between 5 and 9 people. Beyond the most well-known benefit of reducing communication complexities associated with large team sizes, small teams foster the culture of commitment to achieving short-term goals which is harder to break out in large teams.
- Start journey towards flexible teams – When you start with an organization of specialists, you need to organize your teams so that you start making progress in creating an organization of generalizing specialists. By building up these more flexible team members, you improve the probability that someone on the team has the knowledge and skills to get any particular business intent turned into a solution, and therefore, the team does not need to reach outside itself to deliver. As the team members are more flexible, the pressures on having larger-sized teams diminish as well. There are two key paths to begin the journey towards flexible teams. First, you need to put people with differing knowledge and skills on the same team and then provide them the time (and potentially reduced expectations for actual delivery) so that they can concentrate time on knowledge sharing and capture. Second, you need to work on simplifying and consolidating your software architectures to reduce the learning curve for team members to pick up new skills and knowledge.
- Build continuous improvement teams – The move to agile requires support for rapid development and refactoring. This support includes continuous integration (CI) systems, agile configuration management (CM), rock solid environment provisioning and support, test automation tooling and governance, and agile release management. Many of these support roles are best filled with folks that understand these practices. However, for example, you could find some smart developers who are fed up with the lack of CM, CI, and environments. These developers would very passionately get a first round of these practices and tools in place to get you started. The main point here is that you do not forget to get these support roles funded right away and create continuous improvement teams to “catch” backlog to build these support tools and systems for the efficiency and effectiveness of the whole solution delivery organization.
So, you have the guiding principles for organizing to build teams for agility. Now the reality hits – you are starting from a large solution delivery organization of specialists and you cannot adhere to all of these principles immediately. In some future articles, I will outline some team design patterns for large companies that deal with the tradeoffs across the guiding principles and may provide some thoughts on how to organize your teams as you move down the trail of your organizational transformation to agile.