Translate

December 1, 2014

When Scrum needs to mature in the enterprise, architecture comes to the rescue.

This post is the consequence of a comment on my previous post that startled me as it stated that in Scrum there's no place for the architect. Scrum has no future were it not for the architect.

First of all, I am not a fan of Scrum, mainly because it sounds too much like an acronym and I hate acronyms. The other reason why I don't like Scrum is because it entices too many religious zealots to start a jihad against all non-believers. And then there's the third reason, the reason why I don't like Scrum is because too many so-called Scrum practitioners use it as an excuse for not going for longevity and quality of their deliverables.

So, with that of my chest, let me tell you that I really love what Scrum stands for. That whole thing about delivering something useful to who ever pays you for building it as soon as possible. Allowing for the customer to change his mind constantly about what is important and what not. And the very notion that sometimes you do something and than you have to redo it but differently is part of the deal is excellent.
Scrum is awesome and it addresses a lot of very significant aspects of old-school project management. Especially when it comes to long analysis phases, and even longer design phases and excruciatingly long development phases, Scrum has introduced a lot of benefits.

One of the main reasons why Scrum is such a success from an adoption perspective is the fact that it has been introduced in the limited scope of development project teams. And then in most cases those teams that had to face a lot of changes in requirements and priorities, namely front-end, user facing systems. Systems that directly addresses the needs of an end user.

As the common enemy called "customer" united all developers, Scrum thrived.

The rebellious attitude introduced with Scrum appeals to many developers, and I don't mean any disrespect to developers. I am a developer and often I am my own customer, or in Scrum terminology, I am my own product owner and I suffer from changing priorities and requirements all the time. It's part of usable software.

In many organizations these days, development projects are done with the Scrum manifesto in one hand and a sincere lack of documentation in the other.Here lies already a big problem, namely the fact that in these organizations people, even Scrum zealots, still talk about projects. In and by itself it is impossible to do projects using Scrum. The very notion of projects is preposterous, but that'll be covered in another post sometime.
These enterprises have introduced Scrum in their software development projects and those organizations that are a bit more mature have introduced DevOps, which is the second stage in Scrum-olution if you ask me.

Havoc is wrecked when a Scrum team is developing software, functionality that depends on the deliverable of another Scrum team. How are sprints aligned? How are interfaces co-developed, how are release dates, even in continuous delivery situations, coordinated? Scrum, nor DevOps, can answer these questions. The reason for this is that the scope of Scrum was never intended to go beyond the activities of the Scrum team. Inter-scrum-communication is, well not existent.
Of course it exists, because it happens all the time. Initiatives like meta-scrums, meta-sprints and meta-other-Scrum-buzzwords are popping up all over the place.
The fact is that once you look beyond the scope of sprints and epics and what the Product Owner is looking at from a back log perspective, there's not a lot that you can't can do without the quality and talents of an architect. It is always the architect that delivers the bigger picture.

Scrum is, I believe, something that stems from the sport rugby. And if not, than still for the purpose of this post, it does. And where the Scrum teams play the game, it is the architects that define the playing field as well as the rules by which to play. Mind you, Scrum does not equal developer's anarchy. It allows for the freedom of the team, if suitable, to apply a pragmatic approach to realizing the product owner's products. But the freedom is within the limitations set forth by the architect in terms of policies, principles and standards. Because of the architect, features integrate and systems can communicate. But more importantly, it is architecture that allows for cohesion and consistency between different applications and services, thus ensuring for example compliance to laws and regulations. Especially in environments that are predominantly based around SOA (WS* and REST both), it is imperative that policies and standards are defined and adhered to in a consistent and cohesive manner in order to be and stay compliant.
This becomes very apparent when principles like:

  • "One Version of the Truth"
  • "Re-use of business logic"
  • "Role based Access Control"

Are to be followed. Without an architecture framework, it becomes extremely expensive from a governance point of view for an organization to enforce or even ensure adherence.

Do you need an architect in a Scrum team? Probably not as long as you've got one or two members in your team that are taking care of the relevant design work, whether or not implicit to the Sprints deliverables. But in the bigger picture, there is definite need for an architect, especially when you not only want your development teams to be agile, and capable of adjusting to the whims of the product owner but also your whole business to be agile and capable of adjusting to market demands.

Thus, unless you want to keep Scrum to be Waterfall's baby brother for ever and ever, you need to mature your agility and that is only possible by applying architecture and involve architects. But not so much within Scrum teams, but across these teams.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.