What's wrong with scrum:
1. Very often we have changes in current sprint because customer wants them. There are situations when customer wants a new feature. Often it is a simple feature and customer wants to get it with the next release (when current sprint ends), and not after next sprint starts and ends. I think that in this case customer is right. Indeed, why should a small change wait for e.g. 4 weeks to be implemented if it can be implemented in 2 hours and it is important for customer? Maybe it is not a feature, but it is critical bug fix. But if we want to change sprint in scrum we should stop the current and schedule a new one which includes this change. We should stop all developers activities and have planning session. It eats too much time, that's because we have sprint changes added in the wrong way only by architect decision. It may not be so bad but often developers should take time from their planned tasks to do these unexpected issues. It leads to unfinished tasks at the end of the sprint and some tasks finished in a hurry, which is more serious. This leads to bugs, worse tests coveradge, etc.
2. Very often we start sprint with requirements which are not completely defined. The product owner motivation is: now it is not defined, but I'm sure it will be defined soon and we will have enough time to finish this task to the end of the sprint. Lets begin with the defined tasks. In this case I agree with customer too, with the same reasons. Important features should not wait more than absolutely needed. But consequences are bad. We can't estimate sprint properly and can have too much free time or worse we will not have enough time for sprint.
3. Sprints. When I say sprints I mean the period of time to the end of which all tasks have to be done. But I don't mean releases schedules at the end of this short period of time. Managers should like sprints, but programmers have to hate them. I have allready mentioned the situations where programmers adapt their work to sprint ends. I belive: each task should take as much time as needed. If we break this rule we will have dirty unmanaged code, bugs, etc. Capacity of giving right estimations is a very important quality of architect but if estimations were wrong we should leave the task or find the time for it. But I like other side of sprints - releases. When we release often we can be sure that all we write is working. We can demonstrate working code to the customer, perform deeper testing or even customer can use completed functionality and not wait for the moment when all code be comleted.
4. Spend too much time for estimations. Even if we have trivial task we should discuss how much time it will take and process it as all other tasks. We spend half of a day of all programmers at a sprint beginning.
5. At the end of a sprint programmers do not know what to do. Because many of user stories from current sprint are finished and new aren't estimated and assigned. Usually a half of the team does not work half of the last day (while others try to finish their tasks in a hurry).
6. We have releases in the middle of the sprints. Client architect asks us to do these releases because he wants to see some important bug fixes as soon as possible, and do not wait for the next scheduled release. And even more because we should add bug fixing task to the next sprint, estimate it and include it only when it is finished. It takes the time that was not planned.
What I like in scrum:
1. stendups - it is very usefull to control development process.
2. releases after some small changes
Let's look how extreme programming (XP) resolves all of these issues.
1. In XP we haven't got sprints. So if customer or product owner wants some important feature right now than implementation can be started immediately after we have free programmer (he should finish only his previous task) and full defined task. We do not have to wait for the next release or something else. If we have free developer we assign him a task immediately.
2. There aren't sprints there aren't any problems. When requirement will be fully defined it can be assigned to a developer and can be released with the next release after implementation is finished.
3. Because there is not a deadline for developers they can do their job very carefully. To manage risks and dates properly, managers can fill sprints (or analogues), do estimations (may be after discussions with a part or with all the team but if it is really needed), track progress and do releases as often as they want. For developers all of this should be hidden and shouldn't prevent them from doing their job with the best quality. I think that developers if they have only simple, well defined tasks do all of them with the same speed (but different developers of course have different speeds). For developers estimation is nothing. But if they know about them and if estimations are to high, they can waste time. And if estimations are low, they do their job in hurry, which leads to low quality code. My opinion: estimation of tasks should be done by tecnical leads and architects. They can manage releases and risks. But keep developer free from this processes.
4. As I've said above for most of the tasks estimations shoild be given only by tecnical leads and architects. If it is needed they can discuss estimations with engineers. I think that attracting all of the team to each estimation is really big overhead.
5. There is no such problem in XP. When developer finishes his current task he immediately gets a new one which has a bigger priority. It is very simple. The only one important thing for product owner is to keep some count of well defined task all the time.
6. With XP product owner can schedule releases as he wants. It can be similar to the scrum isn't limited by it. Product owner has to know that he can make release with all finished requirements at any time.
That is all for now. It is only my thoughts. I prefere XP, my management preferes scrum. Fill free in your choice.
