Agile, Scrum and the nonsense about architects


Let me start this post with a bit of ranting: I am so tired to hear or read the same nonsense over and over again usually emitted by people obviously hardly knowing what they are talking about.

What am I ranting about? It is about this stupid argument that Agile does not need an architect because Scrum does not know about this role. Aaaaaaaarrrrgh, could scream about that nonsense!

Do not get me wrong: I do not think that you always need an explicit architect — not at all. There might be reasons to have an architect on your project, there might be reasons not to have one. That is not the point.

It is the mindless argumentation usually used that annoys me. It goes like this: “Scrum does not define a role Architect and therefore an architect is not needed in an agile IT project. Case closed. Period.”

I hoped we left this mindless argumentation behind us several years ago but I still hear this crap over and over again — usually either by some blindfold agile disciples trying to justify their point of view this way or by some agile deniers trying to start a rant right after this claim.

I just read it a few days ago again in a session abstract of a big, well-known German conference. And it was not meant as a joke. The author meant it absolutely serious. Aaaaaaaarrrrgh again!

Okay, I guess most of you know already what is wrong about this argumentation. For those of you who are not completely sure, let us step back and think about Scrum a bit:

First of all Scrum is not an equivalent for Agile but just a tiny process framework with lots of gaps and missing bits and pieces (at least if Scrum is all you have to run an IT project). There is a lot more to Agile than just Scrum. Thus, even if Scrum does not provide for an architect it does not mean at all that Agile does not need an architect. But that is not the most important point.

The most important point is: Scrum is IT-agnostic!

Scrum does not know anything about IT!

Or as Jeff Sutherland once told us in my original Scrum Master training several years ago: “You can use Scrum to organize your weekend.” And even though you partner is not provided as an explicit Scrum role you should better not exclude her or him from our weekend organization if you care about your relation … 😉

Actually, Scrum was not developed in the IT domain at all. Scrum’s origins are the design and development of consumer goods. Much later it became generalized and rolled out to other domains, as the IT domain.

And if you look really carefully, you will figure out that Scrum also does not define roles as Requirements Engineer or Tester. Scrum even does not define a role Developer!

There is just a Team and all Scrum tells us about that team is that you better make sure all skills you need to get the job done should be available in the team.

Utilizing the mindless argumentation from the beginning I am really curious how anyone will get an IT project done without developers. Maybe Chuck Norris can do, but not the rest of us … 😉

Conclusion: The fact that Scrum does not mention an architect role does not give any evidence if this role is needed or not in an IT project. Scrum does not mention any IT-specific role because it is IT-agnostic.

Thus, please let us stop using this stupid argumentation for good. And if you should ever see someone using this argumentation again please tell him or her that he or she is talking crap. Let us all get rid of that nonsense for good.

Again, there might be good reasons why you need or do not need an architect in your project but that is a different story … a much more interesting story!


  • Jinlin Ding

    3. July 2014 von Jinlin Ding

    Scrum is a just Methodology, and it defines three roles:
    Product Owner, Team Members, and Scrum Master. That’s all.
    When we talk about the “Architect” role, we should talk about “how to practice Scrum” first. If the words “Future”, “Potential”, “What If”, and “Might be” sparked in our minds, yes, we need “Architect”. But if we only focus on “task”, “deliver”, we do not need it.
    When I practice Scrum at home, I found that my wife, my 21 years old college boy and me always have “Architect” fly around us, but my 9 years old daughter does not, she just did.
    We are human beings, we learn while we doing. From a long view, our product has already been Architect-ed.
    Instead of discuss the “Architect”, I prefer do “Refactoring”.
    I think “Team Decision” is a very strong word, actually I should say it is the spirit of the Scrum.

  • Derek Greer

    “There are no titles on teams. Teams self-organize to turn the requirements and technology into product functionality. This type of state-less, ego-less, development team is flexible to address any work that arises. Scrum avoids people who refuse to code because they are systems architects, or designers. Everyone chips in and does his or her best, doing or learning how tho do what is needed. Scrum Team members don’t have job descriptions other than doing the best possible. No titles, no exceptions.” – Agile Software Development with Scrum, Ken Sschwaber

    All software development contains a design. Whether the design was foreordained by some 90’s model non-coding software architect role, is dictated by a guy on the team with the title “Architect” , emerged from a guided set of best practices, or is the resultant state of whatever a bunch of monkeys slinging code for a month happens to be, there is a design. Most software endeavors benefit from having experienced engineers on the team which can help guide the architecture, but having a specific Architect role works against the overall goals of agile principles in general and is explicitly advised against by Scrum as applied to software development. Why should a new team member who may have strengths in a given area that the “Architect” doesn’t posses have less influence over the direction of the project? Flat teams solve the problem of adapting to these sorts of changes in team dynamics and skill-set makup that having designated roles tend to work against.

    Don’t confuse lack of an Architect with lack of architecture. In software engineering, we don’t draw diagrams of what needs to be built and pass on the work to a general contractor (or at least that’s what our experience as an industry should have taught us doesn’t work). All developers do architecture. It’s just a matter of where you are on the spectrum of skill and experience .

  • sam sneed

    2. April 2015 von sam sneed

    SCUM was never part of agile and will quickly force your best engineers to leave. It’s over mgmt and in loco parentis and really sucks butt.


Your email address will not be published.