It’s been a decade since the McGill web development team began using Agile, and looking back, we have come a long way strengthening team collaboration and improving our ability to deliver work frequently and quickly. We must have had over 300 meetings just to celebrate successes and discuss how we could improve our process. I’ve learned a lot as our team’s Scrum Master, and I recently became Scrum Master certified to see if I could further improve in my role. During the training, I realized what a mature team we have become over the years and I wanted to share our experiences.
Before you read further, it's best we clarify a few Agile terms.
Points: Estimate of effort or complexity of the given task.
Scrum Master: Responsible for managing the Agile process.
Daily Scrum: 15 minute time-boxed meeting for micro planning. It's not a project status update.
Work in Progress (WIP): Number of tasks the team is currently working on.
If you haven’t already heard about Agile, it’s a method to help small teams (3–9 members) become adaptive to change and deliver value quickly by maximizing their efficiency and eliminating waste.
Agile — as defined by ScrumGuide.org as: A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Although primarily used in software development, Agile has also been successfully adopted by other industries including the communications field, notably at NPR.
Okay, so big names use Agile, but will our methods or mindset be applicable to other teams in our organization? Do other teams in a university setting share the same challenges? Are other teams doing things that we can learn from? Can this work for non-IT development teams?
Over the past few years, I’ve assisted a handful of teams with adopting Agile, for instance, McGill's Digital Communications team and, most recently, the communications team at Research and Innovation, which was a great learning opportunity.
“Adopting Agile has transformed how we work together,” says Meaghan Thurston, Senior Communications Officer, Research and Innovation. “Our daily scrum meetings and regular retrospectives encourage more face-to-face discussion and help us to visualize priorities and projects, while also promoting a sense of collective leadership. What’s more, we’ve had fun counting our weekly ‘points’ — it gives us a great sense of accomplishment to see what we can accomplish on a daily and weekly basis.”
The first challenge was to find an Agile strategy most suitable for a team with small projects and ever-changing commitments. You will find many different flavours of Agile and many passionate blog posts scattered all over the Internet describing a multitude of techniques and ideas. I suggest at first that you stick to reading the official documentation of two popular Agile strategies: Scrum for product development teams and Kanban for non-product teams.
Kanban practices are defined in the official guide as:
Visualization of the workflow
Limiting Work in Progress (WIP)
Active management of work items in progress
Inspecting and adapting the team’s definition of “Workflow”
I hope the following notes provide some insight and help you avoid some of the common stumbling blocks we’ve witnessed.
Before you start
Read the official Scrumguide for product development teams, or read the Kanban guide for non-development teams. If you have time read both.
Schedule a 20-minute Daily Scrum with your team.
Choose a system for gathering consensus quickly. We like to list all the choices on sticky notes in a place where everyone can see them. Provide team members with three votes that they can apply to any of the options. If you really believe in something, you can place three votes on one option!
Create a board to visualize progress of tasks and illustrate priorities. We suggest you only create task if it can be tied to a deliverable. Review the board daily to make sure you are working on what you earlier deemed as a priority. Spoiler: We often don’t.
Image by Jason Delmarr.
Essentials to facilitate the process
Have a clear idea which task is more valuable
We have been successful sharing knowledge and completing tasks sooner when we limit the number of priorities we handle at one given time. This boosts productivity and morale as well. While the team is committed to the priorities set, it’s the Product Owner’s job to shield the team from external distractions and unrelated meetings.
Create tasks and update the board
You want to visualize all the work your team does, but that can become overwhelming. As mentioned, it’s best to create tasks (sticky notes) that produce a deliverable. You may want to group tasks related to certain projects. Breaking tasks into small pieces is a must. Having a general idea of how much effort or complexity is involved will become useful for capacity and general planning. If a task is too big — a five-point issue is our red flag — we need to figure out how we can split the issue into smaller completable tasks. A zero-point task can also be useful for a task you don’t want the team to lose track of.
Set the team up for success
Give your team every opportunity to succeed at the task. If an issue is raised at the Daily Scrum, remove impediments quickly. This will maintain momentum and demonstrate leadership.
Have the team take a sincere look at repetitive tasks that don’t bring much value and remove these low-value issues. This may be an ongoing task for a few months but will have great payoffs. It’s best not to lose sight of improvements contributing to the effectiveness of the team. Make sure these great findings don’t sit on your todo list too long. Consider if your team can afford to not make these improvements.
Reflect and revise
Having the team revise the process is arguably the most important aspect of these frameworks. Making modifications during the process just makes sense. Post-mortems are helpful but will only benefit similar future projects, and we can’t be sure when one will be initiated and if the same team will be assigned to it. Focusing on improving the process as early as possible is key to success and accountability in Agile. Every few weeks, check back to see if the team or manager implemented the corrections.
Understand your average capacity
While you’re reflecting and revising, be sure to pay attention to how much work the team can complete in a short cycle — for example two weeks. Repeat the process and see if delivery output remains consistent or improves in the next cycle. The goal is to understand how much planned work is optimal for continuous delivery, avoiding pitfalls like context switching and multitasking.
A continually refined process that is followed systematically keeps expectations clear for all team members. The consistency of output can bring a lot of insight when determining how much your team can produce, therefore maintaining established quality over a given period.
Provide focus on improvements
It’s likely there are many improvements to make; starting this journey can be daunting for sure. The following chart was useful to teams deciding which improvements they should tackle first. A voting system works great for quick consensus here.
Agile instills repetition to normalize positive patterns. The Daily Scrum is an easy first step to get the ball rolling, however, it's not enough by itself! The Retrospectives, Product review, and Planning meetings, as well as the Daily Scrum, when incorporated will support inspection and adaptation. Daily Scrum should be a short update meeting usually no longer than 20 minutes.
Listen and facilitate
Having the Scrum Master facilitate discussion and listen to feedback is key to improving team collaboration and productivity. Listening to what the team needs instead of telling them what you think they need will inevitably take you farther. Trust in the team’s ability to inform how the process should change for better delivery and an effective working environment.
Account for uncertainty
Estimating the complexity of tasks is a great tool that will help highlight parts of projects that need more investigation and provide a clearer understanding of what the defined scope entails. Agile really flourishes in this respect by incorporating what we have learned during the process to inform delivery and future planning. One strategy is to start working on the hard stuff early. Empowering teams to highlight problems and challenges earlier can only lead to a better product and a better guess of completion dates. Build a culture where team input determines whether the project is a success or not.
Invest for the future team
A good team is of the highest value and will make future projects more enjoyable and easier to navigate. Making team improvements a priority is key. We can’t count the number of times we wished we made our lives easier earlier by creating templates, automating workflows, or updating our tools. Ask during the Retrospective where the team is struggling and make each problem an action item to address. Also, someone once said ‘if you think something is important, make someone responsible’. Assign a Scrum Master.
Management Involvement
In Scrum, there is a designated role of the Product Owner which is defined by the Scrum guide as:
The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team.
We have encouraged a similar concept in KanBan. If regular cycles are used to support retrospectives and planning, this is an excellent opportunity for a director or manager to clarify new work while reviewing and modifying priorities. In addition, any impediments that are pending and blocking the team from delivering can be restated. Transparency and regular updates can improve visibility and accountability from all members including management.
Leadership culture
Power hungry? You’ll need to leave your ego at the door for this to work well. Individuals advocating for their personal approval and ‘final says’ undermine the team’s ability to do great work. A bottleneck driven by ego slows down delivery, removes responsibility from the individuals doing the work and therefore, reduces engagement. Instead, help by building guidelines, preferably with the team, to assure quality. Want to lead? Be a servant leader. It’s worth repeating: leadership in Agile is about team empowerment, not leading by a title or position. The official Scrum Guide defines Development Teams as:
They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis;
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
Kanban strategy also promotes teams’ self-organization to ‘Inspect and Adapt Workflow’:
When applying Kanban, The Scrum Team will want to supplement The Scrum Guide with more explicit policies for its process. Those policies will be captured in a Scrum Team’s definition of “Workflow”.
Final thoughts
Success comes with practise. An Agile process sets norms by repetition.
A clear, consistent environment helps deliver reliable quality over time.
Try to adopt the frameworks as closely as possible and then adjust as needed. The official scrumguide.org website is a concise resource worth revisiting.
Scrum works well with product delivery; Kanban works well for operations and ever-changing commitments.
Visualize all work, including reccuring tasks, projects, and operations to better see how you can improve delivering value.
You can always start Agile with the Daily Scrum; be aware that not including the other events results in reduced transparency and is a lost opportunity to inspect and adapt. Agile most likely won’t solve your biggest issues right away, however, it will provide a framework to uncover inefficiencies and challenges that your team encounters on a regular basis. Teams seem to appreciate the initial improvements, but Agile’s benefit really comes from consistency over time.
12_agile_principles_applied_.png
