Back to List

Roles and Responsibility Activity (Habits of a Successful Agile Team)

Rachel Rieck Rachel Rieck  |  
Jul 11, 2019
 
If you have experience on agile teams and are looking to tweak a few things or try something different, then this blog series is right for you. This is the third blog in the Trifecta of Greatness series. For more background on the strategies and tactics our Solutions Consulting Director learned from a pivotal agile journey, be sure to check out the first two installments.
 
RACI, for those of you in the waterfall days, was an activity where you'd fill out a spreadsheet saying who was responsible for what, etc. Often, the Project Manager would do it. Everybody would look at it and say, "Okay," and then move on.
 
Nowadays, when you are assigned a role or a title on an agile project, everyone just assumes they understand what that means, but that is not the case. What I found over the years is that we make many assumptions based on title, but title or role doesn't necessarily mean anything. It doesn't even mean anything based on the training you've had.
 
Title and role mean something based on each person's past experience, but other team members won’t know what that is because they can’t read each other's mind. That’s where this roles and responsibilities activity comes in. I’ve blogged about this previously, but it’s worth going through again. It really helps support the project moving forward.
 

How Does This Activity Work?

During a kickoff, I give all team members sticky notes and say, "We each have this role on the project, and what I want you to do is write on each sticky note what you think your role is". Then we get busy writing.
 

Different Learning Styles

There are a couple of reasons why you do this. First, you want to see what each team member thinks their role is and reinforce it using as many senses as possible (hearing, touching, seeing). This activity uses many ways of communicating. Team members get to:
 
  • See their role written down
  • Touch the sticky notes
  • Write down their role
  • Talk about their roles
 
This way we’re going to really understand our roles. We’re also going to understand what other people's roles are. After everyone's done writing what they think, I put on my role of Scrum Master and go first so they see how this activity goes.
 
I get up and say, "Here are the things I'm responsible for". In consulting, the Scrum Master also does some light PM work. We follow budgets and timelines for our clients. We are not product-based; we are project-based. I talk about how I'm responsible for facilitating the meetings and managing the timeline.
 
After I get done describing all the different things that I believe I'm responsible for, I ask everyone, "Is there anything I'm missing, or anything that you think I should be doing or taking away?"
 

Planting the Seed of Vulnerability

As a leader, this is a great time to plant seeds of vulnerability (which is detailed in the previous blog in is this series). That is, this is a time to show that mistakes are welcome and it’s okay to speak up. I'm going to take an item that is not in my role, and I'm going to put it up there.
 
In our world, our Business Analysts’ like to manage the backlog, so I don't touch it. Before this activity, I'm going to talk to my Business Analyst and say, "I'm going to say that I’m going to manage the backlog. Make sure you call me out on this".
 
When I'm standing in front of the whole team and I say I'm going to manage the backlog, that Business Analyst going to call me out and I'm going to reply, "You know what, you're right". Then I give her or him the sticky note for their role. In this activity, the team is collectively agreeing on what your role is.
 

Knowing Your Role Doesn’t Limit Agility

Scrum says everybody comes together and fills whatever role the team needs. I totally agree. But it’s nice to have defined roles so you know what your primary role is, and then you can jump in and help where needed beyond that.
 
After I'm done presenting my role as the Scrum Master, I'll pick the next role in line (usually Business Analyst, Tech Lead, Developer, Quality Assurance) and we'll do the same thing. They'll plant another seed of vulnerability somewhere with somebody else, so the other project members can understand it's okay to not be perfect.
 
By the end of this, you have a good idea of how the team is going to work together based on how you've defined your roles. Maybe you don't have a Business Analyst; maybe you don't have a Tech Lead; maybe the team is all Developers. It doesn't matter. The work has to get done. Having an idea of how that's going to work is going to help kick off that project.
 
The next step is reinforcing the process.
 

Watch the Full Presentation

This blog is an excerpt of a 33-minute presentation on The Trifecta of Greatness: Creating and Capitalizing on a High-Performing Team. To get all the tips right now, watch our free video.
 
trifecta of greatness
AgileScrum

 

Love our Blogs?

Sign up to get notified of new Skyline posts.

 


Related Content


Blog Article
Pre-Project Components That Can Impact User Adoption
Cory SchmittCory Schmitt  |  
Sep 12, 2019
Does the following situation sound familiar?   You were on a project that rolled out a new application to the organization. You and the team spent many long days (and some nights) building the new application. The team worked hard, and you came in on-time and on-budget. As part of the...
Blog Article
Using Human Hard-Wiring to Create a Strong Agile Experience
Rachel RieckRachel Rieck  |  
Aug 22, 2019
If you have experience on agile teams and are looking to tweak a few things or try something different, then this Trifecta of Greatness blog series is right for you. For more background on the strategies and tactics our Solutions Consulting Director learned from a pivotal agile journey, be sure...
Blog Article
How to Use Prototyping to Model and Analyze BI Requirements
Rachael WilterdinkRachael Wilterdink  |  
Aug 15, 2019
If you’re involved in eliciting, modeling, analyzing, or consuming requirements for Business Intelligence projects, this post is for you. This is the tenth and final technique in our blog series on 10 Techniques for Business Analysts (BAs) to model and analyze Business Intelligence (BI...
Blog Article
Decision Rights, Team Lead Communication, and Smackdowns (Habits of a Successful Agile Team)
Rachel RieckRachel Rieck  |  
Aug 08, 2019
If you have experience on agile teams and are looking to tweak a few things or try something different, then this blog series is right for you. This is the fifth blog in the Trifecta of Greatness series and highlights a few last habits and techniques. For more background on the strategies and...
Blog Article
How to Use Process Modeling to Model and Analyze BI Requirements
Rachael WilterdinkRachael Wilterdink  |  
Aug 01, 2019
If you’re involved in eliciting, modeling, analyzing, or consuming requirements for BI projects, this post is for you. This is the ninth technique in our blog series on 10 Techniques for Business Analysts (BAs) to model and analyze Business Intelligence (BI) requirements.   What is...