„Agility Without Rules is not Helpful – on the Contrary“
Acceleration is happening everywhere. Technical innovation influences society, trends, worklife and lifestyles alike. Rapid digitization is driving these changes.
Whole industries are currently challenged to renegotiate the rules of their games. Stacks of books mention „transformation“. Former industrial behemoths are tottering, startups are taking the fast lane, being very young companies with comparatively tiny staff but equipped with superior understanding of and cultural affinity to agility, this essential quality of the internet age.
Agility has become the talk of every town, breaking out its place of origin, which was software development, and setting out to shape whole organizations. The speed of change demands this: „How do we go about planning projects which will be finished in a future of which just the merest contours are visible?“ - Good question. Netural has long engaged in project agility thinking and it is the company´s main focus in 2016. In the following interview, CEOs Albert Ortig and Stephan Lechner explain the reasons:
Netural´s 2016 top agenda is agility in absolutely every respect. Why is that? Netural has always been quite agile, hasn´t it?
AO: Good question. {laughs} We are quite an elastic organization indeed. But still we sometimes feel that we lack the elbow room to make a speedy decision when the need arises. This is all about velocity, first in thinking, and subsequently in structures.
How do you define agility? Does it stop at corporate flexibility?
StL: I define agility as dealing with uncertainty in a professional manner. Digital projects are increasingly complex, while it gets harder and harder to obtain precisely defined goals. Along project paths, conditions and objectives may undergo substantial changes. The conventional „measure it – plan it – execute it“ approach looks more and more like a thing of the past. Being professional involves elastic responses to changes…
AO: …and even to uncalculable events. Which is a marked difference from classic bread-and-butter project risk assesment. Businesses routinely evaluate - and provide for - risk cases A, B od C. But agility addresses project uncertainties instead of project risks, dealing with totally unforeseeable developments in dynamic environments with high levels of uncertainty.
Approximation replacing execution?
AO: Yes, in every respect: approximating potential solutions, e.g. by prototyping, approximating the horizon for implementation, and of course approximating project volumes, means budgets.
Starting on a journey, knowing only the direction, but not the final destination?
StL: Exactly, and equipped with all the tools we need for orientation along the way, while we struggle to get a grip on the destination.
AO: Important detail here: The trip will still end with a precision landing, at least approximately. It´s just that it will not stringently reflect the originally defined intentions. Take for instance an innovative digital service, one never tried before. These projects will typically need generalistic, agile approaches, and we enter them not with detailed roadmaps, but carrying a bag full of smart, carefully selected tools.
Let´s break this down to processes and structures: Where are the levers here?
StL: I understand agility as a paradox, therefore I feel that the flexibility in projects and related tasks requires clearly structured procedures to keep it manageable. Agility without rules is not helpful – on the contrary. Neither is agility an end in itself, and it is important to question the necessity for agile structures before launching into a project. Customer requirements may necessitate agility. But mind that there are projects which resemble each other, like e.g. conventional web projects. Here we find recurring patterns of uncertainty, and from those we can derive rules. Then again, there are projects which lead into uncharted territory, like many in the Netural Lab. Defining framework requirements for those is sometimes quite difficult.
AO: Netural has been reorganizing for years. This is really an ongoing process. We believe in permanent change as the only really constant factor. But in spite of all the regrouping, our structures are still quite similar to conventional companies. Now we set out to create a framework in which our projects and the organization itself will continuously adapt to changing situations. This will take us far beyond Scrum and related approaches.
How do you go about structuring an agile organization?
AO: Ask me again after the next 500 days. {laughs} But some features are pretty obvious: Agile project organization requires a perfect service backbone. Decision-making should not crawl up and down the totem pole, it should happen on the spot wherever and whenever questions arise. Furthermore, agility requires total clarity and reliability, pretty much like the general setup for piloting an airplane.
How will an “agile” Netural measure success?
StL: By reduced friction and by the satisfaction of clients and staff.
AO: Increased personal responsibility. Problems solved directly on the spot. Projects succeeding in the face of permanent change in the digital world.
