Wavy lines on a blue background.
Use Agile Methodology to Better Lead Your Team
Wavy lines on a blue background.

Use Agile Methodology to Better Lead Your Team

Published in Productivity on , last updated .

A lot of teams talk about how they’re going to “do agile” or how they’re undertaking “agile transformation”. They hire consultants to teach them “One True Way” to manage a project team with Agile methodology, yet still find themselves easily screwing up their agile processes.

There is a lot of information spread across thousands of pages all around the ‘Net telling you how to do Agile methodology the right way. It’s easy to get lost in the noise and worry too much about how to perfectly implement Agile methodology

in your team.

So if you want to find out how to actually run a project team in an Agile way, go back to the basics of Agile, what it means, and how you can accomplish this in your team.

In this article we’ll go over what Agile is and why you may want to try it out. Then, we’ll give you 5 distinct tactical approaches to using Agile methodology in your team.

You ready? Let’s go!

Remembering what Agile Methodology is supposed to do

The Agile manifesto is written specifically about software development, but it’s since grown to be a philosophical approach to team leadership in nearly any field. Fundamentally, it is about inverting two common hierarchies: Individuals over processes, and response to change over following pre-made plans.

So what does that mean for a team?

It means that Agile-led work accepts that humans require flexibility in their work and in their goals. We are bad at planning beyond the immediate future, super bad at judging risk that extends beyond the next hour or so, and need to balance work and other priorities to achieve maximum productivity. Agile-led work accepts that it is way better to deliver 60% of a project on time than 100% of the project 2 years after it’s due.

When you try to create an Agile process for your team, keep coming back to the touchpoints: it is more important that you build a simple and light system that is intuitive for anyone to use than it is to create a foolproof process that takes 9 weeks to train people on.

Agile methodology is supposed to be a simple tool to align and motivate teams to create together. If you aren’t achieving that in your team, your Agile process isn’t working. Try again.

So what are the 5 tactics to manage your team in an Agile fashion? Define outcomes before work starts; Plan less, align more; create AORs & define priorities; change scope, and form new communication habits.

Define outcomes before work starts

This is easily the most important part of Agile methodology project planning.

Before your team began work on this project, there was a reason why it was worth doing in the first place. It could be as simple as “we need a better website.”  It’s important to think about the definition of done as the key first step in undertaking a project or even a task.

If the reason behind a project is “we need a better website”, clarify what needs to be done for the project to be completed. Here is an example:

WEBSITE RELAUNCH CAMPAIGN

  • Goals
    • 40% more time on site for visitors
    • Uptime >99.999%
    • Site load time <10 seconds according to site speed test
    • New branding in place on all pages in
      • Header
      • Footer
      • Replaced illustrations on appropriate pages
    • No crawl errors from moz.com tests
    • All pages have improved social media sharing images embedded in header
    • 5 pages appear as the top ranking on google.com for relevant search term
      • ….and so on.

!IMPORTANT TO NOTE! His step is not about telling people how to achieve these goals up front. It’s just about telling them what the goals are.

TO DO: Before your team undertakes its next project, take 30 minutes to think about what the goals for the project are when it’s done. Better yet, invite several people from your team to think about and define the end goals together. Be as specific as possible. Next, share them throughout the team before you start work on the project, and ensure everyone sees the end goal.

Plan less, align more

A key element to making your team more agile is to push decision making power down the org chart. Spend less time planning out every detail and more time making sure that you’ve aligned the team around the project’s deliverables. When you’re defining a project, focus on clarifying what the delivered version of the project looks like, rather than what all the specific steps are to get there.  Provided that you’ve got a team of good people who want to create something together, a lot of the small details don’t need to be planned before.

If you tried to define them all yourself, you’ll likely miss half of them anyway.  If you take agency away from your team members, they’ll get used to doing what they’re told instead of thinking for themselves, which is usually not what you want.

So once you have your goals defined, write up a small document about what you want to achieve, what the goals are, what the risks are, who the team members are, and then use that to kick off discussion with your team.

Here at Unito, we’re fans of using project charters as a lightweight document. It give people context, goals, risks, and clarifies who the team members involved are, all in one handy place. Here’s an example of an actual project charter we created for migrating our website to WordPress. With that, we defined what success looked like, explained what the deliverables were, and then basically got out of the way of the developer who developed the site. The project was quite simple, so the doc was pretty simple, but we’ve used the same short template for more complicated projects—like developing a completely new hardware device, casing, and firmware for a bluetooth hardware company.

