For a scrum master introducing or implementing agile in a team, should be a balance between implementing concepts and practices at a pace that does not overwhelm the team and demonstrating the benefits as early as possible to build momentum and motivate the team to do even more. Moreover, S/he should take it into consideration that each organisation has its own way of implementing agile. The work culture is totally different. The mentalities of individuals are different. Even the stability of the organisation/team plays a big role in how successfully you can implement agile.
I started working at an organisation a year ago, where Agile was introduced 2 years back. I was selected for my technical knowledge and my experience as a Scrum master in another government organisation.
The team practiced its own version of scrum. It was still in the transition from waterfall to agile process. Few of the issues the team was facing were:
- Clash between IT and Business managers.
- Communication problems among team members and also with the Product owner.
- The Scrum master was already replaced twice in 6 months.
- The motive of the sprints seemed to be – Just get this done, with least effort.
- Dealing with legacy code. Sometimes, as old as 6 years.
- None of the sprints completed in last 10 months.
- Too many s in the team. Members leaving and joining.
The team comprises of 6 people. It was a mix of developers, testers, business analyst and dev-ops. The developers and the dev-ops person report to the IT manager. The business analyst, the tester and the product owner report to a business manager. The vision was considered different. The team was tugged and pulled between the 2 managing bodies.
This led to communication problems within the team and also with the product owner. It was not only limited to the communication but often led to heated discussions and arguments. No scrum master was able to contain the team and make them feel that they have a common goal.
In the first retrospective meeting, I facilitated as a scrum master, I was baffled by the words that were thrown at each other. It was no simple task to bring this team together.
The developers were not speaking their mind for various reasons. I understand, it could be organisational, personal or motivational. Since they did not speak in the beginning of a proposal, the goal was never reached, keeping the integrity of the system. It failed for different reasons.
The scrum master was a business analyst(Not that I am against it). The motive of the sprints seemed to be – Just do it, asap. Since the team members were not speaking their minds, the scrum master and the product owner never realised what is and what is not good for the team. Hence, the team members did not get the feeling of working towards a common goal, and were not motivated to do better.
The team had gaps in the agile approach:
- The backlog was too volatile. The preference changed a lot. The team would refine the stories at lengths and in the next sprint, they might discover that the story is at the bottom of the priority list. By the time the team got to do it, the information was not only stale but forgotten too. It had to be refined again.
- The requirements/acceptance criteria of a story were not very well defined. Often the team members had to find out the problem with the users. This resulted in blind estimates and often under estimation.
- The stories were not picked up in priority. Team members picked up the stories they wanted to work on.
- There were more than 50% of the stories in progress.
- Reviews were done at the last moment, which delayed closing f the stories, which led to incomplete sprints.
In every team, there are introverts and extroverts. In meetings, the same people spoke up and the output was not well balanced. I wanted to get everyone’s opinion on what improvements they seek in themselves, others and also in the team before I started my job. I did one on one meetings with every member of the team, which helped me gain useful insight.
Clash between IT and Business managers
I scheduled a bi-weekly meeting with the Product owner(PO) to understand his expectations and share any concerns that team may have. Also, with the Product manager(PM), I scheduled monthly meetings for giving and receiving feedback on the performance of the team, and also, knowing the expectation from the IT management.
There were a few movements in the organisation. A scrum coach joined to guide us to iron the details on the process. We were introduced to DIM session, where the team comes together along with the Po, to discuss issues. A few goals for the sprint were provided. Speed, quality, focus, motivation… The team collectively scored them as bad, ok or in good state. They would also pick a goal which matters to/bothers them most. The PO was also a part of the discussion and understand that some effort will be put into the area which team is bothered by.
This helped us inform the PO and make him aware of our concerns about the quality of work we are delivering. He understood the issue team faced and agreed that we spend some time in cleaning the code we touch. Also, we slipped in improving test cases for the code, we work on. All members bought into it with time. And so far we have the freedom to add sub-tasks for cleaning up the code, improving what we can and also adding some test cases.
The DIM session helped bridge the gap in communication not only with the PO but within the team as well. We were working together to a common goal and looking out for each other.
Fortunately, a third party came in for integrating with our services and adding value to our systems. I did not see a use case. Although all they asked for was some data for POC, which was not a lot of work, it wasn’t good for the motivation of the team. It was a decision thrust by the management. Not discussed with the team and didn’t look like our opinion mattered.
I introduced “speaking up” and “standing your ground” to the team. Initially, I was all alone in the field, but with every meeting, more and more team members openly joined me to say “no” to what’s not good for the team. I was fortunate to be in the Scrum master position at that time, and be able to speak for the team. Also, relieved that it was the right decision to make. I would have introduced “accepting” as well to the team if I was proven wrong. Killing ego within the team is also a vital part of working together, in my opinion.
Legacy and Motivation
The event above, helped us gain our PO’s faith in us. We were given margin in estimates to improve code, add tests, and get rid of the legacy code. What had been a house of cards, started to turn into a stable wall. The production issues decreased. The re-work decreased. The team could work on new features. The team was sent department-wide kudos mails and the motivation rose up.
The DIM session and our performance, both led us to communicate to the PO, that the backlog was too volatile. The stories are forgotten by the time we reach them and all our efforts turn into vain. As a result, the PO started fixing a sprint ahead, more or less.
Also, we requested him to plan related stories in a sprint, so that we don’t have to work on a wide codebase. This would help the team to review each other’s work easily, share knowledge on the legacy code, and keep track of a minimum number of releases and still deliver value – lots of it, which he happily did. All communication and understanding reflected in the velocity of the sprint and in the quality we delivered.
Working of the team
Apart from the improvements done by the PO, the team had to put in effort in their working process as well.
Slowly, with every retrospective more and more changes/adaptations were discussed with the team as improvement points. One improvement was a solution for a topic that the team was bothered with the most, that sprint. And the other was something related to the outcome for goal in the DIM session.
A few improvements introduced in the team, over the period of 10 months were:
- The stories are to be picked up in priority. If one doesn’t have the knowledge, they were encouraged to peer program. No judgments were made.
- Each story should not be more than 50% of the total sprint goal. If it is so, it has to be broken down into smaller chunks.
- No more than 2 stories should be in progress at a given time, for the complete team of 3 developers and a tester.
- No more than 2 sub-tasks should be in the name of one person at a given instant.
- Before picking up a new sub task, the QA/review column should be checked.
- At least 2 people should review the code and put +1/+2 in the heading so that it is clear that it has been done.
More to do
There is still room for improvement. Apart from the agile processes, there are some problems which are hard to handle.
There is instability in the organisation, namely, lay offs, team shuffling, other team changes. Every time the team is changed, the team goes back to forming stage of the agile process. It has been difficult to manage. It is difficult for a team to go through the process and achieve performing stage, every 3 months.
- The team has been showing continuous improvement with a rise in velocity.
- The PO is a happy PO. The PM even congratulated the team to have turned him around. There is a sense of working together, instead of against each other.
- The team is motivated and aims high. Individuals also seek growth and work also on their own skills.
- Both the business and IT management is very happy with the team performance.
- Impediment list is getting shorter by the day.
- The team is almost self-organising and managing.
- It is easier to gel new team members into the team when the team is clear about it’s working standards.
Every situation is different so of course there is no “one way” to begin or improve on agile practices. The team should be flexible enough to try out practices and see what suits them best.
Occasionally, the team would fall back into old habits. It is the job of scrum master to adjust his approach and choose to remind the team and adjust the ways to support the team.
Note:-Every time a team member goes to a meeting on a wider platform with other teams, they always come back with a smile and proudly declare – Our team is really doing good. It’s the best! That’s what a scrum master always wants to hear.