#1-understanding-and-applying-scrum.md

Understanding and Applying Scrum

Empiricism

Manifesto for Agile Software Development

Principles

Twelve principles that we should follow:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility. → Kinda generic and ambiguous here ⚠️
10. Simplicity - the art of maximizing the amount of work not done - is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams. → Kinda generic and ambiguous here ⚠️
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. → We achieve this with retrospectives ✅

The Independent Signatories

while there is value in the items on the right, we value the items on the left more:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

The Three Pillars of Empiricism

Empiricism means working in a fact-based, experience-based, and evidence-based manner → Progress is based on observations of reality, not fictitious plans.

The three pillars of empiricism are as follows:

• Transparency: Is about presenting the facts as is → All people involved such as the customer, the CEO, individual contributors. They are transparent in their day-to-day dealings with others and all trust each other. No one has any hidden agenda.

• Inspection: Is an inspection by everyone on the Scrum Team. Some popular inspections fields: the product, processes, people aspects, practices, and continuous improvements → For example, the team openly and transparently shows the product at the end of each Sprint to the customer in order to gather valuable feedback. If the customer changes the requirements during inspection, the team does not complain but rather adapts by using this as an opportunity to collaborate with the customer to clarify the requirements and test out the new hypothesis.

• Adaptation: Is about continuous improvement, the ability to adapt based on the results of the inspection. Everyone must ask this question regularly: Are we better off than yesterday? → For example, for profit-based organizations, the value is represented in terms of profit that can be acquired via faster time to market, increased return on investment through value-based delivery, reduced total cost of ownership through enhanced software quality, and improved customer and employee satisfaction.

Scrum adheres to the underlying Agile principles of iterative, value-based incremental delivery by frequently gathering customer feedback and embracing change.

Empiricism is an Essential Element of Scrum

Thermostat → is an empirical device that it detects (inspects) the current temperature whether it is lower or higher than the set temperature, then it calls for the air conditioning to adjust (adapt) the current temperature to the set one, or do nothing if the current temperature is already matched with the set one. The inspection will happen again shortly.

⇒ Three things to have for making Empiricism work properly:

• The Goal has to be clear.
• Inspect and adapt frequently enough → Shorter sprints is prefered than longer sprints.
• Transparency → Understand correctly what is being inspected and adapted to.

An Introductory to Scrum: Empiricism

An overview of empiricism:

• The scrum team exercises the empirical feedback loop through the usage of scrum events.
• Transparent enables inspection.
• Inspect as frequent as possible to identify variances.
• Inspection enables adaptation.
• The adaptation must happen as soon as possible.

Transparency In the Trenches

What is Transparency?

In order to inspect things in scrum in order to make the adaptations we need to optimize the outcome of our work and the value of the product we work on effectively, the things that you do inspect has to be done transparently.

Questions that can help understand transparency:

• What are we looking at?
• What is going on?
• What is REALLY happening?

For example: Raise these questions about a challenge or opportunity that are surfaced in a scrum retrospective.

Transparency implies openness, communication, and accountability → easy for others to see what actions are performed.

This can be performed at the organization culture that people feel safe and trusted to share openly and honestly → Nimble has this ✅

Transparency is actually challenging to achieve. For example:

Case Study from the Trenches

A software-development company that setup all the teams and have all the tools needed and they still failed to deliver software to the market.

To analysize the situation, here were a few points discussed:

• "The mute button" creates a lot of tensions in distributed group discussions - when the project manager was asking questions, there was nothing in return.
• The scrum teams say nothing in public chat rooms (the organization), they create their own private chat rooms (the trenches) and discuss things there (confidentially) → The scrum teams use public methods doesn't feel safe to provide transparency there.
• The scrum master go into retrospective and rank each developer based on their story points delivered to help everyone understand individual performance and how to improve. The scrum master shared what everyone body should do to improve → it actually creates a challenging environment and mostly nobody say anything.

→ To solve this, we need to:

• Build projects around motivated individuals.

• Give them the environment and support the need, and trust them to get the job done.

• Creative workers should focus on trust first → interpersonal relationships can only be built when people actually meet each other face to face, meet, and shake hands, go for diner events.

• Professionally craft a healthy working agreement at the very beginning (as early as possible):

  • Job titles, politics, bias thinking, and criticism are left out of the room.
  • Confidentially, practices for obtaining consensus, be respectful of each others, promote openness and honesty are kept in the room.

  

• The company can offer nice webcams for each members after the face-to-face period of 2 weeks so they can make use of it at to their remote locations.

• Promote face-to-face interactions → respectfully request the remote developers to disable the mute button for a 15 minutes daily scrum → no more mute/camera disable button usage (ideally) + use tools that can support it during discussions (whiteboarding, conference calls, etc.).

• The executive leader can make an emotional and physical pled to gather everyone together and build the trust, even if it shows the vulnerability. For example: we have a true business crisis and urgency that we don't figure out a way to put our heads together to create value for our customers in an aggressive time, we are going out of business. I don't want that to happen, we have such smart people here, we have great idea, we are well-positioned in the market, but I am desperately needs your help and I'm willing to let my own guard down to do what I need to do as a leader to support you all. I am open to re-craft the way we work together.

4 level of trust to be built:

1. Leadership trusting their teams.
2. Team trusting leadership.
3. Team members trusting each other.
4. Trust yourself.

A sample of a correct retrospective:

1. Safety check: A questionnaire (5 levels) on how open you are willing to share openly in the retrospective (anonymously).
2. Storm the timeline of the sprint: can be done and updated frequently on the sprint timeline board with sticky notes on ideas (anonymously).
3. Promote anonymously transparency → Overtime, people will start getting more comfortable to share whose ideas are on the board.

Summary

• Promote transparency.
• Healthy transparency requires environment people feel safe.
• 4 level of trusts.
• Proximity → the value of face-to-face for people interpersonal relationships and building trusts.

QA

Some more good advice:

• Keep things confidentially until the group decides to change that level.
• Discuss and point the finger at the problem/issue/idea, not at the person/personality to remove the blaming.
• How to reward trust/transparency:
  • Extrinsic motivation → external rewards → not effective for complex and creative work.
  • Intrinsic motivation → the rewards came within himself/herself by doing something for someone else → create a subculture with a small group so the larger organization can see → For example. each person has $10 Starbucks cards → then let's say person A will reward another person B based on the transparency the person B can help the person A to learn and be better at → The peers in the group are rewarding each others.

So What is Agile Really About?

• Agile is a set of values and principles (Agile Manifesto)
• Agile is a way of developing software that reminds us that although computers run the code, it's people who create and maintain it (The Agile Samurai).
• Agile is the courage to be honest enough to admit that building software is complex and it can-t be perfectly planned since requirements change.

These 7 principles describe what Agile is really all about:

1. Delighting Clients - "Focus work on delighting the client"

• The purpose of work is to delight clients, not merely to produce goods or services or make money for shareholders.
• The key to an enduring future is to have a customer who is willing to buy goods and services both today and tomorrow. It's not about a transaction: it's about forging a relationship.

2. Self-Organizing Teams - "Do work through self-organizing teams"

• It's hard for those who have never been on a high performance team to understand just how cool it is.
• When working together with people who have different interpretations, perspectives, ways of solving problems, we are often able to solve problems that wouldn't be able to solve alone.
• A complex problem, like discovering ways to delight clients, is best solved by a cognitively diverse group of people that is given responsibility for solving the problem, self-organizes, and works together to solve it. → Kinda generic and board here ⚠️

3. Client-Driven Iterations - "Do work in client-driven iterations"

• Small client-driven iterations is easy to direct.
• Through client-driven iterations companies are able to keep inventory and work in process as small as possible and customize their product not only to meet the customer's original perceived needs but also to adjust it to meet any changes in those needs.
• Client-driven iterations improve productivity for the organization by focusing work on the elements that really add value and eliminating work that doesn't add value or unproductive planning time → This reduces risk by providing management not with unreliable progress reports, but with evidence of whether actual progress is made.

4. Delivering Value to Clients in Each Iteration - "Deliver value to clients in each iteration"

• Client-driven iterations (and Radical Management) imply a mental revolution, a different way of thinking about work. The key to success is delivering value to clients at the end of each iteration.
• A small thing delivered sooner can delight more than a big thing delivered later.
• The primary focus is on performing at a level of quality that delights clients and then provides that sooner.

5. Radical Transparency - "Be totally open about impediments to improvement"

• The truth will set you free. But first, it will piss you off.
• Achieving the complex goal of client delight requires total openness about any impediments to the work: everyone levels with everyone else.
• Radical Management accepts the inevitability of failure and puts arrangements in place to learn rapidly from failure and so progress toward success.

6. Continuous Self-Improvement - "Create a context for continuous self-improvement by the team"

• Is a deeply rooted set of values and attitudes focused on fixing problems as soon as they occur.
• Is fragile and therefore needs every day nurturing and attention.
• Is a top management responsibility.

7. Interactive Communication - "Interactively share stories, questions, conversations"

• The modern organization cannot be an organization of 'boss' and 'subordinate': it must be organized as a team of associates.
• Traditional managers speak to employees as employees, and power is the currency of communication.
• The Radical Manager communicates as one human being to another. Hierarchy is present but in the background.

Agile is constant change

Adaptation has many synonyms, of which 'change' is the most common → After a short time you and your team should reflect on what has happened, and how it affected the performance within the team. Building on the better understanding, the team should decide what they will do to enhance the good things, and remove the bad things – that is you should focus on changing the environment to be better.

Constant Continual Learning:

Common pitfalls:

1. Try to change too much.

• Limit the number of things that you are going to change.
• If it is a significant or challenging thing, then only take one action.
• Talk about this item in each Daily Scrum.

2. Don't see anything to change → There are two extremes for this mindset: being overwhelmed or not seeing any way that the team could work better.

• Focus on a clear vision.
• If the team have a common goal, then the current state can be compared with that goal, and then find the one change that will give the most benefit for the least effort.

3. The team is changing at a rate faster than the organization can accept → smaller teams (development and Scrum) gain the insight that agility is a continuous process and a mindset (not a state) while organizations and leaders think agile is a silver bullet, that gets invoked and that is all that is required.

