Random (s)crums

Some random “things” that I will take away from the CSM-course:

If you need a lot of system design you should still parallelize design and implementation (i.e. do it within the sprint) but it would be wise to add a Sprint Zero focusing on system design alone. This sprint will most probably be a little bit longer than normal sprints (depending on your system).

I will probably take a look at the book Software by numbers.

Ok I’ll cave; using modeling-terminology Scrum can be seen, roughly, as an instance of “Lean”. At least most of the basic principles, or values, are the same.

The Spec/Developer game that we played at the training should be played in every organization… the quick lessons learnt from that one are so easily neglected on an everyday basis.

When e.g. building cars or similar products there are a very strong focus on time, technology and cost, why is value repeatedly left out of that equation? Ok this one is not from the training itself but in Scrum the focus is on value and if anything you should, when prioritizing, look for at least MMF, Minimum Marketable Feature.

I should revisit the agile architecture work together with Peter and Peter. We are on the right track there and architecture is one of the difficult questions when talking Scrum. The answer at this course was that “architecture and infrastructure are highly prioritized non-functional requirements”.

Scrum in large organizations is difficult. Scrum in large organizations developing embedded products is even more difficult. But then again it is difficult using waterfall as well.