fbpx
+38 099 5197809
Publications

Publications

Who is the “Developer” in Scrum?

Who are the “developers” in the Scrum framework? Why are all the participants in Scrum Teams called “developers”? What is the difference between the Scrum framework developers and the ones found in the job description? Let’s explain the difference.

One term, different meanings

The difficulty some teams face while switching to Scrum is a misunderstanding of the meaning Scrum attaches to the concept of “Developer”.

Suppose you come to Scrum with an incomplete understanding of the concept of “developer”. In that case, the team is unlikely to be coherent and genuinely autonomous, self-managing, and agile. Jeff Sutherland argues that the proper team structure is essential to perform “twice as much in less time”.

Definitions

In general, many people are called developers – real estate, business development specialists, etc. In our context, we are talking about IT developers and industries that integrate them into their business processes.

The term “developer” has gained popularity for a long time. Back in my student days, the term Software Developer could refer to different programming languages. Software Engineer provided a broader specialization, but then the industry moved to a more specialized type of developers:

  • Net Developer;
  • Java Developer;
  • Angular Developer and others;

In a broad or narrow sense – we are talking about “developers”.

Specifics of Scrum

The distinctive characteristic of the Scrum Team is also cross-functionality. At Scrum, “developers” are all involved in developing a product and increasing its value to end-users and stakeholders. Each participant has a set of development skills and is ready to lend a hand to a colleague, replace him, swarm around complex tasks, and delegate where necessary.

The team can work not in one narrow direction but has a range of competencies, adapt to business requirements for a new product, and quickly acquire new knowledge if necessary. All this is possible only when there is a focus on the Product Goal.

Ideal Developer in Scrum

Practice shows that the digitalization of a business process can go through dozens of different systems created by other programming languages. In that case, imagine how valuable a team will be if experts cover all required languages, not one?

When it comes to, say, modernization, integrating new technologies is impossible without understanding the old ones, which already indicates a high level of complexity (complexity) of such tasks. That is why those scrum teams with a high level of expertise are highly valued not in one but in several areas directly related to product development.

Given the constant emergence of new technologies and a reasonably extensive list of old, Scrum fundamentally appreciates such a characteristic of the specialist as:

  • The desire and openness to learn
  • Develop and grow professionally
  • Quickly acquire new knowledge.
  • Clarify the nuances, be interested in the product
  • Look for the best solutions.
  • Be proactive.

Sacralization of “Narrow Specialization”

It is unknown why, but there is a certain sacralization of “narrow specialization”. Of course, you can be the best at something alone. But does that mean stopping professional development? After all, “integration” involves the interaction of different systems.

In addition to the artificial sacralization of narrow qualifications, the problem of not understanding the role of each member of the Scrum team is quite common. It causes unnecessary dependence on specialists of narrow specialization. This may apply to outdated systems as not all teams have specialists who can change old systems to integrate new ones.

Scrum Solution

The product is not necessarily a new technology. At the same time, the latest technology will not be valuable if it is not successfully integrated into the existing product(s). In other words, technology is not a remedy.
I emphasize that:

  • Scrums need to be created around the business process, not the technology which can become obsolete.
  • It is worth moving towards the product and increasing its value, not “technology.”

Component and cross-component commands

To better understand the concept of “developers” in Scrum, consider component and cross-component teams.

For example, rare experts are involved in development. They are few, constantly busy, and overloaded. They, therefore, create a bottle-neck and slow down the process at the entrance or exit. Consider two examples.

Case 1 – Cross-component team

The company has set a task to develop two new technologies and modify six existing ones to enable real-time insurance claims processing. The project was highly complex.

Together with colleagues, we decided to involve twenty different specialists, which overloaded the Scrum Team. We barely narrowed it down to fifteen people with us.

Of course, our team worked slower than usual. Still, it was much better than if we were tempted to split into several smaller component groups.

Otherwise, we would have to run several separate development vectors and spend an eternity reconciling all the relationships and integrations between them. The fact is that in real business, many processes go through all its levels, all teams, all technologies (both old and new). This is where the temptation arises to form component commands.

In contrast, the cross-component team is responsible for implementing not one narrowly focused system but the entire business process. Accordingly, the cross-component team must include representatives of both the old and the new (and whatever) IT systems to implement a holistic business process that covers all levels of the product. In this case, you can effectively create an increment within a single cross-component team.

Don’t get me wrong, the component teams also develop increments, but only within their narrow specialization, hence not effectively delivering value to the business. There will be friction between component teams about the changes that each team needs to make. Clarifying the interdependencies and how the increment of the one component team depends on the work of other teams can create a significant increase in the duration of a complex product.

Cross-component teams do not have such a problem because all changes and interdependencies are made simultaneously, within one group and one sprint. In one sprint, minor changes are made to two or more systems. The increment applies to the entire business process and immediately takes into account the specifics of other systems.

Case 2 – Investment Bank

One of the world’s investment banks was migrating the clearing & settlement back office to a new system based on the latest technologies and existing ones. Our experience and qualifications covered 80% of the requirements. The stack of legacy technologies (Cobol, .Net) and lack of experience with old technologies became a big challenge for the entire team.

So we became dependent on rare experts, whose schedule was overloaded and spread for several months ahead! However, we could not sit with the handles folded. Without hesitation, we decided to study these technologies and convinced the management to get a mandate for such a “horse ride”.

With great determination, we implemented the entire business process, regardless of the work schedule of rare professionals. We formed a dream team with four developers, one tester who learned to program well in a few months!

“Give us any task, we will solve it – on our own!” – that was our slogan. It was a natural IT special forces, an elite division. We studied everything we needed and implemented new features earlier than management forecasts. As soon as we completed one end-to-end feature, we were assigned to deliver others in the same way. The result was phenomenal.

True Scrum Developers

What does it mean to have a team of genuine Developers in Scrum? I will share my thoughts:

  • It is better to have a coherent, cross-functional, and autonomous team with five multi-skilled developers without narrowing towards “only” (only JavaScript, only Python, only Java)
  • It is worth removing titles “junior”, “senior”, “genius” from the development team.
  • A great developer puts the business task first, not the ambition to code it in a favorite programming language, and only it.
  • The excellent developer is interested in growing in software engineering. He studies new approaches, new technologies, expands his own competence.
  • A skilled developer delves into the tasks of the business, asks questions, and communicates with a business representative or specialist.
  • A Scrum Developer will always ask for help when he needs it. This does not infringe on the greatness of his person.
  • People who do not want to expand their professional horizons (for example, learning other programming languages) are unlikely suitable for the Scrum Team.
  • Another trap to keep in mind is to “boil the ocean” – not to drown in the ocean of knowledge, but rather to take only the particle that is really needed to solve the problem.
  • A Scrum Developer in the Scrum paradigm has such traits as leadership and initiative. After all, such people can change the whole organization! Management (managers) thinks in terms of resources, costs, revenues, and so on. Real developers (leaders, initiators) create much more favorable conditions for management (allocation of resources, clearer processes, etc.)
  • Agile is a feature of real developers in Scrum.

JOIN AGILE.LIVE

Get a free consultation
Subscribe to our Newsletter

Announcements of Public Trainings

You ordered
Webinar Consulting Training