It seems like agile has become a signal in software development, particularly Scrum. Everyone feels the need to say that they’re up on how “things are done,” and being allegedly “agile” seems to be how they’ve decided to show it. From an executive perspective, to remain competitive in the hiring market, you must be “agile.” And indeed, the teams may be working in sprints and doing all of the prescribed activities, but they aren’t actual building software any differently than they were before they called themselves an “agile” organization.
I don’t mean here that an organization has truly implemented waterscrumfall where you have an agile cycle in the middle of a waterfall process, which I’ve never seen in person. Instead, you’ve taken how you worked before and rephrased everything in agile terminology without embracing agile theory. You don’t have releasable software at the end of an iteration; you still have a two-year roadmap where dates are promises inside and outside of the organization. You are still producing reams of documentation about software that may never exist. For every principle on the agile manifesto there are a myriad of ways that principle can be half-assed.
Scrum has a bad reputation in relation to half-assed implementations. I think part of it is the ubiquity of scrum offerings and commercially-available training where the sales pitch overpromises the results. Scrum is more accessible since, at first glance, it can just be interpreted as doing the same things you are doing now, just in smaller pieces. If the scrum implementation isn’t achieving it shows up in the retrospective. The team identifies their impediments but if they can’t deal with them it becomes an exercise in futility. If the organization doesn’t want to help resolve the impediments then the team’s morale can easily collapse.
Among the twelve principles of agile, I think there is one in particular that, if you follow it, best represents doing the right things (and can’t be half-assed cheaply). I think that the principle “Business people and developers must work together daily throughout the project” is the definitive signal of being truly agile in spirit. The daily interaction is a specific measurable objective that can be monitored.
From the developer’s point of view, this gets you answers to questions when you need to clarify intent. This helps the developers to understand why the product should be doing something and produce additional insights into what the product could do. This insight can be invaluable to the business people since it produces ideas of how the software can better meet objectives through solutions that are not apparent to those looking at the problem from the outside. Even this benefit can be dwarfed from the morale benefit of everyone trusting everyone else to do their best.
Without the organization being wholly aligned in embracing agile theory, the business stakeholders would never have the incentive to put in the time investment to provide this level of involvement. The business stakeholders wouldn’t be inclined to put that sort of investment into the process practice if they don’t see the value. If they see the value of this one principle, they will hopefully understand the rest of the intertwined processes of the agile manifesto.
The signal that the strong businessperson-developer interaction sends is that the whole of agile practices are valued. Compare that to the signal of someone stating “we’re agile,” which just indicates that the speaker thinks you want to hear them say that. Usually those that say those things are doing some agile things, but the difference between a half-assed agile implementation and a true one is the difference between night and day when you are working in it. By looking for the strong signal that the business stakeholder involvement represents, hopefully you can find those that are truly agile and weed out those who are just posing. It is true here that actions signal louder than words.