Last month Ralph Jocham gave a talk about the Risks of Scrum.
He published the slides on slideshare: Ralph Jocham The Risks Of Scrum.
As far as I understood it, Ralph identified two Risks with Scrum:
- Not doing it right or not practicing it to the full extent
- Neglecting technical excellence and accumulation of technical dept
According to Ralph the second risk should be met with XP practices that focus on technical quality.
But in my opinion there is a much more fundamental danger in scrum:
Scrum gives the impression that it is possible to bring "Embracing Change" and "Getting Things Done" under the same umbrella.
This is dangerous. "Embracing Change" and "Getting Things Done" are two opposing forces. On a certain level it is inherently not possible to get things done while embracing change.
Scrum as an agile methodology is all about embracing change. With the focus on the Done-Stage on the Taskboard and the "Definition of Done", Scrum claims that those two opposing forces are actually not opposing. This is in most cases an illusion.
This is mostly a result of focusing on small stories with immediate business value. Getting these stories done is possible, and Scrum can easily misused as an "excuse" to neglect the big picture.
Progressing in Scrum means getting stories done. Often the real progress of a finished story in regard of the whole project is not measured...
A symptom of this antipattern is that certain things get touched and changed again and again by new stories in subsequent sprints... so what was actually done, the story or the real business problem?
Shortening sprint duration and focussing on smaller user stories can even aggravate this problem ...
I agree with you that the two risks you mention from Ralph Jocham (not doing it right and neglecting technical excellence are not) are a bit poor.
ReplyDeleteThese are risks that apply to anything, not only Scrum.
However, on the risk that getting things done opposes embracing change, I take a different position.
Scrum embraces change by allowing to turn arround every Sprint. If you turn your direction every Sprint then it is likely that no product will be release any time soon. However, the same applies to other processes, where constant "change requests" have the same outcome.
But there is something that Scrum gives us. It gives a a box (Sprint) in which we can focus on delivering something - wthout getting disturbed. This something may not be big enough to have sufficien business value of its own, but (if Stories are well chosen) at east provide some business value a user could benefit from.
In more traditional processes with constant change requests, you never get anything done.
Therefore, embracing change and getting things done, is not an antigonism for me in Scrum.
But of course, if you do change everything all the time then you will get a bunch of "done" things that don't sum up to something useful.
Scrum is not perfect but better than any other methodology that I know regarding this aspect.
Anyway, this is a risk a has to be mitigated accordingly (= keep number of U-turns in Stories as low as possible). THis should not be too much problem as long as your project goal is defined clearly.
Cheers,
Urs
In your blog you mention that the risk of scrum is that you just get isolated user stories done and you have no gaurantee that this stories fit in the "big picture".
ReplyDeleteHere my opinion:
1) It in the responsibility of the product owner that those stories together will give the big picture.
And yes, as a consequence, this prodcut owner has to be a real SUPERMAN ... I see this position as the bottleneck ...
2) IMHO not all projects are feasible with scrum. For example if you have a lot of external project dependencies where you have no contorl over it, I still would prefer a "plan driven" aproach.
@fr@nk:
ReplyDeletequote:
2) IMHO not all projects are feasible with scrum. For example if you have a lot of external project dependencies where you have no contorl over it, I still would prefer a "plan driven" aproach.
You may need a plan for your external dependencies, but this does not mean that you can't use Scrum for you part.
And there exists release planning in Scrum that can be used to communicate when you are likely to be done with your stuff in case you are an external dependency to some other (non-Scrum) team.
Cheers,
Urs
In my experience there is a big benefit of not loosing the big picture out of sight in Scrum, namely, that developers talk directly to business people. Thus, me as a developer I get quite a good idea of what is the actual idea of the business. And I thinks that this is much harder to achieve when you have 20 requirement engineers that write 2000 pages full of "exact" specifications.
ReplyDeleteTo have a big picture is very important for me, to keep the orientation in a project.
ReplyDeleteFor example in RUP you have to have the Use Cases and to choose the most critical ones to begin. After that, you could continue in an agile way.
But what happens when the big picture was wrong, or something changed in the environment? In a such case you have to change the big picture. And that isn't cheap when you have to do it very late in the project.
However, it doesn't matter which methodology you choose: Try do define with the customer very early a big picture (or vision?).
Putting the responsability of seeing the "big picture" to the Product Owner is not a guarantee to make it happens. You need some "pokayokee" to ensure that the big picture is taken into account.
ReplyDeleteI have started to advocate at my company that we don't measure progress by "stories finished", but by "acceptance criteria approved". This is actually an attempt to move the focus away from the stories and back to the business value. By focusing on the Acceptance Criteria it is a lot easier to discover a missing requirement, because you force yourself to think about the business process instead of focusing on what needs to be done in the application.
@Urs @fr@nk @bertolami @Patrick
ReplyDeleteThanks for your comments and opinions. Its always a pleasure to get comments from somebody you actually know ...
@soronthar
ReplyDeleteYour approach to measure acceptance criteria approved probably makes sense in your environment. However, it only masks a symptom. A story is only DONE when it fulfills all acceptance criteria; often called the Definition of Done. So, per process you must not account for stories which are not DONE. Furthermore, the business value is the story when written right. AS A ... I WANT ... SO THAT ... . The SO THAT part is the business value which needs to be achieved.
The acceptance criteria are there for validation (business value delivered) and the TDD, UAT approach for verification (the code works correct in all cases.)