I am part of a small company that has 6 developers and 2 support members. this team has been participating in "Agile" development practices for the past 3 years. The Agile/Scrum method has never been truly adopted. They would simply just use a Backlog to look at everything the team was doing, and use Sprint meetings to update what they been working on for the past day, and what they are working on right now. After not seeing any yield from this methodology I was brought in as Scrum Master to improve the teams cooperation and effectiveness.

So far I have the team now assigning effort to items and measuring approximate work. However, the team seems to still be stuck in their methods of this is my work and I only let you know progress updates. There is a serious lack of team work when approaching backlog items and tasks. Everything that team approaches has a monolithic approach. The idea that this backlog item will only be approached by one developer until it is done. I want to transform this culture that has been so pervasive in this team. What is the best way as the Scrum Master to get this team to work together as developers?

I am sorry if I was not clear enough. If you need any more details I will be happy to give you more information.

3 Answers 3


This is a great question and a common problem in adopting agile. Most often I see two factors as the major contributors to this situation.

First, people may feel that they have to stay busy. There's the idea that if everyone divides an conquers, they can work more efficiently and get more done. This isn't completely untrue. If multiple developers work on a single story, they'll probably divide up the work going into it and work in parallel on it. If this is the pervasive attitude, you can try uncovering how the same approach can get individual stories done faster.

Second, there may not be a priority on delivering capabilities. In many teams, the PO brings a goal to the sprint that requires a focus on certain backlog items. This is often a constraint on the team because the work each member feels comfortable with will likely not match the work that needs to get done. If you hear statements like "I don't have anything to work on in the sprint" that's usually a flag that this isn't occurring in the team. This is a nice problem to have because encouraging the PO to bring in those goals feels more like an improvement than correcting a problem and you can see the change very fast.

  • These are two factors I see in the team for which I'm Scrum Mastering now. This is good advice. This is why Ken Schwaber calls the PO role the "lynchpin" role in Scrum. Focus on encouraging the SM (or you) to enable/train/coach the PO in all things Scrum. If the vision and (good) demands of the PO exceed what any individual on the team is likely to satisfy, they have powerful motivation to improve their way of working. Read Dan Pink's "Drive" for insight into the basics of human motivation. Here's a video to get you started: ted.com/talks/dan_pink_on_motivation?language=en Commented Jan 4, 2016 at 16:44
  • Also, have you @Daniel come across any good studies or proofs that demonstrate the pair/mob approach vs 100% utilization approach? This may be of use to the OP and his/her SM as well. Commented Jan 4, 2016 at 16:50
  • @Daniel Thank you. I have been reading some stuff from the scrumguides.org. I think some of the issue with our sprint are with the PO. Unfortunately, we have a committee, ran by a father, son and daughter trio, not a PO. So, I am thinking my first order of business is to straighten out the upper management before we enact changes to the team level is to get a consistent PO. Commented Jan 4, 2016 at 17:52

You're in a transformation that needs to be supported by both execs and the team. Bottom-up transformations usually fail. Some ideas:

1) You need management support to set a clear expectation that Agile teams are the chosen path. Your management should understand and radiate the concept of an Agile team. If that's not there, find another job or take off your SM hat, and put on your Agile coaching hat with the execs.

2) Get higher ups to interact with the team and start asking how they are continuously improving. What did they agree to do during the retrospective to improve; your team needs to understand that managers care about and want to see the team set CI goals

3) Get someone fired on the team. You may have a group of individuals with 1 or 2 bad eggs that are bringing everyone down. Getting them off or out is often one of the best ways to create the fundamentals for a Agile team to actually form.

4) Coach all the team members in 1 on ones. Get specific topics and get support from management to help reinforce those topics.

5) Have a team reset where the team creates a new charter, working agreement, and definition of done. Don't assume that all team members are bought into their current operating agreements since on many transforming teams waterfall/non-empowered processes and practices are often carried over and the team members don't understand they can challenge those practices on an Agile team.


Often, it takes examples for people to "get it". Agile doesn't really lend itself to teaching by PowerPoint. To understand agile, you need to do it.

The good news is there are many exercises, some very simple, to demonstrate concepts like Teamwork, Batch Size, Work in Progress limits and so on.

Batch Flow or The Penny Game: This exercise is perfect for showing how working in smaller chunks (and reporting more often) will lead to getting more done. You can do this almost anywhere and if you don't have coins, teabags work as a good substitute. Multi-Tasking Myth: This is a super simple exercise that is equally effective with teams and managers. All you need is a pencil and a paper. Dive the paper into three columns labled "ABC", "1,2,3" and "Roman Numerals". In the first round the players write down the letter A, the number 1, numeral I and then start on B, 2, II and so on through to letter J, number 10 and numeral X. So they are going horizontally across the page. Run the stopwatch until at least 3/4 of the players are done. Note this down. In the second round players can go vertically, so they do all the letters, then the numbers and then the numerals. Again use the stop watch. However look over someone's shoulder and as soon as they finish the letters, hit the lap timer. At the end of round two, compare the total elapsed time to round one. Then ask when in round one was any value delivered (answer- almost the very end when the J was written down). Then point at the lap time for the letters in round 2 and show how value was delivered much faster. The Ball-Point Game: This game is excellent for teaching a team how to self-organize and work together

Scrum Simulation: This is a very involved exercise that shouldn't be done until you've got them a little more on the hook. It lets you setup a full simulation of the entire scrum process and the best way to show hands on how to do a scrum iteration. The link takes you to the original XP Simulation. Scrum Simulation is based off that, just can't find any good links that don't rely on XP simulation to get you started.

I'm in the process of creating print and go exercises for most of those listed above as part of developing an end to end agile workshop. When I'm done, I'll update here with the link to download the exercises.

  • Did you create those slides?
    – Dagelf
    Commented Jan 6, 2016 at 12:05
  • Sorry, it's going to be a couple weeks more at least. I'm building an entire two day agile class and these exercises are part of that. You can check back here or keep an eye on my blog site TheGorillaCoach.com Commented Jan 6, 2016 at 17:48

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.