Comments on CLOSED-LOOP: The risk of scrum

@soronthar Your approach to measure acceptance cri...

2010-01-20T16:32:09.495+01:00

@soronthar
Your 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.)

@Urs @fr@nk @bertolami @Patrick Thanks for your c...

2010-01-08T21:14:55.898+01:00

@Urs @fr@nk @bertolami @Patrick

Thanks for your comments and opinions. Its always a pleasure to get comments from somebody you actually know ...

Putting the responsability of seeing the "big pict...

2010-01-08T15:46:40.587+01:00

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.

I 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.

To have a big picture is very important for me, to...

2010-01-08T10:05:45.230+01:00

To have a big picture is very important for me, to keep the orientation in a project.
For 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?).

In my experience there is a big benefit of not loo...

2010-01-08T09:22:10.268+01:00

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.

@fr@nk: quote: 2) IMHO not all projects are feasi...

2010-01-08T09:00:52.790+01:00

@fr@nk:

quote:
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 your blog you mention that the risk of scrum is...

2010-01-08T08:54:46.061+01:00

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".

Here 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.

I agree with you that the two risks you mention fr...

2010-01-08T08:51:00.947+01:00

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.
These 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