Cape Town Scrum User group – 6 Nov

I attended the second scrum user group meeting in Cape Town last night. A bit smaller than the launch, but still well attended. The format was a panel discussion with Peter from Scrumsense, Boris Gloger (in town for training) and Steve from MagmaTech.

Using a scrum task board for tracking the questions, it started with the usual question about what “It” is. (I have this urge to riff on the Matrix; “Unfortunately, no one can be told what scrum is, you have to see it for yourself”). Boris used the phrase that is the name of this blog: “Scrum is Scrum”. Who knew germans could be so inscrutable?

A poor fellow soul from Old Mutual asked for advice on how to implement scrum in a restrictive environment like OM. Boris’ answer was terse: “Just do it”. I saw a bit of myself in there; as technologists we want tools and guidelines.

The truth is that all you need to do scrum is: Know what it is and have a desire to do it. And maybe some stationery. Be brave, just do it.

We very quickly got into more meaty topics. The first one which I think was of interest was around Architecture. The question ventured that ‘design by committee’ was not a good idea and how scrum responded to that. The insight was really that, an architecture designed in isolation by an ivory tower architect did not accord with scrum principles. A cross functional team has value to be added in everyone participating in the activity.

This quickly degenerated however into architect slagging (e.g. they can’t be trusted, keep them away from your project etc.).

Another question was about analysis for the next sprint. Boris ventured that spending perhaps 10% on prepping for the next sprint was a good use of time, but that it should not necessarily be the sole province of the analysts. What was important was for the analyst to be prepared for Sprint Planning One; this is the analysis phase of the sprint, and any questions the team has, the analyst needs to be ready to answer. But this analysis should be communicated in the planning session with flip chart diagrams etc. Where analysis documents and artifacts are required to be produced by the team, this should be a task for that story to be done in the sprint.

Which led back to the previous point about design & architecture. If Sprint Planning One is about Analysis, then Sprint Planning Two is about design. Most teams use this meeting to create the tasks for the stories. SP2 should be workshop where the team design the solution that will be implemented for a story. Make some notes to capture that, but don’t laboriously create all the tasks required.

Another question examined the intention of the Sprint Review (or demo). There was some confusion I think since some people also use the term “Sprint Review” to refer to the retrospective. Boris highlighted that the intention of the “Sprint Demo” is to critically examine the functionality produced and how it has improved the product being produced. Too often this session has a tendency to be a chance to reward or to punish the team for performance. Either of these actions detracts from the teams self-management. The “Sprint Demo” should be focussed on the product, and should find the areas for improvement.

A question was around the ‘anarchy’ inherent in letting a team manage itself. This I think is a pernicious misreading of what the role of management in the team context is. The team is still subject to standards (of the organisation) and guided by the priorities established by the Product Owner. As someone from the audience pointed out; the longest a team, or team member should be allowed to ‘go rogue’ would be one day. When the next daily Stand Up rolled around, they should be reigned in by their team members or scrum master.

A clarification of what constituted an Impediment was requested. This boiled down to “anything that the team cannot accomplish” is by definition an impediment; else it is just a task that needs to be completed.

Our timebox finished around then, and it broke into smaller groups of private discussion.

Mention must be made of the uber-cool 24.Com room we met in. With its large screen TV, XBox360 and dual guitars for Guitar Hero, this was an office I would not mind working in… Add some draft beer taps into there and a really good coffee machine, and I doubt their employees would ever leave the building. Wait a second, I think I’m onto their feindish plot…


3 responses to “Cape Town Scrum User group – 6 Nov

  1. Any mention made about the suitability of scrum to new, ground up projects versus projects that are more in maintenance mode? I could imagine projects lacking design direction if too much architecting-by-committee is done.

  2. Well done – a very very good description about what happend int this meeting. thanks. boris

  3. Pingback: South Africa Scrum User Group Meeting Minutes « Scrum 4 You

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s