Thoughts on Sprints

Photo by Luis Villasmil on Unsplash

When it comes to project management, I don’t have any answers or any solid advice. My preference is try and ship regularly(with tests) inspired by a combination of Intercom and Basecamp. I make heavy use of beta flags, staging environments and early user testing to ensure product market fit(or client fit) then have systems in place to offer continuous improvement.

However, this article is not about how I build software.

I once contracted with a company where the staff were petrified of mistakes, being wrong or seen to be ignorant. I was brought in as a senior contractor to help them speed up product development.

Ignorance was scorned, and employees scolded for not knowing more than the next person. It was a shame that the atmosphere existed because many developers were new to rails and were eager to learn.

After a few weeks, I could see the cause of the “slow product development”. The team was using 2-week sprints for project management and didn’t write any tests.

After each sprint, there would be new bugs that would arise from new features developed. They would also have bugs from previous sprints. These bugs would get added to the next sprint along with the new features.

The Jira tickets assigned to each developer started to compound and grow with each sprint.

I’ve observed this pattern in 2 other companies leading me to believe that sprints are not suitable for good Software Development.

The first company I was able to help by making a presentation about Continuous Integration, Automated Testing and small iterations to the CEO and Senior Leadership.

The other companies I could not rescue.

It’s funny reading the Agile Manifesto and then doing sprints to see the complete lack of juxtaposition with a good work environment.

Even the word sprint implies 100% all-out until you hit the finish line.

Retro - Let’s talk about what went wrong more than what went right

It’s good to talk about how we can improve. When playing any sport, new tactics and innovations can help even the lowly human overcome enormous titans. 

However, talking about what went wrong every two weeks is a one-way trip to the bottom. A retro is where people come to air their dirty laundry whether you like it or not. Sit ten people in a room and ask them for their opinion on what went wrong; you will get hurt feelings.

Yet, for some reason, critiquing the process becomes frowned upon. It works for other people so it must be us that’s doing it wrong.

Even worse, people continue on this hedonic treadmill towards burnout.

The idea of the retro is to suggest improvements to the process, but inevitably, it becomes about keeping the process intact and more about what individuals can do better.

Daily Standup - Let’s talk about what we already talked about

Another strange part of sprints is the daily meeting is the default. It’s supposed to be 10 minutes, but it never is. Plus, when there are ten people in a forum, that’s 100 minutes.

Creative work is the result of deep work from hours of focus. Starting the day off with a meeting isn’t setting the proper foundation for getting things done.

Let people self-motivate and treat them like adults. Everything else will fall into place.

Lifestyle

The worst thing I would hate to do to my employees is have a damaging effect on this lifestyle. Overwork, commuting and bi-weekly deadlines are a recipe for burnout.

The two-week sprint cycle does not factor in mistakes and meetings. With a crunchtime every two weeks, overtime is inevitable to get things over the line. 



Final thoughts

My sample size is small. Three companies in 5 years is not the best sample size; however, talking to other engineers led me to a pretty dim outlook on sprints.

I’ve seen development cycles done well, but it was never sprints. Instead, it was a combination of old school goals and continuous integration.

My partner is a product manager, and she regularly exclaims how sprints are brilliant when done well. The problem is that I have never seen them done well.

Overall, when starting a project, taking the pain and barriers out of the way is the most important.

Are too many bugs being created?

Then write tests and use a CI build to help keep them under control.

Is there pressure to get features in?

Then hold off and make sure the parts you’re bringing in are worth it.

Is it hard to onboard a new team member?

Lower the barrier to get code to production.

Ship small. Ship early. Ship smart. Ship often.