8

My team started using Scrum a few sprints ago. Our project involves building software interfacing with physical devices (think robots and sensors) and our typical Product backlog usually represent adding controls device to the whole system.

We split down the task close to the example here. Each device integration feature is split into code, tests, integration tests, peer review, etc. Obviously, there is a sequence inherent to each Product Backlog Items. Typically, our sprints last 2 weeks and the team has between 4 to 6 members.

We run into 2 problems at the end of sprints:

  • The first is to keep everyone busy at end of sprint.
  • The second (related) one is contention on system. We pretty much end up integrating during the last few days of the sprint. We only have one integration system, so people are often blocked from continuing to work on their task because they can't access the system. Since it is the end of the sprint, there is not much work left to do in the sprint backlog. What should these people work on? Pick up items from the top of the product backlog is not well received from the product owner, since the current items are not done. Working on technical debt will help the project as a whole but won't help completing the sprint.

Are there any best practices to either structure sprints to avoid these issues? Tips to negotiate with product owners?

Improve this question
3
  • 7
    The phrase "Continuous Integration" comes to mind.
    – Robert Harvey
    Jul 15, 2011 at 17:02
  • 1
    Continuous integration is what the integration system does all by itstelf once integrators integrally integrated each device on it. Unfortunately, with our setup, it is not as simple as checking the code in, we need physical connections setup with motors and I/O Cards and what not. Making sure your new device runs in the CI environment is a task itself, and that is the task causing contention. Interestingly enough, taking whatever is on the CI system and putting it on the real machine is a rather trivial process - proving that CI is worth it.
    – Vincent Hubert
    Jul 15, 2011 at 20:09
  • 2
    Why do you need to wait for the actual integration device? Do you not have simulators (at least functional, if not total) that you can use to perform at least basic test and integration of the software prior to moving to hardware?
    – Thomas Owens ♦
    Jul 17, 2014 at 21:47

7 Answers 7

Reset to default
6

in some ways it's good that you're slow at the end of a sprint, that means your estimating well and not over committing, as far as keeping busy, on scrum teams I have worked on we always added research tasks for what's coming up next sprint.

This could be doing proof of concepts for things that are coming up, or looking at where to re-factor existing code, working on getting better test coverage on your code, etc.

Improve this answer
1
  • 2
    Fixing bugs was another task that kept us busy at the end of the sprint.
    – Sjoerd
    Jul 15, 2011 at 20:25
5

You should fix your integration system so your team can integrate their work as soon as each task is complete, rather than waiting for a big bang at the end of the sprint.

I recommend working with user stories short enough to be finished in a few days. Finished here means code complete, tested and integrated.

Improve this answer
2
  • 2
    Actually, integration can be done on the system at any time. The issue is that there is nothing to integrate before the tasks are at integration stage, and most arrive at that stage near the end of the sprint, hence contention.
    – Vincent Hubert
    Jul 15, 2011 at 19:48
  • 1
    Seems my recommendation about making your tasks shorter would help here, no?
    – Martin Wickman
    Jul 15, 2011 at 19:51
4

Remembering that it is the entire Team's responsibility to deliver, not individual members, per se, is it possible to have all four-to-six members work on each task TOGETHER--push each one through the process and move onto the next. This might sound inefficient at first, but if the bottlenecks you are seeing are that bad, it may be a valid option.

Also, you might want to look into the theory of constraints (Goldratt's The Goal), and see how you can best analyze why and where you have these integration bottlenecks.

Improve this answer
3

We've addressed this by adopting the Kanban approach.

We have queues in our tracking software (Jira) with minimum and maximums.

We groom 'as needed'. Might be once a week, might be 3 times, depends on the limits and the work that get done.

This will help you in getting the product owner focused on keeping your queue with plenty to do and can reduce micro-management of individual tickets. Just remember that as always change will take time.

We still demo every two weeks and we release weekly.

Improve this answer
2

Wow, if you didn't say robots, I would assume you were on my team right now. We have the exact same set of problems. Having worked on numerous agile projects with varying degrees of fidelity to the manifesto and varying degrees of success, my analysis is that our problem is sprints being too short. We are doing two week sprints which causes a few problems. One is that we end up being overcautious in planning and frequently end up with dead days at the end. Second is the huge overheard of review, retrospective and planning taking up 1-2 days out of every two weeks. Another is, like you said, having to integrate at the last minute and frequently failing hours before the review. My first and most successful agile project had four week sprints, which I gather is pretty huge by industry standards, but it worked great for us.

EDIT: Remembered one more thing from that first project that was a boon. We always had a fully prioritized product backlog and gave developers freedom to grab tasks off of it if their sprint tasks were complete and no other sprint tasks were available.

Improve this answer
1
  • "huge overheard of review, retrospective and planning" - If you feel the retrospective is so burdensome, you don't need to do it for every sprint. Planning would should only depend on what you plan, so should not be less with longer sprints.
    – sleske
    Jul 17, 2014 at 22:34
0

The second problem is probably a consequence of trying to fix the non-problem #1. You should get people that is not busy, to help their peers; instead of working on non-sprint tasks, which cause contention on the limited integration.

Also, you should not integrate at the end of the sprint, but continuously.

Improve this answer
0

You’re just getting started. Give the teams a chance to tackle this problem themselves through their retrospective process.

Secondly, your product owner should trust the team to know best how to organize and optimize themselves. In return, the team trusts the PO to know best what the customer needs.

These are very common challenges with new agile teams. Great to see when a team starts breaking down their own silo’s and grow.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.