Advertisements
Posted by: jsonmez | March 12, 2010

When Scrum Hurts: Mob Achitecture

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 highschool?  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.  The idea that 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.

Advertisements

Responses

  1. I completely agree. Each team member’s skillset or proficiency in a particular technology are not equivalent. In the same vein, all opinions are not equal – in that they should not carry equal weight.

    Much as in your surgeon example, I would not want to turn a criminal or civil legal defense strategy over to my accountant, just because he has some experience defending clients in tax matters. Specialities do matter, since software, like medecine, is too complex for one person to master all disciplines.

    To assume that someone has the experience, training and skill to make intelligent and considered decisions regarding a system’s architecture just by virtue of having been lucky enough to be assigned to a scrum team is plainly dangerous.

  2. It appears you are making a common mistake of confusing self-organization with self-management. Scrum teams are NOT self-managing – they do not get to pick the projects they work on, gather their own resources and choose their own direction. They are self-organizing which means they get to choose how they solve their problems and in what order. This is a significant distinction.

    It appears you are also setting up a strawman argument that Scrum teams do not have specializations or that all decisions are made by consensus. That is not true – specialization is allowed in Scrum, but people are not asked to focus on it singularly. The idea is your specialists bring up the skills of the lesser members, not pull down their concepts.

    Frankly, if a design cannot be explained to other software professionals with a mediocre amount of experience, it is too complex, too cut and too esoteric to maintain. Please keep in mind, I am not saying it has to be explained in five minutes via a powerpoint. If after a good two hours your developers still don’t get the design and understand the tradeoffs, then you have some piss poor software engineers and a design that inappropriate for the people who are going to maintain it.

  3. There is another solution to your problem:

    Establish a small team that explores scenarios and construct solutions, sometimes in sets to explore varius solutions for the problem (spikes), for the most architecturally significant stories. This stories prioritized by how probable the problem would be, and how much risk it will bring if not understood at the beginning, and how valuable to the end user or other stakeholders this will be.

    This teams delivers the first version of the product with all this architectural problems explored and solutions implemented, and leasons learned about architecture, and architectural decitions already embedded in the product.

    The architecture starts to emerge from the implementation of those stories, that bring some needs that the architecture have to support, and from the constant refactoring of that code to allow to acomodate concurrent and sometimes confllicting architectural needs.

    I like to express some architectural constrains in tests or aspecs, that run in our continous integration cycle, giving us much more easily followed rules and conventions, depending the language is possible to create aspects the allow us to check if the code produced breaks some of the architectural constraints that we have in place.

    After that you can scale with other teams that will continue to evolve the product within the architectural decitions that are embeded on the code.
    Architecture is much more easy to follow when there are running examples that shows how things work.

    This is how Eclipse worked, and i think it has a very nice architecture, they really used a much

    The problem I see normally is that people that in traditional enviroment had gained a little more power, don’t know how to influence without authority, and miss old times when they had the final word on matters.

    When in a team enviroment, the everybody opinions is equal means to influence people from a non power position, and most ideias people don’t buy they won’t follow with authority anyway or create “undesired” messes.

    Architectural work will never be the same after crossfunctional teams.

    Hope that this view could help you understand how architecture would mix with other activities in simultaneus engenniering world.

    Cheers,
    Juan.

    • Good points. I think what your saying works well so long as you have mostly senior people. It really depends on the environment. Not every organization ends up hiring all rockstar developers. In that case the mob architecture problem are more pervasive.

      I definitely agree with you about learning to influence without authority. That is very important, and I am not advocating not practicing that skill.

      Sometimes, there has to be a final word though. And sometimes, it needs to come from the expert.

      Thanks for your comment, I appreciate your input.

  4. […] order to create a great product. This, in a nutshell, is the role of specialization in a team. Many criticisms of Scrum assume that there is an intended concept like “design by mob” or some other practice which runs […]


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

Categories

%d bloggers like this: