But there precisely lies the rub: For complex IT projects, that style of planning doesn’t work. Practical experience shows that the majority of old-fashioned IT projects fail and the costs they incur explode.
One cause of this is a false sense of security that stems from sticking to the plan, which makes necessary changes to the process more difficult and costly to implement. Furthermore, we’ve observed again and again how then the people involved cling even more tightly to regulations and specifications in order to disclaim responsibility. In reality — paradoxically — it’s possible to control a project much better by allowing for change.
The most important criteria for this are cultivating transparent communication at every level and placing the responsibility for the quality of a solution on the shoulders of the team that implements it. In addition, shorter planning phases provide a competitive edge by making it easier to tell whether a solution will pay off — when increments of work are small, it becomes clearer sooner if an approach is a dead end or overly complicated. And since in an agile framework, the work on a project is transparent and freely accessible to the customer at any time, there’s no need for supervision and inspections.
That’s where agile working methods come into play.
New horizons
By now, the word “agile” has become ubiquitous in the working world; everyone has heard it before in some context or another. And anyone dealing with modern working methods will have run across the terms Kanban and Scrum nearly as often.
Kanban and Scrum are two typical frameworks that — unlike process descriptions and working procedures — simply provide rough guidelines while allowing a lot of freedom. This is a useful perspective for countering concerns regarding the (often considerable) complexity of Cooperation 2.0. As the VUCA diagram below illustrates, meeting new requirements with regard to collaboration represents a challenge for companies, casting them into new waters of volatility, uncertainty, complexity and ambiguity.
In this context, there’s simply no way around rethinking working culture; nevertheless, organizations, teams and individuals quickly come up against the limitations of agile frameworks. Why is that?
Often the problem is that they persist in searching for solutions according to the rules set by the methods that simply don’t exist in that space, i.e. “you can’t get there from here”. They study guidelines, rulebooks and other presumed authoritative sources to wring every last bit of information out of them, and they arrange and rearrange every possible combination of measures until there’s nothing left to optimize. That’s the point when some give up and either accept the end state as good enough or declare the method a failure.
Looking beyond one’s own nose
We’ve all heard this phrase before: “to look beyond one’s own nose”. But what exactly might it mean in an agile context?
For us, it means we have to examine other methodologies and perhaps integrate elements of them into our own work. It’s ok to dispense with guides and established processes and simply trust the experience within the team. Of course, this only makes sense once we’ve actually fully understood a methodology and experienced it in practice. With an open mind toward change and trusting in experience, it’s possible to mix and match elements from various methodologies in order to redefine the frameworks mentioned above and arrive at better results. And by the way, in adapting frameworks to suit its needs, a team is only acting in the spirit of the Agile Manifesto: “Reacting to change means more than just following a plan!”
It’s important, however, for a team that has agreed on a course of action to stick to it consistently in order to learn how effective it is. For example, if the framework chosen incorporates regularly scheduled meetings, then it’s advisable to keep to the schedule.
Charting the available action space
A team can only make reasonable and good use of Scrum, Kanban, and methods adapted from them if it knows where it stands right now. To determine its current status, the team can use procedures such as that of Dave Snowden, whose Cynefin model helps by categorizing project idea motivations as simple, complicated, complex, or chaotic:
This model describes various situations and systems in order to better differentiate between the agile world and that of the so-called waterfall model. Each category calls for a different approach.
Determining the current state of a project not only allows a suitable, localized methodology to be developed but also boosts acceptance of that methodology. When a project idea is based on a complex foundation, then waterfall-style milestone planning will be more hindrance than help, whereas for a simple topic, the Scrum framework might make the way forward seem hopelessly complicated.
All in all, it’s important to remember that while frameworks are a helpful tool, the basic principles of agility must always be kept in sight. The way to get faster is by gaining freedom of action — not by imposing specifications.
