Don’t really buy into all the hype of agile? Think it works up to a point, but real-life is actually more complicated and demands more of a hybrid approach? – Don’t worry, you are not alone.
Since helping define DSDM in 1994, I have spent the last 14 years helping organizations adopt agile methods like DSDM, Scrum, XP, FDD, etc and have come to realize, like many others, that these methods are not the solution. Instead they are the over-simplified starting points that you need to blend into what already works within the organization. Then overlay and support with additional approaches to create successful project ecosystems.
We need simplified schematics of systems to assist comprehension and discussion. However, all too often these simplified models are put into production as the entire solution and then problems occur. Like a simplified model of a car braking system, it is useful in helping us understand how the system works in theory, yet is full of design flaws for practical implementation.
In real life, servo’s and pumps are needed to amplify the braking force from the pedal. There is not a single shared-fluid system, but instead two diagonally opposed systems (so a leak does not result in total brake failure or pulling to one side in a left and right split system). In addition to the basic system shown here, cars also employ an array of supporting systems for fluid level monitoring, ABS, wear detection, etc.
Luckily people do not read about the basics of car braking systems and then decide to replace the one on their car with their own design. However plenty of people read about agile methods and decide to implement that as their new software production system.
The good news is that the state of existing software production systems is often very poor and so implementing any kind of better conceived system is an improvement. (A basic sub-optimal braking system is probably better than relying on throwing an anchor out the window and hoping it snags on something to stop you!) The problems occur when the current system is not optimal, but understood and working; and it is then replaced by an oversimplified alternative.
The Real Solution is More Complex
These simple models are great starting points, but poor destinations for enterprise organizations. Agile practices need plumbing-in with established project initiation, reporting and 3rd party collaboration processes. Also, just as real-life braking systems need supporting sub-systems to deal with the realities of their operating environments, so too do agile methods to handle things like regulatory controls, dispersed teams, silo’d roles, etc.
To be consistently successful in implementing agile (or any other process) outside of simple applications, a balanced view and selective approach is required. We need to understand all the intricacies of traditional project management and agile methods to effectively create a better alternative. If nothing else, this deep understanding of traditional approaches helps communications with the skeptics. Talking their language is an important starting point for addressing their concerns.
Alistair Cockburn uses the stages “Shu”, “Ha”, “Rei” from Zen Buddhism, to describe agile adoption maturity. Progression moves from obeying the rules (Shu – to Obey), consciously moving away from the rules (Ha – to Break), and finally unconsciously finding an individual path (Rei – to Separate). Todd Little has a similar “Read, Write, Delete” metaphor. First we need to be able to Read, understand and apply agile practices. Then learn how to Write our own domain specific amendments and new practices. Finally, if we develop far enough, we can Delete the rules and practices as we don’t need them anymore and instead instinctively adopt the most appropriate tools.
However, this moderation, consideration and prudent selection sounds more like the doctrine of an oppressive religion rather than the rallying cry for action. How do we sell it, and will anyone listen?
Consideration, Caution, and Careful Balancing is a Tough Sell
This balanced “middle-way” message is not very sexy, and hard to promote. Agile zealots who evangelize the one-true-path to software success, have a simple message and appeal to our desire for “new” and “quick-fix” solutions. Yet they are a bit like eating cotton-candy (candyfloss) it looks and tastes good in the short tem, but soon disappears, does not really consist of much, and leaves you unsatisfied in the long run.
Following this food analogy; people want to be slim, full of energy and healthy and often pursue quick-fix diets like Atkins, South Beach, Detox, etc. They all have some truth in them, but alone are not the whole answer. The true path, a balance of healthy eating and exercise is, well, hard work, slow and a tough sell.
The New Book
I have been thinking of writing a book for a while and have been approached by two publishers to do so. A refresh of agile project management is one option, yet where my passion lies and where I believe the greatest leverage resides, is in effectively describing this balanced approach to leadership and project management. Strategies and visuals for finding that ever changing balance between people skills and process mechanics, order and adaptation, detail and intent.
I see these variables as inclusive ANDs not exclusive ORs. We need both sides, just in varying degrees based on project and organizational factors. For instance very early in a project, when the focus is on feasibility, scoping and ROI calculation then a traditional mechanistic focus is often a priority. Then when we are into requirements exploration, development, and execution a more agile approach is preferable. Finally as we undertake deployment and user training, traditional plan driven approaches work well again. All the while our focus as a leader may be shifting from a collaboration and consensus focus to an execution focus as the project progresses.
Maybe I am naïve to think this skill of careful balance can be explained and illustrated. The greatest business benefits lie not in the approaches, but the selection and application of these approaches – more a philosophy.
Toyota happily shares its manufacturing ideas with the world including its competitors. They are not worried about being copied because A) by then they will have moved ahead so far anyway, and B) the Toyota Way is not a set of techniques, it is a philosophy, a way of thinking and framing problems that is much harder to copy. Heck, the best Toyota engineers don’t even work at Toyota facilities, they are embedded within their suppliers helping to make them better suppliers.
Good managers know about this leadership / management balance, but rarely is it written about because it eludes being easily boiled down into a cook-book approach. I am not sure of the market for such a book. Apparently books only reach 2% of the population, and I am guessing the segment of people who read and think about balance and blend is much less than those looking for the next simple fix.
Anyway, this is where my thoughts lie at the moment, ways to help select that balance between leadership and management.