Emergency Procedure

Published in

Scrum Mastery Community

26 min readFeb 26, 2022

What is Emergency Procedure?

An Emergency Procedure is a plan of action to be conducted in response to an undesirable scenario. The term ‘undesirable scenario” is whereby immediate fixes need to be put in to rectify the mistakes before it gets worse. When flying an aeroplane, what should the pilot do if visibility is low? Pilots will need to assess the situation and apply appropriate measures (actions).

Actions that are planned to be conducted in such scenarios are considered Emergency Procedure. The question one will ask will be “what then is Emergency Procedure in the context of Scrum?”.

Emergency Procedure is one of many techniques under Scrum Patterns. It can also be called Stop the Line. Emergency Procedure is a list of options (techniques) Scrum Team can consider and apply to the situation they are facing. The list of options is: (a) change the way the team does the work. Do something different, (b) get help, usually by offloading backlog to someone else, © reduce scope, (d) abort the Sprint and replan and (e) inform management how the emergency affects release dates.

For example, Scrum Team realised that they are unable to deliver what they have initially committed at the Sprint and they can consider: (a) dropping feature(s) that have lower priority, (b) getting another team to help and etc.

When should Emergency Procedure be called? How does one know if the situation is an emergency?

In the context of flying, a well-trained pilot would have undergone countless simulation training (both theory and practical) to hone their flying skills, equip their necessary knowledge and in the long run, their intuition will automatically kick in when a situation arises. For instance, pilots are multi-tasking when they are flying their aircraft.

Pilots need to constantly check their flight plan, monitor the environment the plane is cruising at, and make the necessary amendments while consciously making an effort to reach the final destination on time. This can be supported in the book titled Scrum: The Art of Doing Twice the Work in Half the Time [1].

A Scrum Team should similarly constantly assess their progress in the sprint, to evaluate whether their sprint goals are at risk. If there is a risk of achieving a Sprint Goal, Scrum Team should quickly discuss what procedures to engage so the Sprint Goal can be met within the current Sprint. Scrum Master can help to facilitate the discussion and if need be, invite the necessary stakeholders (within the organisation and/or outside the organisation) to create a common consensus. Emergency Procedure helps the Scrum team to focus on what can be done (delivered) within a Sprint when situations occur when the team needs a rapid response to manoeuvre.

Prerequisites a Scrum Team should have before executing Emergency Procedure

Emergency Procedure is not commonly practised by all Scrum teams. An average or a lesser Scrum Team does not use it or, perhaps, is unaware of such a pattern. The reason for not invoking Emergency Procedure could be (a) work conditions in the workspace, (b) lack of knowledge of what Scrum Pattern is and what it does and many others. This, in turn, affects the way Scrum is being used effectively and not what Scrum is intended [2].

The Scrum Team will continue to work hard and maybe, put more time and effort to meet what was originally committed and delivered at the end of the Sprint. This sounds like working in a software development life cycle (SDLC) aka waterfall environment, doesn’t it? People, in general, do not like changes, especially for last-minute changes. Changes or deviations from the original plan are not widely accepted.

Truth to be told, changes take place at any point in time and even to the extent when the Scrum Team is developing (progressing) something in the Sprint. When is the last time you don’t see changes (be it unexpected or something popped out of nowhere) introduced in a Sprint?

What a great Scrum Team subconsciously performs is to review and make the necessary list of actions in order to meet the objectives/goals in the Sprint. Identifying the cause of the problem and a list of action items are some of the items which will need to be discussed among the Scrum team [3].

On the other hand, Emergency Procedure is a procedure a great Scrum Team might not have to do on a constant basis as a great Scrum Team continuously applies other Scrum Patterns concurrently i.e; Swarming, Happiness Metrics, illegitimate non interrupts etc in their work.

Why do Emergency Procedure?

Working in a VUCA (Volatile, Uncertain, Complex, Ambiguous) environment, especially in the last few years, changes are expected very often. Given the rapidly changing world shaped by big data, the importance of agility has grown significantly, especially with the ongoing global pandemic. The introduction of a global pandemic, COVID-19, helps to accelerate organisations to go into uncharted business situations, where organisations find themselves in challenging and unprecedented situations [4].

