As agile is becoming mainstream, the issue of scaling development becomes more prominent. When ‘agile’ first appeared in the development community, its goal was aimed precisely at being more flexible in decision making, being flexible with requirements, and designs, code, test and so on, focusing primarily on small co-located teams and how they work. However, when you consider older processes such as CMMI, Unified Process, Lean Manufacturing (Taylor’s production floor), division of labor, etc. they were really trying to solve the problem of scale, when the number of people were many, their competencies were varied, their backgrounds were diverse. The question is whether ‘agile’ can learn from these older approaches. There must be something positive in the older approaches, they are not all bad. After all, many organizations do have a mix of agile and traditional methods. In fact a 2010 Forrester Research article by Dave West and Tom Grant indicated that it is less normal to hold fast to a single approach, hybrids are more of the norm.

Revisiting the Agile Manifesto

To address my question, the agile manifesto is an obvious place to start. As a refresher, the agile manifesto states that:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

No doubt, we have heard lots about the agile manifesto. To me it is all about “uncovering better ways” to do things. Sometimes, we need more of the left, sometimes, there is room for the right. My specific question is what values (on the left and the right) support agility or scale. For example, if we want to scale from a 10 person agile team to a 100 person agile development, should we put more focus on the right. I am an enterprise lean and agile coach who has worked with very large organizations and development endeavors, so I do have opinions of my own. Nevertheless, as a constant learner, I like to check myself.

A natural thing for me to do is simply to ask what folks are thinking and I post a survey to Singapore agile meetup and to a LinkedIn discussion. In a healthy discussion community like LinkedIn, I would expect many interesting perspectives to the issue, and in fact, I did get a number of comments.

Rémy Fannader commented, “You compare agile to three different things: a process assessment method, a manufacturing process paradigm, and a software engineering method. But agile is none of them, as it’s more a development paradigm than a method per-se, as could be said of Scrum. And as could be expected, agility is by nature more of a local capability. Nonetheless, the agile development paradigm can be combined with broader endeavors.”

Brett Maytom also stressed that “Agile is a way of thinking and not a methodology or framework.”

I certainly do agree to both Rémy and Brett. I would also add that “Waterfall” is not a methodology nor framework as well. Lean manufacturing is also more of a mindset and a thinking than a method or framework. Unified Process also carries with it a mindset of “architecture first”. However, all these are beside the point. My questions are:

  • If a team is lacking agility, what values should they focus?
  • If a team needs to scale, what values should they focus?

Thus, I have conducted survey to poll opinions about these questions.

Values Support Agility and Scale

Figure 1 shows respondents view of the the values that support an agile way of working. They strongly advocate individuals and interactions, working software, customer collaboration, and responding to change. They are not so keen on comprehensive documentation, contract negotiation and following a plan. This is of course no surprise. Respondents definitely skew to values on the left hand side of the manifesto. Note however, that respondents are generally supportive of processes and tools (the first right-hand-side value in the agile manifesto).  This is also not surprising, because the advances in agile methods are all somehow related to processes and tools. Experts have given us processes (prescription, guidance, clear steps, etc.) on how to run a sprint, how to write a user story, how to conduct acceptance test driven development, how to improve flow through a kanban, etc.  Along with this comes the development related tools, whether built in-house or provided by vendors. This is perhaps a recognition of the fact that “The right process will produce the right result” long advocated by the Toyota Way. It is not so much that agilists are against processes than bad processes.

Figure 1 Values that Support Agility

Lets look at the values that support scaling (to large development). What do respondents think? Well, respondents still advocates the values on the left hand side of the manifesto (see Figure 2). However, we see a significant rise in the support for the right-hand-side of the agile manifesto.  As a matter of fact, processes and tools win over customer collaboration, and is on par with responding to change, and very close to individuals and interactions as well as working software.

Figure 2 Values that Support Scaling

Comprehensive document and following a plan becomes more important when attempting to scale. Support for contract negotiation increases but by a lesser margin.

Back to processes and tools. Scaling to large development is by nature a complex problem. Just focusing on the left-hand-side while ignoring the right-hand-side is probably a sure road to disaster and chaos. Individuals have different backgrounds, experiences, competencies, and motivations. It is important to get everyone aligned and pointed towards the same goal and direction, which is why frameworks like SAFe (Scaled Agile Framework), LeSS (Large Scale Scrum), etc. are gaining  popularity. Nevertheless, no one should blindly follow whatever framework that is available, but instead get under the hoods and evolve the way of working practice by practice. Our current work on Software Engineering Method and Theory (SEMAT) is precisely about getting to the essentials of practices.

The respondents to my survey are folks who participate in agile meetups and agile discussions. So, they would generally be inclined to support values on the left. If I were able to get more participation from a larger population, I suspect even greater emphasis on such as processes and tools when scaling development.

It is All about Context, Balance, and Growing

In the end, it is all about achieving balance, applying the right force on the right places. Perhaps it is incorrect to pit values against each other, putting them on different sides. Perhaps it is more accurate to place the values orthogonal to each other, and we is prudent to strengthen both sides rather than being prejudice against either side (see Figure 3).

Figure 3 It is a Balancing Act

Graphs like Figure 3 raise interesting questions, like what are the axes, what are the scales of each axis (low or high, poor or good, delegated or controlled, etc.). Where should a development endeavor be located in these graphs. So, it is no longer left versus right or right versus left. Instead we will be seeking to be in the satisfying or optimal position, and how to move to a better position appropriate to the development context. Invoking such discussion is the beginning of getting better.

As one of the survey respondents reminded us, “Stop reinventing the wheel!” Another respondent has similar views, “There are indeed a few good practices and tools in older methodologies that may help us scale up agile. We need to find what it is.” We can all learn from one another.

Finally, thanks to all those who participated in my survey. If you like to participate in the survey, it is still open; just click on this link. Thanks also to those who commented on the LinkedIn discussion.