Agile is a new paradigm. Before the Agile movement, the prevailing belief was that you needed to do a complete analysis of what you wanted to build and that developing a full, detailed plan before starting to design, code and test was the best way to ensure achieving your goal.

The Agile movement made different assumptions and took a different approach. You might say it started from a different system of beliefs. The Agile Manifesto was a declaration of a new belief system. It basically stated that people, software, collaboration and responsiveness are more important than process, documentation, contracts and following plans.

This manifesto is one set of beliefs and has led to one popular flavor of Agile. There are others that lead to other flavors of Agile. In May, I wrote a tongue-in-cheek blog post called The Lean-Kanban Manifesto where I pointed out some of these differences in belief systems. Here are some of the differences in belief that lead to different approaches:

• favoring explicit conversations vs. intuitive abilities
• favoring small steps vs. big changes
• favoring quality systems vs. heroic individuals
• favoring principles that guide our understanding vs. practices in which we must trust

The biggest divide is over the notion of defining process. I have run across many consultants that believe that attempting to define any process is folly. They reason that defined processes are intended to be followed and that in a non-deterministic system this leads to ineffectiveness. They view software development process as a complex-adaptive-system and therefore little cause and affect can be found.

I believe there are two failures of logic taking place here. The first is a fundamental misinterpretation of the relationship between determinism, predictability and degree of definition of a process. For example, lack of determinism does not mean lack of predictability. There is a distinction between micro and macro-predictability. For example, a roulette table is not predictable at a micro level (you don’t know if the next spin will be black, red or green), but at a macro level it is clear that more money will be staying at the casino than leaves! For more on this, read the interchange I had with Don Reinertsen in the blog post, Types of Processes – by Don Reinertsen.

The other misunderstanding is the belief that a defined process is something to be followed. Actually, having explicit conversations about one’s process is not to make it something to follow but to make it so people understand what each other is doing. This is a mindset shift in and of itself – process is not to be followed but to facilitate understanding.

There are other divides based on belief systems. For example,

• Most in the classic Scrum camp believe in starting with pilot projects. Most in the Lean-Kanban camp believe starting with the big picture in mind, even if a pilot initiates the process, is a better approach.
• When it comes to transitioning to an Agile approach, Scrum thought leaders suggest changing the organization to fit the Scrum framework, which success comes in adopting a proven framework. The Lean-Kanban camp doesn’t necessarily disagree that doing so would work, they suggest that doing so is often extremely difficult and that there are easier ways – both financially and emotionally on the people involved. Lean-Kanban suggests starting where you are and managing your rate of change, you can create just as much, or more, sustainable change with less cost and with less time.

It is more than just picking a set of tools. Beliefs lead to very different alternate behaviors. One must be aware of one’s paradigms so they can both question them, learn better ones, and see when they apply.

One size doesn’t fit all, but perhaps one mindset does

I keep hearing people discussing whether they should do Kanban or do Scrum as if one might be inherently better than the other. While, I do believe comparing and contrasting the mindsets of the two promotes good learning, the question is often asked in comparing the practices of the two. Comparing practices without understanding the differences in mindset is not necessarily going to lead to great results. Two of the common mindsets in the Agile space today are classic Scrum and Lean (Kanban fits within the Lean mindset). It is worth considering the differences between these.

Classic Scrum Mindset. Set teams up in a functional structure (cross functional teams with a product owner and Team Agility Coach) and let them figure out how to be effective. Anything in their way is an impediment to be removed. Keep doing this until the entire organization is effective. Scale by considering the organization to be comprised of teams of teams.

Lean. Take a scientific approach to learning with an aim towards continuous improvement. This requires attending to the workflow, explicit policies, visibility of work (including the vision of what is to be happening). Improvement is based on improving the delivery of the highest business value. This is achieved by removing delays in the workflow which is achieved by smoothing out the work load. Options include using Kanban to manage WIP and managing backlogs to get the right people working on the right thing at the right time – but the focus is on flow. One must also take a systems thinking approach (in particular, avoid the fundamental attribution error. It is critical to attend to the human psychology of change to determine how much change the organization can bear at the start. If this is little, use the Kanban method to manage the transition. If more is possible, do what you can. Decide to use iterations and cross-functional teams if it makes sense. One of the motivations to do so may be that they will force discipline and visibility on what is happening (i.e., this mindset may suggest doing Scrum). Achieve agility at Scale by including the entire value stream (i.e., the workflow from the point of origin of the idea until its consumption), i.e., taking a holistic approach.

The Essential difference. In classic Scrum the idea is to expose impediments by having teams work in a manner that makes them readily apparent. You put people between a rock and a hard place where they have to solve the problem. Unfortunately, many opt out by doing “Scrum but” (i.e., we do Scrum but we don’t do this). This, of course, isn’t doing Scrum. In Lean, you are given a model of what you need to do – deliver value without delays in the workflow. You can start where you are or you can do some initial change at the start if that’s desired. Improvement is made by removing delays in the workflow of achieving value delivered. Scrum follows this model as well, but implicitly, Lean says to follow it explicitly.

One thing to note is that the Lean mindset has you attend to more things. It is not a simple framework. I believe this is why Scrum is often more popular – it is easier to do (although not necessarily easier to be successful with). When you get off track with it, it tends to continue getting more off-track (the infamous Scrum-but). Lean affords a way to look at and solve your problems. It does not demand a certain structure as much as a certain result. Focusing on the result (faster delivery of business value) provides clearer insights into achieving it. It is interesting to note that the Lean mindset will suggest Scrum at times (although always within the Lean model) while classic Scrum will never suggest Kanban (no iterations) or gradual change if don’t already have cross-functional teams.

To be clear. I’ll admit to getting tired a little of being accused of bashing Scrum because I say it won’t work everywhere. At Net Objectives we’ve been doing Scrum for 14+ years. We still introduce it at companies and help organizations having troubles making it work or scale for them. However, we don’t take a ‘one size fits all’ approach with it that we see all too often. We suggest it when it makes sense. We suggest Kanban when it makes sense. We suggest hybrid methods when it makes sense. What I do bash is assuming one approach works everywhere – that tends to result in simplistic thinking.

In conclusion. Software development has many facets – human psychology, dealing with organizational change, different motivations of the business stakeholders, management and the teams, technical issues (architecture, design, code, test), the laws which effect development (e.g., delays increase work) and more. To assume a simple framework will solve a complex problem tends to put a severe burden on all but the most simple of development problems (e.g., one, colocated team). Doing Scrum within a Lean mindset can be quite powerful because enough attention is being played to the more complex organizational issues while Scrum works well at the team. The point is one must look at one’s mindset and see what cases it can handle well. If it is skewed towards are particular solution space you will find patterns of challenge. This is an indication that you might want to expand your mindset. I believe one of the reasons we see patterns of challenge in our industry is that the classic Scrum mindset is insufficient for complex organizational problems yet is being applied indiscriminately. Fortunately, one can do Scrum within the Lean mindset – so if you don’t want to abandon your Scrum efforts but need to improve them, you can do so by adopting a Lean mindset. Don’t worry about what one calls what you do, worry about if you have the proper mindset and if the practices it inspires actually solve your challenges.