Agile is not about doing agile but about being agile
Agile is a mindset not so much a methodology
Is a firm applying fake agile or is it genuinely agile?
For firms as well as for consultants it’s highly important to know what “being agile” actually entails and what the most commonly encountered roadblocks are. Special attention is given to the as of yet unanswered question on how to agilize a firm.
The most basic form of fake agile, i.e. rebranding waterfall as being agile
Image source: Serious Scrum
Agile’s genesis is the 2001 “Manifesto for Agile Software Development” consisting of four values and twelve principles. Easier to understand and simpler to remember while at the same time more generally applicable, are the three laws of agile as defined by Steve Denning:
The law of the customer keeps the focus on who is served by the firm and who will actually bring in the money, i.e. the customer. If you think about it, this law is closely related to the “lean” mindset: everything that is unnecessary should not be done. Agile prescribes daily scrums. If most team members don’t benefit from it, the daily scrums can become weekly ones or can even be scrapped. Deliverables with no added value for customers, excessive documentation and inefficient meetings are the enemy.
The second law is very start-up-like. Small teams - composed of members with different skills and backgrounds - require less management (again lean), are more flexible by nature, can more easily work towards a goal (see first law) and facilitate intra- and intercommunication (see third law). Everyone knows everyone else in the team. Everyone knows what everyone else is doing and what the different skills of everyone are. Teams prioritise their work themselves. Helping each other is made easier for the benefit of all. Another important aspect of this law is that big tasks are split up in smaller more manageable ones. Complexity and thus risk is therefore reduced. Finally, this law infers that there’s quickly a Minimum Valuable Product (MVP) produced that is then incrementally improved and it’s the small teams that decide which increments are implemented when. The product keeps getting better and more complete. Once the MVP is produced, which is supposed to happen early on, actual value for the customer exists and increases together with the incremental improvements. Big teams, lack of team communication, long sprints, management imposed tasks are all signs of not being agile.
The last law concerns the network and requires the whole firm to participate. A firm where only one of the many departments, most of the time IT, is operating in an agile way is insufficient. All parts of the firm (e.g. marketing, product development, risk but also higher management) must be agile and must work together. Intercommunication between the teams is crucial. Rigid hierarchies and gateways between departments are thus to be banned. The saying “the whole is greater than the sum of its parts” definitely applies to the agile mindset.
Surprisingly, an indication that a firm is not agile is the agile terminology it uses. Agile is intrinsically flexible, it’s not possible nor recommended to apply agile to the letter. Each firm must invent and improve on its own agile way of operating that works best for that firm. Firms that appropriate the agile mindset often times adapt instead of adopt the agile terminology. For example, a product owner could be called a domain owner because it is in conflict with an already existing but different role. Be wary thus of firms claiming to be agile and that are using the agile vocabulary to the letter or more generally are applying agile to the letter.
For software projects often times detailed release notes are written. If these notes don’t bring value to the team members, to the customers or any other stakeholder … then why put the effort into making them so detailed? In such cases, often the only answer given is “it has always been done like that” which is not an acceptable reason.
More generally, and as said earlier, rigidity is a clear sign of not being agile. By questioning the purpose and value of everything that is done, employees can refocus their work on added value as per the first law. Firms should see such questioning as an opportunity to cut back on bureaucracy and procedures as a means to increase value.
When a firm becomes agile, three phases are identified. The first phase, consisting of introducing agile to a part of the firm, often works out well. Promising results are obtained. The firm cannot be considered agile yet but is instead only in an early stage. That’s normal and acceptable.
The following phase, when agile work methods are generalised throughout the company, is pivotal to success. What often happens, and must be resisted, is that the higher management is satisfied with the results, stops the progress and starts to bring in more structure and rigidity. This is exactly the opposite of what agile is supposed to be. Indeed, the ethos of management is control while agile is about letting go of control. Another possibility is that conflict arises between those that want to keep things as they are and those that see value in adopting the agile way of working. In any case, if this generalisation phase is not handled properly, the agile adventure of the firm is likely to be halted.
The last phase is about strengthening the gains: to continually improve the processes and work methods but also to continue to work on the mindset of the employees. This last phase never stops.
As an illustration, the graph below - from the same article as the three laws - shows the evolution of agile, with its three phases, at Microsoft.
The trillion dollar question with regards to agile is: how to scale it? Or rather: how to have the whole firm become agile? Most literature refers to frameworks such as the Scaled Agile Framework (SAFe) or Large Scale Scrum (LeSS) that shift the focus from bringing value to customers to structure and hierarchy which is the opposite of what agile is. These frameworks come with expensive training sessions and certifications that bring a certain quantifiable measure of progress fancied by management, i.e. the number of agile trained employees, but whose results are questionable. Some argue that instead of scaling agile one must instead descale the organisation. The meaning of descaling an organisation remains vague and as such it’s hard to understand how to apply it or if it’s even in the interest of the firm to apply it.
The difficulty to agilize a firm seems to be related to its size; the bigger the firm the more difficult it is. There are other blocking reasons that also come into play, such as: Old habits to reimpose structure, resistance to change, the difficulty to understand the agile mindset, the (technical, physical or personal) difficulties to interact between teams, not understanding what is valuable to customers and internal politics.
At the moment, no widely used method exists that can truly agilize a firm. The existing methods bring in too much structure or are too vague, they also are too detached from reality and its constraints. Scaling agile leans more to art than to science which could explain why fake agile is much more widespread than agile. The Leitmotiv for those involved should, again, be to question everything and to keep the three laws in mind.
The three laws listed above describe a mindset and not so much a method. The downside is that no clear succession of steps to achieve this mindset is or can be presented. On the other hand, this leaves room for firms to adapt their organisation and work methods as they best see fit. It’s hard to see how an organisation that follows the three laws could not efficiently deliver value to its customers. And in the end, that’s what truly matters … regardless of how one calls it or which methodology is used.
Written by Eric Boulet, Project Manager at TriFinance Financial Institutions and member of the Transformation and Project Management Practice.
For those interested in agile, FI’s Transformation and Project Management practice is, among other things, involved in better understanding agile and applying its knowledge on the subject at the client side. Its members use their experience in project management, business expertise and business transformation to successfully complete projects and to give support to other TriFinance consultants in their work.