Can't get to done, roll-over every sprint

[Guarino]

Hi all,

Hoping to get some suggestions on how to inspire my team to be more responsible for completing the sprints.

I have scrummastered for several years, and while most teams eventually work themselves out of the constant rollover, this particular team hasn't found their way yet.  I am a very hands off scrummaster, allowing teams to determine their own processes, and try to only step in to help recognize problems and offer suggestions on how to move forward.

We are in 2 week sprints, but we used to do 3 week, this issue is not specific to either cadence.

The team checks in "some" stories throughout the sprint, but mostly the stories come in on the last day or two.  We have done several things to try and stop this, the team voted to have a "code frost" date inside the sprint.  This worked ok, but again all the stories showed up on the same day, instead of throughout the sprint.

What our "norm" now is, the majority of the stories are built and sent to "qa" on the last day or two, creating a rollover effect of the previous sprints stories.  So now as qa is testing "last sprints" stories, the bugs that arise are top priority and developers get pulled off their stories to fix bugs from last sprints stories so they can pass.

This is somewhat a normal pattern of scrumteams, so I was not too concerned, and tried things like:  Not buying new stories for a sprint to "catch up", assigning certain people to fix bugs while others worked on stories, have QA folks in the Developer Branch to help vet out bugs earlier int he process...

But they all seem to be fine with a "staggered sprint" approach.

The team has been together for almost 2 years now, and the rollover has always happened, but I was not too concerned since we are building new product and had a long way before we released.  However, we have a product now in production, so we are trying to release every few sprints, but the rollover causes issues now.  Looking back, I realize I should have been more strict on finishing sprints on time.

Of note, we have tried to have the dev actually help QA, but honestly the QA team didn't think it was fruitful at all, and they wanted to test every story anyway.

I tried to just have the PO rebuy the stories, but since they are on the "QA" side of things, the developers are left with nothing to do...

Any suggestions would be great, thanks all for your time :)

[Michael Vizdos]

Sounds like a good topic to discuss at the next retrospective with the team.

What do they want?

Also... If you have been the ScrumMaster for a while with them you may want to bring in someone else who is skilled at facilitating and can stay neutral (this is not a personal dig against you it has happened to me before and I know this was effective for me in similar situations).

There will be more suggestions here.

Good luck with this.

Mike Vizdos
CST

--
You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
To view this discussion on the web visit https://groups.google.com/d/msg/scrumalliance/-/T4QfKXuNXDQJ.
To post to this group, send email to scruma...@googlegroups.com.
To unsubscribe from this group, send email to scrumallianc...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/scrumalliance?hl=en.

[Howard Sublett]

Limiting the WIP may help them swarm on 1-3 stories at a time. Only having them break down 1-2 days of stories at a time and they have to meet the DOD before a new story can be broken down. 

Howard Sublett

howard...@gmail.com

Follow ME on twitter @howardsublett

Find me on Skype @ howard.sublett

[Ram Srinivasan]

Hi Guarino

You probably are going to get a lot of questions from others as well, but I will go first ;)

From what it sounds like, it seems that dev and qa are separate teams? Are your teams cross-functional?

How are teams limiting their dev and qa work in progress ?

I have used story burn-downs in big flip charts and asked them to reflect on the "step" or "waterfall" (not SDLC, but the burn-down looks like a waterfall) pattern they see. Ideally they limit their WIPs, you should see a good "ski slope" in their story burndown.

Ram

--

[Clinton Keith]

Great questions by others.  I'll add one:

Why does the PO find it OK to accept stories that are not complete if there is work left to do (testing)?

Clint

--

[Sameer Bendre]

Great points by others. In my opinion it's the culture issue at the place. Trying to find the root cause behind that could be time consuming and you may have to get in the mud with many people - PO, management etc.

I am facing same challenge and the way I tried to handle it, using the "leftovers" analogy. People can tolerate leftovers one or two meals. [Thanksgiving is coming, think about the turkey leftovers - how many days would you like to eat it? :)]

For 2/3 sprints I kept adding a new story called "Leftovers" which represented all unfinished work from earlier sprint(s). This sprint a team member spoke out saying we don't like that term. This opened up a discussion that led to team agreeing to under commit, clean up the pending items and next choose/plan wisely and realistically. We didn't have to wait till retrospective to address this issue.

It's all about challenging the status quo to unearth the actual problem. If the team really wants to address it, great. If not, it's an accepted culture and you will be in a minority who is trying to disrupt their comfort.

I would be happy to return and report on our progress on handling the leftovers after next 2/3 sprints.

Guarino - Thanks for bringing a very interesting topic that people are uncomfortable to talk about.

Appreciate the questions and pointers from all agile practitioners, Thanks for sharing.

Regards,

Sameer

[George Dinwiddie]

Guarino,

You've gotten some good advice. I'll try to add some things others
haven't mentiioned.

On 11/14/12 8:42 AM, Guarino wrote:
> Hi all,
>
> Hoping to get some suggestions on how to inspire my team to be more
> responsible for completing the sprints.

What would make the team want to do a better job? You can lead a buffalo
anywhere you want, as long as he wants to go there.

> I have scrummastered for several years, and while most teams eventually
> work themselves out of the constant rollover, this particular team
> hasn't found their way yet. I am a very hands off scrummaster, allowing
> teams to determine their own processes, and try to only step in to
> help recognize problems and offer suggestions on how to move forward.
>
> We are in 2 week sprints, but we used to do 3 week, this issue is not
> specific to either cadence.
>
> The team checks in "some" stories throughout the sprint, but mostly the
> stories come in on the last day or two. We have done several things to
> try and stop this, the team voted to have a "code frost" date inside the
> sprint. This worked ok, but again all the stories showed up on the same
> day, instead of throughout the sprint.