Scrum Team needs to adapt to changes quickly. People can get easily confused when changes take place especially if changes are novel and/or continuously evolving, resulting in miscommunication [5]. If the miscommunication is not addressed appropriately, members from the Scrum Team can get burned out easily, losing any benefits (tangible or intangible) which the organisation could have benefited from these changes.

Emergency Procedure can be seen as a form of reflection for the Scrum Team on focusing on what is important for the team to work on in the midst of changes taking place that can impact the Scrum Team.

Scrum Team prioritises what is critical and identifies what can be done within the time left. Hence “saving” the Sprint from not delivering anything to deliver some value to stakeholders. Delivering some value is better than delivering no value at all [6].

Stakeholders, or even the organisation as a whole, can get to see what is done at the end of the Sprint. This is definitely better as compared to seeing nothing at the end of the Sprint. Transparency, Inspection and Adaptation are the empirical pillars of Scrum [7]. Emergency Procedure creates or, to an extent, enhances these empirical pillars by allowing Scrum Team members to stop (pause), review and identify what is important and what can be produced (done) in the remaining time left in the Sprint.

Imagine you are purchasing a property, when you engage an interior designer and are quoted a significant cost and yet you are only allowed to view the work once it is completed in, for example, six months. You will naturally feel uneasy as you do not have visibility of what is going on during these six months. It is natural for people to feel uncomfortable when there is ambiguity and uncertainty [8]. People want clarity and certainty especially when the issue is close to their heart and/or interest.

Challenges associated with Emergency Procedure

This section illustrates the challenges identified by the team. The challenges highlighted might not necessarily be covered in greater detail nor the challenges identified below are major challenges (blockers) pertaining to Emergency Procedure. Rather, the challenges described below serve (act) as a starting point or point of consideration, when one wants to introduce Emergency Procedure in their workplace.

Obsession in achieving Sprint Goal

Scrum Team members who are new to Scrum might have the impression that working in Sprints and having Sprint Goals are like working in a mini software development cycle (SDLC). Whatever requirements are agreed upon and communicated need to be delivered regardless of the situation that takes place in the Sprint. This can be coupled with many factors that team members are not going to change the work even though there is a high possibility that the work cannot be done.

Having bad working experience, the mental mindset of not wanting to change for the better, no incentives to change etc. only helps to reinforce Scrum Team members to focus on what is agreed in the Sprint Goal [9]. These behaviours help to reinforce the unwillingness to change within oneself. Below discuss such intrinsic behaviours.

Pride in one’s work

Having Emergency Procedure in the Sprint gives a wrong impression to Scrum Team members, implying that team members are incapable and require assistance (by assessing what has been done and what needs to be done). Individuals who have a high level of ego might feel threatened. These individuals have the propensity to be defensive or uncooperative and are not able to accept any suggestions (feedback). As a result, the relationship within Scrum Team members, (including Scrum Master) or perhaps, with external Stakeholders can be jeopardised. Chemistry and the team’s dynamics take a toll and the team’s performance, in turn, can be impacted [10].

It can be challenging for those organisation(s) that have Delivery Team(s) embedded within the organisation that functions as Scrum Team when working with clients. Clients, generally, expect clarity, regular cadence to honour what the vendor provided and are able to meet the deadlines (milestones). This is, even so, when the contract has been signed. Agreements have clearly spelt out and expectations have formed at the back of people’s minds [11].

One of the reasons a contract is created is the expertise (knowledge) the vendor equips to help the client. Clients do not have the necessary knowledge to execute what is required and totally trust the vendors in good faith. Organisations face numerous challenges when working with different organisations in a client and vendor relationship [12], which can pose a challenge of having an Emergency Procedure when the situation warrants it.

Too many priorities

Sometimes too much is not good or in some cases, it can backfire. This is true for a Scrum Team too. A good Scrum Team must know what is important (critical) and work following the order of the priorities. If the stakeholder i.e; Project Sponsor, top management etc intervenes with the decision made by the Product Owner by changing the Sprint Backlog, Scrum Team has difficulty knowing what is coming up for the team in the next or current Sprint. No one in a Scrum team is able to know what is knocking on their door the next day. Hence, in this case, having Emergency Procedure might lose its value and Scrum Team members might get confused especially for those who are new to Scrum Patterns or, even Scrum as a whole. In the worst case, Scrum Team will get disengaged in the long run.

