I've finished my first week and my first class as a Danube employee and trainer.

I've collected a dozen Dilbert cartoons relevant to Scrum. This week brings us a couple cartoons depicting a dysfunctional daily Scrum (an exercise we sometimes use in class). Previous cartoons have lampooned user stories, working without plans or documentation ("Just start coding and complaining!"), and forcing Agile approaches from the top down.

In a discussion group, someone recently wrote:

From the very beginning, the PO has been very insistent that we use an electronic tool, despite the fact that everyone is co-located. I have resisted from the very beginning, because the Team feels that

People accustomed to traditional project management often want to know how Scrum deals with "risk management." An example of how many project managers think about risk management is on this page (highlighted in red even):

It is much better to reduce the risks at the start up phase of the project than to allow a contingency on a basis that things are bound to go wrong, but we don't know what!

That thinking is probably useful for traditional projects with known requirements and established technologies. Here's the bad news: When we're doing new product development (somewhat unknown requirements, somewhat unknown technologies), things are bound to go wrong, and we don't know what!

Depending what your risks are, doing Scrum well may help. Let's enumerate some typical risks:

So, since we are astute enough so that we're not expecting a story’s size (In Story Points) to be an accurate reflection of the effort it takes for the story – even though we expect a correlation on average – what is our expectation of what a story’s size reflects?

Team self-organization is one of the key principles [1] of Scrum and its introduction to an organization raises a number of interesting questions around decisions and decision making. Specifically, the introduction of Scrum leads to consensus-based decisions by the team.

Modern languages combined with the engineering practices derived from eXtreme Programming (Test Driven Development, constant refactoring, continuous integration...) make it possible to flatten out the pessimistic exponential "cost of change curve" we learned in the early days.

The ability to *do* this involves learning skills and habits your team may not have yet.