Scrum Diary: Week ONE in a new team

You are appointed as a scrum-master of a team. This team has started the project a few months back and is not yet following lean processes. They are exposed to the lean methodology though. Where would you start? Will your day 1 be lost in setting up the scrum ceremonies and artifacts in place? Or will you take a step back, and listen to the pulse of the team? Ask why lean? Find out what is the expectation from lean in terms of team’s output.

Here is a list questions that I recommend to start with:

Are there specific pain points that lean methodology is expected to address?

This is very important for you as a Scrum Master. Your plan of action should be in-line with the expectation. Assuming the expectation is to reduce the ‘in-process’ tasks, you can use simple techniques within the scrum frame-work to solve these. Like this team I know of, where the team picked up one task each per team-member at the beginning of the sprint. Unless the task at hand was completed (or went into a blocked status) the team member did not pick a new task. Well there could be exceptions such as an escalation that requires the team member to deviate from the plan. But this would be a 10–20% case. Where-as if the expectation is to give the product a better direction, you would have to chalk out a plan to ensure that the backlogs are well-defined and ready. Scrum master can help the product owner in churning out high quality backlogs in terms of the content. But the content of the requirement/backlog in terms of the product scope and vision is solely the Product Owner’s responsibility.

How is the planning done as of now?

Since the team is exposed to lean methodologies they may have a planning process in place. Based on this you may have to introduce planning slowly to the team. Starting with a full-fledged planning meeting, broken into 2-parts. Part-1 with PO explaining requirements and Part-2 where team breaks it further into tasks, may be a quite overwhelming to start with. Be your own judge, and then introduce the concepts. A recommendation, have a first planning meeting and get the PO to explain the backlogs. The team may have a tradition of people doing tasks in their specific areas alone. Yes, scrum advocates generalists and not specialists, but let the first meeting go without intervention. During the sprint, get the team’s buy-in to introduce the ideology. Again, give yourself and the team a few sprints to reach your goal.

What does the current estimation procedure look like?

Estimation is important , mainly to track the velocity of the team. Most of the teams tend to estimate in terms of person-days/hours. Nothing wrong with this methodology, but taking them slowly towards a story-point estimation would be the ideal situation. Take for example a new concept the team is working on. After the first prototype is in place, ask the developers to come up with a baseline story and its estimate in terms of story points. This could be the prototype for story points too. Later as the PoC gets into the product/project backlog, let the story points continue as the estimation technique. The team will get the value in using it in a matter of a couple of sprints, after they see the results. Interesting ways of estimation like planning poker can be used to make this concept more fun and acceptable.

Are the backlogs well defined?

You will have to spend quality time in analyzing the backlogs to understand if the done and acceptance criteria are in-place. If not, better to start with a separate discussion with the PO on this. Get answers to: What is the team’s definition of ‘ready’? Does it include acceptance criteria, UI-mock-ups, dependency information, performance criteria, estimation information? Don’t expect to get the ‘Done criteria’ done in your very first sprint, give it some time, but be assertive. You can look for best practices for the Done criteria from projects/products related to the one your team is working on as the start point. ‘Acceptance criteria’ for each backlog will be an easier win, as this is directly linked to the functionality.

Does the team’s responsibilities include ad-hoc tasks like base-load (customer support for previous releases) also?

Ad-hoc tasks often eat-up a lot of your development time. This needs to be planned for. Your next question is how do you plan for ad-hoc tasks. Well you can leave aside a buffer of 20% of your capacity for these tasks. What-if you don’t get any support issues for a whole sprint. Fair enough, the team might have done a tremendous job in the previous release(s) to get a base-load free sprint as their reward. In your planning you can include items of lower priority for the current sprint, that are soft-committed and take max up-to 20% of the team’s capacity. This way you already know what to do with your 20% buffer in case of no surprise tasks.

Is grooming meeting officially scheduled/on-the fly?

Grooming meetings or pre-planning meetings are not part of the official set of Scrum meetings. They need not follow a specific pattern too. This is more for your understanding. You need to get involved in these meetings in the coming weeks to get hold of the topics being discussed and understand the working model of the team, and the content better. This is also the forum to collaborate with roles like UX designers, performance experts, accessibility experts and so on. These inputs not-only shape-up the backlog, but contribute heavily to the done criteria of the backlog.

Are there dependencies on other teams?

Since the scrum-master will be responsible in solving impediments, dependencies will feature high on your list. You need to have a very good understanding of this. What are those teams? Are we tightly coupled with their delivery? Are we aligned with their delivery time-lines? How do you channel new requirements to these teams? Who are the points of contact? What is the escalation mechanism in case of show-stoppers? What is the communication medium? Are there regular meetings with these teams? If yes, get yourself invited to these.

At the same time, do other teams consume what your team delivers? How do you manage escalations from these teams?And the same set of questions around communication and regular meetings as in the para above.

What is the trust level within the team?

This is not a question you can go about asking people. Keep your sixth sense antenna high enough to gather the pulse of the team in terms of trust. You are part of the team. Mingle with the team members over a casual chat, a coffee or lunch. Let the information flow during the conversation, and let the conversation not become an investigation session ;)

Most important of all. Be open for newer ideas and suggestions. You may be a seasoned scrum master or a novice. But the team existed before you joined them. Respect the fact that the team has some best-practices that work for them, scrum or no-scrum. Do not overrule these, at the risk of gaining resistance to your scrum implementation.

Watch out for a part 2 of this, where we discuss what to do with answers to these questions?

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.