Skip to main content

Making Scrum work

Last post 09:17 am October 29, 2015 by James Starmer
4 replies
08:29 pm September 5, 2015

Hello,
I have been in two scrum teams as of yet and I am not able to see the value add of Scrum to me as a software engineer:
1. The daily standup meetings are informative but most of the time my colleagues are working on something that I have a vague idea about and that is not enough for me to understand the specific status that they are reporting about.
2. We also have a retrospective at the end of the sprint but most of the time people say some general things which are very obvious to everybody and nothing enlightening.
3. One thing I noticed is that most of my team members are not very clear that something has to be delivered at the end of the sprint and they don't demo anything.
4. During sprint planning again I don't have much information about what others are working on to be of any use.

So I was wondering should I be understanding more in depth about what other team members are doing. The answer most people will give is obviously yes but I was wondering as to the cost of this and also without putting almost as much time as they do in understanding the topic most of my input would be useless. Also my manager already understands what each team member is doing so what is the value add of all other team members put time and energy in doing the same?


01:09 pm September 6, 2015

> So I was wondering should I be understanding
> more in depth about what other team members
> are doing. The answer most people will give is obviously
> yes but I was wondering as to the cost of this 

Look at it the other way round. How valuable is each end-of-sprint increment in your current way of working? Is the cost of development clearly justified? How is value being evidenced?

I suggest you read through the Scrum Guide, and consider how agile value delivery can be improved through collaborative team effort.


06:06 am September 7, 2015

To make Scrum work you do need to understand its principals.
Simply having some meetings does not mean you are doing Scrum and you might be right saying it does not make too much sense that way.

If you want to profit from Scrum, make sure you understand the agile mindset. Also make sure you understand everyone's role in the process as well as the real meaning of the meetings.

Good luck!!


04:27 am September 8, 2015

Hi,
If different people make non-connected different works, it maybe isnt a good time to practice scrum. How are your sprint goals defined? How can you all work on a story?

1-4. You are right, in such a case there is little value added in these ceremonies. One of the real power of an agile team is cross-functionality. You have to start sharing the know-how, mainly with pairwork. With this, you will understand much more of others' topics and you will be a much greater asset at the team's disposal.
2. These kind of retrospectives are useless and it seems that your team suffers from a lack of trust, the base of all teams. You have to work on it with your scrummaster.
3. Delevering releasable product is the main part of scrum. If your coworkers cant do this, you are not doing scrum. You have to work on this with your scrummaster.


09:17 am October 29, 2015

I’ve faced this problem before. My team first realized something was wrong when no one would pay attention at the daily standup. We thought, "Scrum says we should have a standup meeting but no one is getting value from it. Is Scrum wrong or are we doing something wrong?" Looking back now, it’s clear that this was an indicator of a lack of team work. Each developer was working on their own story and the stories weren’t interrelated so the developer really didn’t need to interact with other team members. In addition to that, at least one story per sprint would not get finished and would carry over into the next spent.

Solving the carry over problem had the side effect of solving the daily standup problem. The solution was a straight forward, we started working as a team. We’d figure out how to split the work for a single story among multiple developers or we’d pair program. If a story was looking like it wasn't moving, we'd jump in as a team and help to get it moving again. This had huge impacts for us. People paid attention to each other at standup meetings and we started to meet our sprint goals.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.