There has been already much written about Scrum. We can read a lot of case studies, which are in fact success stories. In this article, I’m not going to teach you about the framework or try to brag about perfect scrum implementation. I just want to share with you some of my everyday experiences to make Scrum more accessible and answer the question of how to scrum efficiently. That note is especially for those, who are afraid that it won’t fit their organization.
I was lucky to start working in the big company, where Scrum was well established and widely known. Everybody knew how to scrum. I was extremely eager to learn and there were a lot of people willing to teach me. Step by step I started to understand and turned up in an agile setting. As long as the business environment is becoming increasingly unpredictable, it was inevitable for me to deliver up to date and relevant to market requirements software. Thanks to Scrum’s regularity I was feeling safe and steadily. Well-defined roles, ceremonies, and artifacts enabled me to anticipate and adapt quickly to unprecedented levels of change. The setup like that, gave the fresh Product Owner like me, accurate space for making great decisions and implementing changes in my product vision.
As a Scrum devotee, I decided to evangelize others and answer questions like “How to scrum wisely?”. Considering my psychological education and coaching experience I applied for a position of Scrum Master at Blast Lab. And this is where the magic begins…
Unlike in a typical software house, I was set into a software-hardware mash-up. At first glance, it was easy. From a business point of view, there was nothing different than what I had already learned. The number one priority is to deliver high-value, implementable pieces of the product, in a short period of time – sounds familiar. I met developers and managers with an open approach towards the changes. According to my scrum-o-meter list, everything was fine. Retrospectives were fruitful, daily stand-ups were full of communication and the work progress in a sprint was going well. It turned out that we even made our own YouTrack plugin that enables us to print legible, square-shaped issues, to put them on the Scrum information radiator alias Scrum board. From my point of view, Scrum was like a homie for everyone here.
The number one mistake I discovered, was that we are not able to finish a sprint. Tasks were in progress for two or three sprints. There was always something unexpected, what made us change open issues, the number of bugs were frightening and if it wasn’t enough we were not able to set the real, prioritized backlog. So, there we started to implement temporary solutions like “we can miss the retrospective this time” or “I will do it without creating an issue”. The effects of that are growing frustration, disputes and neglecting Scrum’s ceremonies. The biggest challenge was to stop this vicious circle of ScrumButs.
Discovering how hard it is to get through all of these alone, I met with my bosses to discuss present situation. The idea behind this meeting was to identify the key areas where we need to stick more to the Scrum Guide and to find a way to solve our problems. We pointed out all of our bottlenecks, weak points and established some actions we need to take. The implemented solutions were our biggest leap.
The key to fruitful scrum implementation is to understand that we have to do or do not, there is no trying. So with that in my mind, I started to arrange regular, uncontested ceremonies. I gathered all team-members availability and made a schedule which is fixed. First ScrumBut is defeated – we are getting more and more regular. Only, in this case, it becomes clear for everyone (Scrum Transparency!) if we failed or succeed in the sprint. Therefore we are able to look backward (Inspection!) and learn how to improve (Adaptation!).
Next big step – improving product backlog. Interim meetings with Product Owner were not successful. Every other sprint were only a fulfillment of our temporary whims, based on what we flipped over recently. Is it obvious, that people are less involved because they do not know what is their works purpose. To better understand the vision of our product we need to first look at the roadmap and make a decent backlog. That includes connections between software and hardware. It enables all of us to look in the same direction. For all the discussion whether a feature is crucial or not, it occurs that transparent purpose is vital. Well-defined and mapped requirements were also put in wider business context. That activity allows the development team to break stories into really thin slices. Step by step we go on the right path.
Another milestone into understanding “how to Scrum?” was a confrontation between software and hardware teams, as a result, we decided to invite one person from the other team (rotationally) to daily stand ups. Knowledge about work progress in these teams allows them to cooperate better. The most fruitful solution was installing a trial version of our product all over our floor. That’s how we make the best and the most accurate testing environment.
People starting to embrace the fact that our meetings are regular. And as we experience the power of consistency, there are no longer troubles with drawn-out issues. For now, daily training in communication, taking care of product backlog and patience in explaining how to scrum is most vital in my everyday work. In my opinion, the biggest advantage of my work is that every problem, every doubt is announcing at the very beginning. In this way, we can avoid the serious consequences of having a skeleton in the closet. The job that has been done is a cornerstone and an adaptation should include improving the development process. That everything is based on a continual focus on people and the interactions between them.
Also read: Jira vs. Youtrack