I’ve had many conversations about the failings of Agile and of the inability for enterprises to be agile. One fundamental difference comes down to trust. In fact, we don’t even need to invoke the standard Agile versus Waterfall argument. We only need to look at the process. Waterfall will always take the traditional route (as will blended Agile), but there are others ways to deliver agility without resorting to Agile.
Regarding the image above, traditional software product development products rely on a top-down approach to feeding solutions into a funnel to have them implemented in a step-and-fetch-it manner. Solutions are packaged with some context and deadlines.
Alternatively, as in Agile, teams are fed problems and context. The goal here is as much to achieve value as to implement a conceived solution. This is also the part of agility enterprises fail to capture.
As for the rest, once in the realm of the development team, there may arise other problems and solutions. In either case, this is business as usual. Life happens.
To illustrate the difference, imagine that you’ve got a subscription based product where customers deplete credits based on usage. The customers are asking for a way to visualise how many credits they have remaining before they need to add more credits.
In the traditional scenario, a product manager or owner will dictate to the team to show the remaining credits on a certain place on a certain page in a certain font, colour, and size. Full stop. The dev team will comply as traditional code monkeys do.
In a trusted scenario, the product owner will share the problem with the team. Whilst the team may arrive at the same solution as with the traditional approach, they may have other suggestions. Without pretending to be half as clever, they may suggest a different page or more pages. Perhaps it would go on a global element such as a master header so it’s always available. It may be suggested to be buried on an account page, or it may appear each time one logs in. Perhaps before a customer uses a function, they will be alerted to current credits, estimated usage, and estimated remaining.
When I use Dall-E for generative images, it informs me how many credits I have remaining after I submit a request. The problem I have is that different requests use different amounts of credit, so even if I know I have, say, 3 credits remaining, I don’t know if my next request will use 2 or 4. If I submit a request that uses 2 credits, it will be executed, and it will tell me that I have 1 credit left. If I submit a request that uses 4 credits, it will tell me that I don’t have enough credits and link me to a place where I can purchase more credits.
Black & White
This is not a black and white dichotomy. Even an Agile approach might involve some strong solution guidance. Perhaps the product is limited in the degrees of freedom available, so the options are few.
You might already be working mental models and think of how the Agile model might fare in your organisation or on a certain team. As I’ve mentioned before, it could be that your A-Team can be trusted for turning problems into solutions; your B-Team can be trusted with some hand-holding; your C- and D-Teams are going to take what they’ve been given and be thankful. It could also be that your A-Team can only sometimes be trusted, but perhaps they have a seat at the table, so at least the input solution will have had some technical sanity applied to it. This is still not agile because who knows how much will change between the ask and the implementation?
In the end, I am taking the position that most companies are on the traditional left side of the spectrum. I’d even be willing to defend that very few companies even get to the midway point. I’d guess the distribution would look similar to the Chi-square curve above, which is to say heavily weighted toward the team implementing solutions over solving problems.