I've been doing scrum with a team for a while, but things seem messy for whatever reasons. I've been thinking on how they can be changed and have a couple of questions that would like to raise here.
First, what should be the role of testers, designers and non-developers as a whole in the scrum process? If they are equal to other team members a couple of issues arise. Designers and testers usually work on a task after development is done, so they cannot adequately plan for a sprint because of this dependency.
Second, we have deadlines. These are strict and have a lot of impact on prioritization. The end result is backlog changes in the middle of a sprint because of deadline changes, or bad results in the end of the sprint.
We also have a lot of non-technical work like customer support that has to be done in the meantime and cannot be planned as it varies a lot.
So I'm thinking that the team structure, culture and practices are kind of not compatible with scrum. Scrum for me is a process management tool for teams working on the development of a single software product.
What do you guys think about applying it in more specific and complicated scenarios, do you have any experience to share?
views:
1613answers:
4You really should not add changes to the Sprint backlog based upon changes raised mid-Sprint, they should only go into the Product backlog and ignored until the Sprint is over.
You should be aligning your deadlines with the Sprints. I think it's acceptable to retire a task mid-Sprint, but not introduce an new one.
If you find you are adding lots of tasks mid-Sprint, your Sprints are probably too long. Remember that you're aiming for about 20 days of work in each Sprint, any longer and you start getting the problems you're describing!
Testers are important to any Agile process, but don't really fit into Scrum where the theory is any person without an active task picks the next task. Trying to choose associations between tasks and people starts getting into scheduling, which the whole thing was trying to avoid!
Testers, if working in close proximity to the developers can assist in determining whether a item of work is actually complete!
First, what should be the role of testers, designers and non-developers as a whole in the scrum process? If they are equal to other team members a couple of issues arise. Designers and testers usually work on a task after development is done, so they cannot adequately plan for a sprint because of this dependency.
If designers and testers can't plan for a sprint because of a development dependency then that means that your development isn't being planned correctly. That's a problem that needs to be fixed.
Your team should be able to say "Task B requires Task A being done first. Task A will take 8 hours then Task B will take 4 hours". If your task estimates are accurate, then dependencies are not a problem at all.
Second, we have deadlines. These are strict and have a lot of impact on prioritization. The end result is backlog changes in the middle of a sprint because of deadline changes, or bad results in the end of the sprint. We also have a lot of non-technical work like customer support that has to be done in the meantime and cannot be planned as it varies a lot.
If this is happening, then the problem is that you aren't doing Scrum. The only way that Scrum works is if management buys into the process completely. This means leaving your developers alone for 30 days while they work on their planned sprint and adding new work through the methods that Scrum has in place to do so. You add wish list items to the product backlog and then during the sprint planning, developers and stakeholders agree on what will be worked on in the next sprint.
If you consistently have customer support issues interrupting normal development then you should seriously consider dividing the team and have one group dedicated to working on development in Scrum and have another group who takes care of the customer support issues. You could then rotate people back and forth at the end of each sprint.
In general testers and documenters (and other non-developes) are all equal members of a scrum team. The idea behind that is to minimize risk.
Requiring a definition of done, which includes a potentially shipable product that's fully tested and documented, forces the project to come together at the end of each sprint.
If testing does not start until AFTER dev. is done, what happens is that a lot of bugs are discovered after the developers are done with a task. So now you have to fix those bugs, and that's very slow and expensive both because bugs interact and because the general rule is: "The expense of fixing a bug grows exponentially with time." Bugs you catch early are cheap and easy to fix, late bugs are a nightmare.
That is why you want testing (and documentation) to move in step with development. And right now you should be asking, how! Testing is slow, how the heck can it move in step with dev?
The answer is automation, that is SCRUM always sits on top of XP or Agile, both demand excellent unit test coverage and TDD. Here's another gotcha to watch out for. The features developers should be the ones writing both, unit and system test. All testing automation should be done by the feature dev. team. Some places split feature dev. from automation dev. and that's bad.
OK, so now you have great automated testing and you run it AT LEAST once a day. And obviously you practice continuous integration right? This reduces the work load of the testers by a huge amount. And that's how testing can stay in step with dev. One more thing, the testers now work on the really hard and creative stuff that's impossible or very difficult to automate, every time they find a bug that way, what ever it took to expose the bug is automated and becomes part of the daily regression tests. Phew, that's a long answer!
Now to the second part of your question. Scrum is about discipline. Sprints are short and backlog changes during a sprint should NOT happen. Non technical work should be branched of onto a customer support team and they can do Scrum around that. You're right when you say that is sounds like your culture and practices are incompatible with scrum.
In my experience transitioning to Scrum/Agile is a very painful, stressful process and most attempts to transition fail. One of the key's to success is a champion for Scrum/Agile in the executive team. From your description it sounds like you don't have one.
There are costs and benefits to Scrum, but you're doing it badly you might be incurring costs with little or no benefit. If you're doing Scrum wrong and badly, you might be better off not doing Scrum at all.
first of all, you are not using Scrum at all, you may be using some scrum practices, but not the whole process.
Designers and testers usually work on a task after development is done, so they cannot adequately plan for a sprint because of this dependency.
There is no relation in task dependency, witch rarely occurs, and the ability to properly plan. At the sprint planning, the team should estimate the stories regarding the Definition of Done. If it includes, and it really should, design and testing the story, the estimate of the effort needed to accomplish the story acceptance criteria must include design and test tasks.
The end result is backlog changes in the middle of a sprint because of deadline changes, or bad results in the end of the sprint.
It seems that your sprint length is wider then you need. Why don't you try to make it shorter. A good sprint length is the length you can commit to keep changes out of the sprint. I guess 1 week would work.
And this behavior demonstrates that your Scrum Master is not doing his job properly as he is not removing the impediments.