An alignment among stakeholders is vital, especially in a large organisation, as well as clear priorities and the values which they bring [13]. Without clear priorities, organisations might be in a better position by doing a form of prioritisation exercise with the stakeholders with the right amount of decision-making to prioritise what the organisation wants to accomplish. One will need to know the intent and value of what Scrum brings to the table.

Status Quo

In today’s world, things are moving at a faster pace than one can ever imagine. The time to obtain requirements or requests is now getting faster as compared to years ago. People can easily submit their requirements via different mediums i.e; email exchange, Whatsapp messages or even, a quick voice recorded message from their mobile devices.

Product Owner will need to learn to manage the expectations from stakeholders (internal and/or external). Stakeholder management is important as time goes by, Scrum Team is happy with what they are delivering. They understand what the value the product they are building can bring to their target audience, feel motivated and have a say in how this Product can be developed.

Scrum Teams are empowered to make decisions. Such a way of working is vastly different as compared to working in an SDLC environment where every work package (WBS) has been pre-defined and developers don’t have much say in the products they are developing.

This can be a potential problem whereby the Product Owner might not want to “burst” the Scrum Team’s happy bubbles and let the Scrum Team continue what they are delivering/building. It is important for the Product Owner to share both good and bad news (including any new and critical requirements/requests that might upset the Scrum Team). This is related to another Scrum Pattern — Happiness Metric whereby how happy and engaged Scrum Team members are with the environment they are working in and interpersonal relationships within the Scrum Team [14]. Definition of what Happiness Metric and recommendations to address challenges associated with Happiness Metric can be found in this article published on Medium by Scrum Mastery Community.

Decision Latency

Multinational corporations (MNC) and start-ups and small-medium enterprises (SME) are different, where the former have legacy processes set in place to ensure compliance and control [15]. These processes (which are deemed to hold compliance value) have an adverse impact on innovation and improvement initiatives.

Decision latency is often the result of such organisation(s), as the time taken for the management to make a final decision and inform the stakeholder(s) involved (including the Scrum Team itself) of the outcome and/or action required.

The Scrum Team will continue to work on other items that can have lesser priorities (value) while waiting for a decision to be made. Hence, it can be difficult to trigger Emergency Procedure. It takes time for the Scrum Team to focus on what is required since the final decision lies with top management rather than the Product Owner themselves.

Financial / Contract obligations

Organisations, in general, have obligations to fulfil from either a financial or contract perspective to bind their obligations (commitments). Imagine if organisations today do not have contract obligations, chaos will start to take over as everyone does what they deemed fit.

Nonetheless, these obligations can pose a challenge to delivery teams (Scrum Teams) as the teams might not be consulted when stakeholders are in discussion to draft the contract. Most organisations have different business units i.e; Account Management, Delivery Teams, Solutioning Architecture, Project Management Office and other business units within the organisation that is deemed fit.

Not to mention, there is a possibility that clients insist on a waterfall contract as compared to an Agile contract. Studies indicate that more than seventy per cent of existing contracts between organisations are still based on waterfall contracts as compared to agile contracts [16].

Not all of these units were consulted when the contract was drafted. Miscommunication and expectations across these business units start to emerge when the contract has been finalised, signed and handed over to the respective stakeholders in these units. Applying Emergency Procedure might trigger some clauses to the organisations and in turn, cause a ripple effect.

It is hence important to continuously engage with stakeholders by involving them from the start to create a common understanding of what is required, what can be done and negotiable so that no one feels short-changed and start pointing fingers at individuals or groups of people [17].

Lack of Transparency and Trust

One of the cornerstones for effective Scrum to take place is to understand the three pillars of Scrum — Transparency, Inspection and Adaptation. Not many people know these important pillars. These pillars create the stage of how a Scrum Team behaves in an environment. Everyone in the Scrum Team needs to be open, feel safe and be willing to share information with each other. Information can be good or bad for the team, must be shared with the team for awareness and if need be, create necessary actions (Emergency Procedure).

