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
----------------------------------------------------------------------