{"id":499,"date":"2010-03-12T12:07:52","date_gmt":"2010-03-12T19:07:52","guid":{"rendered":"https:\/\/simpleprogrammer.com\/?p=499"},"modified":"2020-12-31T22:52:52","modified_gmt":"2021-01-01T03:52:52","slug":"when-scrum-hurts-mob-achitecture","status":"publish","type":"post","link":"https:\/\/simpleprogrammer.com\/when-scrum-hurts-mob-achitecture\/","title":{"rendered":"When Scrum Hurts: Mob Architecture"},"content":{"rendered":"

If you have been following my blog, you know that I have a love<\/a>\/hate<\/a> relationship with Scrum.<\/h2>\n

\\n\\nI’ve previously talked about why I think Scrum will eventually die<\/a>\u00a0and I am still pretty much convinced of that point.\u00a0 Scrum has become something you sell through training and consulting.\u00a0 If you make your living off of doing this, sorry, but you may be part of the problem.\\n\\nWhat this post is really about though is the problem of good architecture when implementing Scrum.\u00a0 In my experience, it is very difficult to create or maintain a good architecture and do Scrum.\u00a0 There is one very simple reason for this: mobs don’t build good architectures<\/strong>.\\n\\n<\/p>\n

Why?<\/h2>\n

\\n\\nLet me give you an example that helps to illustrate my point.\u00a0 Let us take a second to think about real physical engineering and architecture.\u00a0 Let us say we are going to put together a team to design and build a custom home.\\n\\nSo we get together a plumber, an electrician, a couple of framers and an architect.\u00a0 Now, let’s have them start building the house.\u00a0 What do you think the architecture of the building will be like?\u00a0 What if the plumber and electrician know a good amount about architecture because they studied it in high school?\u00a0 They outvote the actual architect.\u00a0 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.\\n\\n\"\"<\/a>\\n\\nNow, obviously this parallel does not completely apply.\u00a0 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.\\n\\nAt this point you might be thinking “what an arrogant jerk!”\u00a0 You think a so called “software architect” knows so much better than the average developer?\u00a0 No, that is not exactly the point.\u00a0 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.<\/strong>\u00a0 It is a mouthful, but read that over a few times until you get my point.\u00a0 I think it is pretty hard to argue against, but let me give one more illustration.\\n\\nLet us say now that you are going into a hospital to get heart surgery done.\u00a0 Now, this kind of procedure is not a one man operation.\u00a0 You would typically have a surgeon, an\u00a0anesthesiologist, several nurses, and other doctors involved.\u00a0 But let’s say for this instance that we let this surgical team operate like a Scrum team.\u00a0 Instead of the surgeon or chief\u00a0medical officer ultimately calling the shots, the team will make a decision as a whole.\u00a0 Would you be ok with that?\u00a0 The nurse has the same vote as the surgeon?\u00a0 Two nurses can override the surgeon’s decision?\u00a0 I think I would be a little bit alarmed, especially if I sat in on their design session.\\n\\n\"\"<\/a>\\n\\nI’m not trying to pick on anyone here or devalue anyone.\u00a0 I am also not trying to destroy the concept of team.\u00a0 Teams and teamwork are very important in the development of software.\u00a0 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.\u00a0\u00a0Although more often than not it’s really just as good as the most vocal and assertive member(s) of the team.\\n\\n<\/p>\n

Where Scrum and Scrum-like processes fail<\/h2>\n

\\n\\nI don’t see how\u00a0a resolution to this problem fits inside of the Scrum framework, and that is\u00a0a problem.\u00a0 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.\u00a0 As much as we can despise hierarchy, it really has a value that is completely missed by Scrum.\u00a0 You really want to have the more senior<\/span> highly skilled developers<\/span>\u00a0technical people\u00a0with more power over decisions and direction than your less skilled.\u00a0 This isn’t mean, it isn’t spiteful or power-mongering, it is common sense.\u00a0 The problem with the self-managing-everyone-is-equal team is that it levels the field.\\n\\n<\/p>\n

So what is the solution?<\/h2>\n

\\n\\nWould I offer up a problem without offering up a solution? \u00a0There are several ways of dealing with this problem.\u00a0 It depends on how far you are willing to step outside of Scrum.\\n\\nSolution 1: Scrumminess Factor: 9\\n\\nAppoint a small team of technical and business architects that have the responsibility of:\\n\\n<\/p>\n