Agility vs. Scale

We should not look at agility and scale as competitors but as two sides of the same coin. If there are two people on a team and one person is “agile” while the other person is always speaking and working toward “scale,” that is a killer combination. Have them work together to build the best product in the shortest possible time.

Agile teams are now becoming mainstream across different industries, and not keeping scale in mind while being agile will ensure that the project is going to fail in no time. Initially, the goal of agile when it was introduced in development was to be extremely flexible and aid in fast decision-making. It focused on colocated teams.

When we look at the earliest processes like Division of Labor by Frederick Taylor and so on, we find they were focusing on the scale of operations rather than agility. Now it is time to merge the two approaches and come up with a hybrid model. People at scale can drive the same amount of operations that when replaced with machines is called agile. Not all things can start agile; the framework starts with people. Operations teams first have a lot of people to scale the business; once the processes set in, then tech comes in.

We always thought that when we were building the business process tech team that the company would’ve done the same amount of business at the same scale even if we did not have the tech team. All the efficiency relied purely on people and people processes rather than on data and systems.

When we apply agile and lean strategies at a team level, then we are being strategically forward thinking as this is what will drive teams that are already at scale to function in an agile manner. Usually, when we think of scale, we often think it is a huge number of people and a large number of teams. But if we are being tactical enough, then with a lean team we can achieve scale.

When we look at different ways of working (WoW), applying strategies that takes into consideration the current context and situation helps in arriving at the right solution. Application of strategies that is written in text books would not be prudent. It will help us achieve what is needed for the current project at the current time. This awareness of context while applying strategies will help in creating tailor-made strategies. It will fit the purpose of the situation and the project. If we do select a certain way of working at the beginning of the project, it doesn’t mean we will continue to stick to that. But it acts like a guiding light, and the rolling plans eventually will help us in adapting to the needs of the situation later. Usually, if the situation becomes complex later, then the strategy to change the way of working for that situation will be required.

The choices that we make at the start of the project will change over time as we learn, but the main point to note is that we will make some broad choices at first to get going.

Let’s review these factors now.

Team Culture

Having agile teams requires people to collaborate effectively to achieve things. If traditional-culture people are put on an agile team, that will lead to two people speaking different languages. There would be no coherence or togetherness. The culture for a specific team will also vary depending on what the organization’s culture is. If the organization culture is traditional but specific teams within the organization are agile, that also spells trouble as there will be collaboration required between teams, and when each team cannot understand the other team’s WoW, it becomes difficult to deal with unknowns. People’s flexibility also plays a role in agile teams. Agile teams require people to be flexible and accommodating in their approach. Being rigid only increases the time frame to deliver and acts as a barrier between teams. In Figure 15-1, it shows how people’s mental state can be affected by the increased scale of a product. If the product requires agility, the team will be flexible, and as the agility decreases, the team’s culture becomes rigid.

Vertical bars denote the following team cultures in increasing order. Flexible, Organized, Pseudo rigid, and rigid.

Technical Skills of the Team

The people on a team must have the skills (or gain them) that befit the role they play on that team. For example, developers on an agile software team may need to have test-driven-development (TDD) skills, people-oriented collaboration/communication skills, continuous integration (CI) skills, model storming skills, team-based planning skills, and so on. Developers on serial/traditional teams may be more focused on programming skills for a specific technology platform. Figure 15-2 depicts how the careers of software engineers within the teams can progress as they see the product moving from a prototype to a scalable one.

Vertical bars denote the following technical skills of the team in increasing order. From left to right, fresh graduates, associate software engineers, technical leads, and architects.

Nature of the Problem

Although some people want to believe that certain types of problems can be solved in only one manner, that doesn’t seem to be the case in practice. For example, it’s possible to take an agile or a traditional approach to data warehousing projects, to marketing projects, and to procuring services from an external partner. Our experience is that the real issue is how decomposable the potential solution is. For example, it’s possible to decompose a data warehouse into many small releases if you choose. The same thing can be said of the development and execution of a marketing campaign. But, it isn’t easy to decompose an airplane into several working parts. Either the airplane is complete or it isn’t. Yes, it’s still possible to apply agile techniques to the building of the airplane, and very likely to its design as well, but the airplane team will never be as agile as a software development team due to the physical and regulatory constraints that they face.

Figure 15-3 depicts how a problem is solved through a product by first prototyping it and then doing a complete launch over time.

Vertical bars denote the following project types in increasing order. From left to right, proof of concept, minimum viable product, soft launch, and hard launch.

Business Constraints

The way that the business constrains the endeavor, such as insisting on a certain (always aggressive) delivery date, an approach to managing the budget (often a fixed price/bid), and how available businesspeople will be throughout the project certainly all have an effect on the process you adopt and the type of people you include on the team. It may even influence what tools you use, particularly those for communication and collaboration.

Figure 15-4 shows how teams start with limited resources and then finally move toward all the wings of the company cooperating with each other to launch flagship projects.

Vertical bars denote the following business constraints in increasing order. From left to right, use limited resources, from existing teams, consultants only, and full team involvement.

Alerts and Flags

While scaling operations, there is always a chance of things going downhill, mainly due to the unknowns that were not taken care of when the teams were super-agile. This means that the ops currently running could be at the risk of scaling down suddenly. To subvert these, we need flags and alerts put into place from a technology-driven perspective that helps teams to pre-empt any adversities.

Tech-Driven Operations at Scale

A clear playbook is emerging for how to integrate and capitalize on advanced technologies—across an entire company and in any industry.

The need for a large number of technology solutions and the last-mile challenge may be familiar hurdles to readers who lived through the lean revolution some 25 years ago. Capturing value from lean initiatives involved driving each process change all the way through the operating model of the business. No single lean project could generate a major performance improvement, but a rich portfolio of lean projects could.

To make the transformation manageable, companies implemented lean projects in waves, tackling processes or units of roughly 200 people at a time. They first developed a vision for how each process or unit would be transformed. Then they built benches of lean experts (often called black belts) to manage change and ensure the new operating practices were adopted. Even though lean methods were never proprietary, companies such as Toyota used them to ceaselessly pursue small performance improvements and thereby build and protect an advantage over their competitors.

An essential component of achieving scale in a technology-enabled transformation is having sufficient in-house technology expertise and talent. One proven model for building a technology bench is the “technology factory.” Such a factory is wholly at the service of the business and governed by the business. It provides the sort of work setting that is necessary to attract technology talent and achieve high-velocity development.

Summary

The question that arises is when to augment operations with technology. Some companies realize it late, and the cost of maintaining operations through people will have shot up to an extent where any more scale would just become untenable. Other companies go with a technology-first approach. Neither of them is a sure-shot success. The timing has to be according to the situations and market conditions. While technology can surely enable the operations, not having a suitable product and investing in technology can lead to downfall.