I came across the following quote at a Meetup on Leadership:
“When the Master governs, the people
are hardly aware that he exists.
Next best is a leader who is loved.
Next, one who is feared.
The worst is one who is despised.
If you don’t trust people,
you make them untrustworthy.
The Master doesn’t talk, he acts.
When his work is done,
the people say, “Amazing:
we did it, all by ourselves!”
– Lao Tzu
I believe the above aptly describes the Master in ScrumMaster.
If you throw a stone at a congregation of software people, chances are you will hit an Agile Coach. Being an Agile Coach is almost becoming a fashion these days. “I am an Agile Coach”. I get to hear this quite a lot these days. It’s like ScrumMasters of yesteryears have now graduated to become Agile Coaches.
Not to condescend all Agile Coaches out there (well, I am one of them), I see lot of asses in lions’ skins (ass means donkey here, not what you think!). Yes, some of these Agile Coaches have truly risen from the ranks, worked their way through the trenches, and have earned their stripes (I come from a family with a long tradition of serving in defence forces). Such coaches have reached the Ri stage of Shuhari paradigm. They really know their stuff and are making significant impact with the teams/ organisations they are working with. However, there are others who picked up a ScrumMaster certification after two-days of training and became Agile Coaches overnight. Some of them even flaunt certifications across methodologies – Six-Sigma whatever belt, PMP (seriously?), etc.
Being an Agile Coach is not very different from being a sports coach. To begin with, you can’t be one just by passing a theoretical exam and having worked very little in the field. You need to have years of experience in the field and should have mastered some aspect of it. Like a sports coach, you should know that not all methods apply the same way everywhere – different teams have different training needs because of their own strength/weakness combinations. There is no one-size-fits-all approach. Yes, the basic principles remain the same but you still need to customise the treatment for each team.
And to make matters worse, such Agile Coaches are being hired by organisations (as employees on payrolls or as consultants) eager to get on the Agile bandwagon. And when their methods don’t work in such organisations, Agile gets bad name. People think, “maybe Agile is not for me”. Well, that could be true with some teams/ organisations but a bad implementation of Agile by a worse “Agile Coach” should not be considered a representation of what Agile truly has to offer.
I would just end this rant hoping that professional astuteness would trump fancy titles.
Yeah! That’s right. Doing Daily Scrums (aka daily stand ups) alone doesn’t make you Agile. You need to be doing them well too.
But nobody told you how to do them properly. Really? REALLY? Well, in that case show this post to your ScrumMaster.
Anyways, getting on with it. Here’s how you you can improve your Daily Scrums.
1. The Purpose
The purpose of Daily Scrums is to keep the team in the loop about your progress and bring to light your impediments so that the ScrumMaster / Team can remove them.
2. Some Prerequisites
3. What to say (and what not)
Each team members mentions the following:
There’s a good chance that when a team member mentions something as part of his update, you might have something to add to it / respond to it. If it is a one-liner comment / answer, go ahead with it. If it becomes a back-and-forth discussion, then stop there and take it offline. Do not continue to discuss it during the Daily Scrum.
4. How long does it take
A Daily Scrum should not take more than 15 minutes. In fact, if you are doing Step 3 above well, 15 minutes would be more than sufficient for the whole team.
5. Pay attention to what the team says
Sometimes we do not pay attention to what the a fellow team member is saying because we are not working on the same story. This is not right. You are still a part of the same team. The whole point of having a team is to let the team members help each other out. Isn’t that how a team is defined as? Even if your fellow team member is working on a different task than you and he is facing some issue you can help with, volunteer to help him out. Your help would not be forgotten and when you get stuck in the future, your team members would help you out too.
Also, in case, a team member falls ill or has some emergency which causes him to be away from his project, you might be called in to help move that story along. If you pay attention during each Daily Scrum, you would not have much trouble when you are filling in for him.
So pay attention to who is saying what rather than having side conversations (which disturb others trying to listen to the speaker) or staying tuned out.
Scrum is by far the most popular framework under the umbrella of Agile software development frameworks. It allows for greater visibility to product sponsors while allowing the development teams to build incrementally and iteratively.
For Scrum to be successful, it needs a certain degree of discipline. That discipline requires that team members have specific roles and responsibilities even when they are encouraged to be cross-functional and support other team members from time to time.
Scrum defines 3 roles – Product Owner (PO), ScrumMaster (SM), and Team.
The PO is what it sounds like. This person owns the product from a functional perspective. He writes the user stories and puts them into the backlog. Before each Sprint, he refines the backlog to ensure that the stories are the right size in terms of effort and complexity for the development team to work on. He ensures that the backlog is prioritised at all times (highest priority stories at the top of the backlog and lowest at the bottom). He frequently grooms the backlog akin to grooming a garden – removes stories which would not be required in the future, adding new stories to the backlog, and refining the ones already on it. Whenever, the team seeks any clarification on the functionality or the priority of the stories, he is their go-to guy.
The way a PO owns the product, the SM owns the process. While the PO ensures that the team build the right product, the SM ensures that the team builds the product right. He works with the PO in ensuring that the all meetings required to make the product and process smoother (Sprint Planning, Daily Scrum, Sprint Review, and Retrospective) are held regularly and in the right spirit. He makes sure that the development team is not pressurised into taking on more work than they can handle. While the PO is busy gathering and giving feedback about the product, the SM does so for the process.
The third and equally important role is that of the Team. The Team comprises of anyone and everyone working on the product technically. It includes developers, UI designers, and testers. They are responsible for building the product as per the acceptance criteria specified by the PO while following the process set by the SM. They own the quality of the product. They have a right to take on only as much work as they can finish in a Sprint without compromising on quality. They are also welcome to request the PO to include stories that would benefit the product quality and maintainability.
Together, the three roles in a scrum form the 3 sides of the project pyramid and offer great stability to the development process. Together, they ensure that the right product is being built right. If any role takes on a weak or a dominating stance in the team, the project suffers. Thus, it is imperative for each of these three engines to fire consistently in order to move the ship forward.
The team is also referred to as “Pigs” (because they are committed to the project) while the PO and SM are referred as “Chickens” (because they are just involved). The following image lends context to this nomenclature.
Rajat Bhalla 