Antipattern of the Month: Too Busy
Antipattern of the Month: Too Busy
In Agile, often the most important and knowledgeable leaders are the most unavailable.
Join the DZone community and get the full member experience.Join For Free
Often, the very people whose involvement is most critical to an initiative are those who are least "available." Senior managers, for example, can have a deep level of domain experience which they have built up over years, and they can exert authority over important decisions. Enterprise architects and Product Owners, in particular, may have accumulated responsibilities over sweeping areas of organizational concern. Such people are notoriously time-poor, and can be unable or unwilling to focus on a single product or team. This means that they often fail to make the appropriate commitment to an Agile role, and do not demonstrate the quality of involvement expected of them.
One symptom is that they might see themselves as being "too busy" to fulfill the role and its responsibilities. A Product Owner, for example, may be "too busy" to attend Product Backlog refinement sessions, or perhaps even Sprint Planning, Sprint Reviews, and Sprint Retrospectives. They may allege that they "trust" the Development Team to make an appropriate delivery without their participation. This is unsatisfactory, as it means abdicating their collaborative responsibilities, and the inspection and adaptation of progress are compromised.
When people see themselves as being "too busy" for their role, they may attempt to delegate the associated responsibilities instead. A Product Owner, for example, may try to delegate their role to a "proxy" such as a business analyst. The proxy might notionally fulfill the role of the absentee Product Owner, but in reality often lacks the authority needed to engage with stakeholders. A proxy might not, in truth, be recognized as the arbiter of product value who balances and represents stakeholder interests.
In Agile practice, teams cannot be forced into performing work that they are unable to commit to. Yet all too often they face dependencies which compromise their ability to make a commitment, including upon others who are theoretically available, but in reality are "too busy" to help. A brutal question must then be asked: is the initiative really important enough to start or to continue doing, when priorities evidently lie elsewhere?
"Too Busy" is Antipattern of the Month at agilepatterns.org.
Intent: Ignore your duties as a stakeholder in order to perform other activities that you consider more pressing
Proverbs: "It's not about having time, it's about making time."
Also Known As: The Absentee Product Owner, Assigned Product Owner
Motivation: Key stakeholders often have responsibilities that span multiple teams (e.g. Product Owners, senior designers, and architects). If they do not value a team’s product or service particularly highly, they may be tempted to abdicate or defer their stakeholder duties in order to give other matters their attention.
Structure: A stakeholder in the product (such as a Product Owner or architect) fails to liaise with the team at a critical time. During an iteration in which one or more of items with a stakeholder dependency are drawn from the Product Backlog and planned into the team’s Sprint Backlog, the stakeholder’s input will be needed so that the increment can be delivered. However, the stakeholder abdicates this responsibility in order to perform unrelated activities.
Applicability: Clear product ownership (and sometimes technical direction) can be difficult to establish, especially when products or services affect multiple stakeholders or cross organizational boundaries (e.g. middleware components). Each stakeholder may believe they have higher priorities outside of the team and its work. The strategic importance of the product or service may only be apparent if such weak stakeholders are viewed in aggregate. This can result in product ownership and/or architectural duties being assigned to managers who do not have a sufficient level of individual interest in the outcome, and who consequently do not afford their role the time it deserves.
Consequences: If the stakeholder does not provide the assistance expected, dependent backlog items may not be completed as per their acceptance criteria. The Sprint Goal may be put at risk and an increment of functionality might not be delivered. Alternatively, the team may try to negotiate the impediment by consulting with other stakeholders instead. The interests of such stakeholders may not coincide with those of the absentee, whose own interests might thus become compromised.
Implementation: In many organizations product ownership or architectural authority is vested in senior managers. These managers can be stakeholders in multiple concerns that are in progress or being planned. They may not be sufficiently interested in a particular project to afford it the time that the role demands.
Opinions expressed by DZone contributors are their own.