The Case Against Minimalism

November 5, 2010 — Posted by Al Shalloway

I've been in this industry now for more than 40 years. I like to say that doesn't make me any smarter, it just means I've seen a lot. I've seen over burdensome, bureaucratic process – so I understand why we don't want that anymore. But I've also seen lack of process and chaos that was just about as damaging. An over-reaction to a bad thing is still an over-reaction. I continue to hear people say that agile is about minimalist process and design. I do not agree with this.

The argument should be that we don't want too much, but not wanting too much does not mean we want as little as possible. I suspect that the software industry is the only one that has these ideas. Let's take the medical profession as an example. Let's say you are about to undergo a potentially life-threatening surgery. Do you want your surgeon to have just the barest certifications that enable him to legally perform the surgery or would you want him to be someone who has studied the latest techniques? Arguments for a minimalist attitude here would be scoffed at. I believe they would be discarded most everywhere else. Why do we think software is different? Why do we equate anything more than minimalism with too much?

These are not rhetorical questions. I believe there is a good reason we do this. And I think we need to be aware of it. The two most popular agile methods of the past have been XP and Scrum. Both are based on values and practices. Values, such as respecting people, are universal and apply in all situations. But practices apply in only certain situations. Hence, the more practices you have the more likely you are to find a situation where your set doesn't work. Given this reality, it seems logical that one should come up with the smallest set of practices that you need. Then, go from there – adding additional practices for your own situation as needed. Of course, there is the question of how one does this. "Inspect and adapt" is often the canned response to this

But perhaps our methods should not be based on values and practices. Perhaps they should be based on values and principles, with possibly suggested practices in common situations. This is one of the biggest differences between XP/Scrum and Lean/Kanban. XP and Scrum are based on values and practices. Lean and Kanban are based on values and principles. Yes, they have practices – but only as suggested possibilities depending upon your situation.

It is for this reason that Lean and Kanban are often hard for people to grasp. They are looking for the practices that define them. But, in fact, practices do not define Lean or Kanban. They are defined by a mindset, a way of thinking. This difference may seem subtle, but it is not. It means that when suggested practices don't work, you can abandon them – but not abandon the method. You now must fall back on the principles from which the practices were derived. The question then becomes, not how minimalist can we go, but how many principles can we discover that are always (or almost always) useful? This sets us down a road to build a foundation and to continue building it.

This difference can be readily seen in the methods described. XP and Scrum are not that considerably different today from when they started. Scrum has evolved mostly by defining a product owner role with its associated practices and by finally acknowledging that coding practices are important and therefore suggesting many XP practices be incorporated into it. Lean and, on the other hand, have morphed several times more in half the time they have been in existence. And they're growth is accelerating if anything. Why is this? I would suggest because they are principle based. It means that when one is in a situation where their common practices won't work, they do not leave those trying to use them on their own. The principles on which the practices are based can be used to create new practices in the context the challenged team finds themselves in.

Lean/Kanban practitioners, therefore, are not attempting to be minimalist. Rather, they are attempting to learn as much as they can about what works. They make a distinction between practices and principles. In one sense, they will be minimalist on the practices – because they know no practices works everywhere. So, I suppose they are as minimalist as you can be – they have no prescribed practices. But they are maximalist (a new word?) when it comes to principles. The more we learn the more we'll be able to do.

Alan Shalloway
CEO, Net Objectives

A Correction/Addition:

After writing this blog I realized I was over-stating the case re principles.  There are several principles from the Agile Manifesto that both XP and Scrum do claim (even though both pre-date it).  First, I should clarify what I mean by a principle.  Here are two common definitions:

  1. an accepted or professed rule of action or conduct: a person of good moral principles
  2. a fundamental, primary, or general law or truth from which others are derived: the principles of modern physics.

I mean to use the word along the lines of the second definition.  Principles are rules we must follow in order to work with the universe in the way we want to.  The Agile Manifesto has twelve "principles."  

