What’s next in Agile? Lessons learned over two decades

Have you ever thought of how we got where we are with Agile? What is the end goal and what is going to happen in the future of agility? Looking at trends is important to be able to respond to changes well informed and change our state from complex to complicated (Cynefin), hopefully. Agile is a pseudo science and does not follow one size fit all. Halo effect is the most epidemic issue in the Agile community these days and less experienced agilists do more harm in looking at agile as a science and try to convert frameworks to standardized methodologies. In this Article, I go over the trends around agile evolution from my point of view. Then discuss the current practice that I’ve seen working for several companies that has been useful, followed up with what I expect for the future of agility.

Historically, Agility was a part of Object Oriented for years. After the appearance of Agile development as an independent way of developing software and systems, many researchers and practitioners started to work on creating popular frameworks at the time on the basis of the new Agile prospective in Software Engineering. Studies on Agile development essentially started with the belief that the cumbersome and at times ceremonial documentations and artifacts of the traditional Structural and Object Oriented approaches could be considered over-engineering and overhead for the software development process. The argument was that Software teams do not generally follow the beneficial practices of Software Engineering, and, even if they do, they get entangled with the over-engineering aspects of the traditional approaches which could unnecessarily increase the effort needed for the project. 

 Agility requirements and specifications are changing as time passes and for new situations. However, the unchangeable property of Agile is the thirst for efficiency and eliminating waste 

Agile frameworks used to be adopted for small projects and used to help teams to work more efficiently. After several years since the introduction of agile, several studies have started to modify agile frameworks for medium to large projects as well. In surveys on adaptations of Agile methods for software projects, it was observed that different companies use different combinations of Agile practices. Typically, based on the size, nature, and complexity of a project, different Agile frameworks are modified, combined, or extended to be applicable for a specific project.

 During the last decade, companies started looking at Agile differently. Teams started to mature up and hit a wall as the outside factors were not ready to embrace teams’ agility. A lean principle that talks about looking at system as a whole kept being overlooked by many of the practitioners. Scrum of Scrum as was proposed since the first generation of Scrum was mostly found not to be effective by its own. Scaling frameworks started to emerge. SAFe, LeSS, Nexus, Spotify Model, etc. The idea was to support the Software teams in larger organizations. Once Agility reaches out of a software team, it is not just confined around interacting with other software teams. Scaling agility means it goes to any other team (software or not software) that affects the work that hit the software team at any point through the value-stream. And it took a while for even scaled frameworks to face it. Involving Product more into the agility journey was an effort to help supporting the software teams in most of the scaled frameworks.

 For the last couple of years, a new trend has been started. New editions of Disciplined Agile and SAFe, Scrum at Scale, and Flex are the result of the new needs the industry found over the last two Decades. Leads in the industry started to find out that the more they add to the Frameworks the more not Agile they become. However, there is a need for guidance in organizations as they go through their transformations. The fact that there are not enough transformation agile coaches to help and guide organizations to go through the transformation and that the transformation time and effort almost exponentially increases by the size of the org, made the transformation really hard and costly. Creating the guidance with recent changes in PMI org creating an Agile wing and using creators of two flexible Agile guidance, Disciplined Agile and Flex, is a move toward this direction. On the same line, business agility, as one of the hottest topics and the last trend in agile these days, is the next step in agility that organically was introduced as a solution for the problem I explained above. It is mostly includes agility in business intelligence, marketing, HR, and any other non-software part of organizations.

 As discussed above with these many frameworks, transformation is hard! It should be an Agile process itself and it requires real patience. Situational coaching is the key. Having a Center of Agile Excellence (CAE) which expertise is to situationally coach the organization toward becoming more Agile is almost a necessity in most of the larger organizations. The CAE observes and coaches either from the back of the room, getting embedded, pair programing with the teams, pair scrum mastering with scrum masters, pair coaching with Agile coaches, etc. The CAE could be as informal as community of practice for the Scrum Masters and cadences of meetings with agile evangelists in the company or as formal as a department of its own.

 Agility requirements and specifications are changing as time passes and for new situations. However, the unchangeable property of Agile is the thirst for efficiency and eliminating waste. The name might change and the manifesto might change but what is immutable is that efficiency matters and the attempt to gain it never ends. Lead Agile training and certification organization know that already and they have been coming up with new trainings based on the trends I discussed above. I expect it is not going to be long until a new version of Agile is introduced. It is going to be just another attempt try to reduce waste and well that is satisfactory enough.