Mon 5 Mar 2012
Our culture is conditioning us to instinctively think of success as a one-time event. In movies when lovers finally overcome obstacles and get together the story ends – “they lived happily ever after” (the interesting questions is: “how?”). In sports an athlete runs, jumps, swims – arrives first or jumps the farthest so he is given a gold disc symbolizing his success. Done. No one can take it away from him. And so on.
This thinking spills into business. Many startups are created because people want to follow in the footsteps of others who cashed in big selling one (looking at some of them the thinking seems to be: “create a cool service, get noticed, sell to Google/MS/whatever, live happily ever after”). Also, the whole concept of a project is built on the idea that it is an effort with a definite end occurring at a predictable moment – and we can say it was successful when it reached this end as predicted. Done. Successful, closed.
The problem is all of this is incompatible with the current reality. This reality can be characterized by two key aspects:
- Increasing pace of change – technology, social customs, fashions, regulations, markets – all of that changes much faster than it used to and the rate of that change still accelerates. We can safely say we live now in constant change.
- Everything becomes more and more complex. This is largely a function of connectivity. Everything is now more connected and interrelated. Globalization means supply chains are long and complicated – a flood in Philipines impacts now manufacturers in Europe, China and consumers in the US.
In IT specifically we build much more complex applications and we create way more complicated systems out of them than, say, 10 years ago. Much of this complexity comes from interconnectedness – when we connect systems together their complexity increases exponentially. We also use programing languages and environments that are much more abstract than 20 years ago – this may simplify programmers work, but in the end the applications produced are much more complex.
To make things worse constant change seems to have just one direction: towards greater complexity. This means increasing complexity.
Clearly, if we consider it the notion of success as an event is visibly absurd in a constantly changing environment of increasing complexity. The basic assumption of the classic project definition is also clearly wrong. Completing a project as planned can’t be considered a success in this environment, because the assumptions made when creating the initial plan will in most cases be long invalid by the time the project ends.
This means we have to re-define success. My proposal is as follows:
Success is a state in which an organization (or a system, a team etc.) adequately responds to its environment.
By adequate response I understand delivering what the environment needs/expects while meeting internal goals/visions. Maintaining that state over time is much harder than attaining it once. To do it an organization must constantly analyze both the external conditions and itself then if necessary readjust itself as quickly as possible. In other words, in a highly complex and unstable environment the only way to maintain the state I call “success” is through empirical control. The problem now is that modern world as a whole is now such an environment.
This has deep consequences. The old management model in which someone bright at the top (a prince, a president or a CEO) would think, invent, plan then communicate to others who will just do as they are told doesn’t work anymore. The level of complexity we face now overwhelms the brightest minds, so we need all the brain power we can harness. This means we must form cells (teams?) and tackle the complexity in small chunks – just like we do when building systems using agile methods.
It would seem then that what we know as “agile” is in fact the only way to deal with the modern world and stay successful in it.
March 7th, 2012 at 20:56
Hi Andy-
I think this is all very well said. I see this problem a lot, not normally at the team level but sometimes in the management groups who are further removed from the agile adoption initiative. They want to know, “Are we agile yet?” And I have to point out it’s a journey, not a destination.
I use the analogy of stretching and flexibility. I’ve been trying to stretch (at least annually! 🙂 I can now say, “I am more flexible than I was before.” But I can hardly say, “I’m flexible.” Many things are like this—we can always get better and it’s important not to focus on a single end goal (destination) but to realize it’s a process and not a single end state.