Agile for Humans
December 21, 2018
Agile approaches to teamwork and project management, with their focus on planning and learning in shorter increments, can be a big help to time-strapped teams. However, agile frameworks like Scrum — or “big ‘A’ agile” — can be difficult for many of us to apply in the real world. Practices that work well for software and tech don’t necessarily translate well to non-technical teams.
“We really need to change the perception that agile is just for tech”
That’s where Civic Hall Toronto’s Agile for Humans course comes in. Designed specifically for beginners and for people working in non-technical or hybrid teams, it breaks agile methods like Scrum into a set of individual practices — or “small ‘a’ agile” — that anyone can learn and try out with their team quickly. Participants also get hands-on experience with agile tools like team retrospectives, user stories and kanban.
The half-day workshop, facilitated by writer, agile trainer and team health expert Matt Thompson, is designed to help participants “hack the hamster wheel” of chronic over-busyness, multitasking and juggling so that teams can thrive and do their best work.
“Our default way of working has increasingly become broken,” Matt says. “Constant juggling, interruptions and task-switching are not only bad for our brains — they’re bad for the work.”
Agile can help teams better focus on their priorities by working in short, iterative sprint cycles, or “heartbeats,” with the goal of reflecting and learning from their work earlier and more often.
What does small ‘a’ agile look like?
Specifically, Matt focuses on practices that can be implemented at three stages of the sprint cycle: prioritize, execute, and improve.
At the start of the sprint cycle, create a list of all the tasks the team needs to get done. Being mindful of the team’s capacity, select the most important ones. Then, prioritize tasks based on what absolutely needs to get done during the sprint cycle (e.g., the next week) and what would be nice to get done. Matt says the goal is to be “less busy, but more effective.”
Limit the amount of work in progress and get more tasks done. Focus on one thing at a time, in order to reduce the cognitive cost of switching between tasks.
“Reflective practice is agile’s single-most powerful tool,” Matt says. At the end of the sprint cycle, have team members individually reflect on what went well and what could have gone better. Then, come together as a team and synthesize everyone’s thoughts. Based on the top reflections, generate action items to improve for the next sprint cycle.
Agile in action
At the most recent Agile for Humans course, delivered Dec. 4, 2018, Spencer Daniels, Senior Product Manager at the Ontario Digital Service, spoke about his team used the small ‘a’ agile process to build a new version of the Environmental Registry of Ontario.
“You don’t want the [agile] process to take over,” he said, as his team chose the practices that worked best for them rather than adhering to a strict framework. For example, they held daily team standup meetings, which helped them identify problems and potential solutions more quickly.
The Ontario Digital Service’s agile process involved a weekly design sprint cycle, starting with brainstorming on Monday, building and testing prototypes in the middle of the week, and reflecting on the process every Friday. This enabled the team to deliver a publicly available beta site in just nine months.
Making agile work for your team
“Agile is not all-or-nothing and there’s no specific way of doing it,” Matt said. The important thing is to start small and only pick the practices that are relevant. The length of the sprint cycle can also be whatever makes most sense for the team — weekly, biweekly, or even monthly.
“Agile is simply the ability to continuously focus and improve.”
“We really need to change the perception that agile is just for tech,” Matt said. “I think it offers us an antidote to the Age of Crazy so many of us are living in right now, with a smarter, healthier approach to teamwork. These techniques are too good to just leave to software developers — we just need to translate and simplify them to make them our own.”