Manage delivery, not time

Daishik
7 Mar 2023
0

In a previous post I wrote about a scrum team who's only apparent 'goal' was to fill developer time. They routinely rolled work items from one sprint to another and moved work around mid-sprint often a daily basis.

Whilst I attributed it to a single client, I have seen this kind of thing with minor variations a few times over the years. The effect is always the same: the team expends focus on management of time, rather than delivery.

For the time-focused team, the boundary between sprints is at best a soft, blurry line of no consequence. There is no goal, no commitment to stakeholders; the developers and testers just need to keep working on something. Anything. If they get interrupted or blocked, no problem. They will pick up the new item, or take something off the backlog. It doesn't even have to be on the backlog. The planned items will just slide over by a sprint.

There may still be a milestone or deadline on a project, but it lies outside of, and has no reference to the sprint cycles. The only discernible purpose of the sprint cycle is that it may compel the team once every fortnight, to review pending work in relation to work currently in play. They may re-attempt to align it with actual project goals, or raise the alarm on potential slippage in timescales.

For the delivery-focused team however, every sprint counts as part of the incremental, iterative development and delivery of a product or project. Every sprint is aligned to the overall project objective, and every sprint goal is a mini-milestone toward that. Failure to complete¹ a sprint is a serious matter and must be subjected to a robust discussion in the sprint retrospective because it has the potential to have a knock-on effect on subsequent sprints and the overall project.

The outcome from these two approaches on team effectiveness and productivity can be significant.

Significant in the sense that it might mean the difference between projects being delivered to specification, on time or not.

Also significant in the sense that it could mean the difference between Agile succeeding or failing in an organisation. How?

Empowerment and accountability

Agile purposefully empowers every team member; giving them the power to focus on, and pace their activities in a way consistent with the sprint goal, and simultaneously resist ad-hoc demands, changes and distractions from the wider business. Indeed, failure to adhere to the sprint risks the sprint goal for the entire team. A sprint goal is a commitment from the team to the stakeholders, and a failed sprint is a failure for the team.

In time-focused sprints, team members are concerned with filling their time with activity. If every activity is as good as any other, then distractions and changes can't be resisted. A team member that wants to work on their sprint tasks, may be unable to deny a supposed 'high priority' diktat from a superior if it's acceptable practice to change focus without challenge or consequence.

Focusing on time therefore disempowers team members.

What about accountability? Without the power to say no, to refuse to be side-tracked, team members are no longer accountable for delivery - they are subject to the vagaries of circumstance and whims of superiors. Consequently, if individuals cannot be held accountable, then neither can the team.

In essence, there can be no cohesive team, and no concept of a collective sprint 'failure'.

Sustainability

Over the course of several sprints, a time-focused team will start to notice one or more of the following:

The backlog is littered with partially completed user stories and work items.
The backlog is an unordered, disorganised wish list of activities with little to no detail, analysis or context.
The rigour of discussions during refinement sessions is diluted. A sign that this might be happening is team members regularly skip or avoid ceremonies (e.g. "too busy"), or attend with one eye on the door, or multi-task during the meeting (if remote working). Assumptions remain unchallenged, questions are not asked, issues and problems are not raised, so items that should not really meet 'Ready for development', are scored and marked as sprint-ready regardless.
Important details are obtained during the sprint, so tasks often take longer than planned or get blocked and stay blocked for longer.
Daily stand-ups go off on tangents, unrelated to the planned sprint activities.
The task board contains 'filler' tasks because it's impossible to keep track of all the other non-sprint activities, but the time still needs to be accounted for.
Sprint ceremonies are low-priority because people are "too busy": the ceremonies get skipped, persistently postponed, or rushed through. The first ones to go will be stakeholder demos and retrospectives, but may eventually also include sprint planning and refinement.

When too many of the above become normalised, the team basically undermines itself and the system can not be sustained. The team become AINO (Agile In Name Only).

Conclusion

In my experience it's nearly always the case that teams that focus on time, seem to waste more of it.

Whilst you may argue that even time-focused teams will eventually deliver, it does beg the question, what is the point of the sprints? Why not just have a rolling system using the backlog as little more than a glorified to-do list?

Why not drop the pretence of Agile altogether and spare your team the overhead of ceremonies and maintaining a detailed backlog?

On the other hand, there's no doubt in my mind that if a team is committed to improving itself, then refocusing on delivery can make a positive difference, resulting in less wasted time, less stress and better, faster delivery.

¹ For the avoidance of doubt, a 'complete' sprint is one in which all the committed work items are finished and delivered - done, according to the definition of done. However, even if a few tasks are not all completed, one could still say a sprint is successful and complete provided that sprint goals are achieved.