Without transparency, it can be challenging for anyone including the Scrum Team to know what they need to focus on and re-prioritise (if any). Scrum Team members will be clueless about what they are doing, why they are doing and the value it can bring to the stakeholders.

Employees from younger generations are increasingly getting involved and changing the way of working and at times, challenging the working culture in the workspace. Such examples include questioning the intent, what value the products they are delivering (building) brings to the targeted audience. This mindset and thinking are different from the older generations whereby they follow and do based on the instructions provided, without questions asked [18].

Additionally, Scrum Masters and/or Product Owners will need to be mindful of the need to be culturally sensitive if their team members come from different cultural backgrounds (environment), team size, the working environment and other hygiene factors [19].

Scrum Team’s understanding of Emergency Procedure

This challenge can also be related to Challenge ©, Too many priorities or (of everything), whereby creating an Emergency Procedure might be meaningless if the Scrum Team is constantly “firefighting” on what the priorities are even for an upcoming Sprint. Scrum Team members might not appreciate the value of Emergency Procedure and how it can help the team.

It is also important to take note and understand the environment the Scrum Team is working in.

Are they working to meet tight deadlines? Are there a handful of unexpected requirements within a short time to get them delivered? Is the environment of the Scrum Team in a constant fight over task or topic priorities?

Perhaps these need to be addressed before considering doing Emergency Procedure might be a better (viable) option.

Recommendations

The recommendations in this section are no means of silver bullets in nature. Rather, this section is to list out possible solutions based on the challenges mentioned above. In addition, the proposed recommendations are not in any way exhaustive in nature.

We recognise every organisation has its own challenges and no two organisations work identically. One will need to exercise due diligence and consider the working environments in the workplace when creating solutions after reading the recommendation section below.

Creating Alignment

“Know your team members first and understand who they are. There is a saying in Sun Tzu’s book — know the enemy and know yourself in a hundred battles and you will never be in peril. This is still relevant and applicable today. Individuals need to understand who they are working with, their thought process when solving a situation and even to an extent, challenge each other so that everyone can grow together. As a result, a relationship can blossom in the long run.”

Before applying Emergency Procedure, the Scrum Master can consider co-creating a “Designing Team Alliance”. Some might call this team’s agreement, team’s charter, gentlemen’s agreement or any term that best resonates with the team. In this artefact, team members can consider setting up the culture, environment, way of working and approaches when a situation gets messy and how best the team can move things forward. Studies have shown that younger employees are looking for opportunities where workplace (organisation) values are aligned to their personal values [20].

One of the topics which can be discussed when creating this artefact is to discuss scenarios where what the team can do when they are unable to meet the Sprint Goal and/or unable to deliver most of the features as initially estimated and, need to drop features (deliverables) that are less important at that point of time and etc. Scrum Master should share with the Scrum Team that while the Sprint Goal is something the team should strive to achieve, the Sprint Goal is one that was set prior to changes and events which had happened during the Sprint. Hence there would be a need to adjust accordingly so that the Scrum Team would be able to deliver maximum value to the customer.

A good Scrum Master uses a combination of soft and hard techniques when working with everyone and directs them to move towards a common goal.

Educate what Emergency Procedure is

Share with the Scrum Team the purpose/value of Emergency Procedure while working with Scrum Team to focus on delivering work with customer/business value. Customers might not appreciate it if the work done does not deliver the value needed when the Scrum Team is working on the current topic(s). Emergency Procedure is required to ensure that the value delivered is in line with what is required and would be appreciated by the end-user.

Scrum of Scrum

Scrum Masters must recognise the structure of the organisation where the respective Scrum Teams are working, especially in Multinational corporations (MNC) or heavily regulated and structured organisations. When working in such an establishment it is best to formalise documentation and/or process for escalation procedure with the turnaround time expectations from the approval committee or Project Sponsor coupled with allowing Scrum Master and/or Product Owner to have full and direct access to the top management for emergency approvals.

Build a common consensus on when to trigger Emergency Procedure

Decide the norm where Scrum Team is set to operate and define when to call for the Emergency Procedure with checks on hand. Also announcing to the Scrum Team that they are going to do the Emergency Procedure. Scrum Team should make sure that invoking Emergency Procedure is not easily decided and is the last resort of the Scrum Team.

