In the 17 years I've been involved in Agile software development, there have three areas that are key to success that have been somewhat ignored by much of the Agile community. These are in the areas of complexity, transition and learning. Pretty surprising since everyone says software development is complex, that we must transition to a better way of being and that it's all about learning. Let's look at each of these.
Complexity.
I hear people talking about how software is complex and we're complex adaptive systems as if both are facts.
Even if they are (I don't believe we are complex adaptive systems in the classic sense) what we take that to mean can vary.
I find it interesting that Scrum and the Kanban Method each take a similar approach to complexity - attend to only certain aspects of the system being worked on.
The challenge with this is that complex systems, by their very nature mean they can't be decomposed, one must take them in their entirety. Looking at a few things and trusting people will figure things out, not only cause Framework Tunnel Vision but ignores the vast evidence that they won't. While it is true we can't look at everything, we must be aware of the most salient characteristics. This includes eco-system (e.g., cross-functional teams), workflow, workload, management methods and an understanding of flow. Instead of a method or framework saying "just look at these few things to start" it needs to select a few and provide insights on when and how to look at others if/when things don't progress as expected.
Transition.
Oddly enough, Scrum and the Kanban Method take polar opposites on this. Scrum ignores the impact of changing roles, team structure, methods and acknowledgement. The Kanban Method on the other hand, suggests any significant change is too much. Scrum ignores the reality that people can only bear so much change while the Kanban Method ignores the fact that many times people embrace change (see Resistance Is Not to Change). The reality is we must transition to better methods. But that doesn't imply super-slow or super-fast. We must look to see where we are, where we are going and what is the best way to get there.
How We Learn.
Most people when starting out with something new want to be told what to do. But before long, they want to venture out on their own - to try things based on their judgment. One would think this would be the essence of Agile - teaching people how to learn. But again, common methods tell us how to start but don't seem to recognize we go through different phases of learning - naive, beginner, competent, virtuoso, expert. In the beginning we may want to be told what to do, but at some point principles are needed and roadmaps to guide us should be given.
Perhaps the biggest of them all.
To be candid, my biggest disappointment is that once a thought leader has created a method based on their mindset, they seem to absolutely want to avoid discussing the mindset. I've heard many thought leaders exclaim why something worked or didn't but never wanted to engage with a conversation about if what they were claiming is true. Ironically, most of the time there's been a huge amount of evidence against the claims of why popular methods actually work. But I don't hear much discussions about this. Essentially, what our community is is not scientific. It's also ironic that we use the first issue I mention - complexity - as the implied reason. "Hey, it's complex, we can't reach a rational conclusion about it."
Expect some exciting new insights to come out in the next few weeks from us. We've been writing up our explicit approaches to Lean-Agile and intend to start making more of it available.
Al Shalloway
Further Reading:
