You might find yourself working on a dev team of like-minded people who take software very seriously, and truly feel that every aspect of the code – from the way it looks, to test coverage, to feature sets – reflect who they are as people. They’re proud of what they do, so they refuse to fail, and refuse to let problems or hurdles get in their way. These are usually the people who out-perform others, go on to get great reviews, and eventually get those early promotions.
To their credit, they might be (and the few that I work with are) some of the hardest-working people you’ll ever meet. Their determination to deliver quality products on time and exceed client expectations is something to be lauded. Their willingness to push themselves and their team to deliver amazing work takes a fearlessness that doesn’t go unnoticed. And as much as their peers might see them putting in extra effort, it very well may be only a fraction of the total extra effort they put in when no one is around.
Enter the Problem
A determination to succeed may sometimes translate to a fear of failure. And in Agile, the goal is always to fail early, fail often when failure is necessary; the hope being that when a team fails, they pivot their processes as needed and keep going.
What happens when a team doesn’t fail? Is there ever a major road-block that forced the entire team to stop, look around, and find that point where things start to go downhill? Is anyone asking, “Hey, should we really be doing this right now?”, or is the sentiment to just keep sprinting and prove awesomeness?
Without that failure, the team falls back to the sprint retro to set todos that are meant to help improve the process going forward. A safe and constructive meeting, the retro’s purpose is to raise concerns, express doubts, point out successes, and think of ways to improve processes going forward.
So the question then becomes, whose responsibility is it to take those points gleaned from the retro and apply them to processes mid-sprint? If it’s not the person in charge, does that person have the authority to get in the way of what people are doing, in an effort to rein them in and remind them that there’s a better way? Is anyone keeping track of the improvements that aren’t implemented as the sprints add up?
A universal example: integration day
Let’s take a look at integration day. We’ve all been through them, time and time again. It’s the day when we strip out the mock data from the front end, and revise all of our API calls to hit the backend REST endpoints. Despite Postman collections, data mappings, sharing JSON back and forth, integration almost never goes as planned. It’s so rare that the times in which integration actually worked out as planned really stand out in our minds. We talk about them at the bars after work.
I can’t tell you how many times I’ve brought up integration day in sprint retros. Everyone agrees, integration day sucks. Everyone agrees, integration day needs to go. And yet, every sprint, we integrate around the middle- of the second week. That’s two-to-three days for QA and debugging, with a code freeze at noon on the Friday before the demo.
But guess what – we get it done. Because we’re like-minded, success-driven individuals. We arrive early, work late, and make sure that we deliver on time, every time. We have yet to fail a sprint, so we continue with our broken process.
The Sinking Ship
So let’s look at ourselves – our respective teams of developers – as a naval warship. Not those fancy modern ones, but wooden ships with cannons. You can be a pirate if you want.
Let’s say you’re in the middle of a battle with another ship, and you, member of the ship’s crew, notice a leak. Your ship is now sinking.
What do you do? Do you address the leak? Do you get other members of the team to address the leak? Do you escalate the leak up the command chain and await orders? Do you ignore the leak, since your priority is to sink the other ship?
Let’s not point fingers
I can tell you that in a lot of ways, several people I work with have been known to ignore the leak and continue to try to sink the other guy. Not every time, mind you. And not every person would react the same way.
It’s not for lack of intelligence, nor is it for lack of respect of the team as a whole. The problem with refusing to fail is that you never get to learn from your mistakes. No one ever realizes that your process is broken and needs to be improved.
Some will say, “Let’s just get through this, and we’ll address that later.” In some cases, they’re right. If your ship is being boarded by the enemy, the people trying to plug the leak are definitely going to die. In the real world, we may equate this to a demo that the CIO will be sitting in, or a bugfix that has to be part of the next release lest you should lose a major adopter.
In those circumstances, you’re damn sure you finish that sprint. The CIO has thousands of prompts for his attention every day. You don’t want the minute of focus that he gives you to be about process improvement, rather than the million-dollar feature you were on track to deliver.
On the other hand, if there’s no high-profile aspect to delivering, the priority should probably be around improving things. And a good way to tackle that is to ask what the benefit is of not addressing the problem as it’s happening. If the benefit is to prevent failure, then it’s really not a benefit as much as a skewed perspective.
And yet others may not explicitly say it, but everyone knows they’re just too competitive to not be the best, according to the metrics of what makes a team “the best”.
If that’s the case then your team is following the wrong metrics. Delivering features isn’t necessarily a sign of productivity if the process of building those features was broken. It’s the best way to introduce bugs, prevent scalability, skip testing, and forget documentation. The best team not only delivers, but also writes maintainable code. Finding a balance between those two things is where “being the best” lies.
Jobs are hard, so let’s be clear on that. Dev work is even harder. But there’s no mistake that on every team, there are always opportunities for improvement. The problem is when a team decides – because of one outspoken person, or because of a group mentality – not to acknowledge or implement those opportunities for improvement. While sometimes small, and not an immediate threat, those problems can become massive over time, if not addressed. And when they do, you might look at your coworker (or your coworker might look at your) and say “You don’t look so good”; and whether they say it or not, you both know it’s because the process should have changed a long time ago. It’s at that moment, that you realize your ship is about to sink.