The Problem with Being Agile, is Not Being Agile
In a team or organization, wishing to adopt Agile for the wrong reasons becomes a problem. Born out of a mistaken idea, it is highly likely that those involved in the project do not truly understand what Agile is, and the advantages that would come from adopting it correctly. Furthermore, it's likely that the team or organization may not have a clear idea of how to achieve agility.
“Management is doing things right. Leadership is doing the right thing.”
Peter Drucker
According to the 15th State of Agile Report (2021), the most pressing reasons for organizations to adopt Agile are speed and flexibility. These are not necessarily misguided reasons, but given the urgency, they may fall into the temptation of prioritizing haste over quality of the solution or development team.
Let's remember the four values stated in the Agile Manifesto, in which we recognize the merit of what is found on the right side of each value, but give more importance to what we find on the left:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
These values, like the twelve principles of the same manifesto, should be clear to the entire Agile software development team and put into practice daily. This will help maintain the simplicity and lightness that characterize Agile.
This manifesto is an abstract way of viewing Agile, and it offers great support in determining whether we are doing it right. However, we will come across questions like, "How do we ensure that the software is working correctly?", "How do we accept changes in requirements?", "How will we negotiate with the client to meet their needs?" These, in my opinion, must be answered by analyzing each case. However, existing Agile methodologies, like Extreme Programming (XP), can help answer these questions.
“Even though scriptures deceive people about the true nature of reality, they may nevertheless retain their authority for thousands of years.”
Yuval Noah Harari
These Agile methodologies, and many others, have emerged within what we might consider an Agile boom. As Robert Martin (2020) puts it, they may truly be Agile but with added elements. These additional elements can complicate their understanding and implementation or might lead teams to become something similar to Agile.
For instance, Scrum is an Agile framework that has evolved over time, largely adopting practices from XP. Today, the Scrum Master's role is to help the team correctly implement the framework, that is, to coach the team. It is common to find situations where the Scrum Master assumes the role of project director, a role quite different from that of a coach. This may be due to the Scrum Master's lack of knowledge and experience.
Currently, the Scrum Master certification is offered by various companies virtually. The certification program typically includes a wealth of information to understand Scrum. However, it usually lasts for a week at most. After this, the student would be in a position to take the theoretical exam. If they pass this exam, they would hypothetically be prepared to take on the role of Scrum Master.
“If you are going to win in the digital age, being a better business partner and collaborator with your technology team is critical.”
John Rossman
The reality is that a Scrum Master requires skills beyond just knowing the Scrum framework. For example, they need to develop servant leadership skills, such as the ability to influence others to successfully manage change within the team for the implementation and maintenance of the Scrum framework. They must develop expertise to convince company executives to allow the proper implementation of an Agile methodology, and to provide the necessary trust and freedom for this. These skills, among others, take much more than a week of study to develop. I would even dare to say, they require a lot of experience.
Companies, or their executives, often believe that the only person who needs to be trained in the Agile methodology is the coach. The truth is that the entire team should be trained, as all its members should have this knowledge to facilitate the implementation of Agile practices, and the compliance with Agile principles and values.
For example, it is common for company executives or project clients to feel the need for «contractual dates» where deliveries with a defined scope and cost will be made. Sometimes these milestones in Agile are disguised as a Release Planning, but the reality is that software projects are different from other types of projects. As Robert Martin points out, the team should have the ability and capacity to re-estimate these deliveries over time, meaning, the scope, cost, and date of these deliveries shouldn't be set in stone. Agile invites the team to identify changes on the estimates made for the Release Planning early and have the courage to inform about changes on the initial estimate promptly. This will provide valuable information to the client and executives, enabling them to make more timely decisions. It will also allow both the client and the team to arrive at a more honest and grounded estimate, where the scope can be reduced to deliver certain features of the software that would provide the minimum necessary value for a delivery, and leave other features for future releases. These priorities should be identified and defined between the software development team and the client.
Allowing the flexibility to adapt to changes (both in requirements and in scope) will help to get the most value out of Agile. However, the product's quality should not be negotiable.
Agile teams are known for learning from experience, and this helps to maintain a sustainable pace of work through iterations, as mentioned in XP. However, situations where the source code is not clean will slow down the team, as system maintenance will become increasingly complicated.
“I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.”
Bill Gates
According to Kent Beck (1999), Agile development is for small or medium-sized software development teams to handle unclear or constantly changing requirements, thus reducing the gap between business and development. For larger problems where more substantial software solutions are needed, and projects that need to address many features at once, multiple small teams can be considered, integrating into the management of a large company. For instance, frameworks like LeSS or Scrum of Scrums document a series of tools and practices to manage these more complex scenarios. Therefore, they are more difficult to implement and follow, and they are not just Agile, but Agile with added elements. It's recommended to avoid complicating the methodology as this will allow problems to be solved more easily.
There are many other problems that teams seeking Agile face. In this article, I tried to highlight the ones that, in my opinion, are most common. It's important to maintain simplicity and ease when adopting Agile, taking actions based on information from each iteration, without neglecting professionalism, values, and principles. An Agile coach will be very useful in this process, remembering that the entire team should be able to understand the practices that are adopted.
And you, what problems have you encountered when implementing Agile methodologies?