We follow these principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for he customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a reference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 

I have bolded the 12 Agile principles that represent true laws of nature as opposed to suggested actions. But I agree that the distinction between the two may be considered vague because one can assert principles of action are merely short-cuts to the implied principles of law they are based on. I would suggest then, that in order to assist in the principles of action, it's extremely helpful to explicitly state the principles of law on which they are based.

So, clearly XP and Scrum have principles - I would say both are consistent with those of the Agile Manifesto.  But what other principles are they based on that provides guidance? What differentiates them?  The only one of Scrum I am familiar with I actually don't agree with.  That is that since software development is non-predictable, it must be treated as a black-box process.  This confuses predictability with controllability.   I'll refer the interested reader to another blog of mine: Types of Processes - Don Reinertsen.

So better stated, XP and Scrum do have principles, but haven't been defined by them. This requires us to be very cautious in which practices we can put in them - hence the minimalist approach many espouse.  I have always used Scrum pretending it was based on principles I understood from systems thinking at the start and Lean software once that connection was made.  This is one of the reasons I've included many principles in my use of Scrum from fairly early on.  For a listing of some of these, the interested reader should read Lean (+ some other) Concepts all Agile (including Scrum) teams should know.  

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Comments

Kent Beck adopts a similar approach in his book "Implementation Patterns". In his context the practices are his (implementation) patterns. See this excerpt:

"The principles described here aren't as far-reaching or pervasive as the values, but each one is expressed by many of the patterns. The principles bridge between the values, which are universal but often difficult to apply directly, and the patterns, which are clear to apply but specific. I have found it valuable to make the principles explicit for those situations where no pattern applies, or when two mutually exclusive patterns apply equally. Faced with ambiguity, understanding the principles allows me to "make something up" that is consistent with the rest of my practice and likely to turn out well.

These three elements—values, principles, and patterns—form a balanced expression of a style of development. The patterns describe what to do. The values provide motivation. The principles help translate motive into action.
The values, principles, and patterns here are drawn from my own practice, reflection, and conversation with other programmers. We all draw from the experience of previous generations of programmers. The result is a style of development, not the style of development. Different values and different principles will lead to different [programming] styles.

Sound post! I have used the value-principle-practice idea with clients for many years - especially in discussing business strategies - and find it useful but sometimes hard for folks to grasp the distinctions. What is a Value? How does that differ from a principle, and a practice? Here's a simple example I have used in the past to draw the distinctions, based on the Alexandrian exemplar "Light from two sides of a room" (see e.g.: http://goo.gl/MfUOU).

Value: We want to create pleasant spaces inside our buildings where people can situate themselves in comfort and harmony.

Principle: 1) The quality of light inside spaces (such as a room) has a significant influence on folks' moods. 2) Light from different directions improves the perceived quality of that light.

Practice: Locate each room so that it has outdoor space outside it on at least two sides, and then place windows in these outdoor walls so that natural light falls into every room from more than one direction.

HTH

- Bob a.k.a. @FlowchainSensei

I agree that a team should not use a minimalist set of processes or (worse) no process at all.

I think there is value to these approaches in transitioning people from mind-numbing, everything-is-prescribed-for-you environments into a this new thing where we want them to think for themselves.  The value of a minimalist process in that context is that it forces people to start thinking and making decisions and, as a result, shows them that they can do that.

I know that's not necessary in every transition but, sometimes, it's useful for a short period of time just to get people out of the rut where they spent the last N years.

I would hope people would know they have to think in any event so I don't consider this to be a valid reason to discard things that would be useful. The irony is that many people doing Scrum don't think at all.  They just follow the practices they've been told to start with.  Of course, this isn't really doing Scrum, it's just doing the practices of Scrum.  I think if you give people a powerful model that they can think with and validate, they may do better.

Alan Shalloway, CEO Net Objectives

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban