Scrummaster is not a proxy

Posted on April 16th, 2014 in Agile by siddharta || No Comment

Here is a pattern that is commonly seen in teams — the scrummaster acting as the point of contact for a team. What does that mean?

  • When the PO has a question, they ask it to the SM and expect them to relay it to the team. When the team member has a question to the PO, they tell the scrummaster and expect them to ask it to the PO.
  • In conference calls, the SM is the one who does most of the talking. If there is a question from a team member, they ask the SM and the SM (who is near the phone) asks it in on the call on their behalf. Likewise, if there is a question from the other end, then SM relays the question to the team or team member, then relays their answer back on the call.
  • The SM represents the team when attending the Scrum of Scrums, status report calls, calls with management and others such meetings
There might have been many other situations where you might have seen the SM acting as a proxy or point of contact between the team and someone else.
Being a scrummaster does not mean being a proxy for the team.
A good scrummaster will enable the team to self-manage. That means, leaving the team to take charge, and stepping into the background. So:
  • If the PO has a question, they either ask the team directly, or if they are not colocated, then send it to the team distribution list so that any one of the team members can respond. If a team member has a question to the PO, they ask directly to the PO without routing it through the SM.
  • In a call, the SM steps back and the team interacts directly with whoever is on the other side
  • Send a team member to represent the team for Scrum of Scrums or management calls. Teams can even rotate the team member they send. In a good team, every team memberknows where the team is, where they are going and can represent the team.
The SM only steps in if there is some dysfunction happening, for example a discussion goes off topic and needs to be taken offline or put on a parking lot.
So what do you do if you are a Scrummaster and other people assume that you are the point of contact? At that point, you need to gently remove yourself from the middle.
  • If a team member has a question to the PO, encourage them to email / lync / skype the PO directly. They can update the team after their discussion (if the team members sit together) or at the standup
  • If someone asks you a question directly, forward it to the team DL and encourage them to send future questions there next time. Then leave it to the team to answer the question. Step in only if no one is answering it assuming that someone else will do it (the whole team sitting together helps).
  • During calls, make sure you are not sitting anywhere near the phone :) Similarly, in meetings, take an inconspicuous position near the corner of the room or sit on the floor.
  • Rotate between team members for representing the team in reporting calls with management or others
In some teams, the SM is also an engineer on the team. In such cases, the SM has to carefully switch between playing a facilitator role and a team member role. You may have to switch hats multiple times. Remember which hat you are wearing and play the role accordingly.
The goal of the Scrummaster is not to manage the team, but to help the team become self-managed :)

5 ways to complete a user story faster

Posted on January 28th, 2014 in Agile, Kanban, Scrum by siddharta || 1 Comment

When teams start doing agile, one of the first impediments they usually run into is the inability to complete stories quickly. In Scrum that can result in stories spilling over sprint boundaries, whereas in Kanban in results in really long cycle times.

Do you have this problem?

Here are five ways to complete user stories faster

  • Have smaller user stories: When you have smaller stories, developers finish stories earlier and testers can start testing them early. This way, testers dont get a big story to test later on. So, think hard about whether the stories can be further decomposed into smaller stories.
  • Multiple developers work on the same user story: Don’t assume that only one person can work on a story. Look at your tasks and see if different developers can work on different tasks of the same story, so that it will be completed earlier. Also, dont assume that only a single person should work on a task. Sometimes it is helpful to pair multiple team members together to work on a single task.
  • Automate some functional tests: When developers work on the development, testers can write automated functional test scripts during that time. Once development is complete, the actual testing time is reduced because you can just run the automated tests instead of manually executing each test case. As a bonus, over time you the improve the automated regression suite.
  • Multi-skilling: Testers helping with simple coding tasks, and developers helping with test case execution are two ways multi-skilled teams work better. See how you can bring this capability in your teams.
  • Co-located teams: You will be surprised how much time can be lost in communication between team members who are not co-located. Emails going back and forth over a period of two or three days is a big waste of time. By seating the developers and testers next to each other, a lot of wasted communication time is saved, and more can be completed.

Not all the above approaches are suitable for every team or every situation. The team needs to look at all available options and decide which is the best way for them.

But, is it agile?

Posted on November 24th, 2011 in Agile by siddharta || No Comment

Jim Coplein posted on Jeff Sutherland’s blog basically criticising Kanban and trying to put forward a case of why Scrum is closer to Toyota’s principles that Kanban.

I’m not going to comment on the post (not directly anyway), but here is a story:

Five years ago I posted about a trend that was happening then, of asking whether a practice is agile or not. There would be endless debates about whether doing Practice X was big design up front (BDUF) or whether it violated YAGNI and what have you. Sometimes you would come across a post where a person loved a technique, but was afraid that it was big design up front. Just to set the context, in those days XP was the dominant method in the agile space and BDUF and YAGNI were the hot topics of discussion. The bone of contention was with methods like FDD that promoted up-front modeling, and Crystal which encouraged documentation and up-front UX design, and DSDM which many XP thought leaders found to be too heavy.

People essentially stopped asking “is it useful?” and started asking “is it agile?”

As any community forms around an idea, the first few years are open to playing around with it and improving it, but after a point the community attention switches over to protecting the idea from corruption and external forces. This protects the initial idea, but closes it down to growth. A lot of good ideas get discarded, because “it isn’t agile”.

I’ve learnt a lot of good things from reading FDD, and Crystal, and talking to people about CMMI. Its funny how many people in the agile community are happy to bash CMMI without ever talking to someone accomplished in it. To be frank, I was in that camp too, until I had a number of discussions with people who understood CMMI well. It turns out that CMMI has a lot of interesting ideas.

Today, people dont talk too much about XP anymore. Most of the XP thought leaders have moved on, some to the Scrum or Kanban world, others elsewhere. Meanwhile a lot of XP has been absorbed as standard practices that teams pick and choose for their project. Teams no longer talk about “doing XP” (as a package) but more about we’re doing TDD or we’re doing continuous integration.

But history repeats itself, and once again we find the question coming around once again to “is it agile?” instead of “is it useful?”

PS: Agile India 2012 is coming up next year. Be prepared to discuss a number of interesting topics, some of which might fail the “is it agile?” test :) Registrations are open, so what are you waiting for?

Visualisation in Board Design

Posted on November 12th, 2011 in Agile, Kanban, Visual Management by siddharta || 1 Comment

Following up on a twitter discussion, Pawel blogged about alternative kanban board designs, and showed an interesting board with columns indicating priority and stickies on a card to indicate the tasks to complete. This motivated me to search for pictures of the board we used back when we first adopted agile process. Pawel says that exposure to “standard kanban boards” has meant that everyone has ended up with similar looking boards. I think to an extent that is true. This board was designed in 2005, much before there was a kanban method, and it doesn’t really look like a kanban board you would see today. In fact, I wouldn’t even call it a kanban board as it has no WIP limits or pull. It’s more of a team board visualisation.

Continue reading ‘Visualisation in Board Design’ »

Why Visualisation is the key to being Agile

Posted on November 8th, 2011 in Agile by siddharta || 2 Comments

This coming weekend, I’m going to be talking at Agile Tour Chennai about visualisation in the context of agile teams.

It is my belief the visualisation is the key to being truly agile. Why? Read on..

Continue reading ‘Why Visualisation is the key to being Agile’ »

« Previous Entries Next Entries »