The intent is to have Scrum Team operate a regular sprint; that the Team is working efficiently and effectively to deliver the Sprint Goal, ensuring the value is being delivered to the stakeholders or customers.

Having a clear definition of when the team is activating Emergency Procedures is important. An example would be if the Scrum Team can identify other ways (methods) for uncompleted work while reviewing the burndown chart, get help from other Scrum Teams and etc.

Take this scenario where the team will be doing some sort of refining and descoping due to some User Stories/ topics being obsolete. An urgent task has overtaken the planned topics. The Scrum Team might not always be comfortable with this episode, but at the end of the day, an increment or value is delivered to the customer.

Embracing Scrum Values and Agile Principles

It is important that a Scrum Team needs to be of a certain level of maturity in embracing Scrum Values and Agile Principles for Emergency Procedure to work effectively. Therefore, Scrum Master focus is to instil this mindset within the team such that they can respond in an effective way to changing situations without reliance on either Scrum Master or management.

In addition, a highly effective team can also inspect and adapt the measures to respond better to future scenarios, as part of the learning from executing the Emergency Procedure.

Self-Assessment Checklist

The questions in the checklist help you to understand the state of the team you are working with. There are a total of three sections: (A) Understand if Scrum Team is ready, (B) Identify if Emergency Procedure is required and © Follow up after invoking Emergency Procedure.

Go through all the questions in all sections and tick the responses which best represents your team/situation. After having assessed your team/situation, read the recommended actions based on the answers you fill up and assess if they are suitable to be implemented. This also includes creating your own questions and coming out with appropriate actions.

A. Understand if Scrum Team is ready

Scrum Team’s ability to conduct Emergency Procedure should be assessed to understand if they are ready to conduct Emergency Procedure. Consider the following statements and tick accordingly to how you would feel about the statements:

If you tick with at least three statements (either Agree and/or Strongly Agree), congratulations! The Scrum Team is ready to conduct Emergency Procedure.

Note: Having Emergency Procedure too often (i.e; every Sprint for the past 3 Sprints) is an indicator that the Scrum Team’s understanding of Scrum might be wrong or the environment might not be appropriate for Scrum. For Scrum Team(s) who are new to Scrum, it is normal for the team to be unable to meet the committed work at the start of the Sprint. Generally, it takes about 3 to 4 Sprints for the Scrum Team to stabilise on how much work the team can undertake into the Sprint and the use of Emergency Procedure might not be appropriate.

If you disagree and/or strongly disagree with at least one statement (Disagree/Strongly Disagree), the Scrum Team is unlikely to be ready to conduct Emergency Procedure. We would like to encourage you to think about what could be the reason. Identify the cause and find ways to address it before invoking the Emergency Procedure.

If you have any statement(s) with a “Neutral” rating, we would encourage you on what supports this rating e.g, do you need more data points, is the rating based on your quick assessment without thinking etc. Note: It could be a mixture of agreements and disagreement and hence, neutral would be more appropriate.

In the event, that your assessment does not coincide with the statements stated above, do evaluate and work accordingly based on what would be suitable for your Scrum Team.

B. Identify if Emergency Procedure is required

Something occurred in the current Sprint. You wonder whether Emergency Procedure needs to be triggered. Below are a few statements you can reflect on.

If you agree or strongly agree with any of the problem statements mentioned above, we would encourage you to undertake the first step. This is change the way the team does the work. Do something different. If the Scrum Team performed this and Scrum Team is unable to complete the work, the next option is to get help. This is performed by offloading the backlog to another Scrum Team. The next course of action will be reducing the Scope. In the event the Scrum Team is unable to complete the work after using the three options mentioned above, the next course of action is to abort the Sprint and replan. If this is performed and Scrum Team is unable to complete (deliver) in the new Sprint, the next step is to inform management how Emergency Procedure affects the release dates.

All these steps are done in sequential with changing the way the Scrum Team works as the first step and informing management (stakeholders) on how Emergency Procedure affects the release dates.

If you disagree and/or strongly disagree with all four statements, your Sprint is most likely to be on the right track and Emergency Procedure is not necessary.

