If you want high performing teams, allow slack time for learning and experimentation. This counterintuitive approach is a long term investment in people.
Getting 110% From Our People
One question that I get frequently from leaders during Agile training is about how to make sure everyone is busy. Rather than ask about high performing teams, they want to know how to get the most out of each person. They want maximum resource utilization.
They have a seemingly perverse focus on individual efficiency rather than on team effectiveness and throughput. Rather than focusing on creating an environment for high performing teams, they try to make sure that everyone is busy all the time. This is another form of local optimization.
Some will even ask about how to make sure everyone is giving 100% or 110%. Are any of us giving 110% every day? How is that even possible? I will sometimes glibly respond that the best way to make sure that everyone is 100% busy is to have them do jumping jacks or to go up and down the stairs on their breaks.
Sadly I had participants from a particular Chicago company at a recent Agile Training Course who said that their management expected them to work a minimum of 60 hours a week.
And the CEO was checking individual time reports to make sure they really did it! The results? I bet everyone logged 60 hours on their timesheet. At least the ones who didn’t get sick or immediately find a better job.
How Slack Time Leads to High-Performing Teams
I’ve even had Scrum teams that I’ve coached who struggled with slack time in the sprint. They made the case that if they had some time left at the end of the sprint, they should bring in a new backlog item even if they knew they could not get the item all the way to “done” in the sprint.
I discouraged them from taking on that work and getting it partially done since it decreased predictability. “What else should we do with our time?” they ask.
Plenty I say! It would be foolhardy to run anything at 100%, never mind 110%. Slack time and downtime for a Scrum team is not only OK, it is healthy. I would contend that high performing teams aren’t really high performing teams without slack time.
Here are some specific things that teams can do to leverage downtime, protect their agility and help them to go faster in the future.
-
Invest in Learning & Cross Training
Most new Agile teams are highly specialized – each person just has one skill. This creates efficiencies at the individual level but undermines team effectiveness and overall throughput.
And it creates key person risks. The answer is to invest in cross-training to help individuals to add secondary skills to their primary skill.
It takes a long time to build these T-Shaped skills, even for teams that focus on it. Individuals can invest in learning new skills, pairs can work together, and teams can do cross-training or other group learning activities.
Kata’s and Dojo’s are structured, group approaches to improving coding skills. Team members can even grow their domain expertise by talking to customers or observing their product as it is being used.
-
Reduce Technical Debt
Refactoring code or removing technical debt is another great way to use spare time in a sprint. I encourage teams to maintain an engineering backlog of technical stories that they can work on as they have time.
-
Improve Your Tools
Most teams limp by with inadequate development tools. Teams can use spare time in the sprint to improve the tools that they work with.
There are always improvements to be made in continuous integration and automated test frameworks or other tools. Team members can explore new tools or do maintenance or cleanup on existing ones.
-
Be Creative
Team members can also just use the time to think. Novel idea but most team members won’t find spare time within a sprint for thinking.
-
Run Experiments
Teams that find they have some breathing room in a sprint can use that time to run experiments. They can look back over their improvement actions from previous retrospectives and find areas for experiments.
They can test out interest in a functional topic by launching a community of interest. I have a team that is running an experiment by programming using large 4K computer screens.
-
Help Other Teams
I am often implementing Agile and Scrum in large organizations with multiple Scrum teams within a program. I encourage teams that are done to see if they can help other teams in the system. It helps them to build empathy and think about the good of the whole organization.
Focus on Learning and Cross-Training
Of all these options, I think the most important is learning and cross training. Amir Elssamadisy in his book Agile Adoption Patterns: A Roadmap to Organizational Success states that “Learning is the Bottleneck for Software Development Teams”. In other words, to go faster you need to focus on learning.
Leaders in Agile Organizations would do well to be mindful of this bottleneck. If high-performing teams are the goal, then we need to focus on learning.
Many progressive companies today have a culture that encourages learning, experimentation and thinking time. Google is perhaps the best-known company doing this with their famed 20% policy – meaning employees can spend 20% or one day a week working on anything they want.
Other companies have similar policies. They allow and expect people to spend time on thinking. Or they promote side projects or host hackathons. This includes newer companies like LinkedIn and Atlasssian as well as older ones like Apple and even 3M.
The next time someone suggests that people give 110%, maybe you should recommend 80% instead.