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.

Slowing Down to Speed Up

Posted on August 6th, 2013 in Kanban, Lean by siddharta || No Comment

I recently did a short mini-webinar for SolutionsIQ on the topic of slowing down to speed up. The webinar is based on the systems thinking principle that local optimisations can sometimes be bad for the global system.

Often times in agile, we look for process improvement at the delivery team only. This is fine in the early stages when the team is the bottleneck in the process, but after about 8-12 months they stop being the bottleneck. At that point, it makes more sense to look at the rest of the system, rather than focusing on the delivery team alone.

See the video recording of the webinar below:

[INFOGRAPHIC] Ingredients of Kanban

Posted on June 23rd, 2013 in Infographic, Kanban by Divya Sornaraja || No Comment

[INFOGRAPHIC] Ingredients of Kanban

Adding a Column Policy / Definition of Done to board columns

Posted on June 6th, 2013 in News & Updates by siddharta || No Comment

We just released a small new feature to the board functionality. You can now add a column policy or definition of done to a column, and it will show up on the board.

Just enter the details when configuring the board columns. Once you do that, an icon will appear on the board and you’ll be able to hover over it to see the column policy or definition of done.

« Previous Entries