On May 6th, 2009 Munich saw its first “ScrumDay”, a new conference on Scrum. It paralleled “TeamConf”, a conference on “Microsoft Visual Studio Team System.
The day began with a keynote by Ken Schwaber, one of the inventors of Scrum, on “Scrum, but … “.
At first, he gave a brief introduction to the topic of Scrum and the underlying values (self, transparency, integrity).
Afterwards, he made clear software development in general (and Scrum in particular) is an empirical process, as it is necessary to periodically look at the project situation and make corrective adjustments. He compared it to an air conditioning system’s temperature sensor, which periodically checks the temperature in a room and then sets the system accordingly.
This approach is necessary because the complexity of today’s software development projects is generally too high to understand everything in detail. It’s sufficient to detail the next 4 weeks. In addition, approx. 35% of a project changes anyway, so too much planning in advance is a waste of time.
The solution, however, is not to just introduce Scrum. Instead, Scrum visualizes your problems, and only if you resolve these, a sustainable improvement in project situation can be reached. Moreover, applying Scrum also needs a certain time of learning.
He compared it to a football team: Just because a team knows the rules does not necessarily mean it will win the championship. This needs a lot of training, and most teams still won’t achieve it.
According to Schwaber, only 25% of all software development teams are capable of writing high-quality code. A team of “jerks and idiots” (word-by-word quotation Schwaber) will be able to deliver an product increment at the end of an iteration anyway, but it will be an increment of trash.
Many organizations tend to bend the rules when introducing Scrum. He called it “ScrumButs”: Reasons (or better: Excuses) why the full benefit of Scrum cannot be applied here. He even specified an own Syntax for ScrumButs:
(ScrumBut) (Reason) (workaround)
For example (found here):
(The Daily Scrum meetings are too much overhead) (because the team members do not need to meet so often) (so we only have them once a week, unless we need them more often).
This bending of rules should be strictly avoided because this way you’ll never be able to use Scrum’s full potential.
Unfortunately, we had to leave the keynote at this point, as our own presentation on retrospectives started immediately afterwards (and we wanted some preparation time). So we could not witness Schwaber playing the “Boss & Worker ‘exercise with the audience.
This exercise, often part of the “Certified Scrum Master” training, demonstrates how even large teams (in this case about 150-200 people) can organize themselves in short time and without much of a hassle, and then work on a given task more efficiently as if there were detailed guidelines. If you want to learn more about it check this page, for example.
We found the keynote to be very intersting and even exciting, as was the rest of the day. The presentations were good to very good in quality, and feedback on our presentation was positive as well.
We will shortly publish separate articles on some of the other presentations.
I also found it very interesting that this event (in these days of crisis), although only held for the first time, was very well attended: About 80-100 people showed up for the ScrumDay itself. In addition, some people moved over to ScrumDay from TeamConf. As a result, some presentations (eg. the one by Boris Gloger and Oliver Zeiler) were rather crowded (than well-attended). But it didn’t detract from the good mood.
Overall, we thought the event to be quite successful. I also learned it is likely to be repeated next year. We hope to be there, too.
The next Scrum-related event in Munich, we should note, is the Scrum Gathering in October. Many known agilists will then return to Munich, including Ken Schwaber. So, if you missed him this time, you can still hear him later this year.
BFI
Loading ...