Does Scrum get in the way of technology?
By: Marcos Vinícius Silva
Tags: Framework, Agile Methodology, Developer Stories, Software Development, Scrum

Scrum is but a tool

Scrum is one of my favorite tools for software development. This agile framework is a well-balanced system that enables the development team to have a sense of control over what gets done in each interaction.

Part of this control is because Scrum offers transparent communication to the people dealing with stakeholders. The system is optimized to give precise estimations about when things will actually get done, and this can be communicated upwards in the chain of command.

Of course, as a tool, Scrum only works when used properly, and some texts explain why/how people fail to use Scrum properly. I don't want to write a text about this.

My text is about my professional struggle with doing a reconciliation between scrum and the development team. Let me explain:

Look out for Icebergs

An iceberg is a piece of change that demands unequal efforts from different team members e.g. improving the visual of a site hardly demand efforts on the back-end but for sure will require people working on the front-end to work a lot.

Image from Basecamp

Part of the problem starts when we have to deal with icebergs.

In this example, the person who works with the front-end (let's call them "Jordan") is "blocked" to start new work until they finish coding the whole visual improvement though the person on the back-end ("Alex") can keep working on the next backlog item [BI].

Eventually, Allex will finish their task but won't able to deliver value because the value also requires front-end work.

Scrum is equipped to deal with situations like this because, in theory, the teams should be cross-functional, so Alex should be able to pick up the remaining front-end work to complete the BI, even if the result, code-wise, is not optimal.

Let's imagine Alex picking up their first task on the web project. Alex has to download it, install some tools, study the project a bit, maybe interrupt the specialist on the web to ask some questions, and even pair up. All of this happens before Alex is even able to contribute to the project.

When the contribution is done, as it’s not their specialty, the code might need a deeper review from Jordan (especially if they didn't pair up because Jordan was busy improving the visuals of the site).

Business-wise, we're wasting money because Alex is being paid to be productive and for a while they become the opposite, potentially becoming a drag for the other teammates as well.

In the long run, it pays off, because eventually, Alex gets so confident on doing web that cross-functionality becomes more fluent but this is not always possible, depending on the company you work for.

And even depending on the willingness of people on the team. Scrum disregards that individuals tend to have a specialization, preferences, and cozy feelings about working on one area of software or the other. This also impacts the performance that people tackle a particular BI.

We're not always on the same page

The other part of the problem is that different parts of writing software gave different lifecycles.

Scrum teams that have QA as a member recognize that writing and testing code are two different activities, with their own pace. Why doesn't Scrum do the same for web, mobile, and back-end writing efforts?

About QA: proper testing can only be done after all relevant coding activities are finished, so it's easier to recognize writing and testing as different activities which are time-dependent on each other.

The answer is, of course, because increments on Scrum are value-oriented, which per se, makes a lot of sense in the product perspective but they don't always make sense for people dealing with technology within the Scrum team. Specialty when this relies on bureaucracy.

Let's say that Jordan has finished the lift up that had been proposed by a visual designer. As styling for the web is a complicated matter, even after finish coding, the team's policy dictates that the designer needs to sit with Jordan to make small adjustments, when necessary.

Here Jordan might find themself looked up in a cycle of development-and-revision which takes a while, should we block Alex to work on other tasks?

The idea behind Scrum says that "yes" because if Alex works too much in the future, the team might make discoveries that would invalidate Alex's work, also leading to their time being wasted.

Particularly I'd rather have Alex working on their specialty because it would cause less rework (which is very expensive) and try to mitigate too much work in the future by having talks about how integrations between front-end and back-end would happen.

In this scenario, Alex and Jordan make agreements about how the integration plays out (largely the schema of data and endpoints) and Alex starts working in non-user-oriented tasks about delivering such agreements to the front-end.

To validate Alex's own work, Alex also has to integrate their own changes on the front-end right away but without digging deep into solving BI from the end-users' perspective i.e. Alex's concern is about making technological advancements on the software.

With integration solved, when Jordan can pick up the equivalent BI from the tasks Alex has already integrated, Jordan will have a much simpler time finishing their own task and will be responsible to deliver the BI from the end-users' perspective.

Pretty much I am advocating to make the front-end activities as the "interface" for considering increments done from the end-users' perspective. The tradeoffs with the by-the-book Scrum approach don't seem too bad in my developer's eyes, I'd love more managemental perspectives here.

So does Scrum get in the way of technology?

IMO yes, but it does it as part of the well-balanced system that I had mentioned so not much harm comes from it.

So in the end, it's a matter of understanding your own situation and decide if you will play by the rules or invent your own, like applying the shu-ha-ri method.