If your assessments do not coincide with the scenarios stated above, do evaluate and work accordingly based on what would be suitable for your Scrum Team.

C. Follow-up after invoking Emergency Procedure

To minimise the occurrence of Emergency Procedure on a regular basis, reflect on what had caused the Emergency Procedure as well as what happened during the Emergency Procedure.

Follow-up by checking if:

Scrum Team is going to discuss during the Sprint Retrospective improvements which can be made from Emergency Procedure.
The root cause(s) of why Emergency Procedure had to be triggered has been established.
The follow-up solution is actionable. Scrum Team is able to start to work on it and if need be, allow iterations.
The actionable item has been created and added to the next Sprint Backlog.

It is important to discuss what caused Scrum Team to invoke Emergency Procedure during Sprint Retrospective so that everyone can have a proper discussion, align their understanding and how best the team can work together. This way of working is one way for Scrum Team to constantly improve to be an awesome Scrum Team.

We would recommend considering the following statements after conducting the Emergency Procedure several times.

If you agree and/or strongly agree with at least two statements, we would recommend that you find out the main cause of having multiple occurrences of Emergency Procedure.

If you agree and/or strongly agree with less than two statements, we would recommend the re-evaluation of how Emergency Procedure is conducted and improved so that the Scrum Team can better accelerate and deliver value.

Our Experience

In this section, we will be sharing our experiences. These experiences are not limited to referencing to trigger Emergency Procedure but also includes our real-life experiences when not executing Emergency Procedure.

“The Scrum Team was small, hence, everyone needed to take on a bit of extra work here and there, such as doing procurement and administrative work. At first, this additional work seemed small and could be handled while we worked towards our Sprint Goal. Small changes to the scope of these tasks seemed fine initially, for example instead of receiving guidance from others on how to do it, we would learn to do it all on our own.

However, when accumulated, these overloaded the team and had caused deviations from the Sprint Goal. These were only realised during the Sprint Review, when the team reviewed what had been done.

During the Sprint, when technical spikes revealed that the ticket was a lot bigger than estimated, this would be raised to the Product Owner. The Product Owner said it’s ok to just carry over the ticket over to the next sprint, as it wouldn’t affect delivery of the Sprint Goal. The idea of ‘so long the customer is king’, and that ‘so long as we can catch up later with the plan’ resulted in Emergency Procedure not being applied, and disregarded.” — Zhi Lin

“Team culture is ‘Too Asian and Too Tactful’, thus, does not apply Emergency Procedure. Team is worried the member producing the problem will face a penalty or ‘lose face’. As a result, my Project has been extended for the third-time and impacted the cost of the project.

I was in a project where the developers are vendors, while the Product Owner and Scrum Master are from the clients. Due to the lack of technical expertise on the solution or software knowledge, the customers were not able to get vendors to admit that the sprint is likely to fail meeting Sprint Goal. Emergency Procedure could not be initiated. Actual Project period has become 3 times of the original project period, and so is the project cost” — BeeTin

“In 2021, my team was working on a feature and there were two problems we faced. In the beginning, the planning and implementation were smooth. Until we noticed the scope is too large and we lacked resources due to the festive seasons.

During the sprint review, the scrum team decided to initiate the Emergency Procedure to resolve the problems. The Scrum team discussed rescoping the feature and managed the team members’ availability for December. In the end, the Scrum Team managed to continue building the Minimum Viable Product (MVP) version before the production release.” — Jeanice

“The Scrum Team I am working with is interesting. Interesting in a way that they have experience in their field, but do not have any working experience working in a Scrum Team. This barrier is something that needs to be resolved first as they previously worked in a waterfall/ SDLC environment. Everything is pre-planned beforehand and they follow accordingly.

I need to slowly teach them what Emergency Procedure is and how it works, while educating and guiding them on Scrum framework. Reducing scope is something sensitive, as it gives the impression that they are slow in delivering the deliverables, and looks bad on them. One approach I made was to make myself accountable for any backlash, or if the situation heads downwards in the event the stakeholder is unhappy with the decision made. This approach helps me to open up to the team, and we embrace failure as learning and walking the talk. This takes time as it requires a change in mindset and educating the stakeholder, and not just the Scrum Team.” — Adrian

“While my team was in the middle of the Sprint, we were interrupted suddenly when the product management realised that they missed a certification event less than one month later. If we achieved the certification, we would be the first in the industry to do so, which will further boost our branding. Fortunately, in addition to being a high performing and self-managing team, the team also embraced one of the Agile Principles — ‘ Welcome Changing Requirements Even Late in the Project’ in allowing change to the middle of the Sprint.

After evaluating and understanding the value of this certification to be the top priority, the team immediately started to re-plan what needs to be done, starting with the first steps. Due to time constraints, and with the team open to new ideas, they adopted my suggestion of using Kanban with no estimates, adding tasks daily with the goal of certification at the back of our minds. We were thankful that management understood that there is no point in providing them story points if we could not achieve it.

In the end, we managed to achieve the certification, which I felt cannot be achieved if the team was not open to adopting a different approach. However, we did not just stop there. We held a retrospective on how this can be prevented — took steps to subscribe to the certification body and set reminders to check on any future such events coming up. When executing Emergency Procedure, in addition to responding to the situation, we should also inspect and improve the processes, preventing the need for Emergency Procedure for similar situations in future.” — Aloysius

“I’ve been working as a coach for multiple Scrum Teams in an organisation that does not have extensive Scrum experience, including myself. What can be seen on a quick look at the teams is that they are doing the events or ceremonies as the Scrum Guide prescribes, i.e. Sprint Planning, Daily Stand-up, Retrospectives. Yet, the teams are doing it just for the sake of satisfying the Scrum prescription.

What is not focused is the delivery of the actual value, the increment, the shippable outcome to the customer. When an outsider asks the people in the team if you are Agile, they can reply with a dry, straight tone, ‘Yes, we are?’ When you ask a follow-up question, ‘Does Agile really work?’ Often, if not always, you will get complaints both from the team and the stakeholders or ‘customers’.

From the Scrum Team you get the resentment, as they are expected to work more than 10 hours on weekdays, and sometimes weekends as well. The Scrum Team is expected to do more than they can handle in a Sprint.

While discussing with stakeholders, some of the not-so-good remarks are given.

Remark 1: ‘The team delivered more frequently now but with compromise on quality.’

Remark 2: ‘The lead time now, is much greater than before, doing scrum is clearly not working for us.’

Upon my encounter with the emergency procedure, I came to realise that this is what is missing to make Scrum Teams and stakeholders differentiate what is a normal episode, and what is not. What I have been seeing is that teams are being set in a firefighting mode, where being in a state of ‘doing the emergency procedure’ is the norm. As of this writing, I have yet to try it out to check with a team, and define when a Scrum Team is in the state of ‘emergency’ or otherwise.” — Kenneth

References

[1] J. Sutherland and J. Sutherland, Scrum: the art of doing twice the work in half the time. Currency, 2014.

[2] V. Eloranta, K. Koskimies, T. Mikkonen and J. Vuorinen, “Scrum Anti-Patterns — An Empirical Study,” 2013 20th Asia-Pacific Software Engineering Conference (APSEC), 2013, pp. 503–510, doi: 10.1109/APSEC.2013.72.

[3] J. Sutherland, N. Harrison and J. Riddle, “Teams That Finish Early Accelerate Faster: A Pattern Language for High Performing Scrum Teams,” 2014 47th Hawaii International Conference on System Sciences, 2014, pp. 4722–4728, doi: 10.1109/HICSS.2014.580.

[4] C. G. Worley and C. Jules, “COVID-19’s Uncomfortable Revelations About Agile and Sustainable Organizations in a VUCA World,” The Journal of Applied Behavioral Science, vol. 56, no. 3, pp. 279–283, 2020, doi: 10.1177/0021886320936263

[5] M. Pikkarainen and X. Wang, “An Investigation of Agility Issues in Scrum Teams Using Agility Indicators,” pp. 449–459, 2011, doi: 10.1007/978–1–4419–7355–9_38

[6] J. Dalton, “Agile Agreement,” in Great Big Agile: An OS for Agile Leaders, J. Dalton Ed. Berkeley, CA: Apress, 2019, pp. 113–115. doi: 10.1007/978–1–4842–4206–3_9

