7 MINUTE READ | September 6, 2017
Adapting Agile to Your Team
If you’re like us, you have been through some Agile training, you’re drinking the Agile Kool-Aid, and you’ve renamed a few meetings to “Daily Standup.” But for the most part, how you work and how you think about work has not changed. As a result, you are not seeing many benefits from Agile. Us too.
Here’s what we did about it.
We decided to go through a new round of Agile training to refresh everyone’s understanding and get us all on the same page. We watched a video series (which I highly recommend) then had team discussions after each video.
A few key discoveries on our journey to adopt Agile:
Flexibility is key. Use what works. Discard what doesn’t. Keep improving – kaizen!
Adopting an Agile mindset is more important than changing the name of your meetings to “Daily Standup” and titles to Product Owner or Scrum Master.
Defining your roles and your work is crucial. Get clear about exactly what a Developer does and does not do on your team. Define the types of work you do – how you get requests for work, how long each type of work takes, etc.
If you want to see results from Agile then it’s important that everyone on your team commits to going all in. An easy way to do this is by investing the time up front to clarify how you plan to implement Agile on your team. After watching each Agile training video, we sat down to discuss how we wanted to implement Agile on our team.
A key component to Agile is improving the flow of communication across your team. Pictured below is an example of how the traditional flow of communication might go versus an Agile method. The major difference is that Developers are empowered from the beginning of a project so they can speak directly with the client or coworker and better understand what exactly needs to be done. After all, Developers have the best knowledge of what is needed to get the work done so they should be in direct contact with those requesting the work.
Before you try to shoehorn everything you do into a standard Agile framework like Scrum or Kanban, it’s essential to define your work first.
As a team, discuss the following:
How do the requests for work come in?
How frequently do you get requests? Daily? Weekly? Monthly?
How long does each piece of work take to finish? A day? A month? Continuous?
How do you prioritize work?
After our team discussions, we realized we typically have big projects and small projects. Big projects have many pieces and generally, takes 2-3 months to complete. Small projects only have a few pieces of work and can be completed in 2 weeks or less.
To give you a better understanding of how we adapted to Agile, it’s important to note that our team’s work varies depending on the needs of our coworkers and clients. Besides building new analytics tools for internal teams and clients like Tableau dashboards or spreadsheet reports, we also spend time maintaining existing reporting tools and databases. We receive bug requests for fixing broken things almost daily. We receive new feature requests for existing reports every couple of days. And, once or twice a month we get requests for completely new reports like when we sign a new client for example.
As you can see there are a lot of requests coming to our team, and we needed a way to manage all these. Our primary tool for managing requests is an internal website built by our development team. Everyone at PMG that comes to us with a request is asked to fill out a request form on the website and from there, the request is prioritized and placed in our backlog in Target Process. By using this system, the entire team is aware of all the requests coming in at any given time so requests aren’t lost, there’s a chance to discuss them with the entire team, and work can be prioritized by request urgency.
Before using the request form, only one or two team members may have known about requests which resulted in requests getting lost or delayed and ultimately, unhappy clients. No bueno.
Next, we started with the definition of the typical Agile roles – Product Owner, Scrum Master, Developer – and decided how we wanted to define them for our team.
As a team, discuss the following:
Who will take on which role?
Will some people have multiple roles?
Will some people have different roles based on the type of work?
Given your workflow, which role will handle each piece of the process?
Mostly, our definition matched the roles as defined by the Agile training but we took the time to cover more specifics in our workflow. We talked through various, common scenarios that arise and who would handle each piece. We documented this to provide further clarity and a reference for new team members. In keeping with the flexibility mantra, this document will certainly evolve over time.
With clarity around our work and our roles, it was much easier to make the Agile framework work for us and not against us.
As a team, discuss the following:
Will you use Kanban (continuous flow of work) or Scrum (work divided into Sprints)?
Will you do Daily Standups, Planning Meetings, Retrospectives?
How long are your Sprints? One week? Two weeks?
We adopted the Scrum framework using one-week Sprints. We do a Daily Standup each morning along with the Sprint Planning and Retrospective meetings each week.
We divided our roles based around our big projects and small projects. For big projects, Beverly is Product Owner and I act as Scrum Master. For small projects, I act as Product Owner and Scrum Master. Again, flexibility is key.
For now, we handle big projects in more of a traditional project management way – we have a spreadsheet with a list of features and approximate times of completion. These features get turned into User Stories and added to our Sprint as we progress down the list. This “project plan” provides a method of communicating to clients the features they want and the progress we’re making on them. On the backend, the work is getting managed in an Agile way.
A challenge that continues to pop up is whether we use Kanban or Scrum. Our big projects fit well with Scrum while our small projects lend themselves to Kanban. If your team is faced with similar challenges, here is a great article discussing how to combine Scrum and Kanban together: Scrumban. Our compromise between Kanban and Scrum is to use Scrum but only allocate enough work to fill about 80% of our capacity for the Sprint. The remaining 20% remains open for unplanned things like bug requests. This flexibility allows us to handle the unplanned requests with minimal disruption to our planned work.
As you adapt Agile to your team, remember to be flexible and try things out. Some things will work. Some won’t. It will take time and attention to get it right but the rewards are a well-functioning, empowered team providing great value to your clients.
Stay in touch
Subscribe to our newsletter
What challenges have you had adopting Agile? How have you solved these challenges?
Posted by: Nathan Glass
4 MINUTES READ | August 30, 2021
2 MINUTES READ | February 4, 2020
2 MINUTES READ | September 4, 2019