It sounds like people might be working individually, rather than as a
team. Are they working in cubes? Or at a big common table in a team
room? The latter makes collaboration easier, in my experience.

Are they working on individual stories, or do they swarm over the
stories to get them done?

Do they have clear concrete examples of the acceptance criteria at the
start of the sprint? Or just general descriptions?

> What our "norm" now is, the majority of the stories are built and sent
> to "qa" on the last day or two, creating a rollover effect of the
> previous sprints stories. So now as qa is testing "last sprints"
> stories, the bugs that arise are top priority and developers get pulled
> off their stories to fix bugs from last sprints stories so they can pass.

Are the stories considered "done?" What technique are you using to
determine how much work to take on in the next sprint?

> This is somewhat a normal pattern of scrumteams, so I was not too
> concerned, and tried things like: Not buying new stories for a sprint
> to "catch up", assigning certain people to fix bugs while others worked
> on stories, have QA folks in the Developer Branch to help vet out bugs
> earlier int he process...

I wouldn't call it normal, nor would I call it Scrum. I have seen it
before, though.

> But they all seem to be fine with a "staggered sprint" approach.

What do you mean by "seem to be fine?" Have you asked them? Or have they
just come to think of it as inevitable and unfixable? Is it talked about
in the retrospectives?

When I've seen this, the testers were quite frustrated and unhappy about
it, but felt powerless. The programmers were annoyed at being
interrupted about stories they considered finished, but didn't connect
that annoyance to the root causes.

> The team has been together for almost 2 years now, and the rollover has
> always happened, but I was not too concerned since we are building new
> product and had a long way before we released. However, we have a
> product now in production, so we are trying to release every few
> sprints, but the rollover causes issues now. Looking back, I realize I
> should have been more strict on finishing sprints on time.
>
> Of note, we have tried to have the dev actually help QA, but honestly
> the QA team didn't think it was fruitful at all, and they wanted to test
> every story anyway.
>
> I tried to just have the PO rebuy the stories, but since they are on the
> "QA" side of things, the developers are left with nothing to do...
>
> Any suggestions would be great, thanks all for your time :)

You might find
http://blog.gdinwiddie.com/2012/11/01/avoiding-mini-waterfalls/ helpful,
in case it's a problem of not knowing any other way to work.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[RonJeffries]

Nice!

R

On Nov 14, 2012, at 11:34 AM, Sameer Bendre <sameer....@gmail.com> wrote:

For 2/3 sprints I kept adding a new story called "Leftovers" which represented all unfinished work from earlier sprint(s). This sprint a team member spoke out saying we don't like that term. This opened up a discussion that led to team agreeing to under commit, clean up the pending items and next choose/plan wisely and realistically. We didn't have to wait till retrospective to address this issue.

Ron Jeffries

www.XProgramming.com

I have two cats, and a big house full of cat stuff. 

The cats fight and divide up the house, messing up their own lives. 

Nice work cats. 

Meow.

[Guarino]

Thank you all for your help and suggestions.

I will try to answer these questions, to see if it strikes any other thoughts.

I tried to leave out my opinions in the original post, as someone mentioned getting a 3rd party to help out (that is you guys :) )

We have 2 "QA" members on our team.  The company has a QA department, but they are spread across the teams.  So its cross functional, but the roles are fairly well set when it comes to Who can pass a story to ready for acceptance.  

Our PO doesn't accept the stories until they are "done", so they end up rolling over and they get accepted in the next sprint.  To that end, our monthly productivity is fine, its the fact of not completing sprints that is causing anxiety on the team.

The team is wanting to go to staggered sprints, this is what they want to do.  Though I am hands off, I do feel it is important to try and stop this decision, perhaps I should let them do it?  My guy says no, because the problem is still the problem.  As someone mentioned above, my interest is in finding the root cause of the issues.  

IMO (and as someone mentioned above), I feel development mostly feels that they get the whole 2 weeks to try and finish.  This I "think" gets the deadline mentality of, "I have until friday to finish, therefore it will take me to friday".  Not on purpose, of course, the team works hard.

The team doesnt swarm very well, even with some prodding to get 2-3 devs tackling some of the bigger stories first, while the others start picking low hanging fruit, they still seem to work silo'ish.

Atmosphere is great here, we dont work at a common table, but its close to that.  We have half group like cubes so the team is together, and there are no obstacles for open discussion (white boards everywhere, etc), but their personality is more to stay to themselves.

I have thought about WIP, I am not quite sure I want this to be honest.  I would rather approach it via DSM, determine who's story could use help and have someone help.  They will do this if prodded, so have recently been working this as ideas via the DSM.  I will ask specifically when someone says they "worked on x, still working on it" to see if someone else has time to help.  This is actually starting to work, so I didnt want an official process of WIP if they can organically create this atmosphere.

Acceptance Criteria is a bit tricky, and is one of the things I am working with our PO on, it is an issue with this team, and does feed a bit of this, but mostly it is a nonfactor, the team during planning and DSM etc, eventually get to stories end in the "points" assigned to the story.  But I am not closing my eyes to this, we have it in our sights :)

Sorry I am typing so much, but its just not an easy problem to solve.  I appreciate everyones willingness to comment and suggest.