The New Scrum
Introduction
Scrum definition has gone through a major transformation. The Scrum PLOP (www.scrumplop.org) which can be considered as the new de-facto Scrum standard, lists many many organizational patterns which are observed in successful Scrum teams. People who are used to simple explanation of Scrum will find this drastically different. Why is this important today?
Forgotten Basics.
In last decade, Agile became the default way to execute software projects. But what did it really mean? With Scrum becoming most popular because it looks simple to adopt, most organizations started using Scrum as a way of working. Scrum defined three roles. Product Owner, Scrum Master and ‘The Team’. It defined some ceremonies. Stand Up Meetings, Sprints, Product Backlog, Retrospectives etc. In reality what mostly happens is that manager roles ‘tell’ developers that they need to ‘follow’ these ceremonies because there is a mandate to go to Agile. This is precisely where all is lost.
The Deceptive Simplicity Of Scrum and The Need For Patterns
While most people feel that doing Sprints, Daily Standups, Retrospectives and then having a role called Scrum Master, and a product owner. And you are doing Scrum. Easy, isn’t it?. Not really. Just ‘following’ these simple looking things is not what Scrum is.
There are lot of things need to be done to get it right. As was shown sometime back, Scrum ‘compresses’ at least 33 patterns from the ‘Organizational Patterns’ book. (https://www.scruminc.com/scrum-and-organizational-patterns/)
Getting these 33 or more things right is lot more complex than you can think.
To make this complexity explicit, Scrum authors, primarily Jeff Sutherland, started to list a set of patterns observed in successful scrum teams and document Scrum more formally as patterns at
Is this diverting from the original Scrum? Or its in sync with the original philosophy of Scrum? To understand this, let’s look at some of the history of Scrum and Agile.
Where did Agile come from?
Let’s briefly look at where ‘Agile’ came from. The New New product development game article in Harward Business Review was trigger for Scrum. In 1992, there was also an initiative at AT&T Bell Labs to figure out how to design highly productive software development organizations. Jim Coplien’s analysis of Borland QPW team was published in 1993. (This gave ‘stand up meeting’ to Scrum.)
Scrum was presented as ‘Pattern Language of Highly Productive teams” by Mike Beedle.
Throughout 1990s, many people, documented Pattern Languages for highly productive teams. Notable were Ward Cunningham’s ‘Episodes Pattern Langauge’ and Alistair Cockburn’s ‘Risk Reduction Patterns’.
Kent Beck published his ‘XP’ book in 1999.
In 2001 We got Agile Manifesto, which published all this wisdom in the form of ‘Values and Principles’
The set of patterns and pattern languages researched by Jim Coplien and Neil Harrison was published in a book ‘Organizational Patterns For Agile Software Development’ in 2004.
The timeline looks something like following
As can be seen, most of what became Agile was published as a set of patterns, and Scrum was originally published as a ‘pattern language’. It was later presented as an ‘extension pattern language’. Extension to the set of already published organizational patterns.
Also as we can see, there were two ways in which the Agile wisdom was documented. Most of pre 1999 descriptions were in the form of patterns. XP and Agile Manifesto, chose the form of Values and Principles. (XP added specific practices to it). It can be understood, as pattern format sometimes becomes too cryptic for someone to consume.
I personally prefer the pattern format as it not only nicely describes context, and provides some guidance on which patterns are essential for other patterns to work, providing something called as a pattern language.
Scrum as a Pattern Language
(From https://www.scruminc.com/scrum-and-organizational-patterns/)
The pattern language view allows us to understand which patterns are essential to make a particular pattern effectively implemented. Each pattern is arranged in way that provides context for other patterns..e.g.Informal Labor Plan allows Developer to Control the process which in turn allows Group Validations (standup, pairing etc. etc.) to be effective.
The Scrum PLOP web site lists many more patterns apart from these 33 basic patterns. Patterns range from things like ‘Boot Camp’ required more for a distributed team setup, to Developing In Pairs to coding practices like Daily Clean Code.
It is mandatory for software professionals in 2018 to understand all these patterns and take their guidance in building better Scrum Teams.
Some Examples Of Important Patterns
There are some patterns there which I think are interesting and crucial to the success of the teams. I will list a few below to give some idea of what organisational patterns look like, and also to show how broad they are as opposed to a very narrow view of few practices that we know.
For details description of these and many more patterns you can visit
And
Some important pattern examples follow.
Community Of Trust
It is essential that the people in a team trust each other, otherwise, it will be difficult to get anything done.
Therefore:
Do things that explicitly demonstrate trust, so it is obvious. Managers, for example, should make it overtly obvious that they are at the side of the organization, rather than playing a central role that controls people to do what must be done. Take visible actions to give developers control over the process.
Producer Roles
The overhead and bureaucracy in the organization is excessive, as manifest by the presence of too many roles. Yet all the roles seem important. It looks like there is no way to reduce the bureaucracy.
Therefore:
Identify each role as a producer, supporter, or roles that add no value to the project (deadbeats). Eliminate the deadbeats, and in some cases, eliminate or consolidate some supporters. Nurture the producer roles; they are the ones that pay the bills.
Developers Control The Process
A development culture, like any culture, can benefit from recognizing a focal point of project direction and communication. Successful organizations work in an organic way with a minimum of centralized control. Yet there are important points of focus, embodied in roles, that tie together the ideas, requirements, and constraints into an artifact ready for testing, packaging, marketing, and delivery.
Therefore:
Make the Developer the focal point of process information. The developer is central to all activities of this end-to-end software development process.
Note that other hubs, such as the ManagerRole, may exist as well, though they are less central than the Developer.
Architect Controls the Product
…an organization of developers exists and needs strategic technical direction.
Even though a product is designed by many individuals, a project must strive to give the product elegance and cohesiveness. One might achieve this by centralizing control, but totalitarian control is viewed by most development teams as a draconian measure. One person can’t do everything, and no single person has perfect foresight. However, the right information must flow through the right roles; individual areas of competency and expertise must still be engaged.
Furthermore, there needs to be some level of architectural vision. While some domain expertise is distributed through the ranks of the development team (DomainExpertiseInRoles), the system view — and in particular, the design principles that create a common culture for dialogue and construction — usually benefit from the conceptual integrity we associate with a single mind or small group.
Therefore:
Create an Architect role as an embodiment of the architectural principles that define an architectural style for the project, and of the broad domain expertise that legitimizes such a style.** The Architect role should advise and influence Developer roles, and should communicate closely with them. The Architect doesn’t dictate interfaces (except in cases where arbitration is necessary). Instead, the Architect builds consensus with individual developers, developer sub-teams, and if necessary with the entire development staff, commensurate with the architectural style. The Architect is the principal bridge-builder between development team members.
The Architect should also be in close touch with Customers so the domain expertise is current, detailed, and relevant.
Architect Also Implements
A project needs an overall guiding strategic technical direction. This usually comes from the architect. However, too many software architects limit their thinking and direction to abstractions, and abstraction is a disciplined form of ignorance. Too many projects fail on “details” of performance, subtleties of APIs, and interworking of components — or, at best, they discover such problems late
Therefore:
Beyond advising and communicating with Developers, Architects should also participate in implementation.The Architect should be organizationally engaged with Developers and should himself or herself write code. The Architect may implement along with a developer using DEVELOPING IN PAIRS
Domain Expertise In Roles
Matching staff with roles is one of the hardest challenges of a growing and dynamic organization.
Spreading expertise across roles complicates communication patterns. It makes it difficult for a developer or other project member to know who to turn to for answers to domain-specific requirements and design questions.
Therefore:
Hire domain experts with proven track records, and staff the project around the expertise emodied in the roles.** Teams and groups will tend to form around areas of common domain interest and focus. Any given actor may fill several roles. In many cases, multiple actors can fill a given role.
Domain training is more important than process training.
Local gurus are good, in all areas from application expertise to expertise in methods and language.
Summary
Organizational Patterns were patterns observed in good and successful software development teams. These are far broader than any specific Agile Method. Scrum was originally presented as an ‘extension pattern language’. Extension to the already existing organizational patterns. Scrum PLOP is taking this forward by explicitly listing all the known organizational patterns which make up successful scrum teams. This is a must read resource for any scrum practitioner. It’s time to fix our views about what is Scrum.
