Scrum without a Scrum Master

Charchit — Fri, 28 May 2021 06:09:44 +0000

I've seen some companies moving towards the "True Agile" concept of software development and in that process stumbling upon an idea of "no scrum masters".
Now, some people may misread it as "self managing team" and that's where I think the trouble begins.

I worked with a company which decided one day that they would like to set up their own version of the "Spotify Model". (Read here to know more about what it actually is)
The issue started when they thought that the first step in that direction would be to get rid of the "scrum master role".
Of course it had a little bit of resistance but not something managements haven't seen before. But what I am surprised by are the points they (or anyone in the favour) used to justify this:

1. "Scrum master role is something which should be shared by the team and "Agile coaches" are added as "trainers" to train the team."

Firstly the name "coaches" is very misleading.
A "team" has a coach whose responsibility includes to guide and train the team, and also to keep them working together like cogs in the wheel. Whereas, these coaches are more like "doctors" who will be able to help only when a team is able to self-detect a symptom which is causing an issue.
A coach is supposed to be monitoring every aspect of the team's performance continuously and also help in key decisions, which these people are definitely not doing. They are just suggesting approaches which might help in situations based on what they have learnt in their trainings and experiences, and I think if a polio vaccine has cured millions of people it might not mean it is a great vaccine for covid-19!
If we then decide to make them more accessible and included into the teams then anybody would argue about the difference between them and a scrum master.

2. "Teams to manage inter-team dependencies themselves."

This is a full day activity in itself for which traditionally a scrum master would already be collaborating with few people from each teams, which now comes on the shoulder of a "Tech Lead" or a "Lead BA" who might be the only ones who (are supposed to) have end to end knowledge about the software.
Now if these key people are going to do the inter-team dependency resolution and at the same time do their day-to-day work - please don't complain about velocity!

3. "Teams do not need "protection" from stakeholders."

Ideally, yes! They should not be needing it, BUT it's usually not the stakeholders who are the ones they need protection from. It's those people in "management" who without having much idea about the nitty-gritties of the software have committed some deadlines which suddenly become a ticking time-bomb on everyone's head. A good scrum master is supposed to prevent that from happening by being the key person in those discussions and justifying the reason why 5 seconds is too less of a time to deliver a baby!

There was a time when I practiced eXtreme Programming and I really did not make much sense of this role too, honestly speaking. But that was because how the team was structured and the kind of software we were developing.
We were not following "scrum" and did not have a "project manager". All we needed was a Product Owner who knows his/her product well and either can put the requirements well into a story or explain it well to a BA. Following a kanban board to pick cards from and keep our CI/CD on top priority made it so easy!
But since then been working in multiple scrum/kanban projects which have so many dependencies and team/stakeholder handshakes, I have realised the importance of this role (though I have some reservations about scrum in general but that's a different post in itself!)

I see a scrum master as a "stage director" who might always remain behind the scenes but makes it easy for everyone in the crew to understand the exact timing when they need to enter the stage.
If we want a team to function completely without a "scrum master", may be "scrum" itself is not the best solution for us!

Recipe for chaos in an XP team

Charchit — Sat, 27 Jul 2019 03:28:00 +0000

Our team failed! We failed in delivering value to the client, value to our users as well as we failed in showing the benefits of XP - eXtreme Programming to not only other teams but our managers as well.
So here I am listing some of the factors which I think lead to the fall of the project, the practices and eventually the team itself.
We were quite fine an year ago. We used to pair, practice TDD, interview users frequently and release awesome features to production almost weekly.
I would not go to the extent of saying we were living in perfect times, since we faced some very common problems -

Some people felt that TDD made them slow.
Management kept questioning whether pair programming is really "fast enough" and not slowing us down. This gave birth to some "Duct Tape Programmers" in the team. (That's a real term! Google it.) "The Duct Tape Programmer is someone who is able to cobble together software that solves the immediate problem, but without any concern for the code’s quality or maintainability. Most importantly, management adores them."
Some developers who were accustomed to work in old ways took a little longer to learn these ways which often caused friction among the developers while pairing.

But all these issues seemed quite trivial or not lethal.
So what went wrong?
Here is the ingredient list to get chaos in any team (works better in a high performing XP team):

100 gm of interference from management
A dev lead who is not given much value by the management
Odd number of people distributed in different time zones who are supposed to "pair"
Handful of devs who reject any new way of working - without even trying
A tbsp of "scrum" processes mixed with "XP" processes.
Tight deadlines for the development team - to taste!

Let's start with getting the chaos ready:

Management stopped believing that XP practices (which for them is only Pair programming and TDD) works. Developers started to get a feeling that all these practices are optional and can be carried out as per their convenience. When other devs called it out, the answer which they received from management was "you guys need to decide yourself" and "which ever way is quicker". This caused friction among the devs - those who knew that cherry picking of such practices does not work and those who didn't. (Will have to write a separate post to explain just this point)
Now comes the dev lead. The guy who supposedly is also required to direct everyone in the team on the practices or find a common ground. But sadly, management decided to play democracy here and the lead could not direct until they have a majority. You would be surprised to know, still the XP guys were in majority - so we continued.
Now let's use the oldest trick to win any battle - divide and conquer. The team was split into two. 2 devs in one team and 5 in another! Not only this, let's add an year long of work in the backlog for those 2 people and let the other bigger team work on POC in discovery phase. What an idea sir ji!
Let's introduce another ingredient - "Scrum"! Now people may ask what's wrong with scrum, nothing sir! It's just it is a concept in itself which (if not managed correctly) does not go well with some of the existing XP processes we used to follow. For instance, earlier we did not require a sprint to be started/ended to pick a story. We just worked on whatever feature is on the top of the backlog and keep refining the next set of stories weekly. We never limited or overfilled our current set of work with extra stories than what we were working on, but now we need to perform those extra "ceremonies" and decide/estimate which stories can we pick up-front. (I don't know about you but I smell waterfall somewhere)
Product owner loves only one thing more than on time delivery, "duct tape programmers" who make on/before time deliveries. The product owner starts giving some side jobs to his "second in commands" and this created further silos of work. If you did not see it yet, cherry picking of processes has started. People can choose to pair on some of the tasks and not to on some of the others. This does away with one of the most important part of pairing - context sharing.
Let's get the handful of devs we talked about in ingredients. They are the ones who along with the duct tape programmers will take care of TDD stuff. The secret is writing tests after the code has been completed. Because as per them "no-body can figure out from the tests if they were written before or after the implementation". SMH. (Even if all they wrote were negative tests, which will pass even if we delete the whole source folder!)
Let's heat things up a little now. Let's announce a tight deadline for a new feature which is still being planned. The stories still need to be created, we are just waiting for the architecture and design requirements. Even if it means developers will get hardly 3 weeks to complete development for an epic with 2 months load of work!
Now its time to put the mixture to actual cooking. Management decides to shift the whole team to offshore - stating importance of co-located teams. Even if it means letting go of 3 experienced developers of the team and hiring 7 new developers at the same time, specially when on-boarding a new developer takes roughly 4 weeks! This will crash the team's morale and kill the enthusiasm of the developers who are going to move out just because of their locations. Which will end with developers not giving their full (or even half in some cases) for the remaining of the project's interest.

Perfect! We are now ready with the chaos in the team. Garnish it with a few resignations and serve hot!
Bon Appétit!

DEV Community: Charchit

Scrum without a Scrum Master

1. "Scrum master role is something which should be shared by the team and "Agile coaches" are added as "trainers" to train the team."

2. "Teams to manage inter-team dependencies themselves."

3. "Teams do not need "protection" from stakeholders."

Recipe for chaos in an XP team