I’ve heard different discussions about ScrumMasters and rules. There a some positions that see the ScrumMaster as the keeper of the rules. His responsibility should be to make sure that everyone is following the rules. Another position says, agile (and so scrum) is to challenge the status quo. Therefore to force rule compliance is the complete opposite. So here my view, to get both together.
First have a look on rules, guidelines or directives in general. For all of them I try to use the following statement:
“If you follow the rules, you don’t have to justify yourself.”
That means, you should break rules, but only if you have a good reason and be able to explain it. And I’m not talking about interpreting a rule like a lawyer, but consciously breaking rules for a comprehensible reason.
One cause why we have rules is to be more efficient in decision making, and efficiency is the prime directive of a ScrumMaster. So we want to skip a long and sometimes painful decision making process about something similar which we have already decided. Another reason is to get more matching decisions about similar things by different people or at different times.
Another cause for rules is for managing complexity. Rules could be tools to handle complexity. One way is to add a rule to a system, so the system reduce its complexity. For example setting up a rule to standardize the working environment (everybody has to use eclipse in version x) will reduce complexity. Another way to handle complexity by rules is to use a rule to simplify the view on a system. In more than 99% of cases boolean expressions need a complexity less than 4, so the rule that there should be no boolean expression with a higher complexity than 3 simplifies the system by ignoring the cases with higher needed complexity. (read more…)
Open Space Software Development at the ALE2012 unconference in Barcelona
I met Jason Ayers (@SimplyTalking) at the XP2012 in Malmö and he told me about his rough idea of a session where people develop real software with the presetting of Continuous Delivery. This was based on the question he asked in a lightning talk at ALE2011 in Berlin as to how many people did Continuous Integration and the surprising result of only 6 out of 200 putting their hands up. I liked this idea and we started working out the details to let it happen at ALE2012 in Barcelona.
This workshop should create a project environment as realistic as possible. So the participants would have a chance to try out agile practices and learn them. We wanted to encourage people to participate as long and intensive as they want and to contribute what ever they are able and want to.
The first decision during the preparation we made was the scope of the product that should be delivered. We wanted something which is useful for the participants of the ALE2012 and which can be used immediately. So we came up with the idea of an unconference app (useable on mobile devices too) with helpful information around the event and feedback features for the users.
The second thing we decided was to start the session with a working Continuous Deleveriy Pipeline, a minimal technical architecture and one or two preimplemented features.
After some preparation skype calls (and google hangouts) and enthusiastic technical preparation from Alexandra Klimova (@aklimova), Bastian Spanneberg (@spanneberg) and Lars Rückemann (@lars_rueckemann) we started on Tuesday morning in Barcelona.
In general we use “hourly iterations” with a starting stand-up where we review the current work progress and plan the next things for the next hour. Then the current participants build the next requested feature and deliver the result as soon as it is ready for production. The purpose of “iterations” was to make it easy to allow people to join at the start of a normal conference session or open space.
Since a couple of years different ideas, concepts and methods are propagated under the buzzwords “Agility” and “Software Craftmanship”. But how good are they working in an economic everyday project life?
Within the framework of my job at codecentric I use many of these ideas, concepts and methods in my own projects and introduce them to different customers in the context of agile consulting. In doing so I often face wide differences between theoretic ideas and practical implementation. The existing business environment and the natural inertia in change processes frequently require a decisive adoption. How can you verify agile concepts and ideas in a project situation as realistic as possible? This requires a project environment with its necessities and difficulties, but all persons involved are able to think and act agile and further more the project interfaces (i.e. to the management) are in line with the agile approach, too. The time time pressure to deliver, which is typical for a project, has to be present.