Development teams use a variety of Agile and Lean approaches. These are largely based on common foundations. The most important are:
- incremental development, allowing for frequent feedback and
- creating the organisational conditions to activate the creative potential.
There are, of course, exceptions. I can think of an “agile” framework whose“sales pitch” is to ensure the safety of management in a hierarchical organisation and to add agility to the annual report – I won’t name it.
Given their common roots, we would expect that the functional roles in Agile and Lean approaches are similar and differ mainly in name. Let’s see if this is the case, or are approximations really just approximations?
Roles in frameworks are not created by themselves, but in response to three organisational needs:
- product discovery (what we build and why),
- managing the development process (how to work together effectively),
- technical coordination (coordination of architecture, quality and integration).
Different frameworks address these needs with different numbers of specialised roles. Approximations
Approximations
In the table below, I have mapped three Scrum roles to the roles of the other frameworks, based on their responsibilities. I have chosen the Scrum roles because they are best understood by a wider readership.
The mapping is approximate. For example, in some frameworks the line between the framework process (Scrum Master – SM) and the product management (Product Owner – PO) is blurred because we have managers who are responsible for both the product and the team processes. Also, the line between developers and product management is sometimes blurred when we have roles that are involved in both the development and the definition of product specifications. In the case of such dilemmas, I have mapped the roles according to the dominant activity or towards the right (SM ⇒ PO ⇒ developers). Approximations
The table shows that older* frameworks (RUP, DSDM), which are closer to the waterfall roots, have more roles. On the other hand, newer frameworks tend to reduce them. Extremes in this category are Scrumban** and Kanban.
This is probably due to the democratisation of decision-making processes in organisations, shortening of decision latency and trend towards cross-functional teams with T specialists.
* When I talk about older and newer frameworks, I don’t just mean the first release date, but also the pace of development and the level of implementation. RUP (~1998) is newer in date than Scrum (1993), but it has not actively adapted to new insights and evolution of development environments over the years, so it has fallen behind Scrum in terms of up-to-dateness. In this sense, I consider it older.
** In a previous article, I described why Scrumban is not really a framework. Here, I am just giving it as an example of the Kanban anomaly that some teams are trying to follow.
Is there an optimal lower limit to the number of team roles?
Probably yes. In Kanban, in case of more complex, less well-defined products, the problem of understanding the customer’s needs (gulf of evaluation) often arises. In Scrum, the task of discovering and interpreting needs is mainly the Product Owner’s task, whereas in Kanban this burden falls on the developers.
In a modern product discovery process, developers must also be involved, but for efficiency reasons, this process requires a coordinator. For this reason, especially in more complex projects, Kanban teams working with a product manager (Product Owner) have proven to be more effective than those without one.
A role equivalent to Scrum Master is desirable for the same reason. Self-organising teams are expected to solve their own problems to a greater extent. However, when these go beyond the development team, it is good to have help (Scrum Master) to relieve the developers from negotiating with management.
The Future
In recent years, the development of Agile frameworks has focused mainly on enabling the efficient scaling of development activities across multiple teams. The majority of Scaled Agile frameworks (63% – State of Agile 2024 report) use Scrum as their base, which shows that this framework has achieved an effective balance of team roles and profitability.
I foresee that the development of Agile and Lean approaches in the next few years will focus mainly on:
- Improving inter-team coordination in the creation of complex integrated products.
- Involving developers in the product discovery process
- Integrating the DevOps philosophy into the frameworks themselves.
- Finding new ways to get feedback from end-users as early as possible. AI will also take on part of the “exploratory user testing” load.
- Integrating Lean flow dynamics into Scrum. Or simply put, combining Scrum and the Kanban framework.
