Leaning towards an Agile Software Architecture

People often ask me why I chose to follow a career as Scrum Master. Is that even a job? To be honest I don’t really know for sure, but I am pretty sure it is a role that someone needs to take when working with a SCRUM methodology. And I will explain a bit in the following.

I am a big fan of team sports, mostly because that is the place where I meet all my friends after work. And I always like to consider the SM role as both the referee and the coach of this “game”. You don’t get to decide, you get to observe, moderate and motivate. Get a better traction, increased performance and a better working environment along the way? Great, now you are probably a great SM.

Second most asked question: should a SM have a technical background? From what I just said above I guess not… but I do recommend quite the opposite. I consider that the industry in general is fed up with artificial leaders; you need knowledge to gain trust, and you need knowledge to consolidate trust in others.

Maybe the reasoning from above justifies why I chose the topic of this article in the first place. Should we embrace SCRUM “by the book” and wait for the results or take the core of SCRUM and adapt it to our own needs? After all, you could do SCRUM in a marketing team, right? Sure, but you might use some different flavors.

The flavors that usually SCRUM tastes well with are the well-known XP principles. They worked before, they work now and probably are the most used technical tools that support development still.  The next image captures exactly this, SCRUM and XP are not step brothers but rather congruent subsets.

Image source: safaribooksonline.com

It is that point in a Scrum Team journey where the process works but we need some tools to consolidate it. And yes, I always reach for XP at that point, there might be other options and it is the SM’s role to present and demonstrate them to the team. At the end of the day is always the team that decides what works best for them. And that is where the core of SCRUM resides: “Individuals and interactions over processes and tools”.

I mentioned the top two questions that I am being asked as a SM. I would like to mention the most intriguing one as well: Why would you hesitate to recommend SCRUM to a company/group of individuals?   Well, I first thought anything I would say could be used as an argument to demolish SCRUM but then again there is no such thing as bad advertising.  So I tried to put myself in the shoes of a Scrum team member and think why I don’t like it (it is about individuals after all, so that should always be the place to start looking)

So, I am a great Scrum team member, I work for and with my team and I know a little bit of everything, I can provide my contribution to any sprint, no matter the nature of the stories that compose it. But wait a minute? I like JavaScript, I am really good at it and still…there is no item in the backlog that has anything to do with client side programming. But I want to work and improve on what I like…

Specialization. I think this might be one of the downsides of Scrum. Remember the old ‘technology based’ teams, the ping-pong between UI team and Backend team… Sure we do. I am not saying we should get back to that, but how can we become great Agile teams with great professionals, that enjoy what they do? Maybe we can find an answer in what follows next.

Many experts like to say that Scrum is only as good as the product that is being developed under it. If we go one level deeper with this statement one might say that a key factor for following the agile pattern is to embrace a sustainable software architecture, the kind of architecture that enables the expansion of the system to happen in a gradual, easy and maintainable way along with the growth in complexity of a given project. I can only agree and subscribe to this idea.

When you give it some time to research the basic idea behind Agile Software Architecture is that of an ongoing process, which may never end. An Agile architecture does not define an agile team, but a good architecture is for sure a good driver for agility. There are two famous principles that govern this: Keep It Simple, Stupid (KISS) and You Aren’t Gonna Need It (YAGNI). Not going to explain much about these principles as their reputation precedes them. My concerns are more related to how we can consolidate such an unpredictable approach.  After all, according to YAGNI we should postpone making complex decisions until we actually need them and, according to KISS, we should avoid introducing too many abstractions that complicate the architecture at the very beginning (fancy extra layers, interfaces, factories and so on).

Sounds great, simple is better after all. However there is another key question rising up our minds:

When should we take decisions in and agile software architecture?

There are various answers to this question, some that I agree with and some that I don’t understand. To summarize them all I should say something like:

We should take decisions not in the last possible moment, but rather in the most responsible.

Probably the answer complicates the question even more but I will try to focus more on a solution rather than offering an answer.

The new role in town (or Scrum): Agile Software Architect. This subject was addressed by a few Agile enthusiasts recently.  Sounds like a pretty specialized fellow, right? This might just answer our specialization issue. But how is this compatible to Scrum in any way?

Let’s try to sketch a job description for this role first:

• Hands-on experience – we are not talking about a consultant here, this person is a full-time team member that knows the team dynamics, strengths and weaknesses;
• Offers balance between the big picture and now – sure, every team member could/should do this, so nothing wrong with Scrum here;
• Produces prototypes to make informed decisions when an important technical risk is involved – there is always the need for this in Scrum no matter how well the product backlog is constructed; Spikes or investigate stories are usually the solution but that is not always producing working software, right?
• Focus on sustainability – we could describe this like: think outside of the current story/sprint/release scope in matters that involve the growth in complexity of a product.

It doesn’t sound too bad, right? But who should have this role? Maybe a person that is ’empowered’ by management or someone elected by the team after a few sprints. Well, not sure if I’m right or wrong, but if we want to keep it in Scrum territories then it might be someone elected by the team on a sprint by sprint or release by release basis. He is still a team member, he can still pick up a story from the backlog but at the same time we all agree as a team that he is our visionary for the next sprint/release. Let’s give him some freedom and creativity and we might just get answers before we reach complicated questions and face critical decisions.

This is not a Scrum recognized role, but then again, this is not a Scrum recognized article. It is just a thought I wanted to share and if we can take something useful out of it than it might just be a step forward for Scrum and Agile for our bounded context.

After all, we are allowed to self-organize and adapt to change, aren’t we?!