I’m not an outpsoken guy. I don’t have any social media, other than YouTube or the occasional visit to LinkedIn. I never comment or post on YouTube, I just watch videos, and on LinkedIn I rarely comment. I guess that is to say that this is my only real outlet when it comes to all the chatter around Agile being dead. Which fine, lets say it was… THEN WHY ARE YOU STILL DOING IT!?

Sorry, I didn’t mean to yell. But come on. I go onto LinkedIn and all I see are posts about it. On YouTube the ever present algorithm knows what I like to watch, so I’m lambasted by videos about it. And so I ask myself… if Agile were dead, then how’s everyone delivering software? Did they all just up and decide to go back to a waterfall approach? LMFAO. I highly doubt that. There’s a reason that waterfall is limited to certain and or specific projects. No… more likely I expect that in it’s place, Agile has taken over.

Yep, you read that right. I’m guessing that what’s happening now is an industry wide recognition that there’s just too much “Agile” overhead in the form of guides and manuals and what nots, and not enough principles based engineering. Some of my first posts on this blog are about using the agile manifesto and ignoring Scrum and or Safe, and or all the other “guides” out there. Just follow the principles. And I think that’s actually what’s happening.

I don’t claim to be some Agile history guru, but if I recollect, the reason the agile manifesto was created in the first place was because some expereinced software people were tired of all the software project management overhead of the 80’s and 90’s and said… “There’s a better way to do this”. They got together and devised a document that, like it or not, has driven software development to where it is today. Yep, you read that right too. Most of the way you work today in software is in some way shape or form linked to that document. DevOps, CI/CD, Pair Programming, Mob Programming, Swarming, these are all related to principles based engineering and those principles are in the manifesto.

I’m not gonna lie, when I first started to learn about Agile, I was into Scrum. I dabbled. But even then I knew it wasn’t going to work. So we didn’t do it fully, we did some combination of it and Kanban. This was in 2013 (ish). I recall an auditor for a potential equity investor telling me that what we were doing then was called “ScrumBan”. I was like, ok, whatever. I called it “Better than Scrum”. I wasn’t some genius, I didn’t know the principles then like I do now (by memory), I just knew that if something isn’t working, don’t keep doing it.

I guess my point to all this is that I don’t think Agile is dead. I think the community of software people are just tired of the overhead. I think we’re coming to an inflection point where all that weight is being shed and what we’ll end up with is a new agile manifesto, or some derivative of it at least. It’ll probably be something like:

• If it doesn’t work, change it. If people don’t like change, change the people. This is a deal breaker. Teams need to be able to change and do new things till you find a path. It’ll work well for a while and then things will change again. Life is change, software making is change. And yes, this does mean you should have retros with your team, and no that doesn’t mean they need to be therapy sessions, make them practical.
• Deliver fast and frequently, do what you can to make sure it’s safe and doesn’t break too much. Keep in mind where you’re company is at in it’s maturity. No one will care if you got to 100% test coverage but you never found product market fit. Remember, you’re not constructing a concrete facility of some kind, you’re working with SOFTware. Concrete is concrete, software is not concrete. You can change it fast and easy.
• People working on less things at the same time, helping each other and collaborating is better than more people working on a lot of different things and then tryign to tie it all together later. Stay focused and limit work in progress.
• Don’t burn people out, people are people, give them space and time to live, but it’s also important that people recognize urgency and put in the extra time when it counts. Build sustainably and you’ll reap the benefits of keeping people and all their domain knowledge, and they’ll produce better results.
• You don’t need only the smartest software people on the planet on your team unless you’re building rockets. There are plenty of smart and talented software people out there that can fit on any team. Do your dilligence but don’t be an ass.
• The best way to know if something works is to put it into the hands of the people using it. Deliver these changes in small increments. Don’t spend time on a vision and then try to deliver on that vision without feedback. Ask people what they like and don’t like, survey them, collect user data. Do anything you can to understand what users do and don’t like about the changes your making. And again… MAKE SMALL CHANGES and deliver them frequently. If you aren’t making changes that make it to production or a production like system every day, you could probably be doing better.
• Stop estimating as a regular practice, it doesn’t work and won’t ever really work well. Of course your team can give some “guesstimates”. Your team can tell you how complex they think something might be. But the moment you make a commitment to that, you’re doomed to failure (at least at some very high percentage of the time). Instead, if you follow the item above this one, you’ll be in a better position to validate changes as you make them. And as your team gets better at making smaller and smaller changes, the future changes will become more predictable (there’s lots of tools for forecasting, learn em, don’t stress your team out with unrealistic deadlines).
• Trust the team you have, even if you don’t think it’s the best there could be. The chances are better than not that they’re are most certainly good enough to build whatever you need them to. And if not, they are what you have for now and not trusting them isn’t helping. If you have to, go ahead and provide some guard rails, but not a prison cell. And if the team needs too much guidance… you’re the problem not them, or at least, that’s your fault not theirs.

Yes, this is basically a derivative of the original manifesto, and to some degree a derivative of the DevOps principles which themselves were deratives of the agile manifesto. I don’t expect my off the cuff list above will become the next manifesto. Actually I don’t even think we really need one. I’m a purist when it comes to agile.

On my teams, I try to instill the agile manifesto and its principles in our environment and in the team so that those principles are how we operate. Yes, we have Kanban boards and tickets and process. These are just necessary elements of delivering software for some teams. We have flow metrics, and ticket counts and we sometimes provide guesses as to how long something might take. But as a manager, I manage leadership’s expectations more than I “manage” the team in some cases. I work to free the team up, give them space and time. In return they work with me to learn the principles and implement them, and that looks like the team making smaller and smaller changes, building tests and delivery pipelines, not overengineering things when less work is better. It’s a collaboration between all the members of the team, of which I’m just one. I see it as my job on the team to instill the right principles and then guide the team to find the practices that work best for that team and that follow those principles; I try not to impose any practice, though sometimes I have been known to impose, it’s a balance 🙂

Let’s be real. There’s no such thing as having no process. If you had no process, your process is having no process. And if you had no process, you’re probably a lone developer building your own projects. And even then, I bet you still have a process. No, I think when people say they hate agile or its dead or its dying, or that they are tired of all the “agile” overhead, what they mean is they’re tired of having systems imposed on them, and then having to try and work in that system, instead of having principles, and letting the system and processes form around those principles. And for each team those systems and processes might be a little different, but what won’t be are the principles.

Oh, but Andre, you’re not thinking about teams that need to scale. Is what everyone always says. Scale is just more people, your processes will have to change, but the principles don’t. If you stick to the agile principles and just let the teams form a system and process that include them, you’re going to find that all the so called rules set out in any number of different methodologies are all stupid. 2 pizza teams, 2 week sprints, scrum of scrums… who cares. Do you have a large team, so what if your delivering. Can you delivery daily, good, so why wait two weeks. Let all that shit go, focus on the principles and then see what comes out of it.

Is Agile dead, no. Maybe Scrum and Safe and whatever else is out there is, or will be. But no one’s going back to waterfall. I’d wager that if anyone did, we wouldn’t even know because they’d be out of business. They’d lose out to any competitors who are still agile. No, I think our industry is coming full circle back to the original principles, little by little, whether they know it or not. So, go on, keep writing catchy click baity articles about the death of agile… I expect I’ll still see those same article titles in 10 years.