what should I do to overcome the agile process related issues in my organization?

Question

I work in an organization that follows scrum process and we have been struggling to stand up to sprint commitments and are having to stretch our work hours every time to fill this gap, some times even after that we dont deliver what we have committed. Its very frustrating now as this disturbs the work life balance and even then the end user is left dis-satisfied. So I thought of getting some suggestions online to tackle the scenario, I read some links but didn't get concrete answers. So I would describe the scenario below hoping to get back some solution.

first I would like to describe the team structure : We are a team of 7 developers now including one developer who joined the team recently and are working on a project which is running from past 9 years. The team has developers with different experience levels in the project, resulting in not everyone having the same level of exposure to the project and also

Following are the questions being raised by the client side causing several escalations and a huge pressure is building up on the team. So before I counter back I would like to get some perspective on the opinion I hold , please let me know if what I think is the right approach or there could be a better approach :

1. In the past few sprints the sprint velocity has decreased even though the team size has increased : -> increasing the team size does not guarantee a increase in the velocity, instead it tends to decrease as the new member becomes more of a liability to the team. Also many of agile links I read stated that the team velocity is unknown when the team is new, the project is new or in case new members board the team or old ones leave.So the approach should be to take a few steps back and start with a lower velocity that the team can achieve rather then enforcing them to deliver at the same rate.

2. Things to consider while sizing a story : ->given that we have team with different level of experience in the project, should we also consider the analysis time taken by the ones who have less exposure to the application, as its possible that for a person who is working in the project from last 5 years things are clear and he might feel that the size should be 5, while for the one with 1 years of experience in the project might spend additional time in analyzing resulting in an increase in the size. Also since every individual gives his own estimate for a story, is it fair to consider the analysis time needed while estimating the size ?

3. We have a scrum master who is also part of the production support team for the application, which means he is well versed with the application both functionally and technically -> is scrum masters involvement in estimating the size of the story the right approach or its entirely the development teams decision and scrum master has no word to say in this. as we have had cases where our scrum master went down to saying that its his personal opinion that the team gives more size to the story then needed. this kind of involvement by the scrum master is now having an influence in the sizing game and the team is not able to give sizes freely.

Answer 1

Scrum has no commitments, just a forecast:

One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of “forecast” in regards to the work selected for a Sprint.

Read these two blog posts about why this change was implemented:

• https://www.scrum.org/About/All-Articles/articleType/ArticleView/articleId/95/Commitment-vs-Forecast-A-subtle-but-important-change-to-Scrum
• http://searchsoftwarequality.techtarget.com/answer/Scrum-team-commitments-More-harm-than-good

Answers to your questions:

1. Use yesterdays weather technique and eventually you will find the real velocity of the team. This could take some sprints.

Here’s how it works. First, the Team determines their average Velocity for the past three Sprints, adjusted for team size. For example, if one person of a five-person Team is on vacation for the entire Sprint in which 50 points of work is completed, the Team's raw Velocity (50) should be divided by 80% (4 instead of 5 Team members) for a normalized Velocity of 60 points. Normalized velocity is the number of points you would expect the team to complete if all team members are available full time.

2. What happens if the more experienced team members are sick, now the less experienced need to pick up the tasks, taking them longer. I would average the estimation if they cannot come to a consensus because estimations of the inexperienced are higher. Since the average estimation is a bit higher it takes in account the uncertainty when someone else needs to pick up the tasks. Letting the whole team work on a single story before picking up the next one, this will force them to share knowledge and let everyone grow as fast as possible.

3. If the Scrum master is not a developer in the team he/she is facilitating then he/she should not influence the estimations of the team ever, nor should a technical (ex-developer) product owner.

Answer 2

I think what you have right now is sufficient to approach the problems you and your team are experiencing right now. I'll just add a bit to that.

1. Velocity, as you implied, is relatively based on experience. You can almost accurately determine the velocity of your team after that team runs a few sprints. Adding a new team member basically means having a new team. Thus, this new team will have a different velocity than the previous team which can only be determined, again, through running a few sprints. It is important for all related parties to understand this concept so that they don't expect immediate acceleration right after adding more people to the team.
2. Estimation should consider everything a person needs to do to accomplish his/her tasks which includes analyzing or even learning new technology as required. This is totally fair.
3. Scrum Master should refrain from taking over the estimation process, even if he's a senior in the team. He too needs to position himself as equal members of the team and discuss (not decide) the best estimate for the team. In fact, no team member should feel that they have the right to decide the best estimate for the team; Scrum Master or not. This is an important attitude during estimation.

That's all I can share for now.

PS: If you haven't tried WSJF, specifically the planning poker, I think you should go for it.

Answer 3

I am not quite sure what is your specific question (which agile process issues?). it is also quite possible that the problems you have are not connected to agile. If I got it right you want discuss the 3 points. So lets start with that.

1. team velocity vs. team size

Indeed these are not in correlation at all. As you mention, most if the time once you hire a new team member the velocity decreases. This can be from several reasons, some of them predictable (team needs to spend time explaining things to new member) some of them less predictable (new member has personality not fitting into the team). If you would like to increase team's productivity there are other ways which can be done and are considered important. A very good short video describing the key pillars can be found on www.scruminc.com (open videos - Scrum Best practices).

Since project is a complex system, when you change something the results can have significant consequences. So it is true what you write, once you change the team, the whole process of estimates and velocity can change.

2. Team estimates

During the sprint planning the team should have enough discussion in order to enable all people estimate. Do not forget that

• the team estimates relative size not absolute time. If for one member things a story is 5 times bigger then other story and the other things that they are the same, they need to discuss why.
• you cannot guarantee that the person most proficient in that technology will in the end work on that, team should be aware of that

For sure the new person we need more time, but he would need time for each feature. We estimate relative size. If the team decides to include analysis as a subtask, so be it, that is up to them. (I am trying to avoid that though, we usually discuss what needs to be done (sub-tasks) until everyone is comfortable to estimate.)

3. Scrum Master estimates

Well, if the scrum master is also part of the development team (I do not recommend that though), s/he should estimate. But not as some super-team member but as a regular member. If s/he does not agree on the estimates s/he can do it during the planning session as any other member. Once the estimates are done though, s/he should accept that as a team decision and thats it. From the position of the Scrum Master s/he has not right to say it the estimation is right or wrong.