Are you an Agile Decorator?
As you know, Agile is becoming more popular in organisations — it is an undeniable fact. Every year, more companies invest in large Agile initiatives; more players in the industry, more books, more conferences, and more people are being trained to act in different Agile roles. It’s good stuff, right? Well, think again.
Despite this wealthy Agile ecosystem, unfortunately, it’s rare to see companies doing and being Agile appropriately. Moreover, only a few will actually collect some real benefit from this type of endeavour. The problem is not about adopting framework X or Y in the right way. The biggest problem is because most of the practices do not create any type of benefit for the companies. They are only decorative practices.
The likely reason for this is because of a lack of understanding about the real problem we are trying to solve with these practices. It is like we are living in an age of a cargo cult regarding the Agile practices. Because of that, at the end of the day, most of the companies are left with a bunch of fluffy practices that have no real economic benefit to the organisation.
Based on my experience, the major characteristics of a decorative use of Agile are as follows:
No anticipated delivery of value to the customers — It is the main component of the Decorative Agile. Despite this enormous effort in adopting new practices and roles, seeing a continuous delivery of value to the customers is rare. Most of the companies are forgetting the first principle of the Agile Manifesto:
“Our highest priority is to satisfy the customer through an early and continuous delivery of valuable software”.
Trying to develop a fixed and large scope using iterations — This is the same old mistake again. Fixed and large scope was one of the biggest problems with waterfall/traditional approaches. Most of the organisations are still reluctant to give up this approach. For this reason, the companies adopt iterations/sprints as a way to execute a big project that is already “well planned” and “well analysed”. The teams are still using a Big Design Up Front (BDUF) approach in this type of project. In this case, the organisation is still experiencing a long waiting time caused by the analysis paralysis at the beginning of the project. Therefore, adopting Agile practices maybe is pointless in this type of situation.
Budget/Commercial models based on long-term projects to deliver a fixed scope — The biggest part of the first characteristic is created by the commercial model of the organisation. In this case, the company still funding long projects and still making detailed plans deliver a fixed scope.
Starting by putting too much attention on the tools — Electronic tools could be a useful element to support the management process (especially in large companies). However, it is common to see people saying, “I have to maintain this information on this tool because our Agile process dictates this sort of updating.” Staying compliant with the tool requirements is becoming a synonym for being agile in many organisations. It is especially dangerous at the beginning of a transformation journey to Agile. The companies have lots of waterfall habits. It is part of the current DNA of the companies. Given this legacy, the tools need to absorb the waterfall mindset/behaviour as well. As a consequence, the tool becomes a Frankenstein, with a strange combination of waterfall behaviour and agile terminology. In general, the saddest part is because it is a pseudo-agile way to address waterfall requests.
Starting by scaling agile — Frameworks for scale agile are the hottest topic nowadays. They are fancy, and they can help the executives and the managers be more involved in the transformations, etc. However, most of the time, those frameworks have the same problem as the tools. They can absorb the current organisational dysfunctions in the company. In this case, the organisation is still producing the same crap, but now with some fancy names and events.
The sticky-notes-on-the-wall effect — It is a classic situation where people are thinking “we’re agile” just because they are putting up some sticky notes. In this case, the sticky-notes on the wall are just a colourful version of a waterfall world.
Certifying everybody in the organisation as Scrum Master as the first step of the transformation — This common approach makes the training providers quite happy. The Scrum Master plays an important role in helping teams and organisations during the transformation journey. However, applying Scrum is not always the best initial solution toward an Agile state. Your company can be Agile without any flavour of Scrum. Another problem with this type of action is because of most of the time, the certificate is the only motivation for the participant to attend the course. There is not much real desire to learn a different way of work.
Daily Meeting used as a status report meeting — Take note of this: traditional managers fall in love with daily meetings. They love daily meetings because it is an excellent opportunity to be updated on every single aspect of the tasks performed by the team members. The daily meeting should be a short session to enable the team to synchronise and inspect the progress toward the goal. The content of this session must flow from the team to the team, not from the team to the ScrumMaster or to the Manager.
Waterfall behaviours in cross-functional teams — In this situation, even with a cross-functional composition inside the team, the people are still working in silos. In this case, the pieces of work are moved in large batches among the different roles in the team.
Too much focus on management reports — Reports can be a useful way to increase organisational awareness about some situation. It is possible to see countless ways to provide creative reports to answer management questions. I’ve seen many Agile practitioners creating really fancy and informative reports. However, most of the time, people are creating fancy “Agile” reports to answer the waterfall/traditional questions using some Agile jargon.
Extreme adoption of statistics for predicting the delivery of large batches — Nowadays, many people are using statistical approaches as a tool for answering questions regarding forecasting and predictability. It is good; we love numbers and data-driven stuff. Statistics may serve us as a way to learn about the past in order to improve the future. The main problem with this approach is that people, most of the time, are using this statistical approach as an attempt to solve questions related to the fixed scope and large batches. That is the major challenge. Even using some Agile practice, the organisations are still working on long-term projects and big scopes. In this case, the Agile practitioners are applying statistics (with clever calculations and simulations) to answer questions regarding when all the requirements will be done.
Conclusion: Add chocolate topping will not repair a disgusting cake
The items above are just simple examples of the decorative use of Agile. You can disagree with many of these characteristics, or you can add more items to this list above. To be honest, defining only one right way to do Agile is hard. Regardless of the set of common characteristics of the Decorative Agile, the gist of this idea is about the recognition that most of the organisations have in trying to make some external refurbishment, but the pillar and the core of the institutions are still the same. Maybe it is similar to trying to improve a disgusting cake adding chocolate topping.
The Decorative Agile maybe help you be a bit happy; Maybe help you look cool; Maybe help you to keep your job position, or Maybe help 3M to be richer as a consequence of selling more sticky notes. Maybe the Decorative Agile is part of the initial strategy of change. There is nothing wrong with that; you only need to be aware of this situation.
Agile is about how to enable the company to respond more quickly, with less risk, and more qualitatively for business opportunities. If you are not generating any of these elements, you are probably living in a Decorative Agile. Think about it.
