4.1 RQ1: Usage of Agile Methods and Practices
Four Agile Methods were used by the projects: Scrum (n = 4 projects), Flow (n = 2), iPeP (n = 1), and SAFe (n = 1). The practices that were used in
all five projects belong to Scrum, namely Sprint, Backlog, Sprint Planning, and Daily Stand-Ups, although one project reported that it is not using Scrum. The practices that were used in
most projects were Sprint Review, Sprint Retrospective, Burndown-charts, Definition of Done, Scrum Master, and Product Owner (PO) (all Scrum), and User Stories and Epics (both XP). Continuous Integration, Release Planning and Scrum-of-Scrums completed the set. The practices that were used in
few projects were: Planning Poker and Pair Programming (both XP), 80%-rule and Pull-system (both Lean/Flow), and Backlog Grooming (Scrum). In Table
2, we show the use of agile practices.
Table 2.
Benefits of used agile practices on goals (numbers indicate how many projects mentioned a benefit)
4.2 RQ2: Deviations of Agile Practices
The used practices are now discussed regarding their deviations from existing guidelines, e.g. the Scrum Guide:
The major issue of the Scrum Master was the manifestation as “caretaker”, e.g. in one team the Scrum Master was only inviting for the different Scrum meetings. Further, often the Scrum Master was not the only role. Being a project leader or a PO in combination might result in a conflict of interests. The PO also deals with the aspect of several roles by one person without problems. But some teams defined an additional “feature responsible”, which covered POs tasks, e.g. breaking down the features into Stories. Finally, within one project, they struggled with the issue of having a Chief-PO communicating with the customer high-level, but not knowing the requirements in detail.
The most deviating aspect of sprints was their length. For one project (needing four weeks) more than two weeks were necessary for the integration of hardware aspects. Another one worked with varying lengths over time.
The Scrum-of-Scrums meetings conducted weekly by the larger teams or projects was in one case a team-meeting in which all project members participated. In another case, it was conducted by the project lead to keep the offshore team on track.
The Daily Stand-Ups deviated in three different aspects: (1) Usage only for status-tracking purpose, (2) Meetings lasting up to one hour, (3) Frequency of the meeting: Instead of every day, teams conducted it every other day, every three days, once a week, or unregularly. An extended duration of the meeting (one hour) was the consequence.
Sprint Planning: Within the sprint shift (Review, Retrospective, and upcoming Planning), most of the teams performed all three meetings en-block in about three days. In one of the larger teams, they found a solution to break down the Backlog to the teams by the PO. The planning itself was conducted within the single teams without the PO.
Sprint Review: The composition of meeting participants ranged from meetings without the customer and only with the team leaders and functional owners up to an “open event”. Some meetings were unstructured without agenda or open topic list. Others were not conducted as an “acceptance meeting” with stakeholders or PO.
Sprint Retrospective: This meeting varied within the timing: One team performed it every other sprint, because two weeks were too short to resolve impediments. Another team directly resolved smaller impediments during the meetings. One interviewee mentioned that the retrospective was only weakly defined and valued within their team.
Within the Backlog, two major variations existed: Some included prioritization, whereas other did not. Different backlogs were used, from team-, project- or overall backlogs up to release backlogs. These kinds also contained various backlog items, e.g. User Stories vs. Epics. Two teams did not use User Stories as prescribed by the given templates, since they were not used to it and needed more information.
Planning Poker: One team used this practice for estimating the granularity-level to refine the story or not. Furthermore, not all teams used “story points” as values, but e.g. person hours or days. Finally, one deviation was that in one team just the “key player” (a senior developer or feature responsible) decided on the estimation value.
Within the 80%-Rule, one interviewee mentioned that they are not considering it for the workload, but on their throughput. In the only case using the pull-principle, the responsibility regarding the different functions was clear such that it was “obvious who is going to pull what”. Thus, sometimes one team member just “assigned” the tasks.
4.3 RQ3: Benefits of Agile Practices
Most of the considered agile practices are beneficial for
planning (10 practices) and
transparency (8), followed by
structuredness (4),
communication,
risk management, satisfaction, and
team empowerment (each 3). Checking the overall number of addressed benefits per practice (cf. Table
2), e.g. the highest with five is the sprint, three yield four benefits, and five yield three benefits.
Except for the Definition of Done and the Backlog Grooming, we could gather at least one impact for each of the Scrum practices. Considering the Scrum meetings, except the retrospective, all impact planning. Sprint Review as well as the Stand-Ups also influence communication and transparency. The Sprint Retrospective was the only practice dealing with feedback and knowledge transfer. The Burndown-Chart is a quite good mechanism for transparency. Both Scrum roles impact the team empowerment. The improved satisfaction resulting from the Scrum Master correspond with that. The PO provides transparency as well as planning aspects. Considering the Non-Scrum practices, there is information about the impact of six practices: Risk management, planning and structuredness were impacted by the 80%-Rule. Planning Poker increases planning and team empowerment. User Stories and Epics influence planning (Epics) or focusing (User Stories). Continuous Integration improves transparency and time-to-market. Finally, Scrum-of-Scrums was quite good for communication and it affects transparency, structuredness, and planning.