TO DO: Take the goals you created in the first tactic above and expand them into a full charter. When the time comes to figure a timeline for delivery, ask your team members who will be working on the tasks, to help come up with timelines.

Create AORs and define responsibilities

Areas of Responsibility (AoRs) are not, strictly speaking an Agile methodology practice. At Unito.io, we’ve found that they’re crucial to building a high-speed delivery culture in every team. Areas of responsibility are a key way of pushing authority down the org chart so that team members are empowered to make choices without their manager blocking the issue.  

They’re also key because different teams have different operational tempos. Sales teams prioritize response rate over almost anything else. Marketers tend to see things in terms of distinct campaigns. Developers cherish their uninterrupted focus time. If you have too many people depending on other team members to complete their work, the number of blockers will introduce a huge inefficiency to the process and destroy the whole point of “agile” project management.

To avoid this, define your team’s AoRs. Each team member will then be responsible for the delivery and results of their AoR. This will remove unnecessary people from the decision chain, and will free them up for other work. Be sure to put AoR information in a central place, so that if anyone in your team has a question or needs something done, they can easily see who is responsible for what.

How does this look in practice?

At Unito, we use Asana to store AoR information. Every AoR has an assignee—that’s the person who owns the area. Each AoR has a description of the specific tasks associated with that AoR. This way any employee can, from his or her first day, know exactly who to ask for any type of work they need done.

TO DO: Define AoRs for all of the people who are involved in your next project. When you’re done, make sure that whoever’s in charge of the project delivery, owns as few AoRs as possible. Push authority down the org chart.

Change (& limit) scope

There are a number of reasons why projects don’t finish on time, but the #1 reason is that the scope is not defined well or it changed after the project estimate was made.

The key element to keeping teams agile is to limit the scope of what they’re working on. Trim the tasks required to achieve the end goal down to the bare minimum. And then cut some more. As an example, let’s consider the website relaunch we talked about in the first tactical tip above:

  • Goals
  • 40% more time on site for visitors
  • Uptime >99.999%
  • Site load time <10 seconds according to site speed test
  • New branding in place on all pages in
    • Header
    • Footer
    • Replaced illustrations on appropriate pages
  • No crawl errors from moz.com tests
  • All pages have improved social media sharing images embedded in header
  • 5 pages appear as the top ranking on google.com for relevant search term
    • ….and so on.

Some of these problems are directly controllable and some are not.  Let’s start by eliminating problems we can’t control from our definition of done.

  • Goals
    • Site load time <10 seconds according to site speed test
    • New branding in place on all pages in
      • Header
      • Footer
      • Replaced illustrations on appropriate pages
    • No crawl errors from moz.com tests
    • All pages have improved social media sharing images embedded in header
      • ….and so on.

Of the remaining goals, what are the absolutely most critical elements to deliver for a first version of the page?  Let’s assume that we need the new branding and that we need the pages to load correctly.

  • Goals
    • New branding in place on all pages in
      • Header
      • Footer
      • Replaced illustrations on appropriate pages
    • No crawl errors from moz.com tests

Now we’ve cut this down from 7 deliverables to 2. We can add the other deliverables back in for the next phase of the project. However by cutting every single goal that wasn’t critical to the delivery of the project, we free up the team to focus on what matters most.

TO DO: Look at your list of goals for your current project. What can you cut? If this is your first time doing something like this, you can probably cut 50% out to deliver later, if not more. Add lightness wherever you can.

Change communication habits

Meetings kill team flow. Slack kills team flow. Emails kill team flow. If you search around the Internet, there are articles about how every tool that we use is somehow the worst part about working with people. There’s some truth to that, but the real problem is that we don’t use the channels that we have well.

If you establish good practices in your team, you’ll find that productivity will soar, and the number of dropped / missed tasks will decrease.

Be sure to also decide when each type of communication is appropriate:

SYNCHRONOUS COMMS

Synchronous communication means that the communication is happening at the same time for all parties involved. There is basically no delay in getting a response. It is best used when: Urgent matter, intricate/sensitive topics, needing immediate feedback. Downsides: Interruptive, exclusionary, no accountability.

ASYNCHRONOUS

Asynchronous simply means that their is a delay in the communication process, such as via chat or comments in tools. Best used when: Need a record trail, formal nature to discussion, share docs/files, can wait for answer, multiple respondents. Downsides: Bad for complex topics, bad for urgent topics, hard to judge tone and engagement of recipients.

TO DO: Check out the best channels to communicate different kinds of messages and have your team read up on this as well. Make a plan that seems a good fit for your own needs and introduce it to your team for consideration. Decide if it feels like something that your team wants to try and roll it out for your next project if so.