26.03.2021 - Read in 8 min.
Benefits and Challenges of SCRUM – over 10 years of RST’s experience
26.03.2021 - Read in 8 min.
Read the interview below and learn about our first experiences with SCRUM, when and how we decided to implement it in RST, what challenges arose from this decision and what was essential in the process for the entire organisation. The interview with Łukasz Osiadły was based on the third episode of Drive with IT – 10 years of SCRUM in RST. See how it all started.
Implementation of SCRUM in RST
When I joined our organisation our test teams had already begun the first sprint. The company decided to take this step in view of the cumbersome and complex procedure of implementing upgrades and improvements. Before we used to spend more time on paperwork, signing the annexes, stamping the documents instead of focusing predominantly on working software.
The management board had decided to introduce changes. Ten years ago quite a few people would’ve already known SCRUM and other approaches. We took the risk and transitioned to agile product management, at the same time trying to start some sort of a revolution. So 10 years ago we concluded our first sprints in SCRUM.
What was your first experience with SCRUM?
Starting from teams, not everyone embraced the new. People were afraid of changes, as they often are. We could feel the atmosphere of uncertainty both in teams and the entire organisation. Let’s approach it from the point of view of a developer – you receive instructions and do your work in line with them, ignoring tasks that aren’t included in your schedule. You don’t work depending on needs, there’s no need to take additional initiative (as opposed to agile methodologies). You just receive a ticket and follow guidelines established for a particular project. Not everyone will embrace such an approach, but it’s a convenient and pragmatic solution.
SCRUM in the work of a dev team
Let’s concentrate on how we started because things have changed since. In the past 2-3 teams would be responsible for a particular domain – that was step one. One specialised team was responsible for a given part of a system. Step two was broadening knowledge so that teams would know what SCRUM is – the tendency now is that companies want SCRUM, but they don’t want to invest in it. At the time we knew we had to sacrifice something. It’s worth highlighting that we had to train not a few but several dozen of people. A revolution of such size and proportion calls for the involvement of an entire organisation.
For a long time we were supported in this agile transition. The next stage was everyday work. We established a position of Scrum Master, whose responsibilities, even today, many people fail to grasp. It’s a very extensive role with a broad scope of responsibilities that are difficult to understand, especially if its benefits are not self-evident and measurable.
Scrum Master – process supervisor
It was a huge change for us, something new. People were reluctant to assume this position and it’s important to mention that sometimes it combined responsibilities of a developer with those of a Scrum Muster. So for a sprint, we would select one person who shared these responsibilities. At the beginning we did things by the book, implemented events and artifacts, making sure that our activities had solid foundations. Starting from daily meetings, planning and retrospectives, we learned how to do things and our Scrum Master was supposed to supervise the processes.
Experience was another important step. We were constantly learning as the process was being streamlined on an ongoing basis. We developed tested methods, techniques, approaches, learned from our own mistakes. We didn’t start a revolution but we were developing. After some time we were joined by new employees, our team grew to 7-8 people (the Scrum Guide recommends a maximum of 9 people but 7-8 was more than enough for us at the time). When we built a team of 8 people, where we could learn from each other, we would divide it into two smaller teams, and that way the knowledge was still being passed on. Frankly speaking we were budding.
Developing software vs. a dev team – challenges
If I were to choose only one answer, I would say its the relationship between a dev team and the PO (in other words: the business). In most general terms it’s understanding the idea that what we create must be in accordance with the client’s order. The majority of people would probably think that the problem lies in the “how” part of it, i.e. a dev team not knowing “how” to do something. My experience would suggest the opposite. There are many approaches; we can work in different technologies or invest in something new, dedicated. The possibilities are endless as the last 10 years have witnessed a rapid technological development. I wouldn’t say that cooperation with the client is a problem but it’s definitely a challenge.
What did our first Sprint Review teams look like?
My memories of it are very positive. Once again I want to stress the fact that the organisation trusted us and gave us a lot of freedom in developing this agility. The Scrum Guide provides a great summary saying that a Sprint Review demo is a meeting at which we are supposed to present a working software increment to stakeholders. This meeting, as far as I remember, was attended by all stakeholders and it took exactly 2 hours in 2 weekly iterations.
In this group of people we were able to decide that there’s no point continuing what we’d started, step aside and look for a new perspective that would allow us to achieve our goal (I intentionally say “step aside”, not “step back”). It wouldn’t have been possible, if we’d assumed a waterfall approach where we would’ve been late to realize that something didn’t work. Embracing change is an indispensable part of being agile and it’s something one has to be aware of.
SCRUM – self-improvement of a team, product and process
It’s definitely a long process. Being perfectly honest with you, there isn’t a golden mean or three steps that will lead you to becoming a self-organising company. If I were to name tools, the first would be awareness and the importance of nurturing it. I would say teams are of secondary importance, which is not a very common opinion. A team won’t be agile without solid foundations in the form of a comprehensive organisation; it’ll face obstacles that may be overcome only with the support of the company. This problem often gives rise to a high level of frustration. Imagine you have a team of creative and dedicated people, who eventually hit a roadblock and may no longer continue down the predefined path – it’s debilitating for the entire organisation. You obviously don’t want that.
What’s the perfect scenario? Business comes to you with demand, describes its expectations, presents to you interesting facts (the whole thing about agile is that everything is fact-based, we approach challenges in an empirical way and the only thing we know for sure is what we’ve already experienced). The Product Owner (PO) is ready, they have conducted market research and researched new things they would like to test and implement. This way, by demonstrating their trust in them, they involve the entire team.
As Steve Jobs said:
“It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.”
PO is expected to define requirements for a particular task of a team as well as carefully and precisely describe it, provide them with a schedule and let them choose the best way of reaching the goal. Such independence is crucial in enabling a team to create solutions instead of just recreating them.
Challenges for business – trust and waiting for results.
From the perspective of business it’s not easy to trust the contractor, let somebody else take the initiative, sit back and wait for the results. This is true and our experience – successes and failures – might serve as an example. How can we establish a safe working environment, where everybody is involved? My answer: by building relationships. Of course, we’d be naive to expect that anyone would be ready to let us lead from start to end – I don’t think anyone would do it.
And how can we nurture relationships? Let’s get back to the roots – working software. Deliver something that serves its purpose, produce an element of a system – something that will create initial value and pay dividends – as quick as you can. Business will be working on the business side of the projects and developers will be happy seeing that their project is being used, bearing first fruit.
Or… maybe SCRUM is not the right solution for our company?
Yes, there were many such moments. It’s an anti-pattern. Implementing SCRUM is very demanding. Don’t you even think reading 18 pages of the SCRUM Guide is enough. People tend to underestimate the challenge, believing they will be able to work in SCRUM as long as they follow the procedures laid down in the Guide. The hardest bit, though, is making business realize that it’s worth investing in meetings, roles and building conscious POs – it’s a long and strenuous process. It takes a lot of effort as you need to build a value-based organisational structure.
What values do you perceive to be essential in implementing SCRUM?
First of all bravery (to introduce changes, try and make mistakes), respect (for solutions, other people and their ideas), dedication (an individual won’t win the game, if other team members aren’t dedicated). Only this way may an organisation become truly innovative. We’re agile and open to new solutions.
But it hasn’t always been like that. A few years ago we were diehard believers of SCRUM – we wouldn’t accept any alternative. Today we are once again trying our hand at SAF (Scaled Agile Framework) requiring several elements, events, roles, artifacts that are supposed to help us scale SCRUM, the agile approach, for more than one organisation, more than one team, so that it may be reasonably managed. At the moment 28 teams from different organisations are developing 1 product. These are dev teams consisting of around 5 people each. We obviously have different layers, from a portfolio, through a taskforce, to a program, and we’re constantly learning. Is Agile worth reaching for at all? Read the Agile Guide for Business – a free e-book.
The entire framework tells us we need other teams on the level of the programme, like solution teams, that are on top of everything. The objectives are of course interdisciplinary. That being said, the teams should remain domain-oriented, so that they can work on things they do best, but we assume there will be objectives that will be tackled by all teams. We need to coordinate our work so that at the end of the day we deliver working software and an increment is created not by one team but, say, twenty-eight teams acting in cooperation. The Safe, Nexus and Less methodologies all agree on one – it’s work on a level of dependencies.
Download free whitepaper and learn more
Agile Guide for Business