How Slack Time, Experimentation and Learning Affect Agility

Anthony Mersino
June 26, 2017

One question that I get frequently from leaders during Agile training is about how to make sure everyone is busy.  How do we make sure that we are getting the most out of every person?  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.
Sadly I had participants from a particular Chicago company in one of my Agile training courses 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 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.
I've even had teams in Scrum training that had difficulty with slack time in the sprint. They make the case that if they have some time at the end of the sprint, they should bring in a new backlog item even if they know they cannot get the item all the way to "done" in the sprint. I discourage them from doing taking on that work and getting it partially done since it decreases 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 in a Scrum team is OK, healthy even. Here are some specific things that teams can do to leverage their downtime, protect their agility and help them to go faster in the future:

  • Learning & Cross Training - It takes a long time to build 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 activities.  They can even go out into the field and do some observation of their product being used, or talk to end users.
  • Reduce Technical Debt - Refactoring code or removing other technical debt is another great way to use spare time in a sprint.  I encourage teams to have a backlog of technical debt items that is available to them to pull from.
  • 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 the other tools that the team uses.  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.
  • 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.

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.

Many progressive companies today have a culture that encourages learning 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 about thinking time and side projects.  This includes newer companies like LinkedIn and Atlasssian as well as older ones like Apple and even 3M.

There are other companies that shortchange any type of learning, including Agile Training Courses.  They don't want to lose an hour of developer productivity because they see that as inefficient.  They don't want to cross-train because we already have one expert who can do that work.  Don't be fooled by the efficient argument!
So the next time you are asked to give 110%, maybe you should offer 80% instead.

About Anthony Mersino

Anthony is passionate about helping technology teams THRIVE and organizations TRANSFORM.  He loves partnering with organizations to help teams with Agile thinking and the Scrum Framework.  He teaches Agile and Scrum as well as the cultural elements that are necessary for an organization to gain true business agility. Anthony has  authored numerous articles and two books: Agile Project Management, and Emotional Intelligence for Project Managers.