On the surface, the recipe for agile in software development looks something like this: kanban boards, daily stand-ups, constant feedback loops, reports, collaborations, and team meetings.

The expected outcomes are frequent deliverables and movement forward.

However, over the years, I’ve realized that these things are merely productivity management tools. These tools are not compulsory and are more like guidelines to help you achieve the speed you want. I'm certain that I'm not the only one that's sat in team meetings and discussions – online and offline – where you were only there because the common literature around agile says so.

The recipe for agile is not throwing every technique available into a bowl, mixing it up, and expecting everything will turn out alright. For me, “agile” projects have not infrequently spawned wasted time traps, confused teams, unfinished products, and a boss hammering us for results. It wasn't fun. Then we'd end up going back to waterfall, which wasn't much better, either.

The wrong side of agile

From what we know, agile promises speed to a project. Speed can be defined by the number of features we can successfully push out into production, or ready for marketing's green light release schedule.

However, agile often falls apart. I've been in a few team projects that tried to implement agile. Here are five common missteps I've experienced in the system that led it to crumble under its own idea.

1. Too many features disguised as one feature

There was a project I worked on where the boss saw a full back-end portal as a single feature. We also had to build everything from scratch. Rather than getting the foundations of the app sorted first and then adding the non-crucial features in subsequent rounds, they wanted everything.

Then they kept adding more features, but saw it as a core part of the application.

The issue with this is that there is a mismatch between how agile delivers and what the expectations are. What happened here was that the boss was applying waterfall mentalities to a disguised agile methodology. Yes, we were doing stand-up meetings and had our kanban boards, but it didn't shield us from the monolithic approach in the app's delivery.

How did we solve this as a team?

It took a bit of negotiation with upper management to go for a prototyped approach. We discarded “agile” as a terminology because it was more distracting than useful for what we were trying to achieve with our processes. By replacing the word “agile” with “prototype,” we were able to change the expected deliverable size.

The project ended after the third cycle – after the boss saw that it didn't achieve the same impact that they wanted. If we had delivered in the manner that the boss originally required, it would have been the equivalent of 67 estimated sprints.

2. Lacking clarity

On one side, we can have too many features expected to be delivered. On the other side, when there are no clear features at all but we're required to “just start coding.” I've had this thrown at a project where no one knew exactly what they wanted. To non-developers, there is a view that coding takes up the most time. To them, they thought they were doing us a favor by giving us a head start.

Except that's not how code works.

Code is a translation of ideas. When the ideas are hazy, the code lacks purpose, and anything created can cost more time than it's supposed to save. It's like trying to build a house based on vague ideas and requirements. As developers, we can only fill in the blank so much.

For agile to work, you don't need to see every possible feature. What you do need is clarity and purpose for the particular thing you're supposed to work on. As a developer, when you don't have that, don't be afraid to insist on getting it before you so far as open your IDE.

3. Pivoting mid-feature

There was a time where we were shipping out our milestones towards a feature. However, the project was always in constant delays.

This was because of marketing and upper management pivoting mid-feature, resulting in the agile process restarting repeatedly without ever reaching the finish line.

I once had a marketing manager that requested one feature, then changed his mind. Then he changed his mind back several days later. And then again a week after that. Three months of the same thing happening repeatedly, and then upper management began questioning why the dev team had delivered nothing.

It's not too bad if we need to pivot mid-feature once in a while. It might be because the landscape has changed, consumers may be trending towards something else, or the decision was a competitive-based one. But to constantly change your mind about something and expecting a deliverable based on the original timeline is unrealistic.

When this happens, your team needs to make it clear what the implications and new timelines are. Too many pivots can turn into a bottleneck for project delivery. While the purpose of agile is the ability to respond to change, responding to change mid-sprint constantly is not how agile works.

4. Unfocused reporting

Some agile fallout problems are just communications-based. For most new teams, stand-ups often happen with your fellow team members standing around in a circle, reporting their daily progress.

At first, everyone seems enthusiastic, until it turns into a monotonous and compulsory thing. For me, these sessions can quickly turn into a pointless exercise of reading ticket updates. Stand-ups are good for keep tabs on progress – but only when done correctly.

What does this look like?

Focused reporting.

The best structure I've experienced is when bottlenecks are identified first rather than telling everyone what you did yesterday.

Why?

Because bottlenecks are the things that slow everyone down. They're the speed bumps that need early identification. Sometimes, it's announcing that you're the bottleneck and figuring out who you're going to affect.

You're going to move forward with all the coding you've done. But everything will come to a standstill once you hit a roadblock. It's this that needs to be identified first and solved before continuing on with what you've done to move the project forward.

5. The legacy structures are too heavy and fragile

I was on a project once where if you touched anything, the system would instantly break. It was also a stitched-up Frankenstein creature that merged GWT with Java and PHP with attempts at modernization through Angular with jQuery overriding everything in the most ad-hoc manner.

There's a reason developers love greenfield projects where there are no legacy conditions to hold us back. Every system ages, but not every code base ages gracefully.

The issue that agile and legacy systems face is that few businesses will let you rewrite the entire code base from scratch. Refactoring is a necessary part of ongoing maintenance and you can only ignore it for so long before it affects your code workflows.

New startups can move fast and come up with innovations because the software they've got supports an agile mentality. They're not struggling with old structures that support a different methodology towards working and thinking. The processes we used are often reflected in the code created. In waterfall methodologies, the code is often deeply coupled with each other because there's no expectation for change. Real agile creates code that is modular and easily interchangeable because it expects change.

Sometimes, it’s ok to talk tough with your team and org about whether your tech stack is right for agile.

So what does real agile look like?

Agile software development is an end-to-end process. It's more than just putting lines of code up as quickly as possible. There is no hard and fast rule about how to implement agile – only tools and how you use it. These tools often crop up in the form of daily meetings and kanban boards. However, these things mean little if they become more important than the act of moving the agile sprint forward.

The purpose of a sprint is to get from point A to point B in the shortest time possible. But you also need to be realistic with what these points are. There's no point sprinting when you know you're going to fail. Aim for what's achievable and communicate it upwards.

From what I’ve experienced, an agile business with agile software development is something that’s able to move with the constant changes in customer demands, expectations, and what the rest of the industry is doing. Correctly implemented agile results in software that works. It might not be perfect and it might not be the completed picture, but it's functional and has the ability to obtain customer feedback for the business to make its next move.

Developers are often the ones most caught in the thick of the agile way of delivering software. So as a dev, the more you understand what bad agile looks like, the better you can be at helping to ensuring that your team doesn’t end up on the wrong side of it.

‍