Can a large container ship be as maneuverable as a sailboat? Thanks to the agile methodologies that are so popular among market leaders today, it is possible. These, although they seem like a new deal, are a return to past solutions. Proven and rational.
Duel-tailored “Game of Thrones.”
Nobody has a license to win a streak, not even the biggest business superpowers. We have seen many times how powerful companies lose in the race against small start-ups because their agility turned out to be more important than the giant’s strength. The cooperative collectives of several people, unfettered by bureaucracy and slowness of decision-making processes in hierarchical corporate structures, were able to react faster to changing challenges and chances; as a result, they smoothly negotiated each successive corner on the way to the finish. This is an almost archetypal confrontation: Goliath versus David, or a heavily armed but slow Greek hoplite versus a light-armed, javelin throwing Thracian peltast. In the popular saga “Game of Thrones,” exactly this balance of forces is illustrated by the famous scene of the duel between the mighty Gregor Clegane called the Mountain, a giant in heavy armor, with a slim, fast, and agile Oberyn Martell – the Red Viper.
Size and strength do not always win with agility and speed. However, we all agree that it would be best to be both great and agile. Despite its high displacement, a ship can maneuver between reefs with the agility of a small sailboat. Is it even possible? Yes. I used this clever methodology.
Doubtful recipe for success
Until recently, the IT world dominated the so-called cascade model of tasks, in which the individual stages of work are carried out step by step. If you had to write software for a client, you first had to go through the tedious and time-consuming stages of determining all the client’s wishes, recognizing functional and technical requirements, writing architecture, implementation, tests, etc. It all took months or years, depending on the scale of the challenge. During this rather long time, the customer’s requirements often changed, which meant the cancellation of a huge effort already made.
Handling procedures and inertia that make changes difficult, long time to complete tasks, high costs of errors, and a high probability that we will eventually deliver a product that is no longer needed – all this does not look like a recipe for success.
Fortunately, someone has been through all of this before. And he found a solution. It was enough to use the inspiration skillfully.
As we have already noted, the cascade model is about pushing the project through the successive stages of implementation, step by step. Isn’t that like mounting tape? By all means, and probably not by accident, the precursor to the use of agile methodologies in production was the car manufacturer.
The revolution began at Toyota plants in the 1950s when new methods of work began to be introduced to increase efficiency and minimize the number of potential faults in cars that had just rolled off the line. Until now, each employee on the conveyor belt was responsible only for the performance of his task. In the new system, it ceased to be a mindless cog in a machine – it became an attentive observer as well as a decision-making unit. Even the most recent editor had the right to keep the tape if he deemed it necessary. In this way, faults were detected and eliminated before the car left the production hall. And although when introducing these changes, the theory developed by W. Edwards Deming was used, in fact, the main contribution of the American was to remind Toyota’s decision-makers about the wisdom of the old Japanese philosophy of kaizen, which proclaimed the need for continuous, patient improvement – also of what seemingly seems to be good enough.
If anyone at the Toyota factory had an idea of how a product or production process could be improved, he knew he would be listened to carefully, no matter how low they were in the business hierarchy. Therefore, the abbreviation TPS, which was used to describe the Toyota Production System implemented by Toyota, was sometimes read as the Thinking People System. Many other Japanese companies soon took over the Toyota system. With what effect – we know. The country has become a symbol of modern industry and high-quality products until recently.
Pizza and innovation
Skillful methodologies draw handfuls from these solutions. The rule is to check the product’s functionality at an early stage to catch incorrect design assumptions and common technical defects as soon as possible. Consulting new ideas with the client so as not to wander into dead ends. Constantly checking what else could be improved. Avoiding shoals resulting from hierarchical service relationships.
How do you do this for a large company that feels it might lose the race to small but flexible start-ups? By taking over their strengths. Jeff Bezos, Amazon’s boss, calls this strategy “2 pizza team” – because you have to create a special team, small enough to eat two pizzas. Such a group for special tasks gets a separate room ( open space is too distracting) to focus only on the assigned task. In the most comfortable conditions possible, without bothering with any corporate requirements – if they want to work in pink pajamas and flip-flops, because it is more comfortable for them, and play “Tomb Raider” on the console during the breaks, they have the right to do so. A designated group manager is responsible for all organizational matters, settling details with the client, etc.
The ability to quickly take turns when necessary and constantly improve is a huge advantage of the agile model.
Such a small, well-coordinated, focused team can develop a working version of the ordered software in just a month, functional enough for the client to give an opinion on whether it is a good direction and what should be changed. The ability to quickly take turns when it turns out to be necessary and constantly improve is a huge advantage of the agile model over the waterfall model. Thus, a large tanker gains the speed and maneuverability of a small speeder. In other words, without losing any of its traditional strengths, a large company becomes as responsive and fast as a start-up.
Agility beyond the software
Skillful methodologies cover more than software development processes. They also apply to the operational part. In an ideal, advanced model, programmers write code and send it to one repository (advantages: it is in one place, safe, easy to track changes). And the rest happens automatically – many scripts download the code, build a program from it, the functionality of which is checked in various tests, without human participation and supervision, and at the very end, in the best-developed companies, it also automatically goes to production. This is the case at Amazon, for example, but few companies can yet afford a similar level of sophistication. Man is still usually included in the control system.
The DevOps idea is also steeped in the spirit of agile methodologies. In one team, the idea to reconcile a dog with a cat, that is, to bring together software authors and operational engineers, such as system administrators, turned out to be perfect. On a daily basis, those who want to introduce changes to the software as quickly as possible are in a natural conflict with those whose duty is to ensure stability, failure-free operation, and the greatest possible availability of the system. Collaboration teaches mutual respect and understanding and helps to carry out changes more smoothly and with a smaller margin of high risk. In the DevOps system, many smaller, controlled errors are made deliberately to catch any weaknesses in the system and improve them, thus preventing hypothetical critical failures.
Agile methodologies bring many different benefits, but above all, they allow you to remain competitive. Sticking to the old methodologies does not ensure this. It is simply a requirement of digital transformation – a company must be competitive to stay in business. The most agile will survive.