Are you Agile enough? You’re Doing it Wrong
One thing that I’ve found leads to failed adoption of good methods and methodologies is the rigidity of defining when you are actually successful in that system. Let’s use a couple of examples…
You could use many different versions of the meme:
- Are you DevOps enough?
- Are you Agile enough?
- Are you Keto enough?
I use the capitalized phrasing because these methodologies have the tendency to also get a nearly religious connotation (as in Big G God versus little g god). It’s why I coach people towards defining what exactly they hope to get out of adoption a methodology so they can set their expectations on which milestones and successes they achieve or need to keep working towards.
These questions really are memes because you could easily see how hilarious they are if you separate from the hardline need to adopt or die.
Beware the Dogmatism of Methodologies
Don’t get wrapped around the axle with how far you’ve gotten into the formal program of whatever practice you are looking to adopt. This is important so that you don’t end up in an arms race of measuring who is “more agile” or “more DevOps” than another team, business unit, or company.
I say this from experience as I’ve talked to many people inside organizations who actually find themselves competing with each other over who is more “all-in” on some project management or development framework. They end up fighting more to hit all the framework targets but lose sight of the fact that they aren’t actually hitting business targets.
That’s the actual point of nearly every methodology: move faster, safely. Get from idea to business outcome using a method that reduces waste and increases flow or output. When I had one team lead tell me they were “more Agile” than another business unit, I realized that there was a disconnect in how they defined success.
The team at Basecamp (formerly 37Signals) shared their methodology in a book called ShapeUp which really highlights how the anti-pattern of Agile may actually be the best pattern…but that works for them, maybe not you. Irony is when you go counter culture and it becomes the culture.
Define Success for You and Your Team
What is the goal of adoption a Agile or Scrum or whatever methodology du jour you have on your mind? I say it that way for a reason. If we thought that the current methodology is the “iPhone killer” of methodologies then why do we keep iterating on them?
We can pretty much all agree that waterfall for software development is not ideal. That’s how RAD (Rapid Application Development) and other iterative frameworks came to popularity and eventually went by the wayside as they themselves were iterated on. Just naming the methodology something new doesn’t mean that the old method is wrong, but there were things learned and practices that were successful from past trials.
Your goals need to aim at things like:
- Better communication between customers and developers
- Ensuring we test features widely, early
- Map our plans to sales and customer campaigns
- Maintain competitive positioning and advantage
- Reduce wasted time and cost in our current software development practice
When you stop to evaluate why you do the thing you do, you realize the “why?” of it should always map to a bigger business outcome. That even applies to personal projects and how you do things day-to-day.
The Agile Diet Plan
Methodologies are like diets. The one that works for you is the one you should be using. If you need to adopt intermittent fasting but use a 10 hour window, that works. If you need to be Agile but can’t necessarily do the daily standups or a formal retrospective, maybe that is what works for you.
I like to use a framework buffet as a more appropriate way of working. I’ve got a website that I use certain methods to manage, a team at work who work a specific way and mix between Agile and mixed bag of other methods. There is a software platform I’m building and I use an Agile-ish approach but I don’t do estimates or standups, just stories and epics with asynchronous communication to make sure things are on track.
Whatever the buffet of features and methods you choose, it should be designed and chosen by the need to match the way your team works. Conway’s law states that “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure”.
In other words, you will build things in the way your team operates more than you will make your team operate the way you want products to be built. There are definitely bi-directional process improvements. You can adapt your team to the process and also adapt the process to your team. It should be that way.
In the end, when you think you are not successful because you are not “Agile enough”, just stop to evaluate what larger outcomes and improvements you’ve been able to get. You may actually be just as Agile as you need to be.