Napoleon and the Scaled Agile Framework
By Ostap Soroka
IT businesses going through a digital transformation face challenges, including integrating legacy systems and services with newly-build digital products. Agile, DevOps, and product development approaches became a de-facto standard across the industry. Traditional IT management frameworks are under criticism for being bureaucratic, slow, and process-oriented. This whitepaper provides a best practice guide for IT managers on dealing with a range of issues, from traditional IT management frameworks to agile software development.
The Agile movement started 20 years ago and has steadily gained popularity ever since. Of course, in the high-paced world of technology, 20 years is an admirable span. Yet, despite that, the seemingly ancient Agile methodology is being applied on a bigger and bigger scale in digital enterprises across industries. In addition, there are multiple historical cases where innovative engineering teams successfully used the same management principles. The most vivid example is Skunk Works and related 14 principles, dating back to the 1940s, partially overlapping with Agile.
This paper aims to find a historical analogy to the Scaled Agile Framework – a methodology based on Agile but applied on a broader scale. The historical analogy can be found at the beginning of the 19th century in post-revolutionary France. The turmoil and innovations triggered back then shaped Europe for the coming century – similar to how digital is now transforming industries for coming decades.
NAPOLEON – THE GREAT INNOVATOR
More than 200 years ago, France was ruled by Napoleon Bonaparte, an influential political and military leader. Napoleonic reforms were huge innovations for the 19th century and laid a foundation for our modern world. Napoleon’s military reforms were equally influential and redefined warfare for the coming century.
As with any military conflict, Napoleonic wars were mayhem and led to the suffering and death of countless innocent individuals. Without glorifying the wars of Napoleon, we aim to get some practical wisdom from the Napoleonic army (Grande Armée) and apply it to challenges of Agile product development.
LESSON #1: THE MOTIVATED INDIVIDUAL
The post-revolutionary French Grande Armée was successful in multiple battles. Part of the success of the Grande Armée was due to the character of its soldiers and officers. The French Revolution broke the longstanding social class system and opened military service to all social classes. It was a merit-based organization with great pride in the French Republic and its principles. The Grande Armée differed from other armies, which often consisted of unmotivated individuals, lacking shared vision and goals.
Jacques Antoine Hippolyte, Comte de Guibert, an 18th-century influential military thinker, proposed citizen armies in 1770. He predicted a national army would easily defeat a mercenary army and advocated for permanent divisions with high mobility capabilities. Napoléon studied Comte de Guibert’s work and applied the same principles to the Grande Armée by paying particular attention to the troop’s morale and welfare. As a result, army regiments were not dismissed after campaigns, and regiment group identity was welcomed (this practice lives in many of the world’s armed forces today).
More than 200 years later, motivated and productive people still are prerequisites for success, especially in a highly competitive digital industry. Historically, the software industry had a mixed reputation in regards to employee motivation and engagement. This was reflected in popular cultures such as the Dilbert comics and the Hollywood movie Office Space. Industry corrected itself and came up with the Scrum methodology. There are clear analogies between principles advocated in Agile and principles of the Grande Armée. Agile methodology advocates for self-motivated, cross-functional, and customer-focused team members. Agile also emphasizes the necessity of having a permanent, long-term team. This collides with the idea of employing specialized professionals and temporary project-based teams, which prevailed in the software industry before 1990. The presence of group bonding, mutual trust, unity, and cohesion remains crucial in today’s digital economy.
LESSON #2: THE CROSS-FUNCTIONAL AUTONOMOUS TEAM
The basis of the Grande Armée organization was the army corps—a combination of infantry, artillery, and a brigade of cavalry, plus detachments of engineers. The army corps was an autonomous, independent, and self-sufficient fighting detachment because it could operate at a distance from other units and with little supervision from headquarters. On the other hand, the Grande Armée was not a functional organization—there was no “Chief Artillery Marshal” supervising artillery units.
In software development, cross-functional teams were introduced by the Scrum methodology and re-emphasized later by the DevOps movement. Despite industry adoption and scientifically recognized benefits, not all enterprises adopted this approach—especially product development teams. Similar to the Grande Armée’s ideas, the Scaled Agile Framework emphasizes the avoidance of functional offices. Requiring team members with programming skills to report to the development manager and QA-skilled team members reporting to a QA manager fails to create great teams. Conflicting loyalties are undesirable both in military organizations and in a digital product company.
The idea behind the corps system was to create an organization that could function autonomously. Every individual corps was a self-contained army, led by a marshal and staff corps, including military elements, internal command, and control networks. While independent, each army corps commander knew the overall strategic plan and current commander’s intent and acted aligned with those plans. Marshal was required to operate following the strategic plan, but at the same time, this person was free to decide how to best prepare for an upcoming engagement.
The same principle can be found in Agile Manifesto principles:
“The best architectures, requirements, and designs emerge from self-organizing teams.”
IT professionals adopt the same approach in SAFe teams–largely autonomous, driven by outcomes, not outputs. Overall direction for product development effort is derived from a business’ mission and vision. Priorities for the development of new features are customer-driven. Daily decision-making is pushed down from higher levels of the business down to team level, alongside responsibility for outcomes.
LESSON #3: TEAM COORDINATION AND CADENCE
The next innovation of the Grande Armée was the ability to coordinate movements and concentrate forces in decisive moments of the battle. Despite having capabilities to act autonomously, all army corps were in constant communication with headquarters. Every army corp staff in the days of active troop movements would produce a daily report and deliver it back to the general staff. After disseminating and analyzing incoming messages, headquarters would issue marching orders to individual corps for the upcoming day. The unique capability of the Grande Armée was to “march divided, fight united.” Thus, the French coordinated movements of army corps across vast distances and were able to confuse and out-maneuver other armies.
A team of teams is a widely used term to describe the collaboration between independent and autonomous groups working towards a common goal. So naturally, there is a need to coordinate the efforts of multiple teams regularly (cadence).
Agile Release Trains and cadence synchronization is a direct analogy of the same principle. Teams are challenged by technical uncertainties independently (“march divided”), yet the continuous integration principle ensures the system is iterating as a whole (“fight united”).
Ironically, failure to coordinate the efforts of multiple teams (army corps) was one of the reasons for the defeat at Waterloo—while the French had troubles with directing movements, adversaries beat them at their own game.
LESSON #4: THE IMPORTANCE OF A PRODUCT OWNER
Stakes were high for Napoléon—the fate of the French Republic depended on the military successes of the Grande Armée. Napoléon carried a packet of poison with him and was willing to commit suicide to avoid being captured. From a military standpoint, Napoléon acted as his own operations officer. He required no advice from his generals and carried ultimate responsibility for his decisions.
If we look at software development, the SAFe methodology embraces a product owner role. Emphasis is put on the fact that this is a single person, with the primary function of managing the product backlog and ensuring the value of work that the Agile team performs. A good product owner combines contradictory traits of a doer, a visionary leader, and a team player at the same time.
Organizations have difficulty finding people with sufficient breadth and depth of experience and skills to fill a product owner’s role. A common mistake is to substitute a single product owner with a committee of multiple people without anyone in charge. As a result, the committee is often lost in long meetings, usually consisting of company politics and conflicts.
Napoléon was an eminently qualified company-wide business owner because he transformed post-revolutionary France into a unified country with a stable economy and a world-class army. While commanding his troops, he acted as the product manager of a military campaign. During the Napoléonic wars, his adversaries were coalitions of monarchies that often lacked unity of command. As a supreme commander (a product manager), Napoléon was able to react quickly to tactical situations. At the same time, his enemies were busy negotiating amongst themselves in the same manner as product owners committees often do in software development.
LESSON #5: THE RELEASE TRAIN ENGINEER AND THE GENERAL STAFF
Another critical element of the Grande Armée organization was the general staff. It would serve as the backbone of a command and control network. It was led by Marshal Berthier and included many knowledgeable officers who provided all types of information necessary for military planning. For example, Berthier’s aides provided information on types of roads, layouts of towns, and the quality of equipment carried by enemy units. The chief of staff’s duties consisted of maintaining situation reports, dispatching orders, maintaining an army’s war diary and maps, keeping registers, and conducting inspections.
In the day, the general staff was to acquire, analyze, de-conflict, and internally disseminate incoming information before conducting actions. In the SAFe framework, the functions of available staff do not have a direct equivalent. Some of the functions are in System Architect/Engineering, Release Train Engineer roles, and the System Team. Other functions are replaced by the practice of Scrum of Scrums or Product Owner Sync. The function of disseminating and analyzing information is scattered around all SAFe practices.
Contrary to Napoleonic times, the continuous learning principle encourages learning at all levels, not only at the higher level of the general staff.
Digital enterprise requires new organizational design, and companies face challenges to embrace new ways of working. Digital value delivery demands a paradigm shift, from project-based, top-to-bottom designed, batch-based value delivery to continuous, bottom-up, emergent products.
A subtle balance should be maintained between agile development methods, traditional activities from enterprise architecture domains, and software architecture. There is no single recipe or practice universally applicable to all businesses, as every business context is different. At SoftServe, we are running multiple successful product development initiatives using the SAFe methodology. Still, any methodology will fail if a business lacks its most valuable capital—human capital. Napoléon believed the secret to success in military campaigns was 75% “esprit de corps,” and a mere 25% was devoted to the number of troops and equipment quality. 200 years after the Grande Armée, the Agile Manifesto stated the following principle:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Regardless of what your business is doing, motivated individuals are a prerequisite to succeed in the neverending campaign of a modern economy.
SoftServe has longstanding experience building cross-functional agile teams. We co-create innovation via the services of product management, product development, and multiple Scrum team coordination. Our pragmatic marketing approach is practiced alongside a multi-stage discovery phase to develop new digital products. SoftServe facilitates transformations from the traditional IT enterprise to high-performing IT businesses that support a new way of working.