According to Hackman (1986), four different functions must be fulfilled when the work is done in an organization. First, someone must set the direction for the organizational work to be done. Second, someone must design the performing unit and arrange for the organizational support necessary for the work. Third, someone must outline, monitor, and manage the work process. Finally, someone must execute the work. We categorized the observed phenomena into these four types of organizational authority (see also Section 2, Fig. 1.).
Team Authority in Project Mobility
In Project Mobility, we analysed the cross-functional feature teams from Sweden working on feature assignments. Several roles interacted regularly with the cross-functional teams. These were the operative product owner (usually one per team), the line manager (one per team), the Scrum master (which can be inside or outside the team, or shared among several teams), as well as the design owner and technical area responsibles (TARs) who support the teams during task implementation. The other important roles that emerged in Project Mobility were system owner and the area product owner (one for each product area); the team of architects consisting of a chief architect, software architects, and design architects; and the leadership group, which primarily consists of line managers.
Setting the Overall Direction
The overall direction for the product in Project Mobility was set by the area product owners and the system owner, who had the final decision on what should be in the system. Together, they defined and prioritized the backlog and assigned feature tasks to the teams. The architecture also sets the direction for the product. The product architecture was defined by the team of architects, consisting of experts occupying architecture-related roles from the product and the team level, i.e., design architects who were all part of regular teams and work 50% as senior developers. Teams were expected to consult the design architects whenever the feature they were implementing affected the architecture. In other words, the teams were allowed to change the architecture as long as the changes were approved by the architects.
The features that were assigned to teams, i.e., the specialization of the teams, also affected the direction of the organization and the teams. Specialization was determined by market demand and decided by the area product owners. The lack of involvement in what a team was going to work on was regarded as a limitation and something that reduced a team’s level of empowerment, as a Scrum master complained:
“The team has been back and forth on different projects, but the team has no say on that part either. And now there is actually a discussion to move the team to another area, from operation and maintenance to the application area, or divide the team... And that is totally up to the “power hands”. The team is not involved in those discussions, in that loop… We don’t know from one day to another day what the day will bring. That is bad for morale”.
While the area product owner and the system owner defined which features the teams would work on, teams could contribute to the system vision and content during hackathons, in which the teams were expected to come up with their own ideas beyond those in the backlog. Hackathons are product-specific monthly initiatives that were introduced by the leadership team to provide teams with the platform to influence the direction of the product and elicit innovative ideas. As the development manager described:
“I also have decided that one day a month every section should conduct innovation day. And they can do whatever innovation or improvement they like. It should eventually lead to better results for Ericsson, but it should not be backlog item APOs order.”
Hackathons were quite new for the organization, and not every team or team member had participated in hackathons, and therefore their effect was yet to be determined, as described by a Scrum master:
“Yeah (I participate), we had one last week for section actually. I really like the idea, but it is hard to get time aside. But now this is the thing from above, you should do this one day in a month. Now we try to attend it more and plan for it. I will try. But for the first one I was quite stressed because I was trying to get something working at the end of the day”.
Designing the Team and its Organizational Context
The decisions about who belonged to a cross-functional team in Project Mobility were made by the leadership group. Most of these decisions were made without consulting the teams. A line manager explained that while decisions regarding the team size and profile might be discussed with teams, teams were not consulted about certain staffing decisions, especially regarding individuals returning from parental leave, when teams changed specialization, existing teams merged, or new teams created. This, however, was reported to affect team morale, as a Scrum Master explained:
“We got some new members. Not that we should, we just got them. So that is very un-empowering. But great guys and we like them. But we didn’t have anything to say about that decision. That was really bad.”
The supporting roles for teams were changed continuously by management. For example, the role of TARs was introduced to ensure the quality of team outcomes by focusing on reviewing design proposals, code, and feature solutions. This role was later replaced by the design owner role to give teams more responsibility by focusing on on-demand consultation regarding product architecture in the early phases of development. The introduction, redefinition, and removal of these roles were part of a large improvement process that was run by the leadership group. As in the team staffing decisions, teams were hardly involved.
Monitoring and Managing Work Processes and Progress
The teams in Project Mobility were entitled to a large degree of autonomy regarding their internal ways of working. Further, team retrospectives were used to discuss whether adjustments were needed to find better ways of working and become more productive. A Scrum master described the freedom of choosing how to work as follows:
“We started with Scrum in theory maybe, but we adapted our own ways of working that fit the team. And we are constantly changing things…. we can use Scrum, we can use Kanban for a while. So, there is no overall decision on what to follow.”
Team performance was monitored and discussed by each cross-functional team and its close collaborators, i.e., the team members, the operative product owner, and the line manager. Performance monitoring included feedback on the deliverables and their quality. We found that operative product owners and TARs previously handled quality control through mandatory code reviews and demos. However, as the teams became more experienced, the need for “policing functions” was discussed and questioned, as an operative product owner described:
“I see one risk with the TAR role as a gatekeeping role: a team might use it as a safety buffer. If teams think 'Okay, if something is wrong, that will be discovered by TAR', and I think, we have to get away from that. So, teams take that responsibility, and not rely on someone else to look and make sure that it is really good.”
While a team had freedom to choose the work process, there was a high need for aligning the teams; many mandatory processes and even improvements were defined by the line managers and the leadership group. These included a quality checklist before delivery, sprint length, mandatory reporting meetings, and training courses. The inability to influence the mandatory processes, however, was not always well received by the teams, since teams at different levels of maturity were treated equally. Consequently, targeted improvements were sometimes perceived as meaningless if the mandatory solutions addressed a problem that a particular team did not experience, as explained by a Scrum master:
“Now, what I have not seen before is a lot of directives. Every team should do that and that, instead of work with teams and go forward to find what are the problems with your team, what can you do to improve a team...
Because someone did that, and that was good, so everyone should do it... instead of trying to focus on what could be improved in different areas in different teams. That I would prefer.”
Each team was responsible for unit testing, while integration and system testing were performed by the continuous integration (CI) team.
Executing the Team Task
Teams received tasks from the backlog with features prioritized by the area product owner. Tasks usually contained a brief description, which the team subsequently detailed and designed. Teams interacted with operative product owners when designing the features and could consult design owners if a technical expert opinion or architectural expertise and advice were needed.
When the feature work was completed and tested, a team packaged the feature, verified its completeness by filling in the readiness checklist, and sent it to the continuous integration unit. The final delivery to the customer was undertaken by the release managers.
Team authority in project cloud
In Project Cloud, all teams were members of the community, which was the central decision-making body in the project. This gave the teams authority both on the team and the project level. As stated previously, the community was formed by all project teams and product owners. Under special circumstances, product managers and line managers could take part in the community meetings, but they were not considered community members.
The community made decisions that used to belong to management, including strategic technical issues, as well as process-related ones, e.g., setting the overall development direction and specifying the ways of working. This change of decision-making power from management to the community was a major cultural change in the organization.
Setting the Overall Direction
Given that the product was in a mature market segment, product management retained the main responsibility for the overall direction of the system. Compared to the old project, the technological change from dedicated hardware to a virtualized cloud-based solution provided opportunities for novel features. This, in turn, resulted in the development organization providing both feedback on existing requirements and ideas for completely new ones. The interaction between development and product management changed from a command-and-control style towards one based on trust and dialogue—and a little sense of rebellion against the traditional way of working, as described by a product owner:
“In practice we don’t have top-down management anymore, so if the PO decides something, or if the architect decides something, nobody takes it seriously unless it has the community behind it. The decision has to be made by the community and be accepted by it.”
“The overall direction is set by the community… But it is very challenging, e.g., if they [headquarters] have an architect who has the power to decide, and he comes here and commands us to do something, and then he is told that he cannot decide…that you don’t have the power, you can say whatever you want, but the community will decide and make the implementation anyway. So, we have kind of the reputation of a pirate ship in the sense that we have bravely made decisions outside the mainstream that in retrospect have turned out to be very good.”
The change from an executing organization towards one intimately involved in deciding what to do was based on the fact that the community in Project Cloud gained valuable knowledge about the possibilities and limitations of the new technology. This gave them the confidence to weigh in on requirements-related decisions and negotiate with product management. A product manager argued that this open discussion and negotiation based on a deep understanding of the product and customers in the community led to better requirements:
“We [the community] are really a strange creature in the sense that if there comes a requirement [that we think does not make sense], we … tell that it really does not work this way, we won’t do it. And in particular, if this requirement comes from a person who has not done hands-on work with the cloud, and he argues against twenty guys [who are technical experts], doing real development work, you can guess whose arguments are better… Or sometimes we question the customer value [the requirement] provides, and that often leads to interesting discussions. At least with our product management. If we tell them that this does not produce customer value, and we can motivate it well, then the requirement is rather quickly forgotten.”
In addition to discussing the requirements, the community was responsible for architectural decisions. While the old organization had separate architect roles, in Project Cloud, the technical leads and experts were part of the cross-functional teams. Thus, they were immersed in the technology while participating in the daily technical work rather than living in an “architectural ivory tower” far away from the actual development. This allowed the teams to undertake end-to-end development, as explained by a product owner:
“We [in the CoP] share information and solve problems together and make decisions. And everybody is on the same line, and the decisions mostly come from the teams and the community. In the old days,…, we had a systems department that would study the issue several years beforehand, and would write specifications that were carved in stone and handed over to the developers. Now it is kind of the opposite. Basically, the biggest change was that the old systems experts and system testers were all integrated into the teams…. The teams really became end-to-end capable.”
The project had one remaining architect role, although that role had morphed from decision-maker to assistant, supporting the community and helping to ensure that the architecturally significant decisions made by the community conformed to corporate guidelines.
Through the community, the teams felt that they were able to affect the overall direction in the organization, and that the decisions made by the community made use of the best knowledge in the organization. A team member explained how much they could influence the overall direction:
“In my opinion, quite a lot. In particular, now that we started this virtualized version of our product, there were a lot of people in the community assessing options and pushing it in the right direction. And that is maybe one strength of Ericsson Finland, that we have made the right decisions because we have discussed issues broadly and tried to elicit all knowledge that is available in-house.”
While the organization strived to form teams that would be able to work on any feature, without any areas of specialization, this turned out to be tricky in practice. The main concern was related to productivity, and this meant that the product owners mostly decided what each team would work on next. A team member explained:
“I think it is maybe a bit bad. Of course, they [product owners] would certainly listen to us if we told them that we would like to make more of this and less of this, but they really don’t ask us a lot... And if some team has got… kind of stamp… that it focuses on certain types of tasks, the POs, because they focus on throughput, always give the same kind of tasks to that team, which might not be optimal from the point of view of competence development. So, I think that the PO and line management should think a bit about the competence development needs and wants of people.”
Designing the Team and its Organizational Context
Although line management was responsible for recruiting and staffing decisions, teams were actively consulted, and their recommendations were typically followed. Many decisions were made based on a dialogue between the teams and the line managers. During a recent external recruitment process, selected team members participated in the job interviews and actively contributed in the technical parts of the interviews, giving them influence on who should be part of the team.
The level of authority given to the teams when it comes to designing the teams and their organizational context can be illustrated by the way a recent major organizational change was handled. Since some teams were too small, half of the teams were designated for restructuring. This was achieved by offering the teams a choice: either the teams drive these decisions, or the line managers drive them in consultation with the teams. A coach described:
“... The teams thought that it would be better if the line management decided, and teams were only consulted.... It would be fair to say that the line management was a bit frustrated at the slowness of having to discuss with people, hear them out, and then discuss more with somebody else… But the end result, based upon feedback from the teams, seems to be quite good because the teams themselves feel that they have been able to influence things, and that makes them feel much more comfortable [with the decisions].”
In terms of organizational context, product owners or other members of the community assisted in connecting the teams with the right experts whenever external expertise was needed. As a result, teams in Project Cloud were in direct contact with the other teams and with supporting roles inside and outside the project.
Monitoring and Managing Work Processes and Progress
The decisions related to ways of working and what tools to use were made both at the team and the community levels. If a decision was not in conflict with what had been agreed upon at the community level, nor created problems for other teams, a single team could make the decision. The teams were authorised to define their own ways of working, as long as other teams were not affected. This guideline in Project Cloud aimed to maximize team autonomy, restricting it only to avoid conflict or chaos in the organization. If a team wanted to make a change affecting others or change an agreed-upon community decision, they had to call a community meeting. This was explained to us by a team member:
“The team decides [its working processes] independently... Yes, and for example when some new people came [into the team] around a year and a half ago, we had this session [in our team], where we discussed how to work, how do we want to work, and we created some kind of instructions…. When something has been decided in the community, a team cannot change it, but has to take it back to the community [and suggest changing it]. For example, commonly agreed things, like we use Gerrit [a tool] etc., we cannot decide ourselves that we don’t like it and won’t use it.”
To better understand the type of process-related issues that a team could address independently and what belonged to the community, we asked whether a team could, for example, decide for themselves to use Scrum or Kanban. We learned that since certain alignment points existed between the teams, decisions affecting this alignment required everyone to change, and thus must be made in the community. At the time of the interviews, all teams had synchronized two-week sprints. However, inside the sprints, each team could work the way they wanted. For example, many teams used Kanban boards, some had physical boards, and some had electronic boards.
Each team agreed with their product owner on how team progress and performance were monitored. Teams were required to trace their progress using Kanban or Scrum boards and to hold daily stand-up meetings in which their product owner also participated. The teams considered the daily stand-up meetings as reporting meetings and not team internal meetings held for coordination purposes because of the presence of the product owners. The POs required each team to maintain some kind of board, as well as hold daily stand-ups.
Quality was mainly ensured through automated testing, which was performed on several levels and in different cycles. When working on new features, teams implemented new automated tests as a part of the feature development. Teams were also responsible for continuous integration and the automated testing system, called the “washing machines”. Teams took two-week turns in monitoring the washing machines. Therefore, we can say that the teams and the community as a whole were responsible for quality and also for checking quality.
Executing the Team Task
When teams were assigned features to develop by the product owners, they performed the development work independently, taking full responsibility for designing, implementing, and testing the features. In cases where their work affected other teams or the product design or architecture, related decisions were deferred to the community. In the community meetings, other teams and experts, such as architects, weighed in on the decision.
The final delivery to the customer was undertaken by the release managers in collaboration with the product owners, because the preparation of a release requires “bureaucratic” work that the teams were shielded from.
Level of Team Autonomy in the Case Projects
In Table 4, we summarize the distribution of authority in the two studied projects. The white cells represent the areas and decisions that individual teams are responsible for. The light grey cells represent the areas aligned across the teams and were influenced by the teams or decided by the teams jointly as a community, while the dark grey cells represent areas and decisions made by line management, product owners, or other managerial roles without prior consultations with the teams. Note that product owners are not considered part of the teams, as this was the setup in both our cases. The reason for this was that the POs in Project Cloud, and the OPOs in Project Mobility served several teams. This means that our teams refer to the Development Team in the Scrum guide sense, not the Scrum Team, which includes the PO (Schwaber and Sutherland 2017). The newest version of the Scrum guide (Schwaber and Sutherland 2020) has dropped the concept of Development Team, referring only to Developers instead.
Table 4 Summary of the distribution of authority. The white cells represent areas of team responsibility, while the light grey cells represent areas, in which teams can influence decisions or in which teams are consulted. The dark grey cells represent areas in which decisions are made without consulting the teams Our intention was to understand the amount of authority given to a single team working in a large-scale software development project, what decisions a single team could influence, and which decisions were made without consulting the teams. Next, we briefly compare the cases.
Setting the Overall Direction
In Project Mobility, the area product owners and the system owner decided what should be in the system, while teams could contribute to the system vision and content by introducing ideas during hackathons. In Project Cloud, having an open discussion with the community had a strong influence on the overall direction by providing both feedback on existing requirements and ideas for new ones, while product management retained the final responsibility for the overall direction of the system.
Further, in Project Mobility, the product architecture was designed by the team of architects that consisted of design architects from the teams, while in Project Cloud the community was responsible for architectural decisions. Finally, in Project Mobility, the team specialization and features developed were decided by the area product owners, while in Project Cloud the product owners decided on team specializations but listened to input from teams regarding what they wanted to work on.
Designing the Team and its Organizational Context
The leadership group in Project Mobility decided who was part of each team and which supporting roles there were, mostly without consulting the teams, which negatively affected team morale.
In Project Cloud, line management took the final responsibility for recruiting new team members, as well as for moving people between the teams, while actively involving the teams in the process. The community assisted teams in connecting to key experts and to the other teams.
Monitoring and Managing Work Processes and Progress
Each team had the main authority to decide their internal process in Project Mobility. However, to align between the teams, many mandatory processes, such as a quality checklist before delivery and sprint length, were defined by the line managers and the leadership group.
Team progress and quality were monitored by the team and their OPO and line manager. Integration and system tests were performed by a separate CI team. In Project Cloud, the overall project processes and changes to it were aligned in the community. The team’s internal process and ways of working were decided by each team, as long as they were not in conflict with the community-level agreements. Team progress was monitored by the team and their PO, and teams and the community were responsible for the quality of their work.
Executing the Team Task
In Project Mobility, teams took full responsibility for designing, implementing, and unit testing the features, and were supported by their area and operative product owners, as well as by design owners. In the same way, in Project Cloud, teams took full responsibility for designing, implementing, and testing the features, and were supported by their product owners.
In both projects, the release managers took care of the final delivery to customers.
Comparing the Cases
The results of the cross-case analysis indicate that teams in Project Mobility had similar levels of authority as in Project Cloud when it came to executing team tasks and deciding on team internal processes. However, project-level decisions in Project Mobility were handled to a large extent without consulting the teams, while the teams in Project Cloud either jointly decided or at least influenced decisions with respect to managing ways of working within the project, designing the teams and project context, and setting the overall direction for the system they developed. This was done through a community formed by the teams that included the technical and product experts, as well as the Product Owners. Due to the high levels of technical uncertainty at the beginning of the project, there was a need to combine the competencies and together find the best possible solutions to the challenges that arose. Due to this technical uncertainty, everybody was at the same starting line regarding competencies. The success of the early decisions proved that community-based decisions had a higher likelihood of success than individual decisions, which was the reason to enforce the community as the central decision-making forum, especially regarding technical decisions. The only decisions that were made without consulting the teams for Project Cloud were related to how tasks and specializations were distributed between different teams. Here, teams did not traditionally have much influence on the decisions, as the product owners made the decisions. However, the interviewed team members viewed this as problematic and hoped that teams would also have more influence in this area in the future.