Design is a team responsibility

This leads on from a comment on my previous post. The implication seems to be that in a new project, scrum will tend to result in a ‘design by committee’ design-smell or anti-pattern.

From Wikipedia: “The defining characteristics of “design by committee” are needless complexity, internal inconsistency, logical flaws, banality, and the lack of a unifying vision.”

The implication is that the ‘right’ approach to design is to find some genius designer to produce the perfect design from your requirements and communicate it to the team to implement. This ideal is in many ways similar to the genius fallacy we find in fields like science and the arts. In this media-driven ideal, the genius isolates himself from society and the outside world until he returns with the perfect idea written on a stone tablet, like a revealed truth. The reality is that even reclusive genii like Newton and Einstein worked collaboratively and benefited from the interaction with their peers.

Furthermore, the prevailing metaphor for software developments’ design process (architecture) is a poor description of the actual development process. In a construction project, an architect designs the building right down to the specification of the materials to be used. The people who build the structure have no latitude in the choices of how to implement that plan, and certainly are not expected to exercise their creativity in the execution of their tasks.

This is in stark contrast to the expectation we have of software developers. These are smart creative people who we ask to do what amounts to one of the most difficult endeavors humans have ever attempted. Trying to restrict their ability to apply themselves to the problem by constraining them to a design which they did not participate in, is a poor use of these human assets.

The design is only going to be as good as its implementation. By involving the whole team in the design process, buy-in is created which will translate into a better implementation of the design as a whole. In my experience, a ‘stone tablet’ design is viewed as an obstacle to be overcome rather than a solution to a complex set of inter-related problems. It means that when a developer is faced with a choice of expedience vs. following the design they would be more inclined to follow the design, because it is their design. Or to raise issues with the design during implementation to allow for its improvement.

The other important design lesson from agile development is that design evolves. The Construx white paper on scrum (note: registration required) rightly (in my view) points out that scrum does demand a degree of experience in being able to design an architecture that will gracefully evolve over the lifetime of the development. This is hard work.

Ken Schwaber (in the video of his presentation to Google, ‘Scrum et al‘ talks to this point as well. A scrum team will need to design an architecture and then implement some feature which will use this framework in a tangible way. Driven by the time-box this means that the framework by necessity¬† will have to be small enough to fit into sprint, and will add features incrementally. But it also means that you’ll find out early whether or not your chosen architecture will deliver on its promises.

Further your design within the sprint is contrained to Sprint Planning 2. Typically this means that you’ll need to formulate and communicate the design to the team in a max 4 hour meeting. I suspect that some would argue that ‘Sprint Zero’ would allow for some design as an activity with artifacts produced that are not code or working software. My gut feel is that ‘Sprint Zero’ is an aberration. You may find that within the context of an enterprise environment, where architecture documents are a governance requirement there would be a tendency to push for this.

I would contend that the right place to produce those documents is within a ‘normal’ sprint where the goal is still to produce some working software. After all, the point of scrum is to do just that. Any architecture produced in ‘Sprint Zero’ should be a broad brush stroke rather than a detailed final product.

Similarly, the design produced in ‘Sprint Planning 2’ should be the stuff of flip charts and white board photographs. Producing the UML diagrams and other design documentation should be done in the sprint. It’s a task, and anyone in the team should be able to pick this up. This is design as a collaboration; a group activity.

The role of the architect then is as an expert with experience in design and someone who actively shares that knowledge and experience with the team. And with the flat team structure in a scrum, it means they’re much more likely to also code, which I think is required of a good architect. Think of it as forcing him to eat his own dog food.

Lastly, design by committee as an anti-pattern is described on this website as something that usually happens when the size of the group exceeds 6-10 people, which is also handily about the size your scrum team should be. I think much of the negative press that architecture and design receives is the way that it is implemented in a waterfall-style organsiation. It’s a valuable, important part of the development process, and it has an important role to play in an agile process. It just does not (and should not) receive the level of ‘celebrity status’ it currently has.

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…