5 Things To Avoid if You Want to Be Agile

Where the hell did agile come from anyway?

In the 80s and 90s there was an "application development crisis." This just meant it took 3 years to build and ship a piece of software (longer for some industries). Three years. Can you imagine!? Three years! Within that 3-year span there was inevitably lots of change - architecture, systems, even the original business case. Companies had to find a way to build faster and accommodate for change.

Scrum was the first of the agile methodologies to emerge in the late 90s. Scrum was based on the idea that a team should be given an objective rather than specific assignments, and should self-organize to figure out how to solve for those objectives. Scrum also valued iteration; 'responding to change over following a plan' per the Agile Manifesto.


This is the original agile manifesto.

This is the original agile manifesto.


This was a good thing! Technologies and business needs routinely change, and more importantly, as we build software, we learn what works and what doesn't work, and uncover use cases that we hadn't thought of originally.

I think the misconception of agile being 'dead' has emerged because most companies get a few key elements wrong. I don't think the fundamental ideas of iteration, learning as you build, and accommodation for inevitable change are dead.

What are companies routinely doing that isn't agile? I have a few things I've accumulated over the past decade.

Here are five things many companies do that are very un-agile. 


1 - Sizing with S/M/L but equating each with a specific time period.

I'm not exactly sure why this irks me so, but I've seen many a company use Tshirt sizing because they think it's 'agile.' We have all seen this. Small = 1 month of work. Medium = 2 months. etc. SPOILER: Tshirt sizing is only agile if you use it the way it was intended - to make quick, relative estimates.

T-shirt sizing is meant to be relative sizing. This was part of agile methodology because during sprint planning the team needed a quick and dirty way to put user stories in relative buckets (so the team can see if user story A is a larger effort than B.) Now companies use Tshirt sizing for detailed roadmap planning, but it just doesn't make sense.

If you're going to use Tshirt sizes to equate to specific time periods, then just use the time quantities. Just say '1 month;' rather than 'Large.' There is no shame in this if you require specific estimates!

2 - Detailed planning 2+ years into the future

Product managers always want to think about what the future looks like and set a high-level North Star. You should be thinking about this. However, the obsession with detailed, long-term planning never ceases to confound me.

It's impossible to do detailed planning years (or sometimes even months) into the future. How do you know what the customer feedback will be in that usability testing you have scheduled for next month? How do you know what customers will ask for in January of 2022? What competitors will emerge next year - or even next month? What about architecture? How can you even develop a detailed plan with so many unknowns?

The whole point of agile is meant to accommodate change. Be comfortable with having a North Star, but not knowing the details until a self-organizing team figures them out. The time that you're making engineers sit in meetings to plan for 2023, asking for LOE for user stories planned to be built 2+ years from now, is time those same engineers could be building features - right now - that could bring value to your user base. 

Screen Shot 2018-08-22 at 3.01.47 PM.png

3 - Higher-ups being overly prescriptive about what to build

CPOs and VPs of Product are visionaries and evangelists who lead product vision and product strategy. They have their hands in product design and product marketing and keep everyone involved headed in the right direction.

When someone at this level is telling product teams exactly what to build - down to the user story level - they're probably being too prescriptive. Agile is about self-organizing teams, and self-organizing teams are given objectives. The team then self-organizes to solve for those objectives. 

4 - Engineering Drives with Solutions


Product teams must "fall in love with the problem, not the solution," as the old adage goes. And yet, sometimes, in the real world, engineering hands you a solution, and product is expected to seek out a problem. 

This definitely happens in companies large and small alike, but I can tell you from experience that the outcomes are rarely ideal. Product vision should be driven by what brings the most customer value. This is not to say engineering experimentation/ R&D isn't valuable. Of course it is. But the problem to solve should always been understood by all involved.


5 - Having Multiple Backlogs

A backlog is a prioritized list of user stories to build to make your product better. You only need one.

You should really only be planning the next sprint; everything else should be in one prioritized backlog. There is no "Priority backlog 1" and "Backlog for 2021" (see #2 above). There is one backlog representing everything you want to build for your product.

That said, I do keep a note/ confluence page where I log ideas/ features that we aren't quite ready to build yet but are thinking about. Although you should keep those 'long distance' ideas out of your backlog, but you can definitely keep them somewhere else.