Go Further and Faster with Agility and Luc Taesch
If you are into IT, you must have heard at least every now and then of the Agile development method. If your work is about something else, agility may sound unfamiliar—and perhaps it will come to you shortly. Unless you take a proactive approach to find out first.
Watch the Interview (in French)
How to Fit in a Chaotic—or, at least, very unstable—Environment
Luc Taesch may be one of the hardest guests I ever needed to present here. He coded and commercialized his first software program at 16 years old, became a network engineer, developed various IT structures for a number of trading banks, became a managing junior director at 29, and travelled a lot before establishing himself as a management consultant and independent Agile coach. His journey has been convoluted and rather chaotic. This makes difficult to put him into a specific category, apart from the high-level corporate, both in doing and managing. On the other hand, Luc’s journey also allowed him to embody agility before he started to talk about it.
“When I became a manager”, Luc says, “I began to see a major problem. Management does not change fast. The last frontier lays in changing management—not in going to the Moon but in changing how things are done in IT.” Tangentially, whereas non-IT people may perceive IT as evolving on a fast pace, Luc saw in many IT companies a problem of slowness: deliveries have been taking too much time. Not because developers and engineers were lazy or inept but due to the methods of doing things.
As a field, IT evolved much. At the beginning, it was only a support for other businesses. Information has always been about something else than itself, just like transportation is about moving goods from and to other businesses. Eventually, though, IT has become a center in its own right. Many companies who are barely thought of as IT produce digital content only. Bookshops became concerned with working like Amazon. Video rents switched to Netflix. As Luc says, the apparently dissimilar companies Amazon and Carrefour share the same retailing activity: “the only difference between these two companies lies in their IT.” And what Amazon had built for itself changed the lives of everyone else.
The world is more interconnected, works on a speedier pace than it ever did. Every indicator shows that this trend is to increase exponentially. The more we can do, the more chaotic things become—here Luc and I are in perfect agreement.
If you have an idea, you can reach your credit card, buy up some Internet space, create a website with turnkey tools. Theoretically, in 20 minutes, more practically I would say in 2 or 3 hours, your website is alive on Amazon and you can start selling. This requires have know-how, of course, but the key part is, you don’t have to discuss or negotiate with your central IT department for 6 months.
The Agile Method for Non-IT People
When the wheel was discovered in Egypt, life-changing inventions were rare. Perhaps there would be one every 200 years. Then the Renaissance came with a game-changing discovery every 50 years. During the nineteenth century, these inventions would come at the accelerated rhythm of a newer one every 10 years. Then now, according to some estimations, we live in a world where such an invention appears every 6 hours.
It becomes non-realistic to predict the future, and no rules based on the past can predict a future where new disruptive means can appear anytime. Time scales are short. Projects must be redefined or reworked on constantly. This is where the Agile method comes into play. Agility aims at solving complex problems in a very unstable environment. Due to its rhythm of evolution, the IT domain was the first to really meet with this problem and consequently adopt the Agile mindset.
What is Agile? One of the most typical manners to understand it is to compare it with the older and more usual method of software development called Waterfall. Instead, Luc prefers to explain it by the following analogy.
Before 1908, you had to be wealthy to buy a car, and when you did, you had to wait for a long time—months if not years—before the car was not only planned but hand-assembled as well. The Ford Company would produce the same car for every customer, a standard, black model. 2 million cars were thus produced every year. Then cars came in different colors. Then different series. Then they had options. Then different designs, and so on. And then Toyota invented Lean, a production method revolving around smaller production batches, just-in-time stocks, and more adaptation.
This is not exactly Agile, but a lot of would-be important features were already there: the production cycle was shortened, the feedback loops came faster and faster, new models and projects had to be undertaken again and again. Most, if not all car-makers, moved from the long-life, standard product to the short-life, personalized product model.
This paradigm change inspired cognitive psychologists, who understand the brain as an information treatment system, to looked at how humans discover things and learn—in life, at school, at work. Which in turn brought insights on delivering IT.
The Agile method and mindset could be summed up this way:
- Continuous learning. You are constantly learning, things are never completely static, and there is always something to glean or twist.
- Processes are iterative. Not only are you doing rather than receiving passively, but when you do or make something, you necessarily stumble onto discoveries and make mistakes. Both are chief sources of the aforementioned continuous learning.
- Things must be done through small parts. What comes in big parts tends to be rigid and fragile. To be Agile, you must split your project into small parts, then reconfigure their order, decide to make new ones, change or discard some… according to a longer-term aim and as you see fit.
- Customers or those who give specifications ought to join. They have to look at smaller parts, partly developed projects, prototypes, or whatever the developers make and give a feedback. As the development team delivers on a short duration, those who ordered or have their say in what the product will be must implicate themselves more than before. Both parts of the project, the makers and the receivers, are expected to involve more.
At the beginning, Agile was developed and thought of as a productivity method. Agilists wanted to waste less, to produce more, when they knew they would be forced into revising and reorganize their product before delivering a final version. Then, Luc mentions, other improvements popped up: “IT developers and engineers started to feel better” and customers felt like they had more influence when they started to have their say on a much higher frequency.
If you search a bit, you will find very easily a number of IT companies who dropped the usual waterfall approach and “agilized” their software development successfully. But what about non-IT companies? Did some turn Agile and benefited from it? According to my guest, yes, some did. Here are two famous, though often overlooked, examples:
- Amazon. This no-introduction-needed, headed-by-a-top-buff-billionaire company was once a simple distribution network. It kept things, then sent things to their delivery destination. Quite simple. Then, in the 90s, not only did Amazon benefit from the Internet bubble, they also scaled their website to match their growth in sales. Amazon changed its IT structure, which led the company to change their business model from a distribution-only to a more and more service-oriented one. They invented various content-management methods that were property material at first—and which they sold to an eager public. Now these contents form a set known as Amazon Services. And Amazon keeps venturing in new territories with a brand new food delivery service. From day one, the Amazon developers had an Agile mindset: they morphed their products again and again beyond the usual business segment boundaries. They created, seized, without ever stopping to their main delivery thrust.
- Netflix. At first, this one would send you physical objects. Netflix sent and received DVDs. Internet was only a means to deliver without the customer having to get out of home. Then, the physical aspect was completely dropped, Netflix became purely digital, and now they manage to co-produce part of the content they host as well as get contracts of exclusive distribution. “Before, most Netflix employees were logistic guys. They moved boxes. Now most of Netflix’s workforce is IT guys.”
Both companies showed their agility through a series of shifts. What Ford Company did over decades, Amazon and Netflix did even more and at a much faster rate. They went through a series of steps and transformations after which the initial product only reverberates as an echo—and when you’re Agile such an echo is not even necessary.
Before, Luc remembers, I had music tapes. Then I had CDs. Then I started ripping my CDs. Then I downloaded separate digital files. Then it became much simpler to download through Virgin music, then my downloading was integrated into iTunes, and then I moved to Spotify. For the price of a single CD album per month, Spotify allows me to access unlimited titles plus discover new stuff ! It makes me a custom “weekly discoveries” mix every week— an ephemeral, personalized, unique product, made for me only. Then this mix vanishes to be replaced by another one.
Agilize Your Organization!
A start-up is forced to be Agile. No matter its field, it starts with an idea. Start-uppers need some real abilities, and they have to learn on the spot. Then, if they manage to develop their abilities, learn, and maintain their course while remaining financially afloat, they may notice they could make an even better product. Then they could move there again. Agility “is not necessarily about adding options, it can be about changing completely: for example, you started with a car project, then you develop a scooter vehicle, and after a while you’re selling an electric bicycle with an app.”
Then, perhaps they will drop completely the making of the vehicle and will outsource it to China while selling it together with their homemade app. A long series of changes and iterations can happen because the available options, the market, the latest technologies can change so fast.
Start-ups, though, are not the crux of Luc’s activity. These fashionable contenders are more than Agile. Start-ups applied the lean approach to bootstrapping an activity, which means, roughly, that they can undergo a complete change of activity every 3 to 6 months.
As a consulter, Luc works with bigger—or fatter, to extend the lean metaphor—, less flexible companies. These tend to work with a one-year planned budget and to find the lean approach inapplicable, when they do not reduce it into a productivity-only approach.
You can’t overturn your production chain and what your employees are doing that fast. More important: even if you could, you would have to change your management conception, and this is the most serious problem. The management is usually organized as a control structure, not a regulation one. When you’re part of the management, you won’t tell your budget planner he must revise his views, especially when your bonus and his depend from the one-year target harshly negotiated six month ago during several weeks.
What a startup can do almost instinctively, a bigger company cannot do without entering into a near-impossible conundrum. A system which contains thousands of employees or even more cannot reorganize itself all the time. This rigid structure stifles innovation and agility. “Most of Europe still works within a centralized, controlled system for large companies… but back in the 1950s, it had already been measured that the more centralized companies were less productive than smaller companies, because… the production process becomes too rigid and can no longer evolve quick enough.” Had it remained under the tight, stiffening control of centralized planning, IT itself would never have evolved so much!
How to Agilize When You Are Much Bigger than a Startup?
Luc distinguishes between what he calls scaled agility, or having a lot of Agile teams, and enterprise agility or having a wholly agilized superstructure. The first is much easier to achieve than the second. And both are still frequently confused. If you are, say, a thousand-employees company, you can “agilize” teams of 4 to 10 individuals in a small time. Agile coaches can be hired. It is also possible to apply a simplified Agile recipe such as SCRUM—“pretty basic, but the key tenets are here”, Luc adds. “Then values start changing… it is more than a slogan: in the course of 6 to 18 months, agilized developers start to change their mindset, and they express it by themselves.”
However, even if you agilize your teams, “the management pyramid up above will not change so far.” It does not understand it. Agility is a mindset that comes much more easily to developers—who practice it—than to those who control them.
Managers at the top of the pyramid must share their views, infuse the developers with them, more directly than before. Interactions should be flattened. And top manager should also accept some insight from the doers, and make sense of it, thus turning weak signals into opportunities, instead of suppressing said insight.
Mid-level managers, Luc says, are the most affected by agility. This sounds paradoxical: A manager is supposed to be in control, however, an Agile team is also supposed to be autonomous. What can the manager do then? Especially when he is still supposed to be responsible: how can he be a manager without control and still bear the burden of liability without power?
The Agile team manager does not lose all power. His team may be autonomous, it is not independent. But his role is changing for sure. For he was a liaison between the team and the executive board, and now, he must develop two new roles: first, a coaching one, by being someone who knows how to listen, inspire, help and support the developers and engineers to transform; second, a visionary one, as he engages into the shared vision and contributes directly as well. He must embody a “receptive, assertive and benevolent” stance.
All this, of course, is a bit complicated and necessarily messy when the company undergoes an adaptation period. Before, the management chain looked simpler; now the employees, plus the managers and stakeholders, have to talk more, share more, and make more explicit what they want or do.
According to Luc, the biggest challenge lies moving from agility at scale to enterprise agility. “If IT developers agilize, it changes the IT’s relationship with all other departments and with other companies as well.” Suppliers, internal and external, and all customers find themselves in a position of increased involvement. They must join the loop and take the Agile pace too. Whoever you are, “you can’t agilize alone.”
How to be Future Fit
Needless to add, the very Agile mindset is about being ready for the future. At this point it may seem redundant to ask Luc if he has any piece of advice to share. However, even in a world where many things change, I make a point to not change my custom of asking my guest for advice. And indeed, Luc still has some points to make, too. Here they are:
- Meditate. Agility implies a greater ability to connect with oneself and others. Connection with oneself comes first. “Meditating does not consist in thinking ‘I’m meditating’ but ‘I’m letting myself being meditated’… Meditating is not an action. When you’re tanning, you just go where the Sun shines and let yourself being tanned.” Meditation would be especially needed in a world where “corporate life makes us obsessed with phones, connectivity, the news and other distractions.” Sometimes it is simply a matter of disconnecting from the world so you can reconnect to yourself. All in all, meditating is an ability to develop.
- Cultivate empathy and genuineness. Once you reconnect to yourself, you can do so with others as well. “You have to express yourself genuinely while still being assertive yet caring… this is pretty basic but very different from just saying what you think, feel, judge, and going with others who think, feel, judge the same, and feeling awkward with those who don’t.”
- Co-construct. “Connecting with yourself and others is all and well. Now you are still supposed to do things. How to build a vision, a dream, with other people? Then turn it into something practical with plans and tasks? This is a fashionable theme and a lot of dubious theories have spawned there, but I’d advise to deepen the subject.”
To know more about Luc Taesch’s work as an Agile expert and coach, check his personal-professional website (in French).
