Agile development challenges [duplicate]

Question

With Scrum / user story / agile development, how does one handle scheduling out-of-sync tasks that are part of a user story?

We are a small gaming company working with a few remote consultants who do graphics and audio work. Typically, graphics work should be done at least a week (sometimes 2 weeks) in advance of the code so that it's ready for integration. However, since SCRUM is supposed to focus on user stories, how should I split the stories across iteration so that they still follow the user story model? Ideally, a user story should be completed by all the team members in the same iteration, I feel that splitting them in any way violates the core principle of user story driven development.

Also, one front end developer can work at 2X pace of backend developers. However, that throws the scheduling out of sync as well because he is either constantly ahead of them or what we have done is to have him work on tasks that not specific to this iteration just to keep busy. Either way, it's the same issue as above, splitting up user story tasks.

Answer 1

This is problem of team cross functionality. Basic Scrum expects that each team member is albe to do anything - in some environments (like game industry) this is not the case. Succeeding with agile describes this on example of UI Designer. As descirbed in other answers there is nothing wrong when UI designer works one iteration ahead to discuss and prepare design for developers. You can use same approach for your situation.

But if you do this for each your specialized role you will lose main point of Scrum - visibility. If cross functionality doesn't work in your environemnt you should check another agile methodology - Kanban should work in your environment. If you want to learn more about Kanban I highly recommend this book.

Also there is special book about implementing Scrum in game industry but I haven't read it.

Answer 2

The challenge is this.

How to avoid being dogmatic and unthinking.

Agile requires flexibility. Not dogma.

However, since SCRUM is supposed to focus on user stories, how should I split the stories

Drop the "SCRUM is supposed to" mind-set. (Scrum is a word, look it up, not an acronym. It's a play in Rugby, everyone pushing in the same direction.)

Ideally, a user story should be completed by all the team members in the same iteration

No. There's not "user story should be" anywhere in any Agile description. You finish something that's releasable. That doesn't mean everything is done at once and magically arrives at the finish line together. Scrum means that at the end of a sprint you have something you could release. Maybe you have more. Maybe you have a raggedy list of things ready and things done early. It's all okay. Really.

Either way, it's the same issue as above, splitting up user story tasks.

Relax. Stop focusing on something Scrum is "supposed to be".

Break things up sensibly. Think about it. Talk amongst yourselves. Work out something logical.

Don't be dogmatic. Don't slavishly stick to some rote method. Stop. Think. Talk. Decide.

Answer 3

The purpose of splitting things into small stories and pursuing them in iterations is to get feedback on those stories more quickly, and limit work in progress.

In some Scrum teams I've been involved with, the analysts have been researching requirements for the next iteration while the development team finishes the current one. Your situation seems similar. I would do whatever seems most sensible and allows you to get the quickest feedback on the riskiest aspects of your work.

You may be interested in looking at some of the principles of Kanban, in which we use "cadence" instead of iterations, as this might help you co-ordinate. Kanban also focuses on reducing time for feedback and limiting WIP, so it's sometimes a good next step for a team which has outgrown Scrum. The Kanbandev list is on Yahoo, and I recommend David Anderson's book.

Answer 4

We face a similar problem, because our work often requires external resources (cooperation from technology partners, or in-house resources such as a new server or a configuration change).

What we do:

• We create tasks in the story for those external dependencies (like "Organize new server for load testing", "Run test with technology partner X", "Get new icon for button X"). We then try to start work on those tasks as soon as we start with the story, in the hope that it can run in parallel to our own work an be done when our work is done.
• Sometimes the external dependency is ready in time, sometimes it is not. If it is not, we mark the story as "blocked", to indicate that we cannot continue work on it due to external factors.
• We have organized our team board such that these stories stand out, and resolving the blockers is treated as high priority. Additionally, there is a list of blockers across teams, to give management an insight into areas where teams may need support.

Usually this work well, and a story is only delayed a week or two at most. If the delay gets longer, we try to split off the part that requires external resources, or find a workaround (like a default icon). If there is no way to get by without the external resource, the story just stays blocked.

This does mean that in rare cases a story stays open for months. This is ugly, but it accurately reflects reality, so we feel this is the best solution.

Note: We use Kanban, not Scrum, so there is no problem with meeting iteration commitments.

Answer 5

scrum is a way of really knowing that you are out of sync in a quicker fashion that you would do otherwise. hence here is a formula that I may suggest:

• Every day when you begin work, call for a scrum
• Get a check on who is where and if they are getting out of sync
• Ensure you handle both scenario - someone is falling behind or surging ahead. Remember you do not want to stop someone who is moving fast. You need to get commitments from the folks who are behind on when they are going to finish up. And you need to ensure that the members who are surging ahead, have done tasks that align with the overall plan and dependencies

Answer 6

I don't think you should be looking at this as splitting tasks but splitting the story.

The story structure you are currently using should be an Epic. The create two children stories, one for coding one for graphic design and creation. Prioritize the graphic story above the coding story so that it would be worked at least two weeks prior to the coding story. When both are done the Epic is done.

The other issue is not as clean, I would suggest cross functional training and paired programming. In the short term it does not seem to make sense to have your 2x developer slowed down by working with less senior team members but after two or three iterations you will see a dramatic increase on overall team productivity

Answer 7

I think @S.Lott really captured the essence of the issue here, but considering Bob's desire to maintain the idea of user stories, @JDMyers answer is excellent. You want to break a problem down into manageable chunks, and if it helps to create parent-child stories, then do so. And cross train so every member knows at least a little about their areas of non-expertise. If your front-end guy has extra time, let him learn more about back-end technologies so he can help in that area. He's a member of a team, and the team is trying to achieve the goal (i.e., quickly releasing useable software) together.

As for user stories, remember, it doesn't really matter whether all tasks for a given story are completed or not during a given iteration. What matters is that your team is delivering what it's supposed to when it's supposed to (assuming realistic expectations are being set). Make sure the real problem is understood. Is it that a certain process doesn't seem "right", or is it that business expectations aren't being met? Agile and user stories aren't an end in and of themselves. They're a means to an end, namely delivering product in a timely manner. Refine your process so it supports your ultimate goal.