If you have been following my blog, you know that I have a love/hate relationship with Scrum.
I've previously talked about why I think Scrum will eventually die and I am still pretty much convinced of that point. Scrum has become something you sell through training and consulting. If you make your living off of doing this, sorry, but you may be part of the problem.
What this post is really about though is the problem of good architecture when implementing Scrum. In my experience, it is very difficult to create or maintain a good architecture and do Scrum. There is one very simple reason for this: mobs don't build good architectures.
Why?
Let me give you an example that helps to illustrate my point. Let us take a second to think about real physical engineering and architecture. Let us say we are going to put together a team to design and build a custom home.
So we get together a plumber, an electrician, a couple of framers and an architect. Now, let's have them start building the house. What do you think the architecture of the building will be like? What if the plumber and electrician know a good amount about architecture because they studied it in high school? They outvote the actual architect. In general the team is going to benefit from the real architect's experience and guidance, but when he understands a critical component which the other team members do not see, he is going to be overridden and that will spell trouble down the line.
Now, obviously this parallel does not completely apply. I am just trying to take one aspect of it for the point of this illustration: you don't want a group of people, as intelligent as they are, to make a decision which could be better left in the hands of an expert.
At this point you might be thinking “what an arrogant jerk!” You think a so called “software architect” knows so much better than the average developer? No, that is not exactly the point. The point is that there is a difference in level of experience and ability in software people, roles and labels aside, and when you use a democracy of team based decision-making methods, you get an average of the skill level and experience of the whole team as a result. It is a mouthful, but read that over a few times until you get my point. I think it is pretty hard to argue against, but let me give one more illustration.
Let us say now that you are going into a hospital to get heart surgery done. Now, this kind of procedure is not a one man operation. You would typically have a surgeon, an anesthesiologist, several nurses, and other doctors involved. But let's say for this instance that we let this surgical team operate like a Scrum team. Instead of the surgeon or chief medical officer ultimately calling the shots, the team will make a decision as a whole. Would you be ok with that? The nurse has the same vote as the surgeon? Two nurses can override the surgeon's decision? I think I would be a little bit alarmed, especially if I sat in on their design session.
I'm not trying to pick on anyone here or devalue anyone. I am also not trying to destroy the concept of team. Teams and teamwork are very important in the development of software. But I hope you can see the point that Scrum can tend to lean towards a mob built architecture for a system, and that architecture is only as good as the average of the abilities of the team members. Although more often than not it's really just as good as the most vocal and assertive member(s) of the team.
Where Scrum and Scrum-like processes fail
I don't see how a resolution to this problem fits inside of the Scrum framework, and that is a problem. The idea of a completely self-managing team is ok for making construction type decisions about building the software, but it has no solution for the overall architecture and general best practices for the development of the application. As much as we can despise hierarchy, it really has a value that is completely missed by Scrum. You really want to have the more senior highly skilled developers technical people with more power over decisions and direction than your less skilled. This isn't mean, it isn't spiteful or power-mongering, it is common sense. The problem with the self-managing-everyone-is-equal team is that it levels the field.
So what is the solution?
Would I offer up a problem without offering up a solution? There are several ways of dealing with this problem. It depends on how far you are willing to step outside of Scrum.
Solution 1: Scrumminess Factor: 9
Appoint a small team of technical and business architects that have the responsibility of:
- Overseeing the general architecture of the system
- Creating development best practices and guidelines
- Attending design sessions for other teams
- Stepping in when needed to steer a team back on the right course
This solution works only if you have several Scrum teams on the project, where it would make sense to have a team dedicated to architecture. This team is also a good one to be creating developer tools. I have actually been part of a team doing this kind of role, and I think it worked out pretty well. It doesn't really violate Scrum because that team is a separate Scrum team with a different kind of backlog.
Solution 2: Scrumminess Factor: 6
Appoint a technical architect to the project. This person is in charge of the technical people on all of the teams for technical direction, but not HR duties. This role would have the ultimate authority on any kind of development and architecture decisions for the project. They would be a floating resource that could help teams at times where needed. This person would be thinking about the bigger architecture picture that is being created by each of the teams.
Solution 3: Scrumminess Factor: 3
Appoint technical leads on the teams which are responsible for the architecture and ultimate technical direction of the team they are on. If you have multiple teams the technical leads should have a technical lead for the technical leads. This allows for a unified vision when there is dissent among the technical team leads. It has a low Scrum factor because it puts a direct leadership role on the Scrum team, but it allows for the solution to the mob architecture problem, while still keeping the architecture within the team.
One final word here. If you are still thinking that a central authority is not important to a business, consider this: every company I know of has either a CEO or a president. I have never seen a company with a Chief Executive Committee. Sure, there is a board of directors, whom the CEO ultimately is accountable to, but you have one person setting the vision and business direction of the company.