My name is Linda, I’m 34 years old. I recently started the BVOP Scrum training and I hope to receive my BVOP Senior Scrum Master certificate soon.
I have been working for the US Department of Construction for 8 years. I work in the IT department and deal with the maintenance and updating of the public system for registration and support of construction practices.
This is quite a large organization. The IT department uses 200 people, divided into different teams. Not everyone is expected to work together, but many colleagues need to work together on software products.
About 2 years ago we decided to introduce Agile. Before that, we worked with Waterfall. At least that’s what many high-level managers say. However, I am not sure that we have worked on any methodology at all. The nature of the work and the excessive levels of decision making is overloaded with processes and steps, and managerial approvals. In reality, it is quite difficult for a person working in a development team like mine to be effective, creative, and at least a little independent. The organization is large, there is no room for expression, and is largely interchangeable with anyone, even a new employee. I solve my tasks, the colleague next to me – his. There was no communication, brainstorming, or complementarity as the end result of our work.
We did not have any time limits to complete the tasks. We had time limits, but the problem was that we didn’t know how much work we would have to do by the deadline. People did not distinguish between the tasks being completed and being done as well as possible (which is not equivalent to the product backlog item being closed). The tasks must have been completed. There was a big discrepancy in the definitions of the processes. What it was supposed to be according to Scrum and how exactly something is done according to Scrum. My managers said that was the case with Scrum, and there was no room for discussion. But the truth is that from one day to the next, telling a group of 200 people that we’re starting Agile tomorrow, giving them a one-hour intro about what Agile really is, what SAFe is, what the role of Scrum Master is, Product Owner, Release train engineer. There are mass confusion and even more damage.
Three years ago, when we started with Agile, I had the belief that once managers made that decision, then maybe everything would change. Everything from team communication to the work environment, the distribution of tasks, even the ‘formulation’ of tasks. Who is really responsible for defining the work? Have I defined it, or does someone else appoint it for me?
Three years have passed. I would not say that everything is as it was before. But given the organization and the high turnover, we are still struggling somewhere to clarify some of our processes. How should it be best for everyone? How to fit in the Scrum framework?
For those three years, I stood by and watched as part of the dev team. Someone else was telling me what to do. I just had to do it. However, when I did it wrong, creating a bug, I had as much time to solve the problem plus to fix the bug as in the beginning, when no one knew or expected that there would be a bug.
In short, the definition of the tasks was unclear – from people who didn’t really know how things should work (they were just busy making a new product backlog item in the Microsoft Team Foundation Server). They actually received this assignment from someone else – from the business, a person who simply has nothing to do with our organization and is neither in the IT department nor working under Agile or Waterfall.
On the other hand – going back to the bugs – estimating how long things take, frankly, is still a dream. We waste hours and story points, evaluate tasks, without anyone (including me) having an idea of what the real work is and what exactly is required.
I had no idea what my team was doing in general. I changed 3 project leaders in 5 years (you will ask why a project leader – there is no such role in Scrum?). Every new project leader came up with the idea that he was very experienced and knew how things worked. They were amazed at how vague the principles and distribution of everything in our teams and processes were.
We started from scratch every time. The project Leader came to us, the development team, and asked about everything. How we work, how we know how long the task takes, how we decide who will do what and when, how we decide if we are ready or we need more time. Everything. At one point they said that everything had to be registered in TFS, but no one knew how to do it in practice. We started talking about training, iterations, area path. We discussed planning and estimating. During this time, my teammates came and went. The tasks remained the same, I was just bent on training new people, as well as introducing them to some obscure work process, estimating for them, communicating with those from whom the tasks actually came, reviewing their assignments. Last but not least, let me mention that my current project leader did not know what TFS was. I had to train it, and I was just a developer. On top of that, of course, I had to report ‘where we are’ on the daily scrum.
Why do I want to be a Scrum master?
Well, because I want to participate in the organization of all this chaos I’m in right now. I want to contribute positively, which requires both theoretical and practical skills, built over years. I want to start somewhere. This attracts me and is interesting to me. I want practical skills. I read the Scrum guide, this 19-page official document. I was pleasantly surprised by how much I know and how much of the things described there I actually use. But I lack practice. I lack the soft skills to act as an authority – not a boss, but to be able to talk and convince the people and the team I work for. I hope that from everything I have written so far, it is clear that I have a ‘certain’ experience. I work in such an environment – as much as we are still in the beginning and to rely on this and that consultant, to come and tell us how to fix things. During those three years, I was the unofficial Scrum master in my team. This is how I evaluate myself after reading the Scrum guide. Every day I observe what I actually do at work and what part of my work corresponds to my job description.
From now on I want to develop in the field of management (at low and medium level). I want to brainstorm with people, understand their needs and problems, and help them complete the tasks. But I want all this to happen within some agreed framework, under some rules. I want to motivate people to be responsible and interested in the final product. I want to motivate them to develop themselves and often turn to the past and compare them with how it was before. I want to receive constructive criticism, not just to hate the process. I want us to be the process and solve the problems together.
I also want to learn a little more theory. The team I work with is not Agile. We support other teams that are Agile and try to work with their sprints, etc., but we are not. Maybe that’s where most of our problems come from. I personally have never attended sprint planning and retrospectives and all these events. But I think from my work so far, I’ve pretty well understood the division of roles and who cares about what. For me, Scrum was something new in the beginning, but I think I’m good at terminology, I know who’s responsible for what.
What are your expectations from working as a Scrum Master?
I think this is a logical step in my career development. My background is in a completely different direction, but I decided to combine it with something in the field of management. I want to be a little more attractive in the job market. Given my skills, or rather my lack of them, it might be a good idea to start as a Scrum Master as a start. And I’m not sure about the future yet. But I definitely don’t think of climbing much higher up the hierarchy in the organization. I prefer to work with the team. Close to the team. I think that’s where I belong and I feel better there than being more focused on realizing the products and assessing which functionality to do when and whether any other functionality is more important on a pure product level. I prefer to take small baby steps towards reaching a goal within a 14-day sprint (short-term goal). I want to get better at what I think I can do at this point.
I want to keep the knowledge I have gained here and be able to use it further. I want to have a certificate – for me this is important. I know that the certificate does not mean that I know how things work (Scrum will not tell me how things are done) and that I can do them, but it is a completely logical step towards further development in the field. I don’t want to be a developer forever.
What bothers you most about Scrum at this stage?
I don’t think I have a list of things that bother me much. I just want to see if this is something for me.
I am worried about the reaction of the team when a colleague has some claims and really has no knowledge. What if I’m the person with the pretensions? I want to have the knowledge and be given the chance.
What worries me is that I feel that I know a lot about Scrum, but somehow I’m not brave enough and I don’t know how to develop my strength. That’s why I need a certificate.
What problems do you think you will have in your work?
Time is always a problem and never enough. I will be responsible for the product owner for how we have estimated the tasks with the team. I will have to argue about why we failed. In my opinion, a lot of responsibilities are transferred to the Scrum Master. If something doesn’t work out, it’s kind of like the Smurf Master is to blame. Quite often the problems do not come from the players in the team but are external factors that are independent of any of the team members. I’m going to have to be pretty good at arguing about all this. I am a person who quite often blames myself exclusively.
Quite often I will have to seek help or convince why the workload is not timed. I need to get better at this and stop thinking that I can fix things on my own.