Issues with team, management and clients to run a proper scrum team

Question

Problem:

I am a scrum master ad I've started working with a new team 3 sprints ago. When I started I was warned about the team because they:

1. Has never completed a sprint
2. Politics within the team

When I started I thought OK I can solve some of the issues to complete at least one sprint. The first sprint I noticed a few issues that that I would like to change such as:

1. Three week sprints
2. They are comfortable to carry items over from one sprint to the next
3. Product owner actually test the sprint items - Acts as an tester.
4. Scrum roles and processes are not 100% defined.
5. Someone predicted the sprint velocity (That I think is incorrect)
6. Team is very discouraged
7. They want to add development team members every time something goes wrong
8. Scrum is not followed 100%
9. Obsessive report generation

Solution

1. Three week sprints

I want to suggest two week sprints, this gives opportunity to adapt using retrospectives. I also feel like team "Chills" the first week and the next two weeks they push hard.

2. They are comfortable to carry items over from one sprint to the next.

I've made sure they break tasks down to workable and accomplishable tasks. I've asked the question and got an answer

3. Product owner actually test the sprint items - Acts as an tester.

I've suggested she does what a product owner should do: What is a PO But she insist she needs to test each task (I understand her Point of view) because she is an expert in the area. But if the acceptance criteria is clear then there is no need for her to test.

4. Scrum roles and processes are not 100% defined.

Fist we have one tester (User Acceptance Tester) for all developers.Then we have a "Business Specialist" and she does not really do anything to help the team accomplish sprints. She tells the architects how to architect. For example she said "There is always a place for hard coded in a system". As mentioned we have a Product owner that does more testing and closing tasks than doing what a Product owner should do. If a PO wants to test she can but should not become a bottleneck. I've asked the question and got an answer

5. Someone predicted the sprint velocity

Before I joined the team the CTO worked out that the velocity is 60 story point and we need to do that every sprint to achieve our goal. The architects and Product owner said this wont be achieved. The data he used it not reliable. I've asked the question and got an answer

6. Team is very discouraged

The UAT tester does not talk to the Product owner because they cant see eye to eye. The UAT is a very rude employee and she does not want to be in the office because she has to drive an hour to get to work, and she would rather be at the main office which is a few minuets from her house.

They have never achieved a sprint except two sprints ago, where I helped a lot. There is a communication issue and that cased us to not achieve the previous sprint.

7. They want to add development team members every time something goes wrong.

I get constant calls from CTO where he says they want to add another developer to the team to achieve sprint. I've explained this will drag the team down but they don't listen. (We have a weird setup)

There is two projects that are done concurrently. We have one developer for that project A (Not that important project - Not my words) and the tester, Product Owner and two architects is the for project B (Important project - Not my words). So that is a development team of 4 people excl PO.

Project B has the same tester, Product owner and architects but the project has 8 developers. This team is a size 11 people, excl PO.

9. Obsessive report generation

I have to send out a daily report to stakeholders containing info such as: Burn-down, Sprint goal RAG status, Date when item is Projected and actually in development, code review and testing. Cumulative area burn-down. My team is transparent and the stakeholders can walk up to our actual or Jira board and see statuses.

As you can read scrum is not followed 100% and to make changes is hard because of the client and management at my company.

What suggestions do you have to fix some of the above scenarios or fix all the issues as a whole?.

Answer 1

Let's take number 8 first. Is the team committed to practicing Scrum? Is the company committed to it? The answer may not be what they say. They could say yes, but then not be willing to actually follow the Scrum Guide, in which case the actual answer is no. You need to know this to know how to continue.

For the rest:

1) 3-week sprints are not completely uncommon and well within the Scrum Guide window. However, shorter sprints often help when teams are struggling with effective sprints - it's just a shorter amount of time to manage.

