I was talking to a couple of colleagues yesterday, and we all had similar observations about organizations that consider themselves Agile. Many years ago when asked if they do Agile software development, I’d hear responses like “uh, what’s that?”. Nowadays the response seems to be, “oh yes, we’re very agile” or some variation of that.
From my experience, and from talking to other coaches and ‘Agile people’, we generally find that what these organizations are doing is iterative, not Agile. More often than not I see organizations using Scrum, doing standups, 2 week sprints, demos and retrospectives but don’t behave differently than before they moved to Scrum. Sometimes management hears that their teams are Agile but don’t see much (or any) difference in outcomes.
How do you know if you’re iterative or Agile? Here’s some things to consider and some outcomes that may help you figure it out.
Keep in mind when I say “Iterative Teams” I am talking about teams who are “Agile in name only”. Iterative development has been around for decades, these observations are based on my experiences with teams that call themselves Agile but don’t seem to get any benefit from using Agile practices.
Iterative Teams:
- Can experience testers being crammed at the end of the sprint because there is more clear and stricter enforcement of role-separation between programmers and testers. This can also be called “mini-waterfall”. Agile teams will experience this as well except the programmers will understand why it’s a good idea to help the testers and they’ll work at it to improve.
- Point blame when problems arise and say things like: “well, that’s what the PO wanted” or “Joe didn’t finish his story so we couldn’t do a demo” IMO, this is a symptom of an iterative team that has the same organizational hierarchy and structure from their pre-“Agile” days.
- Tend to not deal with un-certainty as well as Agile teams. You’ll hear things like “we need 2 weeks of research for this” instead of doing minimal planning and a skunk-works hack to learn more information about what’s involved with an un-known task or story
- Say the word “scope-creep” while Agile teams understand the sprint is supposed to start with an un-finished spec and accept changes because they understand that customers don’t know what they want until they see working software
- Say things like “the process is ….” while Agile teams understand a process is a guideline and software development isn’t like making toasters, which is to say it’s not a repeatable and linear process
- Are less likely to experiment with new techniques and practices because Agile may be seen more as a process thing whereas Agile teams will understand that building a learning culture yields great benefits.
- Find problems much later than Agile teams because of the mini-waterfall approach
- Have “hardening” sprints and struggle with the definition of done whereas Agile teams may have a hardening sprint in some occasions but they’ll understand that there is an underlying problem which is driving the need to have hardening sprints.
- Have recurring problems and bugs which leads to constant rework and possible thrashing compared to Agile teams who, upon finding a bug, will start with tests to catch it so it doesn’t come back later.
- Have a less sustainable pace compared to Agile teams.
- Can come up with retrospective improvements like “learn how to estimate better” or “plan better next time” with nothing tangible to do anything about it whereas Agile teams will go to meetups and read books to learn new techniques to experiment with to help solve those problems. Agile teams will also understand there’s a deeper problem when this happens.
Is one better than the other? I could say something fluffy like, well it depends on your context, but I won’t do that. I’ve worked with Agile and iterative teams and the Agile teams I’ve worked with trump the iterative teams without a doubt. The reasons are that Agile teams are open and transparent about the work they doing, challenges they have and they take responsibility when they mess something up. And all teams mess up on occasion. Agile teams have people who get actively involved in the Agile community by going to conferences and meetups on their own time, many of which pay for themselves. Agile teams also understand that they are serving the customer, like talking to customers and are passionate about delivering great software.
Iterative teams like to blame “outside forces” for their problems, try to fix problems with more process, aren’t visible about their work and for whatever reason don’t see the value in building a learning culture. I find that teams that fall into my “iterative team” description use Agile as a crutch because it sounds good.
So what can you do to make the jump from iterative to Agile? That’s the million dollar question. If you are passionate about being Agile but don’t feel your team is really getting what Agile is, you have options. Find 1 person who seems to share your passion and work on showing the rest of team that things can be better by doing lunch and learns or working on side projects using different techniques you want to try at work. Another option is to give up and find a better job with a team that shares your passion. Another option is to latch on to a business person who isn’t happy with the teams outcome and work with them to come up with an improvement plan, whether that be hiring a coach or dialling back the work to give the team more slack to learn.
There are always options. Some of those might work, some of those might not and the point is teams become great Agile teams by challenging the status quo and by not accepting things because of the way they are.