Culture of busyness
Hello everybody,
Given some real life examples (of course, they could be “easily” challenged and they could be improvement topics themselves) ...
[
1-For a 2-weeks Sprint, only one hour Retrospective, but there is a bug in production we just discovered, or our plan is to go to production that day, or we are late on some development/Sprint Backlog, and so some members do not come
2-Backlog management is not done regularly and refinement in group is often skipped to leave time to progress on the Sprint Backlog
3-Working on several subjects in the same Sprint (Sprint Goals are almost always multiple and not "one")
]
... and based on my direct observation of the context, my opinion is that this is linked to a busyness culture.
How should we deal with that, as Scrum Masters?
What impact are these 3 issues having on the business you mention? What are the consequences, and who sees any urgency for change?
@Ian Mitchell, the way I understand it, I think Alessio refers to busyness as in "being too busy to attend Scrum events" :)
@Alessio:
1- Many options/solutions depending on the context or the situation. Are the team members really not coming because of other commitments (based on your example, are they mandatory to correct production bugs?)? Do they not come because they are late on some of their developments? Anyway, keeping in mind that if not everyone attends it has an impact on empiricism, I would keep things this way and have the retrospective with anyone attending; however I would voice my concerns/frustration that not everyone is there. My hope here would be that the other team members realise that it is an issue and that everybody should attend the retrospective, and that we all find a solution to make this happen.
2 - I would observe if the irregularity of the Backlog management becomes an impediment (i.e do you have a Product Backlog with 400items, some of them as old as 5 years old? Are the items unclear during Sprint Planning?), and make it Transparent to the team, then I would remind them that refinement might be a solution to solve this.
3- I would have an incremental approach here : first (maybe 1 sprint) having at least one proper goal which would be the mandatory goal and secondary goals, then (maybe the next sprint) try to merge all the goals into a global one, all while highlighting the importance of the Sprint Goal for commitment and focus, and for the empiricism.
What comes to mind when discussing busy-ness culture...
Other symptoms could include starting, but not finishing work. We are busy with all of the started work, but perhaps not finishing it because there is too much in progress and our focus is split.
As Scrum Master we can bring transparency to the situation, perhaps through data, illustration, and/or sharing of observations. We can discuss how busyness can impact productivity and the real impacts and costs of context switching when we split our focus. We can teach about the importance of inspection and adaptation and how it helps to ensure we are continuously improving, even addressing what has us so busy and finding ways to better manage our busyness.
Each of the scenarios you provided, and others, could be explored further. As an example, we have more than one Sprint Goal. Why? Are we able to achieve both Sprint Goals or even one of the Sprint Goals? If not, what might that tell us about our approach? How does multiple goals impact our focus each Sprint? How much context switching occurs as a result of multiple goals? What is the time lost to this context switching? Could we experiment with one Sprint Goal and compare outcomes? And so on...
Thoughts?
Thank you all for your rich and valuable comments!
Perhaps we could try to split the discussion between two linked different angles.
The "inside team" angle:
@Ryan
If I may quote your words, I also agree with the fact that "we can bring transparency to the situation, perhaps through data, illustration, and/or sharing of observations".
When you said "We can discuss how busyness can impact productivity and the real impacts and costs of context switching when we split our focus." how would you actually do that?
The "outside team/company culture" angle:
I've already heard several times some of our coworkers also worried about the fact that people might not be "busy enough" ("not enough work to do") in the "short term": this does not consider any room for improvement, technical debt, bug fixing, refactoring and - correct me if my opinion is wrong - makes me think about some sort of micro-management and some sort of low level of trust. One symptom would be the fact of assigning different topics to different people in the team arguing that it is not possible to split that topic and to allow pair programming for progressing, from which we could easily end up with multiple Sprint Goals.
What are your thoughts/suggestions about it?
@Alessio, one way I have illustrated impacts of context switching is by creating a spreadsheet where the number work items a person has on the go can be plotted out along with Scrum Events etc. The cost of context switching is a variable you can set in the spreadsheet. Some studies suggest the impact can be up to 25 minutes when switching between complex work. The spreadsheet calculates time lost to context switching, purely based on the number of items/meetings/etc. for one person and uses only 1 context switch between each item in a day. Even if you set the context cost variable to 15 mins, this shows how the impact compounds quickly with each addition. You can see impact at daily, weekly and Sprint level (in our case 2 weeks). If this is the impact for one person, imagine what this looks like for the whole team.
This is obviously not meant to be precise, and is as a way of illustrating. The impacts could actually be much worse if team members are regularly being pulled away from their work to focus elsewhere or doing a lot of switching amongst their started work. This can be a talking point.
If you want to research this topic a bit more you could start with Gloria Mark study or go down the google rabbit hole of studies, visualizations etc. on this topic.
There are some infographics out there that may help with visualization as well: https://visual.ly/community/Infographics/business/high-cost-multitasking
Henrick Kniberg has some great demonstrations related to this topic, that could be shown or replicated as exercises with the team.
Thank you @Ryan for your deep answer!!
If we know would think at some possible "solutions"...
1. I would say "It is okay to be busy, but just do and complete one thing after the other and say 'not now' when you are already doing something", would you agree with that?
2. I would add that the only sources which would require to stop performing our current task to switch to another would be joining a Scrum Event or being involved in "urgent work" (like urgent a bug in production). Would the key here perhaps be striving to "limit" those two exceptions? If so, I do not really see how that could be done with Scrum Events (maybe put them in specific moments of the day and of the week?), while for the urgent work probably a sort of "post-mortem" analysis identifying the causes and the "remedies". Would you agree with that?
3. Others?
I would say "It is okay to be busy, but just do and complete one thing after the other and say 'not now' when you are already doing something"
One of the sayings we have in Scrum is stop starting, start finishing. There is no value in starting work: the value only comes from finishing it and rendering it usable.
Limit work in progress to that effect, and cultivate a workflow based on pull signals, rather than the push signals which currently seem to have a hold.
Thank you @Ian for your reply, great point! :)