2, 5, and 7) These suggest that the actual plan is many months long, which is exactly what Scrum tells us not to do. If the goal is just to meet the deadline 9 months from now (or whatever it is), then why would I worry about spillover work, sprint-to-sprint velocity, or delivering increments with the team I have today? If the answer to #8 is yes, then they would need to adopt a truly iterative, incremental, and adaptive mindset to their work. If they aren't willing to do that, then the answer to #8 is no.

3) Is verifying each story stopping them from doing their job as PO? Is it possible to focus on the things the team needs to do as PO and if those get done and she wants to do deeper testing, then it probably doesn't hurt.

4) This is a little confusing to me. Scrum has just 3 roles.

6) I'm not there, but throws red flags as a personal conflict that's gone on too long. Why can't she work at the other office? I know face-to-face is more efficient, but that seems really solvable. A team I was on had a member way up in the NW territories in Canada and we just set up a video feed between our team room and his office that he turned on in the morning. It feels like this doesn't have to be a sticking point.

One of the most common misconceptions I encounter is that Scrum can be used to make a waterfall project run faster. It sounds like that might be the kind of situation you are in. Of course, it doesn't. It's a different mindset and requires a different approach to the project. Again, my questions around #8 seem like the linchpin to me.

Answer 2

what a story! It seems that you are working in a difficult environment. Here are my two cents:

Three week sprints

Covered in your question, but It does not have to an issue that a sprint lasts three weeks, but I must admit that when we changed from 3 to 2 weeks there was slacking around. I believe this is a team mindset, they should be able to perform with the same effort in a two week sprint than a three week sprint. But as said, the two week one works better here as well. Changing it seems like a good place to start

Carry work over to the next sprint

Do you have a proper planning session in which you determine the amount of work that can be completed? If you do, the team 'commits' to a certain amount of work and should really try to complete it. If you think the low motivation is a problem, try to get them to open up during a retrospect to tell each other what they need to be motivated. You would be surprised how little people might need to be motivated

PO testing stories

The PO should not test the stories, she should confirm with stakeholders that the implementation is what customers need. This can be done in the review meeting or in a UAT environment after the sprint was completed. If the PO becomes a bottleneck in testing I would try to make that visible. Assign her to the story that she is testing or needs to test and make sure she knows she is holding you back. E.g. by writing a simple report with the information: Start date | development complete date | test complete | PO test complete This would easily show that you are done but that the PO is blocking you.

Scrum roles and processes are not 100% defined

This should be easy to solve, define the roles and processes. E.g. for a business analist you could define that they have to write stories that are functionaly clear. This means that the stories says what needs to be accomplished, but now how. The how belongs to the team that does the work. Please note that I found this part very difficult to get clear, and after 4 years we are finally at a point that people start to understand what the limitations of their roles are.

Someone predicted the sprint velocity

That is weird, you do not need to predict the velocity, it can be calculated by dividing the total number of story points with the number of sprints. This is actually a fact that cannot be denied. If the last 5 sprint you completed 40, 45, 30, 45, 38 story points, than you can calculate the velocity: 198 story points / 5 sprints = ~39 points. this could be affected by new people joining the team or vacation / sickness of team members, but that's about it.

They want to add development team members every time something goes wrong

Adding a resource will obviously increase the velocity, after a period of a lower velocity while getting that person up to speed. But I think the best way to get a good velocity is by having a dedicated team. From what I understand team A and B share developers, which is not very efficient. Would it be possible to divide the resources per project so that they no longer share developers? Then it would make sense to add a new developer to the team

I hope you can do something with this, or that somebody is able to help you out further

Answer 3

I think your main problem is that your team is not a team. Many managers put people on the project and start to call them a team, where in fact you need to invest time and money to create a team.

But if the acceptance criteria is clear then there is no need for her to test.

Remember: in agile user story is done when all the talks - development and testing - are accomplished. Of course acceptance criteria has to be clear, but we need to test it to make sure that we developed exactly that. I suggest you to read "Perfect Software: And Other Illusions about Testing "