Types of Agility
- Ability to move quickly and easily
- [Context: business] Ability to deal with change in the business context well (and often, rapidly)
I care about agility because I care about the companies I work with. Because of how my career has developed these are mostly software development companies. And, I really care about the effects of the software we produce for people to use. I’ve seen some products work, and I’ve seen some fail — sometimes terribly.
With twenty or so years under my belt, I feel under pressure to know what I’m doing. At this point in my career, I should know the recipe for a working software company. I need to know how to produce software products which don’t fall apart under the pressure of generating profit, and I need to know how to help companies that are struggling.
When product companies go wrong, they either collapse financially, or they lose the agility they need to keep developing, and get stuck in on a plateau of maintenance and operation of a product which has lost the ability to truly evolve or change.
In other words they lose their agility.
Agility can mean many things. A mountain goat jumping across a rocky mountainside. Or a boxer in a fight. A minnow. An elephant’s trunk. A sprinter. There are many types of physical agility one might strive to attain.
Likewise in business, there are many types of agility we might desire. Agility might allow for significant shifts in market demand, or new regulations which adjust the rules of production. It could be needed to fend off new competition, or to scale down in the midst of a recession. It can help us grow at a rapid rate in order to exploit an emerging gap in the market. So without thinking about technology, there are many types of agility that one might strive to attain in a business context.
Small wonder then that “Agile” software methodologies have struggled to achieve a clear, coherent definition of what they are trying to achieve when applied to a business context. This isn’t necessarily a bad thing — generally useful techniques are often not focused on one particular measure of success. But it does mean that we should ask big questions about what we’re trying to achieve with “Agile” in our own context.
Thinking through my own experience, I’ve chosen four different businesses which I’ve have been a part of, or have been significantly associated with over the last twenty years in the industry. All these companies were addressing different market verticals, but they all produced web applications hosted “as-a-service” on internet-facing servers (or some private-public hybrid).
All of them enjoyed some initial form of success, succeeding well enough — generating profit or securing investment — to expand the initial development team of one, two or three (often including the owner), up to a professional team of ten or twenty developers.
But, all of them also got pretty stuck.
It wasn’t that they had bad ideas — the products were all great ideas, easy to sell and marketed by charismatic sales people who were usually core members of the founding team.
It wasn’t that they lacked good technologists — they hired reasonably well, attracting a range of talent — some able, some very able, and a few truly great technical minds.
It wasn’t just a process problem. Processes in all four were mediocre. Not terrible, but not great either.
But, all four of these companies lost their agility at some point in their journey. Product development was bogged down. Releasing new versions of software was guaranteed to introduce new bugs which would often be found by customers using the product. Morale amongst developers was often low. Frustration and stress amongst management was high.
In one of the four, the technical team members were reticent to speak out about the technical situation — the owner was emotionally volatile. In the other three, developers would frequently point out huge problems in the product — features, implementation, processes, deployment — but complained that nothing was ever done about it.
In all four, executives at some point told me that nobody would take responsibility for fixing the situation, and that inevitably they were forced to intervene to prevent things completely collapsing.
What sort of agility did these four companies need? How did they lose it? What is needed for agility to exist in these situations?
This is part of a series of articles on agility and software which are linked below:
