Keywords

1 Introduction

Software Development, compared to more established industries, is still in it’s infancy. The frameworks to guide the creation of a software product are maturing rapidly, with inspirations drawn from other industries shaping and evolving the models over time. Scrum, has grown in popularity in recent years and a trend has emerged to move away from a pure Scrum approach, Robinson and Beecham (2019), which is Scrum as per the Scrum Guide (Schwaber and Sutherland (2018)), to move towards a hybrid model. The hybrid aspect often involves modifying some of the core ceremonies or bringing in additional changes, often inspired by other frameworks. One of the most popular hybrid approaches is the introduction of Kanban. The term Scrumban, as mentioned in Nikitina et al. (2012) has emerged to describe this model with some of the key benefits being increased visualization of work and a focus on Work in Progress (WiP) limits. This has the affect of pulling work through the system at a faster flow rate, by focusing teams on a finite number of items. The Agile Manifesto (Beck (2001)) talks about people and interactions over processes and tools. Scrum advocates strongly for in person execution for the most optimal results and control for the team, with a strong motivator being the presence of the customer and team in colocation. The enhancements or modifications to Scrum, particularly those inspired by Kanban, focus on a visual way of implementing and running the team, lending itself to in person interactions. Minimal research, such as Faniran et al. (2017), Smits and Pshigoda (2007) and Paasivaara et al. (2012) have investigated remote friendly Scrum, but no standard tools and techniques have emerged for teams to follow. In addition, the unprecedented nature of this unexpected and first global pandemic in the history of the digital era, means that the world is learning how to adapt.

Several online tools are emerging that are proving to be more than adequate to replicate in person interactions, however, teams have not fully embraced or invested in them. In early 2020, a global pandemic named covid-19, caused a paradigm shift for the worlds workforce. With global health advice advising against in person business, most industries moved into a remote way of working. A subsequent scramble to form an IT strategy that was conducive to sustained performance was now needed. This brought several challenges for teams who had a heavy focus on in person interactions and this shift to remote work came with the expectation that performance and delivering the same output would be maintained. This paper will focus on the lessons learned from a software engineering team that had a mix of remote and in office team members before covid-19 where a culture of remote first work was already prevalent. This team had been working in an Agile manner for almost 18 months, were trying to follow the Scrum Framework and had a full time Product Owner and ScrumMaster. The team executed Quarterly Planning (QP), a process whereby stakeholders would help prioritize multiple sprints worth of work to execute a larger piece of functionality in order to align across the enterprise. The team as a whole numbered 26 people divided into 4 delivery teams, each responsible for delivering standalone functionality. The work from home enforcement of family members and house mates created an environment that put strain on our team. Of particular focus was the waste generated by following the Scrum framework and this paper will focus on the key waste elements identified in both the ceremonies and the key inputs to the team, with recommended adaption to minimize waste provided.

2 Remote Scrum Challenges

A number of challenges have emerged for remote teams running Scrum in the current environment. Scrum operates on a predicable multi week cadence, broken down into ceremonies that are designed to continiously feed a team relevant work, be highly collaborative with the customer in mind and ultimately to deliver incremental value.

2.1 Scrum Ceremonies

Daily Scrums are timeboxed at 15 min. In person interactions can allow for better facilitation and control of the communication and to ensure that the timebox is adhered to. Using online video conferencing tools introduces technology as a factor, chiefly audio/visual and network issues making the tighter timebox difficult to stay within or compromises the quality of the discussion within the team

Sprint Planning is timeboxed at a maximum of 8 h for a 4 week Sprint, with that ratio of hours to sprint duration scaling appropriately. While held in person, engagement can remain high for a longer period of time than working from home can achieve. Best practices for ergonomics, as seen in Bontrup et al. (2019) states a minimum of 5 min away from the screen every hour. This can be highly disruptive to the flow of a long running meeting like Sprint Planning, where a full Agenda cannot be set ahead of time. The natural breaks in person are more difficult to translate to that ergonomic recommendation, with meetings often running to close out a section of the planning successfully. The Sprint Review suffers from a similar timeboxing issue as it recommends a 4 h meeting for a 4 week Sprint, this, however, is less of a concern in shorter sprint durations. Sprint Retrospective is one of the most valuable tools for a Scrum team to inspect and adapt. Psychological Safety is one of the hallmarks of a strong Agile team (Edmondson (2018)), that is in part detected, and acted upon by the ScrumMaster. In person, the use of body language is a key tool to help discover and assess psychological safety. In a remote world, where web-cameras may not be available for everyone, it is impossible to gain that sense of how safe the team are. This can have a major impact on the quality of the contributions and hampers the retrospective longer term.

2.2 Distractions

While participating in any of the Scrum Ceremonies, having the team present in a mental capacity is hugely important. That diminishes quickly in a remote environment, as team members are on their laptops with a plethora of noisy distractions from emails, to instant messages through to web surfing. The result is a lack of focus within the team, and while the ceremonies are executed as close to the Scrum Framework as possible, the result is a mechanical version of Scrum, rather than the Agile mindset which results in a longer term transformation. While the impact here is hard to quantify, 6 months into the pandemic, the longer term impact will be a follow on to this research paper.

2.3 Fatigue

In person interactions allow for a lot of time away from a desk and by extension from the work at hand. A trend in recent years in the IT industry is to have an office with collaboration focused areas, wellness rooms, games rooms and multiple social interaction touchpoints in common spaces like the canteen. This has a noticeable impact on human collaboration as noted by Bernstein and Turban (2018) and the passive result is a workplace that has a social element to it, which increases staff happiness. This is an important element of a team and company culture, which results in the teams weekly contribution to their project, versus their contractual obligation, being reduced. That reduction is often passively factored into project and release plans. In a work from home environment, personal and professional spaces may collide, with variable working hours. Another factor is the narrowing of the social interactions to just that of your immediate team and extended functions critical to your day job. This focused social group, coupled with the work day being closer to the contracted hours, has a magnified intensity to the work day that workers have never experienced before. Pairing this with meeting fatigue and burnout is a real possibility within the team. That can impact the overall team and the product may suffer.

3 Waste Within Scrum: Key Inputs

A focal point here is on observations about waste, or muda, in the Lean terminology, that our team have identified for later actions.

3.1 Requirements

Working with Stakeholders is a core facet of the Product Owner role, often bringing in key technical members to fore-run on feature requests to stock the Backlog. Good Product Owners often work several Sprints ahead of the development team to ensure that Sprint Planning is a smooth and efficient process (Sverrisdottir et al. (2014)). The Quarterly Planning (QP) approach used by our team helps to indicate the delivery goals for customers. QP is a maturity indication for Agile teams, where the teams velocity, their sizing analysis and overall execution are capable of predicting 12 weeks (multiple sprints) with a high degree of confidence. With this in mind, QP brings stakeholders to analyse the User Stories scoped at the right size to be delivered in that timebox. Mature products often have longer term functionality that needs to be built upon quarter after quarter, to achieve the ultimate end goal. An element of waste here is the involvement of stakeholders in the lead up to, and the execution of QP, when the teams capacity might be a fraction of their true potential due to longer running initiatives. In our team, this has been the case for 3 Quarters running due to long term initiatives that have an overarching need to deliver a complex system.

Roadmaps are a very popular sales tool to entice Customers into longer term investment in a product offering as described in Munch et al. (2019). That involves future projection to showcase longer term direction of the Product. This involves engaging with Customers, who are attracted to some of the future roadmap, with the view to try and accelerate features by building out requirements. Roadmaps, however, are often a marketing mechanism, talking about longer term future branch points that may not align to the Product Vision or the direction the company are trying to take. This involves the Product Owner and key team members engaging on in depth requirements gathering for features that might never be realised for a variety of reasons from technical, to product positioning through to investment required in skills, people and infrastructure.

3.2 Backlogs

With the default separation of a Sprint and Product Backlog, Scrum has a funneled approach to take items into a Sprint and allow the team break them out in more detail for consumption. The granularity of the tasks matches the Definition of Done, ensuring that multiple, often very similar in nature pieces of work being identified. While the need for Quality is undeniable in software, the process for the team to take time to create tickets (a generic term for work items to progress) to capture the items needed to complete a User Story to done, is an exercise in repetition. The risk of not doing this level of breakdown is the team missing some of their Definition of Done criteria when it comes to Sprint Review.

Multiple teams often work together on a product. Mature, complex products are often viewed as sub-products, as the functionality has grown to a level of complexity that a dedicated team owns the feature set. This creates siloed backlogs, with feature teams drawing select User Stories from the Product Backlog to stock their sub-team backlog. This approach sees the members of that team attend wider Backlog refinement, and while the knowledge sharing can be invaluable, it is viewed as muda once their subsection User Stories are discussed and agreed upon. Layers of complexity build on top of this to ensure that cross sub-team coordination can exist, with Scaled Scrum Frameworks emerging which bring multiple additional meetings and coordination in an attempt to get back to a singular product view of the world. The larger the organisation, the larger the waste footprint becomes.

4 Adaptions to the Scrum Process

While the onset of the pandemic forced many of the adaptations to accelerate, the team had already worked on modifications to the Scrum framework to become a more hybrid Scrum team.

4.1 Scrum Ceremonies

Small changes remove a lot of waste and free up precious calendar time for the teams by defaulting some of the updates to an asynchronous manner. The Daily Scrum, as an example, can be delivered over instant messaging applications for consumption by the team at their own pace. Blockers and escalations can still be elevated to calls, however, the majority of Daily Scrum conversations are coordination of work. While the Scrum Guide emphasizes a focal point on Blockers, teams use the call to align on the goals for the day and recap the prior days work, this is a relic of the original intent of the Daily Scrum that prevails as it is attractive to teams for coordination benefits. Sprint Reviews often come with demos, which can be time consuming to setup and establish. Pre-recording demos and making them available to the team to consume in their own time is another key removal of waste, allowing the team focus a conversation on the demo over other communication channels.

4.2 Backlog Adaption

Backlog refinement looks at the longer term horizon for the team from a product perspective, ordering the backlog and allowing for Sprint Planning to proceed with the certainty that the highest value items will be progressed. At Sprint Planning time, the breakdown of those tickets selected into smaller, consumable pieces for the team is a necessary step. Typically, the entire team gathers for this process to benefit from the knowledge sharing, however, a percentage of a cross functional team will have no input or real value taken from the discussion on Stories outside of their immediate skillset. While the more experienced developer leads the conversation, most of the team enter a silent observation mode. Discussing the tickets in a just in time format is a heavy team burden, as the technical depth of conversations required to articulate the needs is time consuming. The adjustment proposed was to merge the backlogs from a granularity perspective, which some Scrum variants recommend Gancarczyk and Griffin (2019). The team have the certainty of the next several sprints worth of work and this allows the technical leads to investigate the User Stories as individuals, documenting their observations, their recommended implementation details and finally sharing this with the team. Over the duration of a Sprint, the team established 1 h Backlog Refinement calls, to go in and discuss at a high level the implementation detail as documented ahead of time, to answer any questions that could not have been resolved on the tickets and to finalize their plan. Strict timeboxing ensures that the team do not feel burned out and the frequent cadence of the meetings allows team members to dip in and out as necessary, with the option of watching the recording of the meeting and following the detailed breakdown in the ticket and raise questions there. The benefits here have helped streamline the QP process as a more in depth backlog view is possible, allowing for more informed decisions on what to prioritise and when and no sense of loss was reported by the move away from a Product Backlog view.

5 Process and Tools

The Agile Manifesto clearly states individuals and interactions over processes and tools. As remote teams, tooling is important and issue trackers provide a number of ease of life improvements with APIs and plugins capable of eliminating a lot of waste. Our team implemented their Definition of Done (as defined in Schwaber and Sutherland (2018)) in an automated manner by auto creating tickets for documentation, testing validation and release readiness as part of the new ticket creation. This, when combined with static code analysis tools that can provide a gating mechanism before code merge, ensures lower technical debt all around and that the DoD is adhered to. The waste removal here is significant in backlog refinement sessions and a far safer method from a quality perspective.

Software teams spend a lot of time debugging and tracking down issues and bugs reported by their users. The ability to observe the system and quickly understand where a fault might reside represents a saving in debugging time, context switching and a quicker resolution, which ultimately allows the developer to get back to more value add work faster. The investment by our team in Observability and Monitoring stacks has provided a reassuring level of Quality to complement already expansive test coverage and eliminated a large amount of muda that the team were experiencing.

The Product Owner introduced the concept of an Epic Brief – a one page summary proposal – for stakeholders and team members to simplify the process of funneling work into the team. Previously, stakeholders would have engaged with multiple groups as they evolved their idea, resulting in a lot of wasteful meetings and often the end result was discovering that the work was not aligned with the teams mission statement or simply beyond the scope of what they could deliver. This minimal required information allows the Product Owner engage more efficiently. The benefit of this approach is a fail fast approach, to discover that the work proposed was not a good fit for the team for a number of reasons. Combining this with QP, the Product Owner is able to ascertain the workload on the team as well as the size and scope of incoming requests. This helps level set expectations before too much time and effort is put into an Epic Brief that might be important to that particular stakeholder, but that will ultimately be a lower priority for the team as a whole and several quarters away based on current trending velocity and in flight needs.

6 Conclusion and Future Work

The paradigm shift to work from home is putting a strain on teams like no other experience in their lifetime. The Scrum Framework has multiple prescribed routines that are optimized for in person interactions and that when followed to the spirit of the Scrum Guide, result in the generation of waste. Having recognized this, our team has taken the first steps in eliminating this waste and moving towards a more Lean inspired version of Scrum. As this global situation is still evolving, the work from home approach looks set to remain the status quo for years to come. More work is planned by our team on investigating the tooling from a production line viewpoint, where requirements and code eventually get baked into a workable product. Deeper statistics are being gathered to make informed changes, with the more obvious waste, as documented in this paper, eliminated already. The key constituent roles of Product Owner and ScrumMaster also generate a lot of waste within a Scrum team and is a planned future research topic.