How to encourage teamwork instead of individual focus?
How would you encourage teamwork when your team seems to be working as individuals?
I'm a Business Analyst in a team and I'm experienced with Scrum. I'm not the Scrum Master but I try to encourage Scrum values and working in an Agile way. We have a relatively new Scrum Master and a team working on an internal software product.
I've noticed a few things in the last few months since I've been in the team around teamwork:
- Development completing then "handing over" to testing
- The team, including the Scrum Master, refer to groups within the team such as "front end team", "back end team", and "test team".
- The team writing user stories based on horizontal slices and disciplines and referring to them as "UI stories", "back end stories", and "test stories"
- The team including the Scrum Master referring to "your board" and "your tickets" rather than the team's sprint board.
- A desire by the developers to bring more work into the sprint to keep busy, even though those doing the testing are building up a queue of work
- Sprint Planning involves asking the developers "which of your tickets do you want to bring into the sprint" and no discussion as a team or input from the PO
- Team members looking at the backlog for work that aligns to their discipline (e.g. front-end developers looking for UI stories, back-end developers looking for back-end stories)
I'm aware there's no such thing as back-end stories and that we should all work as a team towards the sprint goal, but education and encouraging the team are different things.
I've tried to encourage user stories that cover all layers of the system, and ask the PO what stories are important to work on, and mention that if we focus on keeping the developers busy by bringing in more work then we won't get it completed in a sprint. The team isn't creating a done increment every sprint.
It seems like a mini-waterfall and I'm not making much progress with convincing them there's a better way.
Perhaps there are small areas I can focus on first (e.g. discussing sprint planning with the SM) or some questions I can ask.
The first thing that comes to mind is to teach the team about a Sprint Goal. The Sprint Goals helps teams work together rather than as individuals.
The team isn't creating a done increment every sprint.
There's a lot to work through based on what you've shared. The whole point of Scrum is to have a done Increment by the end of the Sprint. It might help to have the team go through a Scrum refresher training to all get on the same page.
Thanks Chris, that's a good suggestion. A Sprint Goal is another issue in the team, we've been writing a sprint goal at the end of the sprint planning and it always contains 3-5 different unrelated points.
I've gently suggested that the sprint goal should be the single focus for the team, but it hasn't really been accepted. I suspect the team is using the sprint goal to summarise the sprint for reporting to stakeholders.
I'll teach the team about the sprint goal before our next planning.
The team isn't creating a done increment every sprint.
Scrum is a means of establishing empiricism under conditions of high uncertainty. Without a usable increment there can be no empirical feedback. Even if no-one really cares about the Scrum framework, I'd wonder about that, and why stakeholders get reports rather than value.
I would say let the change start from you. For all observations that you listed, your team is be the best validators. Use the retrospective to share these points with the team and see what is their opinion or view point.
The division of stories by front end and back end is all depends on how your product is defined. Check the perspective of the PO about this.
You can discuss with your SM about the deviations from the Scrum guidelines.
Reading I was thinking 2 things:
The Definition of Done must not include 'releasable' and 'tested', because that is just not possible. See whether something is possible: the PBI must be tested to be "done", and if it is done, it should be releasable. This means UI, backend and testing persons need to have their work done.
The second thing are WIP limits: try experimenting with a limit of work in progress. If you keep lowering that, people will have to work on the same story together. You can also combine UI, back end and testing stories into 1 story that then 3 people work on. In that case, the WIP limit can maybe even be 1/3 of the available developers. (try 1:1 to start, and then lower it as an experiment)
Of course, you need to convince the team to do these things, and that may not be simple. But, there is no obvious problem having specialism in the team: someone can be a UI specialist and work with a back end specialist and a tester to make a feature.
Construct the PBIs as fullstack items.
Focus on getting feedback early e.g. encourage demo and feeback many times per sprint.
Reduce the WIP:
Showing something in order to obtain feedback often will help here.
Use the tools to hand too.
Encourage the team to Task out the PBIs.
At the standup walk down the board asking "is there any reason why this item will not get to Done today?" if the answer is it will take more time then ask why others are not helping.
Without a usable increment there can be no empirical feedback. Even if no-one really cares about the Scrum framework, I'd wonder about that, and why stakeholders get reports rather than value
Ian, good point. There are a range of discussions and meetings which I believe all come from a lack of a usable increment and a sprint review. It's something I can bring up with the team.
Use the retrospective to share these points with the team and see what is their opinion or view point.
Thanks Balaji. I can bring these points up in the Retrospective. I've brought up a couple in the past and the team has been open, so I feel it's a matter of slowly and patiently making improvements and suggestions.
See whether something is possible: the PBI must be tested to be "done", and if it is done, it should be releasable.
Good point Mario. Our DoD includes several things such as automated tests passing, and validating with Product Owner. But I don't think they are releasable because of many other steps we need to take to get it released (automated tests don't run on any environment other than the local environment, a bunch of other tests and approvals need to be done as well). A long term goal for me in this team is to help the team expand their Definition of Done to enable a story to be releasable when it's done.
The second thing are WIP limits: try experimenting with a limit of work in progress
I'd love to introduce WIP limits, it's a good theory to improve flow and teamwork. I'm not sure if the team would be open to it, as they're very focused on individual stories and full utilisation, but perhaps this is all the more reason to suggest it!
Niall - great ideas to help with teamwork and feedback. I can bring them up with the team.
It is simply a slow process. You need the buy in of your team. A good start is to let all members of the team take part in a Scrum Master training. So they can discuss on common basis and find for themselves, that splitting the team is not the best ideas.
On the other hand: Not all team members need to do all tasks and members may specialise in my opinion.
no discussion as a team or input from the PO
That is something you could adress or discuss with the Scrum Master by simply showing the Scrum Guide. It is clear, there need to exist some kind of priotisation of the backlog.