Agile/Scrum through the eyes of a software developer

Colleague Sander van Laarhoven, Front-end Developer at Oliver IT, talks about his experiences with working according to the Agile/Scrum method and the development that companies that apply this method have gone through. A method that works provided it is embraced by the entire organization and the important pillars within Agile/Scrum are properly applied.

From the waterfall method to Agile/Scrum

As a software developer, you have always been used to getting a book in which everything the business wants to get from oats to groats is worked out for you. Sometimes every pixel in the screen has already been put in place by a designer and leaves nothing to the imagination. "Go make it" is the message. All projects used to be picked up according to this waterfall method. Then there's someone on the team who's heard that there's another way, too: Agile/Scrum. With that, all the problems of the waterfall method are a thing of the past. The first time Scrum. For me, that was where a period of both successful and less successful experiences with this method began.

After ten years and more than ten projects with Scrum, I have seen a lot of improvements around this methodology. But unfortunately, I have also seen a lot of well-intentioned but wrong implementations of Scrum methodologies. I once started as a consultant/developer at a large client and experienced the transition from waterfall to Agile/Scrum completely. First as a team member and later as a Scrum master. After this time, I carried out a dozen projects at different companies according to Scrum. I have noticed that each company is different and has its own challenges that play a role.

Scrum implementation within an organisation

When a company introduces the Scrum methodology it is quite a change. What you often see is that the whole company does not switch and commit to it. Only the development teams of the IT department are then committed to Scrum and other departments are not or only indirectly involved. This results in a crooked way of working in which the upper part of the organization works according to the waterfall and PRINCE2 methods and the lower part with Agile/Scrum. In consultancy we also call this 'Waterscrum'. That takes away a lot of advantages of the methodology and is therefore far from optimal.

The organization as a whole, where I worked at the time, was not really familiar with the methodology, but the development team was keen to try it. We started by working in sprints and delivering stories from a large functional design (FO). This was before the time of Jira and Pivotaltracker and we were forced to use a physical scrub board. This went surprisingly well because we worked in a fixed space and not from a distance. What followed were stand-ups next to the scrumbboard and then moving the notes. Post-it's that were moved more often fell off but it felt good to slowly move all those notes to the other side of the board.

The business was not used to dealing with a scrum team, so colleagues walked in at the beginning to ask something directly to a developer or other team member and, if possible, add or change some functionality. Since the team itself was still a bit green, those people were not always referred to the productowner and scope creep became a problem. Slowly we learned not to respond and the productowner in turn learned to protect us. He struggled to position himself in the organization because the method was not yet fully embedded. People from the business were invited to do a review session after each sprint and there was a commitment from the team to deliver the promised piece of functionality every sprint. This went so well that the organization embraced it and completely switched to Agile/Scrum. Later this organization grew to 150 people and consisted almost entirely of scrum teams. This made it a real success story, despite the slow road to it.

The Scrum methodology in practice

Since then, Scrum has become the standard within IT projects and better tooling is available to support this. A drawback is that there are many people who think they know how the Scrum methodology should be applied and they just misperform the most important aspects.

An example is playing poker story's. Everybody knows that Scrum is all about points, but a lot of people can't help but spend time on points. For example: "It's about 2 days of work, so 3 points" or "You played 5 points for that story, how many days is that?". They have not fully understood terms like complexity, team strength and velocity. The complexity of a story determines the number of points and time learns how many points a team can 'burn' in a sprint. That in turn determines the velocity. A complete team has a 100% team strength and can expect the complete velocity, while an incomplete team, for example due to holidays or illness, has a reduced team strength and therefore a lower velocity. If you know in advance that the team in the sprint has a reduced team strength, the number of points included in the sprint can be reduced. In this way a team becomes predictable and a long term planning can be made. Then only the backlog needs to be played and plotted against the number of sprints, taking into account team strength and velocity. As a result, the productowner knows exactly which stories he can deliver in the time remaining. Another example is fixing almost all pillars in the famous devil triangle/square:

In waterfall projects, all pillars of the square are often fixed and as soon as a change in scope is needed, a change follows. The pillars Time and possibly Money are then adjusted, so that Quality remains guaranteed. This is different in an Agile/Scrum situation. There, the Scope may not be fixed as with a waterfall method. A time is agreed in the form of a number of sprints and the velocity of a team determines the number of storm points that can be realized within it. By prioritizing the stories in the backlog, the productowner determines which stories will be included within the defined sprints and thus which scope will eventually be realized. The scope of the project can change continuously over the entire period, only within a sprint are the included stories fixed in the sprint in question. He can put new stories on the backlog so that other stories shift in priority and may not be realized if they are too low on the backlog. The stories that are lower on the backlog are then apparently not important enough and therefore the business value of the ultimately realized functionality is as high as possible. Should it still be important to realize these stories, more Time (in the form of sprints) and / or Money (more people and / or time) must be given.

It is often the case that the organization above the team is still stuck in the waterfall methodology and therefore wants all the functionalities they came up with (fixed Scope), for a fixed amount (Money) and with a fixed deadline (Time). As soon as there are extra wishes or changes, then Quality is the only pillar that can still move. This is a situation that often occurs and which I myself have regularly had to fight against. It is difficult for an organisation to get used to the fact that only the highest priorities are realised. Confidence within the organisation in this way of working will have to grow. Then the business with Agile/Scrum, by getting regular feedback (reviews) and by being able to adjust continuously, will get much more value for money than with the waterfall method.

In my opinion, everyone can play a role in the turnaround that an organization needs to make when introducing Agile/Scrum. Tell people how you think things could be improved and make sure you stick to the guidelines so that there is no confusion and the tools are used properly. The scrum master has the role in leading the team, but each team member also has the responsibility to do their utmost. For example, prevent a stand-up from being disturbed by someone constantly wandering off or staying too long in the details.

As can be seen from this blog, I am very much in favor of carrying out projects according to Agile/Scrum, but only if the organization fully embraces this way of working and ensures that the important pillars within the methodology are properly applied. There is always room for small adjustments, but some decisive aspects need to be implemented in the right way. This will lead to a better result.