Developers in Scrum Team: ineffective and not functional

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.