[7] H. Doshi. “The Three Pillars of Empiricism (Scrum).” https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum (accessed on 17 2022).

[8]J. Saint-Charles and P. Mongeau, “Different relationships for coping with ambiguity and uncertainty in organizations,” Social Networks, vol. 31, no. 1, pp. 33–39, 2009/01/01/ 2009, doi: 10.1016/j.socnet.2008.09.001

[9] G. Costa et al., “How Teams Learn Agility, a Beginner’s Guide for Software Development,” in Perspectives and Trends in Education and Technology, Singapore, A. Mesquita, A. Abreu, and J. V. Carvalho, Eds., 2022// 2022: Springer Singapore, pp. 133–143, doi: 10.1007/978–981–16–5063–5_11

[10] M. Leary, M. Terry, A. Allen, and E. Shonkoff, “The Concept of Ego Threat in Social and Personality Psychology: Is Ego Threat a Viable Scientific Construct?,” Personality and social psychology review : an official journal of the Society for Personality and Social Psychology, Inc, vol. 13, pp. 151–64, 08/01 2009, doi: 10.1177/1088868309342595.

[11] J. Sarkis, S. Talluri, and A. Gunasekaran, “A strategic model for agile virtual enterprise partner selection,” International Journal of Operations & Production Management, vol. 27, no. 11, pp. 1213–1234, 2007, doi: 10.1108/01443570710830601

[12] J. López-Martínez, R. Juárez-Ramírez, C. Huertas, S. Jiménez and C. Guerra-García, “Problems in the Adoption of Agile-Scrum Methodologies: A Systematic Literature Review,” 2016 4th International Conference in Software Engineering Research and Innovation (CONISOFT), 2016, pp. 141–148, doi: 10.1109/CONISOFT.2016.30.

[13] M. O. Ahmad, P. Kuvaja, M. Oivo and J. Markkula, “Transition of Software Maintenance Teams from Scrum to Kanban,” 2016 49th Hawaii International Conference on System Sciences (HICSS), 2016, pp. 5427–5436, doi: 10.1109/HICSS.2016.670.

[14] “Happiness Metrics.” https://medium.com/scrum-mastery/happiness-metrics-2fe2bf647d36 (accessed on 17 Jan 2022).

[15] J. Abdelnour-Nocera and H. Sharp, “Adopting Agile in a Large Organisation,” in Agile Processes in Software Engineering and Extreme Programming, Berlin, Heidelberg, P. Abrahamsson, R. Baskerville, K. Conboy, B. Fitzgerald, L. Morgan, and X. Wang, Eds., 2008/ 2008: Springer Berlin Heidelberg, pp. 42–52, doi: 10.1007/978–3–540–68255–4_5

[16] S. H. Zijdemans and C. J. Stettina, “Contracting in Agile Software Projects: State of Art and How to Understand It,” in Agile Processes in Software Engineering and Extreme Programming, Cham, G. Cantone and M. Marchesi, Eds., 2014// 2014: Springer International Publishing, pp. 78–93, doi: 10.1007/978–3–319–06862–6_6

[17] D. Jamieson, K. Vinsen and G. Callender, “Agile procurement to support agile software development,” INDIN ’05. 2005 3rd IEEE International Conference on Industrial Informatics, 2005., 2005, pp. 419–424, doi: 10.1109/INDIN.2005.1560413, doi: 10.1109/INDIN.2005.1560413.

[18 ]M. E. Moreira, “Reinventing HR for Agile,” in The Agile Enterprise: Building and Running Agile Organizations, M. E. Moreira Ed. Berkeley, CA: Apress, 2017, pp. 249–259, doi: 10.1007/978–1–4842–2391–8_21

[19] R. Sandstø and C. Reme-Ness, “Agile Practices and Impacts on Project Success,” Journal of Engineering, Project, and Production Management, vol. 11, no. 3, pp. 255–262, 2021, doi: 10.2478/jeppm-2021–0024

[20] E. Parry and P. Urwin, “Generational Differences in Work Values: A Review of Theory and Evidence,” International Journal of Management Reviews, vol. 13, no. 1, pp. 79–96, 2011, doi: 10.1111/j.1468–2370.2010.00285.x