Scrum Diary: Week TWO in a new team
Now that you have answers to the following 8 key questions, What Next?
- Are there specific pain points that lean methodology is expected to address?
- How is the planning done as of now?
- What does the current estimation procedure look like?
- Are the backlogs well defined?
- Does the team’s responsibilities include ad-hoc tasks like base-load (customer support for previous releases) also?
- Is grooming meeting officially scheduled/on-the fly?
- Are there dependencies on other teams?
- What is the trust level within the team?
Based on the input you can chalk our your own action plan.
The start point
Well the first question should be your start point. This will give you the most pressing concern of the present way of functioning of your team. This should tell you exactly what needs improvisation or correction. Let us take a simple example, of reducing in-process tasks, and increasing velocity of the team. This would have come-up while discussing with the stake-holders, management, PO etc. This will help you come up with a draft, but to proceed you need to get the big picture clear in your head. The team needs to discuss as a whole to understand the current scenario and the improvement areas.
Mine would look like this, assuming the planning (or its distant cousin that is already in place) is done for the current development cycle. Planning for the next sprint is usually done after the review and retrospective for the current sprint is over. But in this case, we may have an exception.
Start with a retrospective meeting with the team to find out the 3 most important things: What is going well? What needs improvement? What needs immediate attention? This will be your first retrospective meeting with the team. make sure it is light and interactive to the core. I used ideas from the book: Fun Retrospectives for our first retrospective meeting. Here is a peek at our Agenda.
Energizer — Short ice-breaker activity to get the team started
Check-in — To get the participants to focus on the agenda of the meeting
- Happiness Radar in terms of Technology | People | Process
- People to add smiley stickers for each of these
Rewind-Retrospect-React — using the leads from the Check-in exercise, we will talk about the current set up and discuss about the practices and values in the team. Each of these will fall into one of the following categories:
- Keep Doing — something the team is doing well and you(team-member) recognize the value on it.
- Less Of — something already being done; you(team-member) see some value, but you(team-member) rather reduce a little bit.
- More Of — something already being done; and you(team-member) believe will bring more value if done even more. –
- Stop Doing — something that is not bringing value, or even worse, it is getting on the way.
- Start Doing — a new idea, or something you(team-member) have seen working before that you(team-member) would like to bring to the table. This is where the scrum meeting idea has to be brought forward and discussed
This is followed by the filtering of the points discussed so far and reacting to the points. Check-out involves the next steps, and ensures that team leaves the room with accountability for the critical issues discussed.
Filtering — Use a plus/minus voting on the points that come up to decide on the most prominent ones
Check-out — Come up with an action plan — Who? What? When? — assign people responsible along with timelines for each action item. Set measurable goals for the team and yourself based on this.
Drum roll for the hero to enter. Bring in the ‘story-wall/scrum-board’. However it is called, this serves as the ‘information radiator’. If the information is on the face, the reality strikes you on the face too. I am not saying people love to sit on their tasks and leave it in-process while jumping on-to others. There may be underlying causes like blockers, dependencies. less clarity on requirements and so on. Stick to the 5 Why technique. Avoid bringing the who in the question. You are trying to fix the process not to get the blame-game started. To reduce in-process tasks, the simplest way is to ensure that each team-member has only one task to work on from the planning meeting. Unless this is done with the next is not started. Well you may have other maintenance tasks that come your way, but that much of multi-tasking is within allowed limits.
I have assumed that the sprint timelines are in place, and soon after the Retrospective meeting the next sprint starts. Scrum Meeting time would also be a discussion point in the first retrospective meeting. This is also the time when you decide on some ground working rules for the team. Here is a sample:
The tangibility associated in moving tasks from in-process to done is actually a fulfilling experience for many developers. I see this working in our team for sure.
Backlogs need some grooming
Get involved in the next sprint preparation. If backlog refinement or detailing was an issue, now is the time to look into the ones for the next sprint. This does not stop you from raising concerns regarding the backlogs that are already in process. Raise your points, get them clarified, do all that it takes in your power to ensure that the team can continue to work without any productivity loss.
At the end of the sprint, introduce the first review meeting with internal stakeholders. Review is the time to show-case your work as a team. Bring in the desired structure into this. Publish the agenda before-hand. Encourage the team to present from the productive system. No demos from local code-lines to be accepted by the PO. The developer has to present it himself/herself. This also gives the team a chance to represent their work, the increase in accountability this brings is surprising.
After the Review, have the 2nd retrospective meeting to see if the team already sees a difference? Then introduce the planning meeting for the next sprint. Based on feedback from the team (retrospective meeting) Repeat steps from planning to retrospective, with key focus on maintaining the velocity and addressing critical issues effectively.
Nurture your team
Well you would say what is new about this? This is exactly what a Scrum Master is supposed to do. Yes you are spot on. The question is how do you make this part of your persona as a Scrum Master. It is not a job definition you can live-up-to unless you imbibe it as a quality. It is a collective effort at the end of the day, and you win if the team wins. Nurture the team as you would nurture your child, for sooner or later the team needs to stand on its own. The journey of a team is very similar to that of a child; from baby steps of an infant to a wobbly toddler and a champ athlete. And with that your team will be ready to move to an auto-run mode.
How was your experience in a new team? Eager to hear your views…