Does anyone have any proven ideas/methods/workshops for increasing autonomy and accountability in a Scrum/Agile team.

I have used the following thus far:

  • Definition of done
  • Working agreements
  • Roles & Responsibilities

However, I think more work is needed to get the team to really take ownership, accountability and in turn be autonomous.

Update: Examples of team not being autonomous

  • Team doesn't think ahead. If there is a story on the board that perhaps needs a technical meeting arranged, they won't pre-arrange, they will only try and arrange when they pick up the story
  • If there is a story which is close to meeting DoD, they won't necessarily think to look at it first
  • If they lose a team member, they won't arrange handovers themselves
  • If they have 2 days left of a sprint, they won't necessarily try and get the story closest one to done done first
  • 1
    If you are willing to share some specific examples of how your team is not achieving autonomy & accountability, it might help people offer better answers. Commented Jul 24, 2018 at 2:05
  • Thanks for the examples! Do these issues come up, either directly or indirectly, in the retros? Commented Jul 24, 2018 at 15:34
  • They do come up, but the team don't seem accountable at all
    – user32613
    Commented Jul 30, 2018 at 15:34

3 Answers 3


I'm the Scrum Master on a cross-functional team that initially had little to no experience with Agile. I think Barnaby's answer is great and definitely something to strive for. From what I've observed, though, if the team doesn't have a certain level of maturity (Agile-wise), they won't necessarily learn if you leave them to their own devices. If in their career, a team member has never had the space to take initiative, they won't naturally decide to do that when you leave them space. Teams need to define what self-organization mean from them, but providing some structure and nudging them in the "right" direction goes a long way, especially early on in the process. It's always hard to figure out what the right balance of guidance vs. freedom is to get the team to a point where they're a model of self-organization, but I think Mike Cohn's Situational Scrum Mastering explains this well.

I've encountered all of the issues you've mentioned, and the two things that I've found work well to address them are:

1) Using retrospectives as an opportunity for team members to become aware of those issues. Ideally, wait for them to flag them, but if they don't have that reflex yet and you think they're missing the boat, come up with a set of questions that will lead them in that direction. You can even dedicate the whole retro to a single topic if you feel it'd be helpful.

2) Showing short (5- to 10-minute) videos related to agile principles and values and facilitating a discussion afterwards. In the last few months, I've been dedicating 15 minutes to that in our weekly meetings, and it's worked wonders. I've noticed team members referencing concepts they've seen in the videos, and slowly but surely applying them in their work. I've found the Scrum Life series to be particularly helpful in that regard (slow down the pace and use English subtitles if necessary).


Helping a team to be more autonomous is one of the most difficult things to do because you achieve it by doing less rather than doing more.

As a Scrum Master, I sometimes:

  • Attend a ceremony/meeting and say nothing. There is often some initial confusion but after an awkward silence typically somebody steps up and starts to drive the meeting.
  • Hold back, even when I know the solution to a problem. I may gently prod the team but I let them arrive at the solution even though it may take a while.
  • Attend the daily Scrum, but stand a distance away or behind a pillar or some other obstruction. Don't make eye contact with anyone in the team and let them initiate all conversations.

Having said all that a team is unlikely to develop autonomy if they have no real authority. Ensure that the team is empowered to make decisions. Having a hierarchy that exists outside the team that can veto decisions is particularly problematic. Negotiate with your organisation until the team is genuinely empowered.


There are also some best practices of self-organizing teams exist. You should teach your team how to work without managers. For example:

  1. Ultimate transparency on all information by the project -- if there is one who knows more then anyone else, then team members are not equal what prevents self-organizing.
  2. Advice process -- anybody can make any decision, but he must get advice of those who are experts and impacted by the decision.
  3. Conflict resolution -- if two members have a conflicting decisions, they should a) try to resolve the conflict themselves, looking for win-win solution; b) involve an arbitrator to help then resolving it; c) involve arbitrating group.

And other practices. There are some established methodologies and approaches exist, such as:

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.