I was pondering various Twitter debates (e.g. #NoEstimates, agile vs. Agile, the dangers of incremental thinking, Scrum vs. Agile) over the weekend. These exchanges leave me pretty frustrated, and I was wondering why. I also got most of the way through Jeff Gothelf and Josh Seiden’s book Sense and Respond which offered up some new angles.
Here’s the best I can come up with (re: my frustration). These various debates lack context. At any given point, you should keep the following questions in mind about your particular situation:
- The Game. What game are we playing? What are the “rules” (self-imposed, external, etc.) ?
- Disruption. How can we change the nature/rules of the game?
- Evolution. How will the game change without our intervention(s)?
- Best Practices. How do the best players play the game?
- Training. How can we become better game players? How can we can eventually outperform the best players? These questions are obviously related. For example, one might use best practices (#4) to identify the game (#1), and train people to become better at it (#5). Or even use best practices to shift games (#2), and render other best practices less effective. Or the iPhone might get released (#3) triggering a shift in how we think about the game (#1). Etc.
People use expertise, tools, and methodologies to help:
- Understand. Answer these questions
- Act. act/execute based on our answers to these questions
- Reflect. reflect on/reassess our answers to these questions
- Improve. Get better at answering, executing, and reflecting And this gets super meta … you can think of these points as games.
Some things that seem to hold true:
Some games change very slowly. Most dominant actors play the game in a similar way. Other games are in a state of flux. The rules are loose. Approaches to playing the game vary widely. There are only so many ways you can fulfill government contracts for missile guidance systems (for example)
You can be playing many games at once (e.g. broad games like “software development” or “design”, and narrower games like “cloud analytics providers” or “consumer fitness wearables”)
Innovation often involves changing games that were previously considered unchangeable, acting on knowledge of a changing game, or pretending to play one game, while really playing a different game
Sometimes you win by consistently playing a known game perfectly. Sometimes your key strength is rule changing and game identification. Sometimes you win by learning new games quickly
Best practices in a highly constrained game may not be applicable to a less constrained version of the game. Practices can be “first principles” — applicable to a whole class of games — or offer more specific guidance for a narrower game
“Transformation” involves understanding the current game, possibly changing the game, predicting external changes to the game, understanding what skills remain applicable in the new game, and adopting new skills where applicable. Transformation is not about playing the existing game better (which can be very important, as well) What to watch out for…
When you find yourself saying “it can’t work here” … what are you basing that on? Is the game truly different? Are you referring to internal rules or external rules? What are the “best” people doing who play your game?
Debating tools and practices without discussing these questions (1–5) is a waste of time
High level manifestos and principles are helpful, but it is important not to conflate these with the practice/tools they inspire (e.g. Agile and Scrum). The problems that Scrum solves may not be applicable for the game you are playing
Scrum is cited as something for beginners. Yet it doesn’t resemble what more advanced teams are doing. Is that smart? This relates heavily to how the best people are playing the game (#4) and the best way to get them there (#5). If you take a step back, you might be in the business of software product development. Scrum is a small part of that game.
We frequently cite compliance and the “existing culture” as a blocker. Why do we start first with the front-line teams (#5) and the generic game of software development (#1) ? It would seem that the first step would be to start playing a different game (#2). But that’s hard because it is a lot harder to get executives to do something different (#5). Devs are easy in comparison
Depending on who you ask about NoEstimates, you’ll discover that someone is trying to solve dysfunction and shift the game (#2), the next person feels they have a better way to play a particular game (#4), and most people aren’t clear about the game in question (#1). That’s confusing There’s nothing groundbreaking (or original) about these questions. I’m sure game theorists would eat my for lunch. My point is that people should 1) question their own assumptions, and 2) try to build shared understanding. Most of the “debates” I participate in are lacking any sort of shared context. Let’s fix that.