You are currently viewing Things That Drive Me Bonkers About Agile

Things That Drive Me Bonkers About Agile

My friend Ed Hunt and I were having a conversation the other day and we talked about this: people either want to do projects in the software development life cycle (SDLC), or they want to go Agile to save money.

While SDLC is often perceived as old and slow, it’s at least a methodology. Agile isn’t as slow as other project management methodologies. It includes a lot of best practices, but misses a lot of key pieces more robust methodologies cover (as you’ll see below).

The concept of Agile is to take the best traits of good project managers and wrap them into a methodology that forces bad project managers to do best practices. It’s essentially a playbook that forces people who are shitty at project management to be better…but that’s not the best way to solve a problem. Shitty project managers need training, not just a methodology that tries to work around their weaknesses.

Agile was originally created to put the best project management practices into one playbook to get better engagement from your business lines when creating software and functionality. Most large enterprises now see it as a way to cut costs, but it usually ends up costing millions (and then more often than not, they scrap the program because it doesn’t work for the world we actually live in).

What’s Great About Agile

Agile forces businesses to break down what they’re trying to accomplish into component parts. I always say that computers are like the dumbest babies in the world, and it’s true. You have to tell them literally everything step-by-step in order to get it right. That’s fantastic if you lay out the process soup to nuts, but they don’t do well with grey areas. Business requirements must be broken down into component parts so there aren’t any holes or gaps in your solution, and Agile helps you do that.

The other thing I like from the SCRUM form of Agile is the daily standup, a 15-minute meeting where everyone on the project shares what they’re working on that day and any blocks to their progress so the project manager can unblock those things. That way, everyone is heard and the entire team understands the big picture. Teams like that tend to be better, more cohesive unions.

So those are two things Agile does a good job with. But it falls down in numerous places.

What Sucks About Agile

User stories are organized in an inefficient way that can lead to disjointed projects.

A business user needs the ability to see how many hours were worked on a project and filter by different criteria. In Agile, you also assign difficulty levels that determine how many points delivering that functionality will be. You do your work in two-week sprints, delivering functionality and doing a demo at the end of those two weeks. The idea is to show incremental projects and fail quickly if you’re not on the right track.

But the user points are really arbitrary and a lot of teams don’t do them well. In order to get the right amount of points, a team will sometimes do varying functionality which can make for disjointed demos. It doesn’t make sense to work on a bunch of different modules at once. You want to be able to tell a developer what you want, whether it takes 2 weeks or 3, and break those things in to logical chunks not point values willy-nilly.

When Agile is implemented at a large scale organization, they often do this part especially wrong. Because of the points process, tech teams can take projects in weird directions and the business line thinks they’re not getting any value from the work.

For example, technical teams at the Agile bank I worked with weren’t attached to any business lines and would rarely deliver anything of actual use to the business. As a project manager on the technical side who is very pro-business line, dealing with technical teams that couldn’t care less about what the business wants drives me up a tree.

There’s no point in building functionality if it’s not going to make the business better. That’s like going to Q for equipment for a stealthy mission where you need to go over lasers and lower down a rope, and Q gives you a jackhammer and a bazooka. It doesn’t make sense and it won’t help with that job.

The Four Agile Ceremonies and How Companies Get Them Wrong

The purpose of the four Agile ceremonies is to foster and facilitate team communication. Basically, they try to make sure you have meetings at the right times with the right players. Large enterprises often struggle with this (see the article I wrote on soul-crushing meetings), and if you’re really good at sticking to these ceremonies they can definitely help. But the problem is, it almost never plays out that way in real life.

Some will say that you can’t just add any of these ceremonies to a project. I say bullshit. I’ve done the hybrid model, taking the tenets I like from Agile and applying them to projects, and it works great because some things in Agile are just best practice for project management.

Sprint planning— Sprint planning is preparation before starting a two-week sprint. This is super important if you don’t have all of your business requirements done and prioritized into some sort of road map. This is part of where I see large enterprises fail — the product owner isn’t as engaged as they need to be because they’re busy, so there isn’t strategic planning behind what functionality needs to get done first. The tech team often ends up telling the product owner that these pieces of functionality the product owner wants are the right amount of points to finish in a two-week sprint, and the product owner usually okays it even if it doesn’t make strategic sense because they’re stretched too thin to make decisions like that. Then you just end up with disjointed demos and owner disenfranchisement.

The thing is, Q (the tech team) is never the owner of a mission. Q doesn’t make tactical decisions for James Bond (the product owner), James Bond tells Q the tactical piece and asks what he needs so he can do his best at the mission. With Agile, things often end up ass backwards with tech people deciding what the business needs and building a bazooka when James really needs a laser watch.

So rather than sprint planning, I like to call this one yet another meeting management won’t show up to.

Daily standup — This is the only ceremony I actually like! It’s a daily 15-minute meeting that happens literally standing up (and in a COVID world, happens over the phone). It’s a super helpful beginning-of-the-day meeting where you get to hear what your team is running into so you can get it out of the way, share priorities, and offer slight course corrections to help reprioritize people. These super efficient meetings are basically a football huddle where you clap, say break, and off you go. Everyone ends up on the same page.

In places I’ve worked, these ceremonies were the most adhered to and absolutely the most useful. Even when these places scrapped Agile, a lot of these teams still kept the daily standup because it was so helpful.

Sprint review — this is where the development team comes back together with the project manager and product owner to show them what they’ve done. Developers select a mishmash of things that fit the user stories points, and often the product owner is wondering okay, how does this help me at all? And that’s if they do a sprint review at all — I’ve been at companies where they don’t demo anything.

Which makes sense, since business line people have shit to do and don’t usually want to show up to look at willy-nilly incremental progress.

I call this the fucking shit show that may or may not even happen because no one shows up.

Sprint retrospective — In a perfect world, you would be getting together with everybody after the sprint review to figure out what went right and what went wrong. Then you can document and course correct for incremental progress and make adjustments going forward. But no one has time for this, and it just doesn’t happen. I call this the ceremony that never happens.

In a perfect world, many parts of Agile work great.

But you already know we don’t live in a perfect world. A lot of the changes that an organization needs to do to make Agile work are culture-based so you get the participation you need. It’s built into the fabric of the culture so people understand these ceremonies are important.

If there are tenets of Agile or lean you wish to instill in your management teams and culture (without all the bullshit), hit us up and we can help you implement them so your managers can lead effectively.