Many organizational “transformation” endeavors are doomed to fail because they try to take on too much, and try and change everything, all at once. Instead, you need to learn different ways of looking at the dynamics of the system and its outcomes.
A seed, as we’ll use the term, is a generative principle. It’s an abstraction that can advise and inform you in many different contexts. Once you understand the nature of a seed, you can apply that idea in multiple situations. This will help you answer questions and solve problems depending on your unique situations. Seeds are fractal: they can apply across all different levels, to individuals, teams, departments/divisions, and organizations.
There are four seeds:
These are explained in detail below.
✓ Critical ❑ Helpful ❑ Experimental
The central idea of Loops, not Lines is that a naive approach often follows very linear, predictive thinking. Unfortunately the real world does not work that way.
Instead of a linear cause and effect of “this causes that,” look at the problem as a loop: this and that both influence this other thing, which in turns causes more of the first thing. Loops are often self-reinforcing, and can be constructive, making things better and better; or destructive, making things worse and worse.
Loops also refers to continuous activities. Learning and training, for example, are never “one and done” activities. Learning is a lifelong commitment: for your professional life, for the life of the team, for the life of the organization.
The poorly-named activity of “requirements analysis” is never “one and done.” It’s an ongoing process of continual, shared learning by the team, executives, and users.
Do not develop software in linear Death Sprints
You develop software continuously, in a series of small, fast, loops—not a single long, drawn out linear death march, or even an endless series of small, painful, linear death sprints.
Rate of feedback is your speed limit
Fast feedback is essential to success in modern organizations, and that too is done with small, fast loops. Always try to think in terms of Loops, not Lines.
Systems are not built, they evolve. The evolving, non-linear and learning nature of software and digital work is closer to an organic process, such as gardening, rather than some sort of mechanical assembly line or idealized factory process. Perhaps even more importantly, people and their relationships are the most critical component to success: not tools and rules.
Teams don’t start with all the answers. No matter how hard you try or how skilled the team is, you cannot solve or even identify every problem ahead of time. Instead, problems and solutions have to be discovered and learned in the context of the project over time.
And to make matters worse, systems are built by people. People are unreliable components, prone to random failure:
“When dealing with people, remember you are not dealing with creatures of logic, but with creatures bristling with prejudice and motivated by pride and vanity.”― Dale Carnegie
People are also subject to a wide-range of cognitive biases (Wikipedia lists over 90 common ones). People don’t respond predictably like machines, and can’t be treated like machines. That means we need to take into account “human maintenance” to ensure their well-being, including addressing such organic topics as empathy, transparency, trust, and collaboration.
Software development is evolutionary; it’s a messy, non-linear, organic process, so those are the sorts of tools and processes you need for successful outcomes: Organic, not Robotic.
Many critical activities are often neglected and left to chance, where they might happen poorly or not at all. Instead, you want to be very intentional.
For example, instead of adopting technology because it seems popular, actually try it in the context of this project to evaluate its suitability. Experiment, deliberately, for important questions about features, architecture, process adoption. Just try it. See what happens. Learn, tweak, and repeat.
Experiment deliberately. Learn, tweak, repeat.
In order to use experiments you have to know how to do them safely, how to avoid accidental waste in your process, and what tools to apply to what sorts of problems.
You’ll also have to learn, and re-learn, continuously. The whole basis of modern software development and digital-oriented work is continuous learning, and that needs to be an explicit part of your daily working environment. Learning and problem solving needs to be Intentional, not Accidental.
Humans naturally filter raw sensory input. You don’t really see everything in front of you, your brain reduces the vast amount of visual information to simplified forms, re-uses stale input, and other tricks to keep the bandwidth down. We run the same risk in organizations, relying on low-quality proxies of information instead of actual empirical data.
For example, an industry certification is a proxy for an engineer’s experience and ability. But it’s not a very good proxy, it may not amount to much more than an attendance certificate.
Velocity is a proxy for value produced by a team.
Estimates are a proxy for learning.
Certifications, velocity, estimates are all low-grade proxies
Gerald Weinberg once wrote that every crisis is the end of an illusion (Rhonda’s First Revelation: “It may look like a crisis, but it’s only the end of an illusion.” Secrets of Consulting, page 149). Proxies of any sort will cause information distortion, reducing accuracy to at least some degree. In the worst (and unfortunately common) case, this can cause a full-on illusion.
Wherever you can, you want to the real data, not the proxy. Actual capability, not a piece of paper. Actual shipping software that generates value, not numbers on a spreadsheet. Actual users in their native habitat, not a watered-down version in a memo or on a story card. You want the real stuff, you want Actuals, not Proxies.
Anti-patterns from the Hall of Shame