• The organization needs to move to the mindset that things will be different, every day, every week → using a framework may help to provides the robustness needed to embed an enduring change.
• Use the phrase “for our team, we have found …” to describe your ways of working - regardless of what framework you started out with.

Scrum Values

The Scrum Values

There are 5 main values: Courage, Focus, Commitment, Respect, and Openness.

Updates to the Scrum Guide: The 5 Scrum Values Take Center Stage

Successful use of Scrum depends on people becoming more proficient in living these five values:

• People personally commit to achieving the goals of the Scrum Team.
• The Scrum Team members have courage to do the right thing and work on tough problems.
• Everyone focuses on the work of the Sprint.
• The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.
• Scrum Team members respect each other to be capable, independent people.

Examples of misunderstanding the values:

• Commitment: Committing to something that you don't understand because you are told to by your boss instead of committing yourself to the team and Sprint Goal.
• Focus: Focusing on keeping the customer happy instead of being focused on the Sprint and its goal.
• Openness: Telling everyone everything about all your work instead of highlighting when you have challenges and problems that are stopping you from success.
• Respect: Thinking you are helping the team by being a hero instead of helping people to learn the things that you are good at and not judging the things that others aren't good at.
• Courage: Even after the decision has been made continuing to push back instead of being transparent, but willing to change even if that means accepting that you are wrong, or that your opinion is not the direction that the team is going.

Five ideas for encouraging the values to be transparent and considered in your Scrum Team:

1. Put the values on a wall and have each team member write up how they are going to demonstrate the value in their working day.
2. Add a 'values moment' to your retrospective. This gives everyone an opportunity to inspect and adapt on their values.
3. Introduce a 'values' prize. Not a serious prize, but a fun prize that sometimes can be delivered to two people or the whole team when a value has been demonstrated and everyone is aware of it.
4. The 'whoops we dropped the value' prize provides a way of demonstrating courage, but also highlighting when we missed a value. Of course, this prize could end up being a very negative thing so it should always be delivered in a fun way without negative implications.
5. Getting external managers or stakeholders to demonstrate to the team a value and what it means to them.

Intralinks Case Study: Scrum Reboot, This Time with the Values

Overview

In their first attempt at attaining agility, Intralinks took a well-intentioned “mechanical” implementation of Scrum - done in good faith and with lots of hard work - but failed to deliver against their goal of greater agility. Their goals are:

• Increase product development scale
• Decrease lead times to delivering business value
• Improve quality
• Attract talent

→ They took on a “Scrum Reboot” and succeeded by augmenting the mechanics of Scrum with the fundamental idea of inspection and adaptation and the Scrum Values of Courage, Focus, Openness, Respect and Commitment. They made the Scrum Values real by focusing on 7 principles:

• Self-organization
• Team size and composition (7 +/- 2 team size)
• Done means done
• Empowered Product Owners
• Servant-leader Scrum Masters
• Scrum Team ownership for adaption
• The delivery of business value

Definition

Scrum is not a methodology. It is a lightweight framework that neither requires nor is necessarily incompatible with other tools, tactics, processes, and methods. This framework (the “easy to learn” part) will not deliver on its promise unless it is exercised with its core values (the “hard to do” part).

The importance of the Scrum Values:

• “When the values of commitment, courage, focus, openness, and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.”
• Commitment - “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.”
• Courage - "A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint ... This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration." → the team must have the courage to underwhelm, disappoint, or even upset stakeholders (openly and with respect of course).
• Focus - “The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet its Sprint Goal”.
• Openness - "The Scrum Master is responsible for ensuring Scrum is understood and enacted ... The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren't. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team." → In fact, managers are frequently ill-suited for the Scrum Masters role.
• Respect - "The Product Owner is the sole person responsible for managing the Product Backlog ... For the Product Owner to succeed, the entire organization must respect his or her decisions." → It takes tremendous maturity, and requires organizational backing at all levels.

How Intralinks failed

• Commitment - "We don't need no stinking Sprint Retrospective!" → When the team closed out their Sprint Retrospective and headed into Sprint Planning, they were taking on new work in their Sprint Backlog but not committing to improve how they worked due to the pressure to get work done → The value of the Sprint Retrospective was nominal that Inspect and adapt became inspect and complain, and then eventually inspection ceased entirely.
• Courage - "The Sprint Report?" → the team lacked courage so they set up the Sprint Review for success. The Sprint Review turned into a Sprint Report: here's how much work we did; here's what our burndown looked like; this is how many defects we found and fixed. The team took credit for having worked hard whether or not that hard work generated business value. Stakeholders stopped attending after a while. Remaining participants were managers instead of stakeholders.
• Focus - "Daily Scrum for everybody?" → The team lacking focus on the Daily Scrum. It moved around, it skipped some days. Project and program managers showed up because it was a convenient way to check in on the team's progress. The Scrum Master started to drive the meeting and instead of a half-circle around the Sprint board inspecting the work, it became a half-circle around the Scrum Master with rapid fire status reporting. Team members were engaged for the 45-60 seconds they spoke then they tuned out. Instead of epitomizing focus, the Daily Scrum became a 15-minute distraction.
• Openness - "The Scrum Manager?" → the manager-turned-Scrum-Master took on the new role in good faith, but it resulted in a lack of openness in the team. These upper managers had not had the same exposure to Scrum and still expected the Scrum Masters to manage the work. Put differently, they held the Scrum Masters accountable when the work wasn't happening the way it was expected to. So even if the Scrum Master was liked by the team and if behind closed doors the Scrum Master was reasonably good at being a servant-leader instead of a manager, the team closed up and put on a good face for the organization. They hid failures and therefore what should have been a self-organizing team lost the opportunity to improve.
• Respect - "The Product Steward?" → The Product Management was - as in many technology driven companies - very much a technical product management organization - responsibility for implementation, but very little business ownership. As a result, the Product Owners were given the title but remained in the service of the product as its steward rather than its owner. When the team came to the 'Product Steward' with an issue requiring a decision, he or she retreated into email, meetings, and conversations. More often than not the answer did not come back before the Sprint ended, if it came back at all. With the 'Product Steward' consistently unable to resolve issues in a timely manner, the team in some cases just stopped bothering to ask. The team perceived the Product Owner not having the respect of the organization, the team similarly lost respect for the Product Owner.

→ The values part is hard. It's not obvious how to get people to behave according to a set of values. The more you push values on someone the more likely they are to reject them. A coach shouting at the team: “commit to inspection and adaptation”; “have the courage to review the Sprint with transparency!”; “use the Daily Scrum to focus on the work in the Sprint, not your respective statuses!”; “be open about how hard it is to adopt Scrum with your Scrum Master!”; “respect the authority of the Product Owner even when the CEO barges in!” - is not likely to obtain good results.

The Reboot

Focus on Scrum principles - the hypothesis was that successful adherence to the principles would lead to adoption of the values.

The principles sit between the framework (a fairly 'hard' set of events, roles, and artifacts) and the values ('softer' behavioral attributes). For example, you can easily hold a Sprint Retrospective at the end of a Sprint in the appropriate time-box, but if the team does not take ownership of adaptation (as opposed to mere inspection) nothing will ever improve.

• Self-Organization - "The ability for a team to take on work, make a plan to complete the work, and execute that plan. It means that some people (managers) have to stop doing what previously defined them professionally, or that they need to do it as part of a team without the authority that organizational structure would have previously given them" → For Intralinks, this led to a genuine sense of ownership of the work and the team felt that it had the respect of the stakeholders. It evolved from a candy-coated progress report to a mutual commitment (team and stakeholders) to have a conversation about the business value of what was just delivered and what was planned next.

• Team Size and Composition - "Between 3 and 9 people, and consisting of all the skills necessary to do the work required of the team to produce done software." → If team size and/or composition is not right, something has to change. The change may be within the team's control (e.g., skills and training), but it may not (e.g., they need additional team members) in which case they bring the issue as an impediment that the Scrum Master can help remove.

