5.1 Diagnosing
Diagnosing started in May 2013 and lasted until December. To understand the context, interviews were held with employees across all roles, resulting in a description of current roles and mapping of involved domains of practice. Generally the reported problems constituted a lack of structured process connecting the development to portfolio level decisions. On average the company has been working on two ‘very small’ projects and 30 to 40 ‘individual’ to ‘tiny’ sized projects a year. When the company grew it became very difficult to keep an overview and coordinate these projects effectively. Further, the small teams were linked to multiple POs exposing them to discussions due to conflicting customer priorities.
During interviews and discussions with developers and management we identified a number of issues: (1) Development staff is highly distracted, to a large degree caused by discussions with multiple POs. (2) Little connection of portfolio to strategy. Little coordination across the portfolio leading to suboptimal and unprofitable choices. Portfolio decisions are made by developers. (3) Poor knowledge management, resulting in overhead and posing a danger to project continuation. (4) Daily maintenance shifts help get maintenance tasks done while keeping most of the resources focused, however, overhead for working on unknown projects is high. (5) Hard to keep an overview and deliver work promised to clients.
5.2 Action Planning
Following the diagnosis, management acknowledged that improvements were necessary. In discussions with all actors it became clear that a team having to deal with multiple POs does not work well because developers end up making decisions about portfolio priorities for a large part of their time. It was concluded that removing the portfolio decisions from the development staff and limiting interruptions of staff by management will likely reduce the distraction of team members and improve portfolio decisions. In early June 2014 an initial plan was developed based around the following proposals: (1) Introduce agile portfolio management, (2) introduce stable teams, (3) work with true Scrum sprints, limit task switching, and (4) improve company-wide knowledge management.
Based on that and hints found in practitioner’s literature (cf. [
39]), we designed the
Team Portfolio Scrum (TPS) practice and the
Team Portfolio Owner (TPO) role to support the implementation of portfolio management. TPS is based on a one week Scrum cycle including the usual Scrum practices (e.g., Sprint and review, daily stand-ups, retrospectives) in which the PO is replaced by the TPO. The practice follows characteristics of agile portfolio management [
1] by (1) adding transparency of resources and work items through a Portfolio board, (2) close collaboration based on routines and artifacts enabling frequent feedback-loops across teams and management, (3) commitment to strategically managed portfolios, and (4) team orientation. In Table
2 we summarize the description and responsibilities of the new role.
Table 2.
The team portfolio owner role
Team Portfolio Owner:
|
Person responsible for the success a team’s project portfolio. Analogously to a Product Owner, the Team Portfolio Owner (TPO) sets the priorities across projects during a Sprint. TPO shields team members from internal politics and different customers pushing project priorities |
Responsibilities:
|
• Coordinates inter-project priorities with the team, portfolio team and customers |
• Takes task switching penalties into account in discussions with the team and the Scrum Master |
• Channels multiple projects into a single team backlog |
• Guards inter-project priorities (1) when scope changes are needed (work taking longer/shorter or urgent other work, and (2) during the sprint planning meeting as the team negotiates work items |
• Single channel of communication towards the team, lessening distractions (outwards communication is at the team’s discretion) |
• Attends the portfolio meetings to align priorities with company strategy |
• Attends the daily stand-ups to keep up to date with the progress of the team |
5.3 Action Taking
Before introducing the TPO role, a portfolio team, a portfolio board and a team portfolio backlog were introduced. The TPO role was appointed from one of the three POs previously working with the team. On June 25 a workshop was held with the development team and management staff. Initial resistance arose among the developers as the goal was initially defined around increasing engineer productivity. In response the goal was rephrased to remove mid-sprint management interruptions and portfolio level responsibilities from the engineers.
Action taking began on June 30, 2015 with a reiteration of goals during a lunch presentation. The implementation of the practice was reflected throughout the project in Retrospective sessions staring on July 4. On August 15, 2014, the team leader left the team for reasons unrelated to the project which had a big impact on the morale of the team as became visible in our satisfaction graphs. The action research continued with the practice being perceived as useful. The following time line outlines the execution of the project:
-
May 6, 2013: Diagnosing: Scoping interviews
-
December 2, 2013: Action Planning: Discussion of improvement initiatives
-
April 15, 2014: Initial presentation of action plan to all employees
-
June 9, 2014: Introduction of portfolio management (portfolio board)
-
June 24, 2014: Preparation meeting with management and appointing TPO
-
June 25, 2014: Workshop with development team and management
-
June 30, 2014: Action Taking: Introduction of TPS practice
-
July 4, 2014: Retrospective after first sprint
-
October 6, 2014: End of Action Taking, beginning of evaluation
-
January 1, 2015: Company wide implementation of TPS
5.4 Evaluating
The Team Portfolio Owner (TPO) role was adopted company-wide by our case company three months after the action research was completed. We consider this as an indicator for the success of the project. We now return to the research question in order to evaluate the action research.
Barriers to a team portfolio task prioritization practice: Additional overhead: In the case company, the hours of a manager, including the TPO, can not be billed to clients:
“As to whether it [the TPO role] is overhead, yes, per definition, because the work isn’t billable to the client. This is related to the way clients are billed at this company: actual booked development hours. Other methods exist that are much more suitable for Scrum [
40]. However these methods assume one project per sprint. Billing might be a general problem for multi-project software development as is it hard to predict the proportions of the sprint for each customer in the face of scope changes.
High workload: The TPO reported his high workload at several occasions, especially towards the end of the action: “..in the beginning I had much more time to do proper backlog management.”; “it is extremely busy to fulfill this role.”
Benefits to a team portfolio task prioritization practice: Better adherence to company strategy: Due to the oversight the TPO can make better decisions in coordination across the entire portfolio. Yet, choosing the right projects can be difficult for a small company: “For existing customers we basically have to do everything, we can’t choose to not do a project. It is useful to decide on new customers though.”
Removing portfolio level decision making and conflicting decisions from multiple POs: This benefit of the introduced role functioned very well from the beginning, as confirmed by observations and multiple actors. Before introducing the practice, developers had to make decisions and were blamed for those. When asked about what to do when a task threatens achieving the sprint goals, a developer commented: “I go directly to the TPO. The TPO manages what tasks get dropped. This works very well.”
Limiting interrupting requests from multiple POs: Before the change POs would often come to a developer’s desk asking questions, planning work and lobbying for projects. As a developer comments: “It is easier for developers to defend themselves.? and ?[the situation] improved. We have more breathing room because of the experiment. We can be more focused on software development.”
Specifying Learning. Not more than one large context switch per day: In our case organization the developers reported a benefit from the introduced TPS practice. However, also the number of parallel projects increased. Recommendations we found in literature deviate between two [
12] parallel projects as an optimum, and not more than one large context switch per day - thus five projects per week. However, this largely depends on the homogeneity of the assignments. Here it is for the TPO and the team to discuss what a reasonable number of projects is according to: (1) familiarity with the project (architecture, code standards), (2) homogeneity (domain, application type), and (3) urgency.
TPO needs sufficient mandate: For fast resolving of issues, the TPO needs to have a complete mandate for choosing between the customers in the current sprint. A team member said at the beginning: “The role itself has too much responsibility, at least too much for what the current TPO is mandated for. This adds a step between the management process: the team signals a problem to the TPO, the TPO needs to consult with the PO to make the decision. This means extra overhead for certain tasks. The TPO should define the priorities and shield the developers from the outside.” The POs appreciated this delegation of responsibilities at later stages of the project: “I liked it that the TPO could make the choices.”
Collaboration of TPO and POs: The introduction of the TPO role had a strong impact on the interaction of POs and teams. The POs had previously direct access to the teams, and had to go through the TPO as a Master Product Owner now. It took time to go through the TPO for planning or urgent maintenance: “For me as a PO, the effect was that the planning was less fine grained, which was something I had to get used to since I’m a control freak. [About closing the scope] The smaller projects and maintenance are really hard to plan.”
TPO and the Portfolio Team: Knowing the inter-project priorities is very important for this role. The project portfolio board is the primary tool for the transfer of this information from the Portfolio Team to the TPO. Attending the Portfolio Management Meeting gives the TPO additional information and the possibility to discuss the priorities. The TPO said: “The weekly portfolio management meeting is very important for this role.”
Limitations. There are two main limitations to this research: First, we present the results of a single action research study. Credibility of AR lies in knowledge generated and tested in practice [
36]. Generalizations and external credibility from such AR studies depend on rich storytelling as well as application of AR guidelines such as CAR [
37]. Second, with one developer leaving the team composition changed. This resource problem impacted the team, both in getting more work and lowering morale. However, many action research projects take an unpredicted course while still providing considerable scientific value [
37].