Multiple research studies have shown the negative impacts of multitasking.
Whether it is the waste generated by context switching, the elevated stress levels for staff or the increased cost of poor quality, few people would assert that it is a good practice for knowledge-based work. Front line workers might argue that their managers think that multitasking works, but I have yet to meet a management team who believe in the practice since most of their members will also suffer from its negative outcomes.
Lots has been written about the benefits of reducing multitasking, but this is not a straightforward feat for most organizations. The Lernaean Hydra (as opposed to the Marvel universe's evil organization) could be used as a metaphor for this unhealthy practice. Deal with one contributing factor and others will take its place.
Here just a few of the forces encouraging multitasking and some suggestions on how to slice and cauterize each one:
Similar to battling the Hydra, these ideas need to be considered from a holistic perspective to avoid sub-optimizing the whole.
Reducing multitasking might seem like an impossible feat, but leadership teams should draw inspiration from Heracles.
Information radiators are a great idea.
After all, who wouldn't want to reduce the effort involved in keeping stakeholders up-to-date about a product or project or increase the consistency in messaging to all stakeholders?
But convincing executives to use information radiators as a primary means of staying current is not an easy task. Yes, there might be a few early adopters who are open to trying a different way but most are likely to prefer to receive these updates the way they've always got them through one-on-one or steering committee meetings using status reports. So project managers or Product Owners spend time harvesting and curating information from the radiators into traditional status reports or presentation decks.
This introduces a few challenges:
So how can we help executives through the transition to using information radiators?
Start with why - if they don't understand how traditional reporting approaches hurt them, they are unlikely to have any sense of urgency about adopting a different approach. Whether it is reducing delivery costs or improving the quality of information presented, find out what concerns them and use that as a lever for change.
Second, you will want to ensure that the information radiators being published are relevant to senior stakeholders. Taking the time to understand what they need to support their decision making should help in creating dashboards which they will actually want to use.
Finally, rather than asking them to make the significant leap from a meeting-based approach to a self-service model, consider continuing the meetings, but use information radiators as the supporting materials for the discussions in place of traditional presentation decks. This should spark your stakeholders' curiosity as they are likely to ask questions based on their interpretation of the information published which will provide you with an opportunity to provide live "color commentary" about the project or product's status.
If you want management to change, you need to apply effective change management.
The Scrum Guide calls sprints the "heart of Scrum" and also indicates that they should be one month or less. The Guide also cautions about setting sprint durations longer than a calendar month to ensure that inspection and adaption is happening frequently which will reduce the risk of wasted team effort or of building the wrong product. This aligns with the third principle from the Agile Manifesto which encourages teams to deliver value frequently, from a couple of weeks to a couple of months.
A research survey conducted by Scott Ambler+Associates found that the most common duration used by teams following a sprint-based delivery model is two weeks, but how should a team decide what is the optimal sprint length for them?
Their decision should consider a number of factors including:
For teams which have just formed or are working with technologies or a product which is new to them, too short a sprint duration may prevent them from being able to complete anything meaningful. This could cause them to get discouraged and might frustrate the stakeholders who are expecting to see progress every sprint. On the other hand, if the team is new to flow-based delivery approaches and they start with a long sprint duration, they could revert to traditional behaviors where they complete batches of work items in phases over the life of the sprint.
When in doubt, it is usually better for a team to choose a shorter sprint duration as this should encourage them to identify, elevate and eliminate the real constraints which limit their ability to deliver. With the longer duration, while they might be aware of the constraints, their sense of urgency may be less.
The team should not change sprint lengths on an ad hoc basis, but if they have identified triggers which suggest that they need to increase or decrease duration then such changes might be done after a major product release. Improvements in the team's productivity or a high degree of volatility in the product backlog are two possible triggers. Another example is if the stakeholders attending sprint reviews consistently feel overwhelmed with the content of the product increment being demonstrated to them.
Sprint duration is another case of Goldilocks and the three bears - finding out what's "just right" will take some trial and error!
The old saying about committees came to mind when I was considering the default approach companies often use to achieving a control objective. Bringing together diverse perspectives can help to reduce bias, but in many cases a simpler approach might result in a better outcome.
Let's focus on the specific example of a solution architecture review.
It is rare that there is accountability for each member of a committee if their decisions were poor as they have no skin in the game. The power imbalance between the committee and the creator of the architecture proposal being reviewed might also encourage nitpicking over format or style rather than substance.
There is also an increased likelihood of incurring delay and other forms of waste. Committees meet at scheduled intervals which might not align well with the needs of a specific team. The committee might also be faced with a "feast or famine" challenge where they are overwhelmed with submissions at some meetings with the result that certain teams don't get their proposals reviewed. Beyond the proposal review itself, there is usually a need to go through some type of formal intake process and to provide other documentation for committee-specific needs. The overhead costs of running the committee are likely to be charged across all teams. And don't get me started with the increased costs of re-work or repeat reviews beyond the initial presentation...
So let's consider a simpler alternative as the default approach with a committee used only an exception basis for the most complex situations.
Why not require all architects to spend a fixed percentage of their capacity on conducting structured peer reviews of each other's architectural proposals? Each architect is expected to have a clear understanding of enterprise standards and good architectural practices, so control objectives should still be met.
This addresses both of the previous disadvantages:
It might also result in a better architecture as we may be more open to incorporating feedback from one of our peers than a group of seniors.
Ensuring that there is a fair balance of review work across all architects might be achieved through some sort of random allocation system that prioritizes reviewers based on their last review date.
Delivering in a leaner manner should not require sacrificing the control objectives which will keep us safe, it will just require re-thinking how we approach governance.
In an earlier article I'd written about the pros and cons of a Scrum Master or agile lead having deep technical expertise in the solution space but what about a Product Owner (PO)?
In their 2003 book, Balancing Agility and Discipline: A Guide for the Perplexed, Barry Boehm and Richard Turner coined the well known acronym C.R.A.C.K. to describe the attributes of an effective PO and the K in that acronym stands for Knowledge. Normally, we consider that this is business or product knowledge, but couldn't it also extend to technical acumen?
Technical expertise is likely to help the PO prioritize the product backlog such that there is a healthy balance between business and technical drivers. In the absence of this knowledge, team members might find themselves spending greater effort in helping the PO understand why certain technical work items are time sensitive from either a risk management, dependency or technical debt reduction perspective.
While there is some benefit in a PO having such knowledge, it comes at the cost of greater vigilance. The PO will need to be disciplined to ensure that he or she is maximizing product value by focusing on the "what" and "why" of the product and letting the team own the "how" and "when". Without that mindfulness, such knowledge could result in a PO who:
With great knowledge comes greater responsibility.