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.

I agree strongly that Architects that don’t code are an antipattern, and not just in scrum teams. Design in software takes place at all scales, from the single line of code to the whole application. Design divorced from coding is likely to be unrealistic.

this is what a “spike” is for – to validate architectural decisions early,and to provide a working example to follow.

I haven’t really experienced the “design by committee” problem in scrum. Does review make design worse? Not often.

The teams that I have been on generally have had a “technical lead” who has the last call on how to do it. The only time that I have seen this go wrong was with a technical lead who though he didn’t have to listen to anyone else’s input.

I don’t think that scrum “demands a degree of experience” and that novices can’t use it (so if everyone used scrum, how would novices then gain skills?), just that they should ask their colleagues “how would you do this?” more frequently. With more novices, do more code reviews. Inspect and adapt.