Antipattern of the Month: Time Theft
Make sure that your planned and timeboxed Sprints are not being interruped to protect yours and your team's productivity.
Join the DZone community and get the full member experience.Join For Free
An Agile way-of-working is founded upon the ability of team members to agree and make certain commitments. In Kanban, for example, they might agree to provide a certain quality of service or service level expectation. In Scrum, they might commit to meet a certain Sprint Goal.
The fulfillment of any commitment is, of course, quite likely to demand that time be reserved and made available for the necessary work. Furthermore, the quality of that time will have to be fit for purpose. If a team is not allowed the necessary time, uninterrupted, to meet the commitments they have made then the expected outcome cannot be assured.
Teams will often frame certain timeboxes, such as Sprints, within which the necessary focus can be applied. They may also use clearly defined queues or backlogs which provide transparency over the work they have forecast for completion. The clarity afforded by burn charts and other projections can give a degree of assurance that any commitments are then likely to be met.
The surreptitious and unplanned usage of team members' time not only decreases the likelihood of success, it also reduces transparency over the work team members are actually doing. Although any one interruption may not appear to be of significant impact, in aggregate they can be substantial enough to compromise a Service Level Agreement or Sprint Goal. The time lost task-switching also needs to be taken into consideration, as does the possibility that work may end up being done which has not been properly budgeted for.
The incentive to interrupt team members can be felt by stakeholders whose work is of a lower priority than they believe is justified and who wish for it to be expedited, and by those who would rather it be done "on the sly", perhaps in order to avoid paying for it. It can also be felt by stakeholders who do not consider themselves bound by team protocols such as prioritization and ordering at all, such as executives and senior managers.
A good Product Owner will exercise stewardship over the Product Backlog and ensure that stakeholders do not attempt to circumvent it. A bad one will hold team members to any commitments made while also attempting to introduce new work reactively in response to unmanaged pressures.
Note that the expectation that team members ought to behave immediately and reactively can sometimes be confused with the demonstration of "agility." The introduction of an Agile framework can bring a level of rigor which is quite alien to an organization's established culture. A Scrum Master ought to recognize impediments such as these, act on them to protect the team, and coach Time Thieves to engage with team members more appropriately. This can be challenging when violators hold seniority in the organization, or when stakeholders are otherwise used to approaching certain development team members directly.
Time Theft is Antipattern of the Month at Agilepatterns.org
Intent: Coerce third parties into assisting you without negotiating their time
Proverbs: "Time is the coin of your life, be careful lest others spend it for you."
Also Known As: Waste (in the context of unplanned work)
Motivation: Agile teams draw their work from prioritized backlogs, which means that those waiting at the bottom of the queue may expect some degree of delay. Such parties may thus be incentivized to circumvent the backlog management process by approaching team members directly for assistance. Parties seeking assistance in matters that lie beyond the team’s remit can have an additional incentive, given that such activities would not be appropriate for inclusion on the team’s backlog in the first place.
Structure: A team member plans to do timeboxed work. All work completed within the timebox is inspectable and subject to review. A time thief approaches the team member during the timebox, involves them in unrelated activities, and thereby interferes with the team member’s ability to complete the work satisfactorily in the time available.
Applicability: Time theft can happen in environments where stakeholders are used to approaching team members directly, or where product ownership is weak and backlogs are not rigorously managed.
Consequences: Time theft reduces the ability of teams to deliver planned work in a Sprint or other timebox. Incremental releases will be put at risk. Inspection and adaptation of the team process may be compromised if time theft is unrecorded.
Implementation: Agile methods such as Scrum reduce the opportunities for time theft by introducing servant leadership roles such as a Scrum Master. The person fulfilling such a role must protect the team against unwarranted interference and coach its members to beware of time thieves. It should be noted that the incentive to commit time theft can only be eliminated once all parts of an organization subscribe to Agile practices, including backlog management. Teams must also have a shared view of release planning so that they can manage their dependencies in a timely fashion.
Opinions expressed by DZone contributors are their own.