Programmer and organizational change specialist Dan North applies principles from lean operations and agile software development to help organizations align their technology capabilities with their business objectives. Dan is currently working on his book Patterns of Effective Delivery, helping organizations radically improve their delivery. He blogs at dannorth.net.
Noel : Your upcoming session is titled "Embracing Uncertainty: A Leap of Faith." Convincing others to embrace something as often scary in the business world as "uncertainty" sounds like an awfully difficult task. What are some of the ways you help convince those who may find this intimidating?
Dan : In the business world we deal with uncertainty all the time, but we use the much more business-sounding word "risk" to describe it! To say "I'm uncertain,” sounds weak, but it's OK to say "I think this is risky." There's a lovely Swedish phrase "When you are talking to farmers, use farmers' words." What it means is: if you use familiar language you are more likely to engage people. So the first thing is to frame uncertainty in the more familiar terms of risk.
The next thing is to generate quick wins. If I ask you to do something unfamiliar, say speaking in a foreign language, I would expect you to be a little nervous or self-conscious. If I teach you some simple phrases and you repeat them, and a native of that language smiles and recognizes the phrase, you will immediately feel more confident. So taking small steps with tangible feedback is a powerful technique for exploring uncertainty.
Noel : When you talk about this being a "leap of faith," for those that need more than faith, like actual proof that this is the right thing to do, what do you give them?
Dan : That's an interesting phrase. There are different kinds of faith and different degrees of leap, so it's worth clarifying. I'm not talking about a blind faith, where I ask you to believe something just because I tell you. This is more like an empirical faith: look at the evidence and let that guide you, even if it is counter to what you would normally do.
Eli Goldratt, the author of the excellent business book "The Goal," talks about the difference between common practice and common sense. The shift in thinking to embrace uncertainty - rather than our usual approach of trying to resist or deny it - is common sense even though it is not common practice.
Noel : You've mentioned that "contradictory opinions" in a development team isn't actually a bad or hindering thing. What positives come from opposing views, and how are delays avoided in situations where an agreement must be reached?
Dan : Diversity in any group has many positive aspects, as long as the team can manage disagreements effectively. Any opinion should be open to debate or challenge. I've argued before that there are no "best practices," just different practices that work well in certain contexts. It's easy for a monoculture team to fall into repetitive habits "because that's the way we've always done it," and to fall behind developments outside of their team.
An opposing viewpoint or a fresh perspective can challenge the status quo, which can result in either adopting a new, better practice or gaining a clearer understanding of why the current practice is still appropriate: there's no downside!
On the other hand, a team can get stuck arguing the pros and cons of a way forward and find itself stuck in a form of analysis paralysis. This usually indicates conflicting opinions in the absence of any hard evidence. In this case it can often be effective to drive forward with both approaches and see which one seems more appropriate over time. In the short term this is less efficient, due to duplication of effort, but can be much more effective because you don't lose any time debating the approaches: the evidence speaks for itself.
In some situations of course you don't have this option and you need to make a call. In that case I like the approach used by the 19th century explorer Earnest Shackleton, which is to hear everybody's opinions and then make a decision - and stick to it! That way everyone feels heard but you aren't making decisions by committee. Sometimes you need to move forward in a direction - any direction - rather than be stuck in endless debates.
Noel : You’ve mentioned that some have "turned their backs on the original agile manifest" - what likely caused this to happen?
Dan : There are a number of aspects to this and I'll cover some of those in my talk. The short answer is that the Agile Manifesto requires us to embrace uncertainty - preferring to respond to change rather than following a plan for instance - and as humans we are deeply uncomfortable with this. It's the organizational equivalent of a fear of heights: the way you learn to climb is by just getting on and climbing, and by using decent climbing equipment to reduce the impact of making mistakes!
Over time your familiarity with climbing helps you overcome your vertigo. Conversely we all have a built-in bias known as confirmation bias, which means we unconsciously look for evidence that confirms our prejudices and fears, and delete evidence to the contrary. So we have managed to convince ourselves that slavishly following the rules of an "agile" methodology is the same thing as following the values of the Agile Manifesto, which it demonstrably isn't!
Noel : What constitutes "effective organizational behavior" or will that differ from company to company or even project to project?
Dan : That's a great question, and in fact it's the basis of an entire body of training I've been putting together. The short answer is that an organization needs to decide what its purpose is - its goal. Then you can think of the organization as a system whose output should be that goal. The goal needs to be clearly articulated and measurable, and not just "make money" or "delight customers." Of course those things matter but they are really just indicators that it is doing what it set out to do! Then you can define effectiveness as how well aligned the system is with producing that goal.
You imagine the perfect system as one that would perfectly achieve that goal, as quickly and effectively as possible. Then you overlay that on your current organization and see where the gaps are, and where you could start changing things to produce a better system. This then forms the basis of your entire organizational change program, and it is the only way I know to create lasting change.
Conversely, most organizations I encounter don't really understand their goal so they don't have an objective basis from which to define effectiveness. Instead they fall back on effort- or cost-based metrics like utilization, cost-per-use or adherence to budgets. (There's a whole other conversation about budgets too, but that's for another time!) These are not just unhelpful metrics, they can actively sabotage an organization's efforts to become more effective. So my advice is to decide on your goal, and if you don't have one then figuring it out is the single most important thing you can do. Otherwise you can't know if you're doing well.