• Done Means Done - "The team takes ownership of a specific Definition of Done and only shows work done in a Sprint that meets the definition" → For Intralinks, adhering to the principle of done means done meant a change in team composition through self-organization. Previously, separate automation testing, quality assurance, design resources were brought into the team. Defects that were discovered in-Sprint and deferred to a “hardening Sprint” were taken on immediately, and if not fixed by the end of the Sprint the work item was returned to the Product Backlog and not inspected at Sprint Review. Now, by adhering the principle, it reinforced the values of focus (on the Definition of Done), courage (to admit when work was not done), and respect (by refusing to waste stakeholder's time with unfinished work).

• Empowered Product Ownership - "An empowered Product Owner is one who can make decisions about the product. This enables teams to rapidly make decisions instead of having to wait for consensus, democratic decision-making, or the process to churn out signed off requirements. The Product Owner may represent the desires of a committee" → For Intralinks, the Product Owner role evolved from Product Steward to Product Owner. Stakeholders learned to respect the Product Owner and the Product Owner developed the courage to take ownership of the product.

• Scrum Master as the Servant-Leader - "The Scrum Master does not manage the team or the work. In fact, the Scrum Master shouldn't even manage the adherence to Scrum. Instead, the Scrum Master observes the team and reacts to deviance from the Scrum framework as an opportunity to ask the team why it's happening. Where the manager's instinct might be to correct deviation from a goal the moment it occurs, a Scrum Master may choose to see where it goes and give the team an opportunity to self-correct" → For Intralinks, instead of continuing to have “Scrum Manager” role, there was a newly courageous move to train in-the-trenches developers, have them obtain Professional Scrum Master I (PSM I) certification, and then take on the Scrum Master role. When the corresponding managers backed away, stopped managing the work, this demonstrated respect for the team. They served the teams by supporting improvement initiatives proposed by the team, for example addressing team composition changes or pursuing training/learning opportunities.

• Adaptation Requires Ownership - "The team owns the responsibility to improve based on empirical learning. Management may assess team performance and may be required to facilitate adaptation initiatives (e.g., provide budget for training, equipment, or increasing team capacity by adding members to the Development Team), but the team, by virtue of the principle of self-organization, is on the hook for coming up with improvement proposals." → For Intralinks, teams would maintain an explicit improvement backlog and took on at least one improvement backlog item per Sprint. This in turn promoted commitment by the team to improve, and openness by the team to speak constructively about what did not work well in the previous Sprint.

• Delivering Measurable Business Value - "When the backlog is refined and work is taken on in a Sprint Backlog, it must be accompanied by some hypothesis about the value it will deliver. This value must be expressed in a way that is quantifiably measurable after it is released, and tracking against that metric is required. Delivering measurable business value, is the most important one. However, that does not mean that you should prioritize it over the others but instead, you need to understand that adherence to the other principles combined makes the probability of successfully adhering to this principle much higher" → For Intralinks, this added a new responsibility for the Product Owner. Previously, backlog items were primarily features, and prioritization was primarily a war of opinion, and the Product Owner was on the receiving end. Now, the Product Owner had to justify priorities with hypotheses about net new business, increased adoption, improved positioning against specific competitive offerings, and/or cost savings. The Product Owner was not expected to accurately predict the outcome, but rather to make a case and provide a means by which the actual result could be measured against what had been forecast.

Results

For Intralinks, The Scrum Reboot has had successes with some teams and struggles with others. Adoption at the management tier similarly has peaks and troughs. But compared to the first attempt, the renewed effort is resulting in the expected benefits where real change is occurring:

• What once would have been one large project involving a complete re-implementation of the Intralinks Platform's UI has gone from a monolithic release plan to a rolling program releasing updates almost monthly.
• Accumulation of technical debt previously deferred to hardening phases has been eliminated.
• Sprint Planning has become the venue for the team and the team alone to take on and plan work to be completed in the Sprint.
• Large “Scrum Team” run by a single “Scrum Manager” was recomposed into two smaller teams (with designers integrated into the team) resulting in lower running costs and greater velocity.
• The teams nominated a “Done Champion” for the first few Sprints and committed to a Definition of Done that evolved from learnings in those Sprints.
• The Product Owner, while not particularly senior in the organization, is the undisputed decision-making unit with respect to the Product Backlog.
• The Scrum Masters (who are also Development Team members) are servant-leaders that are not responsible for managing the work, and do not have any direct reports on the teams.
• The Sprint Retrospective is held religiously and the teams maintain an improvement backlog that they act on every Sprint.
• The Sprint Review showcases done software. They are lively conversations with stakeholders, and are a transparent review of the anticipated business value.
• Post-release updates on business value metrics are shared with transparency, usually indicating positive adoption, but occasionally indicating a misfire, and resulting in de-investment where the hypothesis put forward by the Product Owner proved wrong.

→ For Intralinks, the key difference with the Scrum Reboot compared to their first attempt to adopt Scrum was to get to the Scrum Values.

What We Learned

• Scrum adoption is not only hard at first, it keeps on being hard.
• If it is easy, things change mostly on the surface but outcomes are the same.
• Scrum will simply give you a framework, principles, and values that make the hard work much more likely to result in positive business outcomes.

Visualizing Scrum Values

The exercise used is to rate yourself of against a list of questions, giving yourself 1 point for each question you agreed with and then mark result on a scale. Once completed you should end up with something like this:

Questions Used (Yes/No)

• Courage

  • I work on the next highest priority Product Backlog Item (I do not cherry pick the work I pick up in the Sprint)
  • If I see something that is wrong with what I'm being asked to do, I will say so.
  • I will question & reproach my team members if I feel that they are doing something wrong.
  • Regardless of the person talking, I will correct them if I believe that they are incorrect.
  • I will stand firm if I believe I am right, even if I'm in the minority within the group.

• Commitment

  • I always know what the sprint goal is and how my work supports it.
  • I do everything I can to ensure we achieve the goals of the sprint.
  • In my current team, I have never thought of taking a sick day to avoid going into work.
  • I always arrive on time for the events, my colleagues never have to wait for me to start the event.
  • I know what it means to say that an item is done, i.e. I know the criteria that meets our Definition of Done.

• Focus

  • Whilst working on a story I do not get distracted.
  • If I am not enjoying the work in a story I still give it the attention it needs.
  • When enjoying working on a story I will not over work a story just to prolong it.
  • I do not procrastinate when working on a story.
  • As soon as the story is ready to move into a new state, I will tell my colleagues and either hand it over or ensure that they know it is ready to pick up.

• Openness

  • I do not shy away from telling difficult news to team members and stakeholders
  • I do not hide away difficult issues in the hope that they will sort themselves out.
  • If something / someone is annoying me I will address it / tell them.
  • My colleagues can judge what state of mind I'm in, I can share my feelings with my them.
  • I always say the true state of an item, and do not over/under play it.

• Respect

  • I listen with equal intensity regardless of who is talking.
  • When listening to people I never talk over them.
  • I value everyone's opinion equally.
  • I am never concerned who works on what item in the backlog.
  • I feel that my opinion is respected and that I have an equal say in the team.

Next Steps

• Discuss the outliers, talk more freely with each other, and generally felt positive that we were open with each other.
• Look at where people recorded low against some key areas (Respect, Courage and Openness, etc.) then encourage improvements in these areas.

An Introductory Video Series to Scrum: Scrum Values

Remember:

• The values work hand-in-glove with each other → have Focus but without Commitment is pointless → need Courage to be Open → need Focus to Commit to one sprinkle at a time.
• Focus:
  • Teams work within the time box of each scrum event.
  • Focus on a single sprint goal per sprint, a single product goal at a time.
• Openness:
  • Everyone are open about work and challenges.
  • Individuals require to show vulnerability.
  • Trust each other to identify impediments as soon as they occur rather than fear of looking less able.
• Commitment:
  • Teams are a cross-functional effective collection of skilled equals → teams commit collectively → nobody commits on their behalf, especially external managers.
  • Team members commit to support to each others and the product, and perform to the best of their abilities.
• Courage:
  • Do right things (not the easiest things).
  • Challenge each others and their organization.
• Respect:
  • All team members respect their colleges and organization → zero hierarchy.
  • Accept that everybody's voice is equal.

Scrum Team

A Day in the Life of a Scrum Master

The Scrum Guide

The most obvious answer can be found in the Scrum Guide itself. It offers a clear description of the services a Scrum Master provides to the Developers, Product Owner and the organization:

• Coach the Development Team in self-organization and cross-functionality.
• Help the Product Owner finding techniques for effective Product Backlog management.
• Support the organization in its Scrum adoption.

Author's Personal Description as a Scrum Master

• Create successful teams with strong skills in self-organization and cross-functionality and a drive for continuous improvement.
• Support Product Owners in visualizing progress, creating a transparent Product Backlog and maximizing the value of the product.
• Help organizations by supporting management in changing processes, procedures, culture and behavior.
• Ensure the spirit of Scrum is truly understood.

Characteristics of a Great Scrum Master

A great Scrum Master:

• Ensures the entire team supports the chosen Scrum process;
• Manages the impediments that exceed the self-organizing capabilities of the team and it prevents them in achieving the Sprint Goal;
• Recognizes healthy team conflict and promotes constructive disagreement;
• Is prepared to be disruptive enough to enforce a change within the organization;
• Understands the power of self-management;
• Understands the value of a steady sprint rhythm and does everything to create and maintain it;
• Knows how to truly listen and is comfortable with silence;
• Understands the strength of coaching and has learned some powerful questions by heart;
• Teaches the Product Owner how to maximize ROI and meet objectives;
• Is also competent with XP, Kanban, and Lean.

Important Points

1. First of all, a Scrum Master should always prevent a fully booked schedule. Smart Scrum Masters has lots of free space in their agenda. The more the better.

2. As for a daily preparation, a Scrum Master could consider some example questions like:

• How is my Product Owner doing?
  • Is the Product Backlog in shape?
  • How is he/she managing the stakeholders?
  • What about delivering business value and return-on-investment?
• How is the Scrum Team doing?
  • Are they working together?
  • Is there conflict in the team, do they resolve that?
  • Is the team making decisions?
• How are our engineering practices doing?
  • Is the team caring and improving them?
  • How is the test automation?
  • Is the team expanding their Definition of Done?
• How is my organization doing?
  • Is there inter-team coordination?
  • What organizational impediments are in the way?
  • What about the HR practices?

A Typical Day of a Scrum Master

• Start the day with an open and curious mind (and in my case some good coffee).
• A good first question to consider is "How can I improve the life of the Scrum Team by facilitating creativity and empowerment?"
• Remember: your agenda is as good as empty! Except for the Daily Scrum and maybe some other Scrum events.
• You attend the Daily Scrum as an observer. You listen to what is and isn't being said.
• You consider some of the questions I've mentioned earlier.
• Based on your observations you determine your next steps. This might be coaching, consulting, teaching, facilitating, mentoring, managing, problem-solving, conflict navigating or... just sitting with the team, listening, and watching the team.
• Doing "nothing" is a perfect activity for a Scrum Master! The biggest pitfall for a Scrum Master is being too busy and not noticing what is really going on.

Why a Scrum Master Should Not Have Other Roles

Reasons:

• There can be conflicts of interests, for example:
  • You are working on an important lengthy scrum task and other developers might need your help urgently on developer-related responsibilities.
  • Product Owners are busy with stack holders, while Scrum Masters need to work with their development members.

Myth 8: The Scrum Master is a Junior Agile Coach

Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach. Simplicity is not only its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum.

The Myth - The Agile Coach tends to larger organizational issues while Scrum Masters focus on Scrum Teams

• Poor/incomplete understanding of what a Scrum Master actually does and should do according to the Scrum Framework.
• Position the Agile Coach as being higher in a traditional hierarchical structure: The Scrum Master as the junior, Agile Coach as the medior and the Enterprise Coach as the senior → easy to match with the organization's increasing hourly rates and expensive training programs.

The above myth leads to:

• Contradictions with the services these organizations provide: advising clients to think in 'horizontal structures' that promote the self-organizing capabilities of the teams, yet promote a 'vertical structure' because it works well from a commercial/marketing perspective.
• Artificial boundaries between what Scrum Masters and Agile Coaches do → The Scrum Master is only “allowed” to act on team level, which makes Scrum-friendly culture is far more difficult and harder to adapt. Meanwhile, the Agile Coach is expected to “implement” the necessary organizational changes, but fails because of limited experiences “from the trenches” and not knowing how to deal with “outside in” change management.

Busting the myth

It is actually remarkably easy, and requires only a simple reading of the Scrum Guide. → It offers a clear description of the services that a Scrum Master provides to the Development Team, the Product Owner and the entire organization.

The 8 Stances of a Scrum Master

The various responsibilities of the Scrum Master is captured in eight stances:

• An Impediment Remover that helps resolve issues that are blocking the team'''s progress, taking into account the self-organizing capabilities of the Development Team;
• A Facilitator that sets the stage and provides clear boundaries in which the team can collaborate. This includes facilitation of the Scrum events to ensure they'll achieve the desired outcome and - most importantly - that the empirical process is optimized;
• A Coach that helps individuals and groups to continuously improve in how they deliver valuable outcomes as a team or as an organization;
• A Teacher that ensures that Scrum and relevant techniques are well-understood and enacted;
• A Servant Leader that creates environments where teams can work effectively with stakeholders to create valuable outcomes;
• A Manager that is responsible for managing (true) impediments, eliminating waste, managing the process, managing the team's health, managing the boundaries of self-organization, and managing the culture;
• A Change Agent that helps to enable a culture in which Scrum Teams can flourish - on every level of the organization;
• A Mentor that transfers agile knowledge and experience to the team.

Dealing with "senior" challenges

“A good Scrum Master helps a Scrum Team survive in an organization's culture. A great Scrum Master helps change the culture so Scrum Teams can thrive.” - Geoff Watts → Being a Scrum Master means dealing with difficult challenges and influence the organization's culture in such a way that:

• Team success is valued over individual success;
• Continuous improvement and experimentation are promoted;
• “Agile contracts” are encouraged;
• Stable team composition is supported;
• Behavior is rewards, not individual achievements;

“The Scrum Master enables change from the inside out.” → The Scrum Masters help:

• Teams uncover the impediments that are holding them back and the other ways by which the organization can deliver (even) more value.
• HR departments find practices that are better aligned with Scrum.
• Sale departments move from 'fixed-price/fixed-scope'-contracts to contracts that are more Agile-friendly.
• Increase collaboration between Scrum Teams and stakeholders.

“The chances of successful Scrum adoption will increase drastically when you consider your Scrum Master as the true “inside out” change facilitators!” → Ignite the necessary organizational changes by influencing the system from the inside out with other Scrum Masters → a Change Facilitator.

“When organizations choose to work with Scrum, there should be no need for Agile Coaches.” → No need for Agile Coaches or other roles to help organizations generate valuable outcomes with Scrum.

Should we fire all Agile Coaches?

Not at all, as Scrum Masters use an “inside out” approach, Agile Coaches use an “outside in” approach.

• “inside out” approach drives organizational change.
• “outside in” approach can definitely work, but it's incredibly difficult because:
  • They are powerless to affect change and have a very superficial understanding of what goes on inside the Scrum Teams (where the value is being generated).
  • They are not part of the team, lack the necessary support from management and don't have the kind of extensive experience that is needed to drive change from “the outside in”.
  • They barely have experience with Scrum or as a Scrum Master.

“The reality is that most Agile Coaches are junior Scrum Masters.” → The advice for organizations is:

• Focus on enabling Scrum Masters to facilitate change from “the inside out”. Support the Scrum Masters in creating great teams that build awesome products. Help them build the experience and the toolkit to do this, together.
• Get rid of 'Seagull Coaches' that fly in, make a lot of noise, crap all over the place and fly on to a next customer, leaving a big mess behind;
• If you really want to hire an Agile Coach in addition to the Scrum Masters already present within the organization, make sure that they have real, proven experience in affecting change “outside-in”. Make sure they focus their efforts on helping the teams and the Scrum Masters drive change themselves.
• Don't create the artificial distinction between “change on the management level” (by Agile Coaches) and “change on the team level” (by Scrum Masters);

What if we use Kanban/XP/DevOps?

No matter what kind of framework or methodology you choose, it will involve organizational change to some degree.

“Organizational change should be driven from the inside-out by people that are truly part of the teams.”

The 2 Best Scrum Masters I Ever Worked With - The Master Of Coaching And Facilitation

Best Scrum Masters' traits:

• Excellent servant leaders who fostered self organization.
• Supported the Development Team and Product Owner.
• Guided their organizations on the path to agility.

For example Laurence - the second Scrum Master - has acting background. Then he used his skills as a trained actor to observe and learn the behavior and characteristics that made this Scrum Master effective → He "learnt" the role of the Scrum Master, just as he would as an actor learning any other role.

His strength was in his abilities as a coach and facilitator. When the Development Team approached him with an issue or impediment, rather then trying to solve it for them, he opened and facilitated discussions with the team and helped them find their own solutions.

Laurence knew he didn't have the best answers for all the issues as he had only 2 years IT experience → He had no choice but to help the team to find their own solutions. He wanted to be useful to them in this process so quickly learnt to ask the right questions and encourage the team to be open, confront the issue, explore options and then decide and fix on a course of action. He also encouraged frequent inspection and adaption to ensure the selected option was helping as planned. If a solution wasn't turning out to have the desired effect he would raise this to the team and challenge them to find another way forward → he became adept at helping the team find their own solutions and served as the conscience of the team.

The Truth About Job Titles in Scrum

Remember about the types of problems we are solving:

Inspection and adaptation requires flexibility:

Scrum provides a Great Framework for That:

Roles

Scrum describes 3 main roles (+1 extra):

• Product Owner - PO:
  • Maximize the value of the product and DT.
  • The sole person responsible for managing the product backlog.
  • Must be empowered to make decisions about the product.
  • No one else except PO is able to tell the development team what to do!
• Scrum Master - SM:
  • Promote and support Scrum usage.
  • Focus on transparency.
  • Is a servant leader - service to others, promote a sense of community, holistic approach to work, share decision-making power.
  • Serve the PO, DT and Organization.
• Development Team - DT (recognize to titles other than DT Member):
  • Self-organizing in pursuit of delivering value.
  • Cross-functional with all the skills necessary to deliver work.
  • Small enough to be nimble, large enough to deliver.
• Agile Leaders - AL (create the environment necessary for scrum and for agile to happen and there can be many types of leader):
  • Create environments for agility to flourish.
  • Manage impediments and problems.
  • Coach and support PO, SM and DT.

What about other roles (PM, Testers, BA, etc.)

Scrum does not really care about job titles. As a matter of fact, it need skills to deliver value and care about the outcome the team deliver, but it hard to just say "I want someone to do stuff and deliver" → roles are needed.

All different roles and teams needs to feel safe and valued.

Ultimately, here is the rub:

How to manage the rub:

• Separate work management from Talent/Skill/Job management.
• Incrementally transition to the 4 key roles: SM, DT Member, PO, Leader of xxx.
  • Names can be varied per organization.
  • Put in place a community/scaling/development structure that allows growth, promotion, and a career.

Self-Organize to Form Teams

What motivates people:

1. Autonomy
2. Mastery
3. Purpose

Form team naturally, guided by business goals:

• Who want changes (opt-in)
• Who want to work together (self-organization)
• Mutually-agreed commitments and decision processes (self-direction)

Break Away from Command and Control

• Boss trumps transparency
• Hard to balance the needs of today vs the future
• Scaling is about helping others, not managing
• Installing a learning culture requires an organization

What Shape Are Your Team Member Skills?

Communities Connect People Across Teams to Share and Improve

• Share experiences and grow skills via immersion and pairing
• Use peer coaching to share knowledge and increase professionalism + consistency
• Remove common impediments

The Famous Spotify Model

• Squad: similar to a Scrum Team
• Tribe: collection of Squads in a related area
• Chapter: a family of people inside a Tribe with similar skills
• Guild: a community of practice across Tribes.

Project Managers

In the end, find the role that makes the most sense for you:

• SM: If you are more about enabling flow, driving processes, helping others learn, removing impediments, and raising transparency.
• PO: If you are passionate about the solutions you provide, the problems that you solve, and the customer
• Technical: If you want to master and share a set of skills or technology.
• Leadership: If you want to glue together an organization, build an environment that supports agility, and delivering value.

Summary

• Job titles and specialism of labor don't connect with Scrum, but skills do.
• Focus on the 4 roles: SM, DT Member, PO, and Leadership.
• Everyone has to understand the customer → become more valuable.
• Decouple work vs people management.
• Build community around mastery and skills development → more people centric approach.
• Focus on learning rather than job title!

Part 8 An Introductory Video Series to Scrum: Accountabilities

• PO is accountable for the product value.
  • is one person.
  • be the single the source of truth.
  • makes decisions transparently.
  • can delegate work to others, but still hold accountability of that work delivery.
• SM is accountable for the effectiveness of the scrum framework.
  • is a true leader who serves the scrum team in the wider organization.
  • commonly seen as a coach, not boss.
• DT developers are accountable for creating the increment output.
  • collaborate through sprints.
  • each developer are equally accountable for the achievement of the sprint goal.
  • create a plan and adapt the sprint backlog everyday.
  • commit to conforming the DoD with quality.
  • hold each other accountable as professionals.

→ The accountability is a series of tasks and actions that are instrumental to deliver product value.

Scrum Events

A Typical Sprint, Play-by-Play

The first day: Sprint Planning

The whole team, including the Product Owner, meet on the first day of the Sprint and conduct a Sprint Planning session.

Preparation

• Ensure that the Product Backlog has been refined to an appropriate level of detail, with estimates and acceptance criteria - this is the purpose of Product Backlog Refinement.
• Product Owner should have ordered the work on the Product Backlog.
• The team should have an idea of their capacity for this Sprint, which is to say, how much work they believe they can take on.

First plan the value that will be delivered

• Each Sprint should result in a valuable increment of completed work, fit and ready for immediate release.
• The team work with to select which items from the Product Backlog should be worked on in a Sprint.

Be sure to agree a Sprint Goal

• This selection of work should be cohesive, and not just a grouping of unrelated and disparate items.
• A good Sprint Goal will allow the team to demonstrate focus and commitment, and allow collaboration and the re-planning of work so it is met.

Next plan how the work will be done

• The Product Owner should be available to answer any questions the team may have, and to provide any clarification that may be needed about the scope of the work.
• The team should have made a good forecast of the work that will be needed to meet the Sprint Goal and begin implementing the plan immediately and with a clear understanding – such as a Sprint Burndown - of how much work remains at any given point.

Each day, every day

• Each team member will collaborate with each other, as a team, to make sure that those tasks are completed.
• Be sure to keep the Scrum Task Board and the Sprint Burndown updated, so the information can be relied upon by others.

Hold a Daily Scrum

• It should never take more than 15 minutes.
• It is a time-boxed opportunity to re-plan the Sprint Backlog as a result of new discoveries and lessons learned during the Sprint.
• Each team member should be able to account for:
  • What they did yesterday to help the team meet the Sprint Goal
  • What they intend to do today to help the team meet the Sprint Goal
  • Any impediments which are getting in their way

Refine the Product Backlog

• Product Backlog Refinement is not a formal event but an ongoing activity.
• Refinement shouldn't take more than 10% of a team's total time during a Sprint. For example: half an hour a day, or an hour or two a couple of times a week, etc.
• The whole team, including the Product Owner, should participate.
• A refinement session typically begins with:
  • The Product Owner presenting the current Product Backlog to the team.
  • The team starts at the top of the Product Backlog and work their way downwards, refining each item in turn.
  • The team examines each one and discuss its scope, and the acceptance criteria that will be necessary for its completion → A large item may be broken down into smaller ones which capture greater detail. Epics may be decomposed into user stories, for example.
  • The team stops once the session's time-box runs out. They will recommence where they left off the next time, eventually starting at the top again so the backlog is kept up to date.

Always collaborate

• Each Development Team member must collaborate with his or her peers throughout the day, as they are jointly responsible for the progress of work.
• Examples of collaboration include:
  • Helping peers to complete work in progress before bringing in new work from a backlog
  • Pair programming, such as taking it in turns to use the keyboard and helping and checking each other's work
  • Peer review
  • Asking for help, and being keen to give it
  • Going to where the work is and helping, instead of waiting for work to be passed over to them
  • Making sure that all work does in fact meet the Definition of Done
  • Calling a Scrum in order to resolve problems which need the team's immediate attention
  • Raising impediments to the Scrum Master so they can be handled in a timely manner
  • Updating a Scrum Task board and burndown chart so that the information is up-to-date and can be relied on
  • Skill and knowledge sharing

The final day: Review and Retrospective

Hold a Sprint Review

• The Sprint Review looked at the Product and the value delivered, at the work which has been done, and honestly and candidly at any work which wasn't done, whatever the reason.
• If the Product Owner thinks it would be a good idea to invite stakeholders, then those invitations ought to have been sent.
• A Sprint Review is also an inspect-and-adapt opportunity → the Product Owner to explain how well the product is performing, to get feedback first-hand from any invited parties, and to draw any lessons which might be used to improve the Product Backlog further. If any work has not been completed, this will also be reviewed and re-estimated on the Product Backlog for possible planning into future sprints.

Then conduct a Sprint Retrospective

• A Retrospective considers the process which the team is following.
• It's generally best to hold the Retrospective immediately after the Review, because the former can introduce ideas for consideration in the latter.
• The whole Development Team, the Product Owner, and the Scrum Master must all attend the Retrospective.
• Can begin with: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
• In a “Retro”, everyone has an equal voice to identify:
  • Things which went well
  • Things which didn't go so well
  • Ideas for improvement
  • Shout-outs for team members who did something exceptional
• Establishing a timeline can help jog attendees' memories about significant events during the Sprint.

The Daily Scrum is NOT a Status Meeting

Daily Scrum vs Status Meeting:

• Daily Scrum:
  • Inspect progress towards the Sprint Goals to sync activities and create plan for next 24 hours by the DT.
  • 15 minutes time box everyday.
  • Promote self-organization - DT determines how to do tasks and owns the sprint backlog with accountability.
  • Maximize transparency which helps enable frequent inspection and adaption.
  • Focus on achieving valuable outcomes by identifying issues that slow down the progress and then adapting the plan.
  • Promote collaboration and have situation awareness -> a collaborative planning session.
• Status Meeting:
  • Team members come together and give updates on their progress to somebody else (who maintain a plan eg. PM, TL, Manager).
  • No self-organization and accountability, just plain reporting and decisions are made by somebody else.
  • May not get transparency with the full story about the progress and not emphasize the inspection and adaption cycle.
  • Focus on what tasks are being done and individual contributions.

Effective Sprint Planning

2-week sprint: the schedule should be around 4 hours. Popularly divided into 2 sections:

• What are we going to do in this sprint:
  • Take from the product backlog and move into the sprint.
  • DT will figure which items can be moved.
• How are we going to do it:
  • Visual the next steps by breaking product backlog items into sprint backlog items (smaller decomposed tasks and user stories)
  • Involve the PO for outstanding questions.
  • DT can have In-Progress and Done sections and see it updated daily.

Planning in Scrum

• "Plans are useless, planning is indispensable" → We knows that plan is going to change and we honor the agile value of adaptation.
• Planning is collaborative:
  • Sprint Planning event: The entire scrum team gets together for a collaborative negotiation to determine what is the valuable outcome (Sprint Goals) that we want to achieve for the Sprint. DT will create the sprint backlog items and plan how to deliver it.
  • Daily Scrum event: DT inspects their progress and adapts their plan to meet the sprinkles.
  • Sprint Review event: Gather the input needed to help plan the next sprint.
  • Sprint Retrospective event: enable and plan for continuous improvement on how the team work together (tools, interactions).
• DT owns the sprint backlog → DT is in the best position for perform planning.
• To reduce planning waste, keep the plan lightweight and minimize the time for analyzing things too far in the future/too fine in details.
• Accept the complexity and unpredictable nature of software development.
• Incorporate meaningful feedback every time we plan.

What is a Sprint Review

• 4 hour time box.
• To inspect the increment and adapt the product backlog to get closer the product goal.
• Stack holders are needed to play around on the product and then come up with new ideas on how to improve the product backlog → reach the product goal or get a jump in product value.
• It's a collaborative hands-on working session (not demo, formal presentation, acceptance meeting, etc.).

Why You Need a Retrospective Every Sprint

This questions are raised because:

• The Retrospective was boring.
• No value gained in the change in the process.
• We are adult, we only do it when we believe it is needed.

To be more professional and have continuous improvements (Football example) → need to reflect more frequently by thinking about when you need to:

• code and analyze how to test the program.
• maintain the product.
• introduce and take off the old technologies.

Scrum Artifacts

The Importance of Product Backlog Transparency

Product Backlog: make transparent all the work and express the values that we put into our product to all members.

Top items: highest priority work (highest in value to Stakeholders), set by the PM. PM needs to talk to all members to figure out the right orders.

Recommendation: Show the product backlog in sprint reviews as part of the inspection to figure out what is the best thing to do in the next sprint.

Myth: The Sprint Backlog can't change during the Sprint

"Changes are not allowed during the Sprint; no work can be added or removed". Why is this a myth?

Busting the Myth

"Although the Sprint Goal is fixed during the Sprint, the Sprint Backlog is not" → Even if that future is a single Sprint, it is entirely possible that new insights or impediments emerge as the Development Team works through the Sprint Backlog. For example:

• A team might learn that a technology they picked does not perform as expected.
• A key feature needed to reach the Sprint Goal was missed during the Sprint Planning. → As issues emerge, changes to the Sprint Backlog may be warranted in order to reach the Sprint Goal. In short; a Sprint Backlog is flexible, as long as changes do not distract from the focus on the Sprint Goal.

About Commitments and Forecasts

In the context of the Sprint Backlog, the word “commitment” was replaced by “forecast”. It describes the Sprint Backlog as a forecast by the Development Team about the functionality that will be part of the next Increment and the work needed to deliver that functionality into a “Done” Increment. This underscores that insights and unexpected issues are likely to emerge during development - even within a single Sprint.

However, commitment is still relevant for the Development Team; they commit themselves to:

• Fulfill the Sprint Goal.
• Delivering working, high-quality and usable software that meets the expectations of the customers and users.
• Working only on the Product Backlog items with the highest value.
• Focus on continuous improvement, learning, and technical excellence.
• Continuously inspect and adapt, by which empiricism is supported.
• Collaborate with all the business people involved.
• The values and elements that build up the Scrum framework. → The goal should be to reach the desired outcome (the Sprint Goal) with the least amount of output (Sprint Backlog).

Embrace the emerging nature of the Sprint Backlog:

• Encourage the Development Team to change, modify and improve the Sprint Backlog during the Sprint.
• If new work is required, the Development Team adds it to the Sprint Backlog.
• It's up to the Development Team to apply the changes and inform the Product Owner if this is considered necessary.

Sprint Goal

Myth: Having A Sprint Goal Is Optional In Scrum

Busting The Myth

"The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives” — Scrum Guide.

Three important purposes of Sprint Goals:

1. They give guidance during the Sprint on the objective that the Scrum Team wants to achieve in the Sprint, as well as why that is important.
2. They help the Development Team focus on what (kind of) work is important, and what is not.
3. They promote collaboration by giving DTs one clear purpose to work on, instead of separate initiatives.

→ Having a Sprint Goal is one of the rules of Scrum, as is having a shared understanding of “Done”. Neither are 'artifacts' according to the framework, but both are incredibly valuable to navigate complexity and all the potential confusion that entails.

What happens without Sprint Goals…

• A wide variety of items will be pulled from the Product Backlog during Sprint Planning.
• The Sprint Backlog is likely what Development Teams implicitly (or explicitly) commit to instead.
• With the pressured feeling to complete a Sprint Backlog full of unrelated items, there is no obvious incentive to collaborate.
• With everyone in the team working mostly on their own items, the Daily Scrum takes the form of a status update where members announce what they've been working on and what they plan to work on. You will hear more “I” than “We”.
• Members will complete 'all their work' at different moments during the Sprint.
• It is hard to know who to invite for the Sprint Review. Although some stakeholders may show up to inspect individual items implemented for them, they also have to sit through all the other items being discussed.
• The Development Team doesn't have guidance on how to decide where to invest time and what to let go (for now).
• It is hard to know when a Sprint is successful. There are hardly ever any opportunities to celebrate.
• Each Sprint implicitly has the same purpose: complete all the work. This makes all Sprints the same, and can make people (rightfully) complain that they are artificial.

→ Sprint Goals are intended to:

• Help organizations break free from the output-driven approach.
• Focus on efficiency and getting as much work done as possible.
• Focus on valuable outcomes and an experimental mindset.

Intermission: Examples of Sprint Goals

• Sprint 1: “This Sprint exists to set up our deployment infrastructure to deploy a secure, working login page”.

• Sprint 2: “This Sprint exists to use-test the interface for entering hours”

• Sprint 3: “This Sprint exists to allow flex agency employees to validate the hours submitted this week.”

Reasons for not having Sprint Goals

• Product Owners don't have the mandate to decide what goes on the Product Backlog and in what order.
• Product Owners don't have a vision or strategy for the product.
• Scrum Teams struggle with the formulation of objectives and Sprint Goals when their Product Backlogs span thousands of items.
• Scrum Teams may be too large, making stakeholders and the Product Owner scramble for enough work to keep everyone busy.
• Scrum Teams may work on different products or projects at the same time, making it hard to identify one singular goal for a Sprint.
• Sprints may be too short or too long, making it hard to define concrete, tangible Sprint Goal.
• Scrum Teams may be organized as 'component teams', working only on certain layers or components of the application (e.g. database, a specific web service or the UI).
• Some teams do work that is not suited to the time-boxed and purpose-driven nature of Sprints. For example, Support Teams that are responsible for many different products or services probably won't benefit from using Sprints as 'value-creation timeboxes'.

Tips

• Help Product Owners plan ahead by identifying potential objectives for upcoming Sprints.
• You can use the Liberating Structure Nine Whys during Sprint Planning to help Scrum Teams determine the purpose of the Sprint.
• Ask powerful questions to help Product Owners dig deeper into the “Why” of their decisions, like:
  • “If the entire Product Backlog was lost, what would be the first things you would bring back at this moment in time? Why?”
  • “What do you hope this objective makes possible for stakeholders or in this organization?”
  • “What opportunity would be lost if don't do this item this Sprint?”
• The Sprint Review offers potential objectives for the next Sprint(s) when you make good use of this event to gather feedback from stakeholders and to debrief together.
• Use a template to craft Sprint Goals, for example:
  • “This Sprint exists in order to…”
  • “This Sprint, we promise to…“
• Make your Sprint Goal transparent by hanging it in the room or putting it above the Sprint Backlog. A nice template for crafting Sprint Goal can be referred here.
• Begin each Scrum Event by stating the Sprint Goal.
• Don't worry if you can't relate all the items on a Sprint Backlog directly to the Sprint Goal.
• Find Sprint Goals that offer guidance during the Sprint and promote collaboration in your team.

Scrum from the Trenches - the Sprint Goal

Challenges with the Sprint Goal

• Challenge #1: There is no Sprint Goal

Tips to help improve this:

• Ask around and have a constructive conversation with the Scrum Team about why there is no Sprint Goal.

• Talk to the Product Owner (or if you are one, ask yourself this question): what is it that we want to achieve at the end of this Sprint?

• Be patient. Change takes time. Don't be hesitant to experiment. People are more eager to try something out and verify the outcome (experiment) than they are open to enforced changes from the outside.

• Challenge #2: The work is the Sprint Goal

  Tips:

  • Product Owners should share their vision and what goals need to be achieved next. They should talk about it, share it, get feedback on it.
  • Product Owners take the lead in Sprint Planning. And they should at first, but then they have to let the Developers self-manage how to achieve the Sprint Goal.

• Challenge #3: There is no room for anything else

  Potential problems:

  • The solution thought of turns out to be a lot harder to implement;
  • Production failures need fixing;
  • Danny (the guy everyone relies on) is ill (again!);
  • The Product Owner promised a particular stakeholder that he can get this last minute fix in the Sprint anyway.

  Tips:

  • Product Owners should share their vision and what goals need to be achieved next. They should talk about it, share it, get feedback on it.
  • Product Owners take the lead in Sprint Planning. And they should at first, but then they have to let the Developers self-manage how to achieve the Sprint Goal.

• Challenge #4: There is no focus on the Sprint Goal

  Tips:

  • Be transparent. Make sure the Sprint Goal is visible somewhere for everyone to see.
  • Talk about it. During Daily Scrum, make sure the Sprint Goal is the (only) topic of conversation.
  • Make sure Product Backlog Items on your Sprint relevant for the Sprint goal are on top and worked on first.

• Challenge #5: The goal is not a goal

  Tips:

  • Formulating the Sprint Goal as really technical or on the -how- axes may be caused by underlying aspects of the organizational culture.
  • Check if the accountabilities within the Scrum Team are not clear or not practiced.

Six Reasons Why You Need to Pay More Attention to the Sprint Goal

• Gives the Development Team some flexibility → If a team knows their Sprint Goal, they can regroup and achieve the Goal, even with less functionality than planned. For example for the goal - Implement the functionality for user registration, then at the end of the Sprint, the team realizes that they have no time for implementing the Restore Password feature. However, the goal can be achieved because the end users can sign up and create their profiles.

• Gives sense to the tasks and motivates the Team → People tend to be more enthusiastic and enjoy their work when they understand what it's for.

• Unites the Development Team → Team members need to work together as one instead of pursuing separate initiatives.

• Helps in managing risks → During the Sprint, the Development Team may implement prototypes in order to lower the risk of a worse decision.

• Helps with focus and making decisions → Let's imagine that during the Daily Scrum on the third day of Sprint, a developer says he found out how to fix a bug that the team couldn't reproduce over the last few weeks. However, the team reminds him that the bug has a lower priority than the tasks at hand. Moreover, it is not related to the current Sprint Goal, so it will be fixed during the next Sprint if the Product Owner puts it on top of the Product Backlog.

• Helps manage stakeholders' expectations → Stakeholders don't need to know all the details of the plan that the Scrum Team is working on during the Sprint. Often, the Sprint Goal is enough to satisfy their curiosity.

Getting to Done: Creating Good Sprint Goals

Here are 4 common problems with Sprint Goals and a few tips for improving them:

1. The Sprint Goal is too big:

• We are working on multiple unrelated projects or initiatives → When ordering Sprint Backlog in Sprint planning, consider both cohesion of the work and the top priority (singular) initiative.
• We try to encompass every Product Backlog Item (PBI) → This is the equivalent of not having a Sprint Goal at all. Take the time to do it properly.
• We think the team may not work as hard if the challenge isn't big enough → Trust team members to figure out if there can be more functionalities/improvements to be done.

2. The Sprint Goal is vague:

• During Sprint Planning, ask "how will we know if we have achieved the Sprint Goal?"

• Make the Sprint Goal measurable.

• Use a consensus technique to everyone's understanding and commitment to the Sprint Goal. This is also a way to help encourage team ownership.

  Some examples from Unclear Sprint Goal → Clearer Sprint Goal can be:

  • Enhance shopping cart functionality → Streamline the purchasing process to enable an increase in conversion rates.
  • Improve performance → Increase page load time by X%.
  • On-board new market segment → Enable new market segment to purchase Service Y.

3. The team doesn't pay attention to the Sprint Goal during the Sprint:

• Make it visible by:

  • Writing the Sprint Goal on or near the Scrum Board.
  • Making it large.
  • Using a color or border that stands out.

• Talk about progress towards the Sprint Goal in the Daily Scrum (can help improve team collaboration):

  • Make it part of the Daily Scrum.
  • Ask the team at the end of the Daily Scrum how they feel about the likelihood of achieving the Sprint Goal.

• Make the Sprint Goal a team measure and keep it visible in the team space:

  • Keep this information visible helps the team think about it.
  • Historical data and trends can be used for discussion in the Sprint Retrospective.
  • A word of caution: Achieving a Sprint Goal is pass/ fail, there is no such thing as 85% achieved.

4. The Sprint Goal doesn't feel meaningful:

• Make it business or user focused when possible → What will a user be able to do when we implement this feature?
• Make it focused on testing business assumptions and getting feedback → We do not know what users actually need or are willing to do (because even users don't know). Thus, a Product Owner needs early feedback to test assumptions regarding value to users.
• Make it focused on reducing risk → Proving out a technology or design is an important part of reducing risk. The earlier we change direction, the cheaper the cost of the change.

An Introductory Video Series to Scrum: Sprint Backlog and Sprint Goal

Sprint Backlog:

• Definition: A forecast created by DT in order to meet the sprinkles or sprint goal (this is done by the PM or TL in Nimble 🤔)
• Commitment: is the single Sprint Goal collaboratively defined in the sprint planning event.
• More things can be learned by the DT throughout the sprint, daily scrums, optional refinement, and feedback → adaption are necessary.
• Anyone who is working with the DT needs to know that planning can change and the DT will be transparent about the changes.
• The DT and PM may influence each other to change the product backlog and sprint backlog respectively → The DT doesn't have to change anything.

Sprint Goal:

• Focus: is the coherence the DT has committed to and worked to achieve as there can be different ways to achieve.
• Can be measured to have been met or not met.
• The DT needs to self-manage or reallocate during the sprint if the spring goal is in danger of not being met.
• Not everything in the sprint backlog contributes towards a sprint goal. (small pieces of work that just need to be completed)
• Sprint goal won't change even if the DT learns something that the work turns out to be different than expected i.e. emerged critical work (support queries, major incidents).
• When the sprint goal is obsolete, the PM will make the decision to cancel → The scrum team immediately move into sprint planning and restart the sprint with a new goal.

Done

Getting Started with a Definition of Done (DoD)

Definition of Done:

• Provides a shared understanding of work completed in the Increment.
• Product Backlog items must meet Definition of Done to be released or presented at Sprint Review.
• Items that don't meet Definition of Done return to Product Backlog for future consideration.

The DT needs to:

• Decide what Done means within the organizational context and the product domain.
• Sit down and create a list of things that must be true for every Increment of software that they deliver.

What is a Definition of Done (DoD)

Here are some characteristics of a Definition of Done:

• A short, measurable checklist.
• Mirrors shippable. → While you might not have shipped your product, you should have that choice.
• No further work.

Tips: Get the Scrum Team (the PO, the DT, and any relevant Stakeholders) into a facilitated DoD Workshop.

My first Definition of Done (DoD)

Examples of things to put on your definition of done:

• Increment Passes SonarCube checks with no Critical errors → Work on improving it over time.
• Increment's Code Coverage stays the same or gets higher → Looking at a specific measure, like 90%, of code coverage.
• Increment meets agreed engineering standards → Decide rules for naming methods, tests, variables, and everything in between. (Compass)
• Acceptance Criteria for Increment pass → Recommended - automating them with ATDD practices.
• Acceptance Tests for Increment are Automated → Make sure that you automate all of your tests
• Security Checks Pass on Increment → Use an automated tool.
• Increment meets agreed UX standards → Can make use of Wiki.
• Increment meets agreed Architectural Guidelines → Can make use of Wiki.

Growing your Definition of Done (DoD)

Tips:

• Reflect on your Definition of Done on a regular cadence and should always check whether your DoD fits your needs.
• If a significant issue results in you not having working software, then you need to stop and fix it. (Such an event is called a Scrumble).
• If a non-significant issue exists, keep working and add what you need to your Product Backlog.

Walking Through a Definition of Done

“No book of mine is complete without a dog” - Peter Temple

The tyranny of work which is nearly done, but not really done, can put a team in servitude to technical debt. Team members are obliged to repay the “deficit for release” at compounding rates of interest, as it becomes harder and harder with each Sprint to bring that delinquent, half-finished work into a usable and releasable state.

DoD tips (applies to an increment)

1. Environments are prepared and checked for release:

• No unintegrated work in progress has been left in any development or staging environment.
• The continuous integration framework is verified and working, including regression tests and automated code reviews.
• All of the test data used to validate the features in the release has itself been validated.

2. Handover to support is complete:

• All design models and specifications, including user stories and tests, must be accepted by support personnel.
• Support personnel must also be satisfied that they are in competent control of the supporting environment.

3. Review ready:

• Sprint metrics ought to be available, including burn-down or burn-up charts.
• User stories which have not been completed ought to be re-estimated and returned to the Product Backlog.

4. Code Complete:

• All “To Do” annotations must have been resolved.
• The source code has been commented to the satisfaction of the Development Team.
• Source code should have been refactored to make it understandable, maintainable and better able to support future change.
• Unit test cases must have been designed for all of the features in development and allow requirements to be traced to the code implementation
• Code coverage should be known, and should meet or exceed the standard required.
• Unit test cases should have been executed and the increment proven to work as expected.
• Peer reviews ought to be done. (Note: If pair programming is used, a separate peer review session might not be required).
• Source code is checked into the configuration management system with appropriate, peer-reviewed comments added.
• Source code should have been merged with the main branch and the automatic deployment into elevated environments should be verified.

5. Test Complete:

• Functional testing should be done.
• A test report should have been generated.
• All outstanding defects (or incidents such as build issues) should be elicited and resolved, or accepted by the team as not being contra-indicative to release.
• Regression testing has been completed.
• The functionality provided in previous iterations has been shown to still work.
• Performance, security, and user acceptance testing should have been done.
• The product should be shown to work on all required platforms.

Deficits for a Release

"Done" criteria which are needed to effect a release, but which cannot yet be observed, constitute a deficit → they should be enumerated here (e.g. by moving them out of the Definition of Done).

"Better a little which is well done than a great deal imperfectly" - Plato

• Different teams, individuals, and consumers of the work (end-customers, business managers, etc.) in team have different ideas to what work completeness (coding UI, logic, etc.) means → DoD is the standard terms for everyone to refer to. Dod takes a incremental release of the project as close as possible to be potentially releasable, defined by the PM decisions and organizational standards (our Compass, or the client's constraints).
• Every time there is disparity in Done → create rework and wasted efforts.

Introductory Video Series to Scrum: Increment and Definition of Done

Increment points:

• are accumulative i.e. they are built on top of one another.
• is something done that is inspectable to determine whether the scrum team have moved further towards the product goal.
• presented at the sprint review as an artifact designed to elicit feedback and gather evidence for PO to make next focus decision.
• must be usable.
• can be deliver at any point of the sprint, not just sprint review (sprint review is not a roadblock preventing value delivered to stack holders)
• DoD is a formal description of the increment and therefore the product by Scrum team, and must follow the organization standards if any.
• include multiple product backlog items, formed a larger increment.
• can be referred to as a common language of inspection.
• product backlog items don't meet the DoD are return to the product backlog for later ordering and sizing.
• always pay attentions to the users' needs at all times.
• DoD is not fixed and evolved over time → as we gather more evidence about what is needed by our users.

Summary:

• Never say: "Let's release the project and take a risk" → less stable and harder to fix the product overtime.
• Treat DoD meaningfully and respectfully alongside your increments during sprint review.
• Show the outcome that development team delivered rather than simply the output (code implementation).

Scaling Scrum

The Nexus Guide

Nexus is a framework for developing and sustaining scaled product delivery initiatives. Scaled Scrum is still Scrum.

The Nexus Guide - 2021 (PDF English version):

The Nexus Guide (online English version): https://www.scrum.org/resources/online-nexus-guide

Takeaways

Nexus Definition

A Nexus:

• Is a group of approximately three to nine Scrum Teams that work together to deliver a single product.
• Has a single Product Owner who manages a single Product Backlog from which the Scrum Teams work.

A Nexus framework:

• defines the accountabilities, events, and artifacts that bind and weave together the work of the Scrum Teams in a Nexus.
• builds upon Scrum's foundation.

Nexus Theory

The goal of Nexus:

• Scale the value that a group of Scrum Teams, working on a single product, is able to deliver.
• Reduce the complexity that those teams encounter as they collaborate to deliver an integrated, valuable, useful product Increment at least once every Sprint.
• Reduce cross-team dependencies, preserving team self-management and transparency, and ensuring accountability often caused by:
  • Product structure: The degree to which different concerns are independently separated in the product.
  • Communication structure: delays in communication and feedback reduce the flow of work.
• Provide opportunities to change the process, product structure, and communication structure to reduce or remove these dependencies.

Note: Scaling the value that is delivered does not always require adding more people. Scaling-down, reducing the number of people who work on something, can be an important practice in delivering more value.

The Nexus Framework

Nexus extends Scrum in the following ways:

• Accountabilities: The Nexus Integration Team ensures that the Nexus delivers a valuable, useful Integrated Increment at least once every Sprint. The Nexus Integration Team consists of the Product Owner, a Scrum Master, and Nexus Integration Team Members.

• Events: Events are appended to, placed around, or replace regular Scrum events to augment them. As modified, they serve both the overall effort of all Scrum Teams in the Nexus, and each individual team. A Nexus Sprint Goal is the objective for the Sprint.

• Artifacts: All Scrum Teams use the same, single Product Backlog. As the Product Backlog items are refined and made ready, indicators of which team will most likely do the work inside a Sprint are made transparent. A Nexus Sprint Backlog exists to assist with transparency during the Sprint. The Integrated Increment represents the current sum of all integrated work completed by a Nexus.

Accountabilities in Nexus

In Nexus, an additional accountability is introduced, the Nexus Integration Team.

Nexus Integration Team

• Is accountable for ensuring that a done Integrated Increment (the combined work completed by a Nexus) is produced at least once a Sprint.
• Common activities the Nexus Integration Team: coaching, consulting, and highlighting awareness of dependencies and cross-team issues.
• The Nexus Integration Team consists of:
  • The Product Owner: A Nexus works off a single Product Backlog. The Product Owner is accountable for maximizing the value of the product and the work performed and integrated by the Scrum Teams in a Nexus and for effective Product Backlog management.
  • A Scrum Master: The Scrum Master in the Nexus Integration Team is accountable for ensuring the Nexus framework is understood and enacted as described in the Nexus Guide. This Scrum Master may also be a SM in one or more of the Scrum Teams in the Nexus.
  • One or more Nexus Integration Team Members: The Nexus Integration Team often consists of Scrum Team members who help the Scrum Teams to adopt tools and practices that contribute to the Scrum Teams’ ability to deliver a valuable and useful Integrated Increment that frequently meets the Definition of Done.

Nexus Events

Nexus events consist of:

• The Sprint - A Sprint in Nexus is the same as in Scrum.
• Cross-Team Refinement - of the Product Backlog at scale serves a dual purpose:
  • helps the Scrum Teams forecast which team will deliver which Product Backlog items.
  • identifies dependencies across those teams.
• Nexus Sprint Planning - results are:
  • a Nexus Sprint Goal that aligns with the Product Goal and describes the purpose that will be achieved by the Nexus during the Sprint.
  • a Sprint Goal for each Scrum Team that aligns with the Nexus Sprint Goal.
  • a single Nexus Sprint Backlog that represents the work of the Nexus toward the Nexus Sprint Goal and makes cross-team dependencies transparent.
  • A Sprint Backlog for each Scrum Team, which makes transparent the work they will do in support of the Nexus Sprint Goal.
• Nexus Daily Scrum - identify any integration issues and inspect progress toward the Nexus Sprint Goal. Cross-team communication can occur throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint's work.
• Nexus Sprint Review - is held at the end of the Sprint to provide feedback on the done Integrated Increment that the Nexus has built over the Sprint and determine future adaptations. A Nexus Sprint Review replaces individual Scrum Team Sprint Reviews.
• Nexus Sprint Retrospective - plan ways to increase quality and effectiveness across the whole Nexus, and concludes the Sprint.
• Nexus Artifacts and Commitments - Artifacts represent work or value, and each artifact contains a commitment:
  • Artifact: Product Backlog <-> Commitment: Product Goal - describes the future state of the product and serves as a long-term goal of the Nexus.
  • Artifact: Nexus Sprint Backlog <-> Commitment: Nexus Sprint Goal - is a single objective for the Nexus and is the sum of all the work and Sprint Goals of the Scrum Teams within the Nexus.
  • Artifact: Integrated Increment <-> Commitment: Definition of Done - defines the state of the integrated work when it meets the quality and measures required for the product and is done only when integrated, valuable, and usable.

Nexus Framework Poster

An Introduction to the Nexus Framework

The Nexus Framework Introduction - 2016 (PDF English version):

Takeaways

Definition: The Nexus framework is a foundation to plan, launch, scale and manage large product and software development initiatives.

The Nexus framework was created by Ken Schwaber, co-creator of the Scrum framework.

When multiple Scrum Teams are working on one product as it allows the teams to unify as one larger unit, a Nexus. It protects and strengthens the teams by creating connections between them and by maintaining bottom-up intelligence.

It is extremely useful for those struggling with a scaled initiative as the framework focuses rigorously on two core scaling matters: cross-team dependencies and integration issues.

The Nexus Integration Team (NIT) works off the Product Backlog and takes ownership of any integration issues. Integration includes resolving any technical and non-technical cross-team concerns.

A Nexus works within the boundaries of a Sprint (30 days or less).

To start a Nexus, organizations should first:

• Identify the teams in their Nexus.
• Form an initial Nexus Integration Team.
• Have a single Product Backlog.
• Have a definition of “Done”.
• Identify a Sprint cadence.

For larger initiatives you can form the Nexus+™ (using 10+ teams).

Avoid having dependencies across Nexuses by take advantage of the technologies or architectural patterns existing today.

Cross-Team Refinement in Nexus

Cross-Team Refinement in Nexus (PDF English version):

Takeaway

Cross-Team Refinement

Representatives from each team attend and should be selected and attend the workshop based on the work being refined.

In a Nexus, there are many Scrum Teams pulling work from a single Product Backlog; therefore, new Refinement questions need to be answered:

• Which teams pull what work?
• How can we best sequence the work, across Sprints and teams to balance early delivery of value against risk and complexity?

Which teams pull what work?

• Decompose and sequence Product Backlog Items:
  • The Product Owner should explain the PBIs to be refined.
  • Expect initial conversations to focus on the liquidity of skills. (e.g. which teams have the skills necessary to undertake what work.)

Figure 1:

How can we best sequence the work, across Sprints and teams to balance early delivery of value against risk and complexity?

• Visualize and Manage Dependencies - Categories for dependencies may include:
  • Build Sequence – An item cannot be completed until its parent is complete (can include technology, domain, software...).
  • People / Skills – Only certain people / teams can complete an item.
  • External – The parent item is being delivered outside the Nexus.

Figure 2:

Tips:

• At a minimum, consider identifying external dependencies with a color, and add additional color codes to denote common causes of dependencies in your organization e.g. Operations, Legal, DBA Team etc.
• Dependencies should be represented in the form of arrows (dependency arrows), because the direction of the arrows indicates parent to child relationships and their direction informs delivery risk. (e.g. Item number 8 depends on Item number 4.)
  • A dependency arrow that is horizontal represents a dependency within a single team across time.
  • A dependency arrow that is diagonal represents a dependency that is across teams and across time.
  • A dependency arrow that is across teams within a single Sprint is vertical.
• External Dependencies typically do not have an ID.
  • Downward facing diagonal dependency arrow is external across time.
  • Downward facing vertical dependency arrow is external and represents another in Sprint dependency.
• Once dependencies have been visualize:
  • Teams might move toward a model - a single team owns a feature from start to finish → Good for minimizing cross-team dependencies, bad as the model might cause delayed delivery.
  • Moving work between teams so that there are less cross-team dependencies.
  • Moving people between teams so that there are less cross-team dependencies.
  • Reshaping the work to eliminate dependencies.
  • Using different risk-based strategies, e.g., entirely remove an ‘in-Sprint’ cross-team dependency, front load all the risk as early as possible and take many cross-team in-Sprint dependencies in earlier Sprint.

Continuous Cross-Team Refinement

Cross-Team Refinement should be scheduled regularly for teams to discuss new items as well as for time to adjust the board as needed with any new information, e.g., using the Cross-Team Refinement board as a focal point (Figure 2), we can see that if Item 2 is not finished in the current Sprint, then it will move into the next Sprint. This slip will create an additional in-Sprint dependency between items 2 and 6 (Figure 3). We can see that there is already an in-Sprint dependency in the next Sprint between items 5 and 6.

Figure 3:

Cross-Team Refinement does not replace individual Scrum Team Product Backlog refinement.

Tracking Dependencies Over Time

• Use the number and type of dependencies as an improvement measure.
• Limit the number of dependencies they will accept, by limiting the number of arrows allowed e.g., we only have 10 dependency arrows to use when building the Cross-Team Refinement board. Once that limit is met, we cannot pull any more items with dependencies into the next 3 Sprints.

Cross-Team Refinement and Nexus Sprint Planning

• Take Cross-Team Refinement information into Nexus Sprint Planning for the teams to plan for the current Sprint and its dependencies.
• Use it as a focal point for daily cross-team synchronization about risk and progress during the Nexus Daily Scrum.

Visualizing the Nexus Sprint Backlog

Effective Nexus Sprint Planning occurs in 2 steps:

1. Each team in the Nexus selects their work for the Sprint. This is a collaborative activity with representation from each Scrum Team.
2. Each team performs their normal Sprint Planning process. This occurs per Scrum Team and can happen in parallel.

Representatives from each team can come together with the Product Owner to validate that the Sprint information is valid. If so, then the Nexus Sprint Backlog can be created using that information.

All work that has dependencies should be visualized on the Nexus Sprint Backlog as shown in the below Figure 1:

It shows in-Sprint dependencies between the teams during the Sprint:

• Product Backlog Item (PBI) 1, being delivered by Team B, depends on PBI 4, being delivered by Team A.
• Product Backlog Item (PBI) 3, being delivered by Team C, depends on PBI 8, being delivered by Team B.

It may be possible for work to begin on a dependent item before it becomes blocked by a dependency. For instance, in Figure 1, PBI 4 is “In Progress,” and PBI 1 is dependent on it being completed, as represented by an annotation dependency sticker. When Team A finishes Item 4, they should place it into “Done” and remove the annotation dependency sticker (e.g. the black stickie number 1). This is a rigger to remove Item 1 from the “Blocked” column. Team A can let Team B know that Item 1 is ready for them to continue working on.

→ During the Nexus Daily Scrum, the Nexus Sprint Backlog board is normally a focal point. If a Nexus does not have in-Sprint dependencies, as an alternative, teams may choose to represent the Nexus Sprint Backlog through the current Sprint column within the Cross-Team Refinement Board.

3 Ideas to Improve a Scaled Sprint Review

5 Characteristics of a Great Sprint Review:

• Stakeholders are difficult to recognize → they blend themselves between the Scrum Teams making it one big collaborating group of people.
• Every Developer Participates.
• Feedback. Feedback. Feedback → Everyone could actually use the product and share experiences and lessons learned.
• A Tailor-Made Sprint Review → A great Scrum Team continuously searches for the ideal format to gather feedback, e.g., sometimes using different market stalls for every team, sometimes a central demonstration & discussion, etc.
• Beer & Bitterballen → the follow-up Retrospective processes the Sprint Review and discuss possible improvements combined with beer & bitterballen.

Some pitfalls start to appear, for example:

• The Sprint Review becomes a Demo.
• Stakeholder abundance → this is not only time consuming, but it also doesn't add any value for the Scrum Team, who wants detailed feedback on their previous Sprint.
• Developers are not participating anymore.

⇒ Ideas for Experiments:

1. Organize a monthly demo besides the bi-weekly Sprint Review.
2. Organize "small circle" and " large circle" 2-part Sprint Reviews:

• Each team uses the first part of Sprint Review (say 40 minutes for a 2 week sprint worth of stories) to get detailed feedback from their own “small circle” of mandated users/accepters (a small group of 4-6 people) with whom the team and Product Owner works with closely for both Backlog and user story level refinement and acceptance.
• Then the teams proceed to the joint demo- the “ large circle” where each team presents a summary of the increment and its value (thus not the details per story) to the other teams and management/wider stakeholders.

3. Continuous-flow acceptance decoupled from Sprint Reviews:

• Make stories smaller, more vertical, etc, and consequently, they are getting good at getting valuable stories to "done" every few days.
• Embraced Getting Things Done and face-to-face collaboration to achieve this.

How Net Health Used Team Self-Selection to Reorganize Their Scaling Initiative

Why Net Health Implemented Scrum and Nexus:

3 Knobs to adjust and optimize outcomes of product development → Team optimization is the best choice:

Stakeholder Identified Constraints:

Nexus Member Card:

Key takeaways/tips:

• Prefer each individual to choose their Scrum Team instead of organizing teams around the work → Nexus supports this.
• Can add Business Analyst (BA) on Scrum Teams.
• Team formation: use Nexus Member Card per person (Name, Title, Team Constraint, Scrum Master status) → add the card a team board → check constraints (what needed to happen in a Nexus) → vote of confidence (Green, Yellow, Red).
• Encourage team members to grow and become Scrum Masters.
• Define team names, timeline of team formation, NIT presentation, and Q&A time.
• Team didn't want to be reorganized, felt conflicted from "top-down" organization and constraints.
• BAs could choose which Scrum Teams to join.
• People welcomed to switch teams to learn new things from different people.
• Focus on the benefit of Nexus when forming teams.
• Build trust between teams and their leaderships.
• Encourage teams to form different teams whenever the need is visible.
• Focus on simplicity (easy solutions) when dealing with scaled Scrums (Nexus).

The Nexus Framework for Scaling Scrum Book

2021 Nexus Guide-related changes:

• Development Teams is replaced with Scrum Teams. Any subsequent references to Development Team(s), or Development Team Members should also be replaced with Scrum Team(s) and Scrum Team Members.
• The artifact Product Goal is added.
• The heading Roles is changed to Accountabilities.
• The event Refinement is changed to Cross-Team Refinement.
• Development Team members on the Nexus Integration Team are now Nexus Integration Team Members.
• The Nexus Event Refinement is now Cross-Team Refinement.
• The Nexus Sprint Planning no longer prescribes how to plan. Instead, it says that the result of Nexus Sprint Planning is:
  • a Nexus Sprint Goal that aligns with the Product Goal and describes the purpose that will be achieved by the Nexus during the Sprint.
  • a Sprint Goal for each Scrum Team that aligns with the Nexus Sprint Goal
  • a single Nexus Sprint Backlog that represents the work of the Nexus toward the Nexus Sprint Goal and makes cross-team dependencies transparent.
  • A Sprint Backlog for each Scrum Team, which makes transparent the work they will do in support of the Nexus Sprint Goal.
• Nexus no longer prescribes how to run the Nexus Sprint Retrospective, nor does it prescribe which questions to ask to facilitate discussions.The practices mentioned here are now considered optional practices.
• Scrum now prefers the term self-managing over the term self-organizing. The same is true in Nexus.
• Nexus no longer prescribes specific practices for the Nexus Sprint Retrospective. The practices described here should be regarded as optional, complementary practices.