Imperfect Sprint

This post is inspired by one of the many presentations I've seen in my life on how to plan a development sprint. And they are all similar to one another, like identical twins – always very beautiful drawings and verified text like “here we have analytics, here is development and testing, a two-week sprint, at the end of the sprint all tasks are completed, management is delighted, the customer is happy.” I would like to show reality as it is.

Let's go through problems that are completely common for every team leader, and ways to solve them. Let's start with the most common one.

My name is Sultanov, and I am a team lead (heavy sigh). I try to complete all sprint tasks on time. Sometimes it even works out. And I also have channel, where you can discuss this and other articles. Subscribe, it's interesting.

1 Niuspe…

I've never seen completed sprints look like this in presentations:

Ideally, of course, you need to be able to do everything, but in all honesty (and the other on bible constitution), admit it, what percentage of sprints are fully completed? It’s good if the answer is “about 50%”). In the rest of the sprints, we don’t manage to achieve at least something. What to do?

Standard solutions are to simply move it to the next sprint and finish it, close it and finish it in the background, close it as is and add it to technical debt. All these methods are not very good for one reason or another.

Solution:

Recalculate the story, and credit the team with as many story points as the team has accumulated, then make an injection into the backlog, where to enter the remainder of the sprint as a separate story with a residual score and highest priority, and do it in the next sprint until the victory. The disadvantage of this solution is obvious – why estimate stories accurately, why rush, if we can always take time and finish it in the next sprint. In this case, it is a good idea to apply some penalties to the team, for example for each such case, deprive of part of the bonus assign penalty points, and organize team competitions.

2 Problems with a specific developer

The developer is a cunning and resourceful beast. It just seems that they are all so independent and proactive; in fact, they, like all people, are very different.

Of course, there is the “don’t work with assholes” approach, but it’s not scalable at all. It is possible to recruit 10 superheroes for a super interesting and socially significant project. Recruiting 100 superheroes for a boring banking legacy is very unlikely. So working with assholes is the real everyday life of a team leader especially when he's an asshole himself.

2.1 Outright deception

I must say, the case is really quite rare, since in the end they will still fly for it. But after. Therefore, you can transfer a small task to “done”, knowing that the lead is now busy and will not check, and go on vacation, and then we’ll somehow get away with it…

2.2 The developer stopped working

Usually happens after long holidays, vacations, weddings and other breaks in work. Well, when you burn out, of course. This is where very interesting stories arise with such “incredibly complex floating” bugs that were “done” in half a sprint, and were ultimately resolved in 2 minutes upon closer examination.

Solution:

Cases like this at the beginning of my team leadership journey taught me not to take anyone’s word for it, and to ask to see what had been done. Regularly, once every couple of days. This teaches developers to be conscientious and to the fact that the lead still won’t lag behind. The trouble comes when the lead ceases to control everything himself – he simply does not have time. Then it’s best to organize a cross-code review and show the lead more or less ready-made functionality.

3 Conflict

Both within the team and with the customer (his representative, product owner, etc.). Usually looks like a bunch of comments (and comments on comments) with a gradual increase in intensity, right up to the transition to personal insults.

It happens that someone from the team really wants to try some technology that is not needed for the project, and begins to lobby for it. It happens that he turns it on on his own, runs into problems and then doesn’t know how to solve them, which doesn’t make others very happy.

Sometimes the customer representative and the technical lead disagree, which leads to a lack of agreement and failure of the sprint, since the story cannot be completed without the agreement of the customer representative.

Solution:

Usually a conflict ends with a strong-willed decision of the person in charge, and this is why it is very good to clearly distribute areas of responsibility in advance. If it doesn’t work out, it can be done directly during the conflict, only in writing with notification to the entire team, and further one-on-one meetings with the parties to prevent deliberate sabotage of the decision or humiliation of the “losing” party.

4 We tested and tested, but didn’t test

Occurs regularly when there is not enough time for testing and an attempt is made to close the story before the end of the sprint. I think everyone understands that an incompletely tested solution cannot be included in the release.

Solution:

Described here. And you can catch this situation by requesting written test results from testers. They will be stubborn (working with documents is always boring), but even a fleeting glance at the test plan and results will be enough to ask a number of significant questions. Well, at the same time, fail the deadlines in history.

5 Customer for demo: that’s not what I meant

Everyone is afraid of these words, especially management, because these words almost certainly mean a missed deadline for the project and a reduction in the bonus. At the stage of pronouncing nothing can be done; the story most likely disappears to the trash heap on the table, and the stage of clarifying the requirements begins. Whether this should be considered a sprint problem (after all, essentially the story is done, and done on time) – scientists argue.

Solution:

Work with the customer not only during the demo, but also during the sprint, periodically checking to see if his requirements have changed. It doesn’t always help simply because the customer with whom you can work and the customer accepting the work are not always the same person. But at least something needs to be done.

6 Include a very urgent task beyond the plan in the current sprint!

It doesn’t happen often, but regularly, usually associated with bugs in the product or directly urgent requirements of very high management of the customer, which everyone, including representatives of this same customer, unanimously forgot about. It misses all the deadlines, demolishes roofs and towers, causes rework, and then sits there for a month and a half, useless to anyone, because “we’re waiting for the release window.”

Solution:

Prohibition of including any tasks in the sprint other than those planned. Everything that arrives from above, below, from the side is included in the backlog of future sprints with the highest priority. In addition to creating a calm atmosphere in the team, this solution also cools the hot heads of people who are trying to please the customer, approving any of his requirements and rushing to fulfill them immediately.

And now, having become familiar with this far from exhaustive list of problems everyone sprint, you will stop asking questions like: