on Agile

Overcoming the Five Dysfunctions of a Team with Scrum and Agile

Mon, 31 Jul 2023 14:44:55 GMT

Patrick Lencioni, in his book “The Five Dysfunctions of a Team,” identifies the five issues that most often prevent teams from functioning effectively.

Absence of Trust

This is the foundation of Lencioni’s model. Without trust, team members are unlikely to feel safe enough to be open and honest with each other. This lack of trust can stem from a fear of being vulnerable with team members and can prevent the building of trust within the team.

Fear of Conflict

Teams that lack trust are incapable of engaging in unfiltered, passionate debate about key issues, causing situations where team conflict can easily turn into personal conflict. This can lead to a lack of respect and trust within the team.

Lack of Commitment

Without conflict, it is difficult for team members to commit to decisions, creating an environment where ambiguity prevails. Lack of direction and commitment can make employees feel detached from their responsibilities, which can negatively affect the overall performance of the team.

Avoidance of Accountability

When teams don’t commit to a clear plan of action, even the most focused and driven individuals hesitate to call their peers on actions and behaviors that may seem counterproductive to the overall good of the team.

Inattention to Results

The ultimate dysfunction of a team is the tendency of members to care about something other than the collective goals of the group. An excessive focus on personal success, status, and ego can become a distraction to the team’s overall success.

Scrum as a Model for Continuous Improvement

Scrum, as a framework, provides several tools and practices that can help teams improve by overcoming the five dysfunctions.

Absence of Trust

Scrum promotes transparency and frequent communication among team members. The Daily Scrum meetings, for instance, provide a platform for team members to discuss their progress and any challenges they might be facing. This regular communication helps build trust among team members.

Fear of Conflict

Scrum encourages healthy conflict in the form of constructive discussions and debates. The Sprint Retrospective is a key event where team members can openly discuss what worked well and what didn’t in the previous sprint. This encourages open dialogue and helps to resolve conflicts in a constructive manner.

Lack of Commitment

In Scrum, the team commits to a set of goals for each sprint during the Sprint Planning meeting. This commitment is not imposed by management but is instead a result of team consensus, which fosters a sense of ownership and commitment among team members.

Avoidance of Accountability

Scrum promotes accountability in several ways. For example, during the Daily Scrum, each team member updates the team on their progress, which creates a sense of personal accountability. Additionally, the Scrum Master role is designed to foster a sense of accountability within the team by removing obstacles and facilitating Scrum practices.

Inattention to Results

Scrum focuses on delivering value to the customer through the creation of a potentially shippable product increment at the end of each sprint. This focus on results is reinforced by the Sprint Review meeting, where the team inspects the increment and adapts the Product Backlog if necessary.

Scrum’s roles, events, and artifacts all work together to create a framework that promotes trust, healthy conflict, commitment, accountability, and attention to results.

The Scrum Values and Overcoming Dysfunction

The five Scrum values - commitment, courage, focus, openness, and respect - can be directly mapped to overcoming the five dysfunctions of a team. Here’s how:

Absense of Trust

Scrum Values

The Scrum value of Openness is key to overcoming this dysfunction. When team members are open about their work, their challenges, and their successes, it fosters a culture of trust. Openness in communication allows for transparency, which is the foundation of trust.

While openness is a key Scrum value to overcome the absence of trust, other Scrum values and principles from the Agile Manifesto can also contribute to building trust within a team:

Commitment

This value is about being dedicated to the team and the project. When team members show commitment to their tasks and to the team’s goals, it helps build trust among team members. They know they can rely on each other to do their part.

Courage

It takes courage to be transparent and honest, especially when things are not going well. This honesty, even in difficult times, can help build trust. It shows that team members are not hiding issues or challenges, but are willing to face them head-on.

Respect

Respect for each other’s skills, knowledge, and contribution is crucial for trust. When team members respect each other, they value each other’s input and trust each other’s decisions.

Focus

When the team is focused on the same goals, it helps build trust. It shows that everyone is working towards the same objectives and not pursuing their own agenda.

Agile Manifesto

Individuals and Interactions over Processes and Tools

Agile emphasizes the importance of human interactions. When team members interact effectively, it helps build relationships and trust.

Customer Collaboration over Contract Negotiation

When the team collaborates closely with the customer, it builds trust both within the team and with the customer. It shows that the team is not just interested in fulfilling a contract, but in delivering value to the customer.

Responding to Change over Following a Plan

Agile teams are adaptable and flexible. When team members show that they can adapt to changes and still deliver value, it helps build trust.

By focusing on these values and principles, teams can create an environment where trust thrives.

Fear of Conflict

Scrum Values

The Scrum value of Courage helps overcome this dysfunction. It takes courage to engage in constructive conflict and to voice differing opinions. Courage also means standing up for what is right for the product and the team, even if it leads to conflict.

Respect

Respect is crucial in managing conflict. When team members respect each other, they understand that differing opinions are not personal attacks, but are aimed at achieving the best possible outcome. This understanding can help reduce the fear of conflict.

Openness

Being open to feedback and differing opinions can help reduce the fear of conflict. When team members are open, they are not defensive about their ideas and are willing to consider other perspectives. ##### Commitment When team members are committed to the team and the project, they understand that conflict is sometimes necessary to achieve the best results. This understanding can help reduce the fear of conflict. #### Agile Manifesto ##### Individuals and Interactions over Processes and Tools This principle emphasizes the importance of human interactions. When team members interact effectively, they can manage conflict in a constructive manner. ##### Customer Collaboration over Contract Negotiation This principle encourages close collaboration with the customer. When the team and the customer work closely together, they can manage any conflicts that arise in a constructive manner. ##### Responding to Change over Following a Plan This principle emphasizes the importance of being adaptable and flexible. When team members are flexible, they can adapt to changes and manage any conflicts that arise from these changes.

By focusing on these values and principles, teams can create an environment where conflict is seen not as something to be feared, but as an opportunity for improvement and innovation.

Lack of Commitment

Scrum Values

The Scrum value of Commitment directly addresses this dysfunction. In Scrum, team members commit to achieving the team goals and delivering value to the customer. This commitment is not just about the work, but also about supporting each other as a team.

Focus

When the team is focused on the same goals, it helps build commitment. It shows that everyone is working towards the same objectives and not pursuing their own agenda.

Openness

Being open about the team’s progress, challenges, and successes can help build commitment. When team members are open, they understand the importance of their work and are more likely to commit to it.

Courage

It takes courage to commit to a goal, especially when it is challenging. Courage can help team members overcome their fears and commit to their tasks and the team’s goals.

Agile Manifesto

Working Software over Comprehensive Documentation

This principle emphasizes the importance of delivering working software. When team members see the results of their work, it can help build their commitment to the project.

Customer Collaboration over Contract Negotiation

This principle encourages close collaboration with the customer. When the team works closely with the customer, it can help build their commitment to delivering value to the customer.

Responding to Change over Following a Plan

This principle emphasizes the importance of being adaptable and flexible. When team members are flexible, they can adapt to changes and still commit to their tasks and the team’s goals.

By focusing on these values and principles, teams can create an environment where commitment is valued and encouraged.

Avoidance of Accountability

Scrum Values

The Scrum value of Respect can help overcome this dysfunction. When team members respect each other, they hold each other accountable for their work. They understand that everyone has a role to play in the team’s success and that each role is important.

Absolutely, let’s explore how Scrum values and Agile principles can help overcome the “Avoidance of Accountability”:

Commitment

When team members are committed to the team and the project, they are more likely to hold themselves and each other accountable. They understand the importance of their work and are committed to doing it well.

Courage

It takes courage to hold oneself and others accountable, especially when things are not going well. Courage is about being honest about the team’s progress and challenges and taking responsibility for addressing them.

Respect

When team members respect each other, they are more likely to hold each other accountable. They understand that everyone has a role to play in the team’s success and that each role is important.

Openness

Being open about the team’s progress, challenges, and successes can help foster a culture of accountability. When team members are open, they are not hiding issues or challenges, but are addressing them head-on.

Agile Manifesto

Individuals and Interactions over Processes and Tools

This principle emphasizes the importance of human interactions. When team members interact effectively, they can hold each other accountable in a constructive manner.

Working Software over Comprehensive Documentation

This principle emphasizes the importance of delivering working software. When team members see the results of their work, they are more likely to hold themselves accountable for it.

Customer Collaboration over Contract Negotiation

This principle encourages close collaboration with the customer. When the team works closely with the customer, they can hold each other accountable for delivering value to the customer.

By focusing on these values and principles, teams can create an environment where accountability is valued and encouraged.

Inattention to Results

Scrum Values

The Scrum value of Focus is key to overcoming this dysfunction. In Scrum, the team focuses on the sprint goals and on delivering a potentially shippable product increment at the end of each sprint. This focus on results ensures that everyone is working towards the same goal.

Commitment

When team members are committed to the team and the project, they are more likely to pay attention to the results. They understand the importance of their work and are committed to delivering value to the customer.

Openness

Being open about the team’s progress, challenges, and successes can help foster a focus on results. When team members are open, they are not hiding issues or challenges, but are addressing them head-on and learning from them.

Courage

It takes courage to focus on results, especially when things are not going well. Courage is about being honest about the team’s progress and challenges and taking responsibility for addressing them.

Agile Manifesto

Working Software over Comprehensive Documentation

This principle emphasizes the importance of delivering working software. When team members see the results of their work, they are more likely to focus on these results and strive to improve them.

Customer Collaboration over Contract Negotiation

This principle encourages close collaboration with the customer. When the team works closely with the customer, they can focus on delivering value to the customer, which is the ultimate result.

Responding to Change over Following a Plan

This principle emphasizes the importance of being adaptable and flexible. When team members are flexible, they can adapt to changes and still focus on delivering results.

By focusing on these values and principles, teams can create an environment where attention to results is valued and encouraged.

Scrum, Agile Testing and the Role of Quality

Sun, 09 Jul 2023 16:06:00 GMT

Designing Quality into the System

You cannot OBSERVE Quality into the system. We have done a continued disservice to our testing organizations by holding THEM responsible to determine the quality of the systems that we develop post development, rather than holding the development teams responsible for quality and correctness at the time of development.

If you are waiting to determine if you have quality in the system until after development, it is too late, and you have failed to create quality in the system. Our systems aren’t some quasi-Heisenberg Environment that will somehow change because we decide to observe them, so we must engineer quality as an asepct of our development processes, not our testing process.

How do we design quality into the system?

We can Design it with Strong, Emergent Architectures that are projected as code and built through automation
We can use SOLID Development Patterns that are unit tested, LINTed and Checked at the Pull request through Automation
We can ensure good Acceptance criteria that gets projected into good automated Acceptance testing and run through automation regularly.
We can use these patterns to Prove or Disprove correctness of function and the expression of our desired “–ilities”, which we’ll define shortly.

The Scrum Team

We know that a scrum team is:

Self-organizing
Cross-functional
Comprised of 3-9 members (recommended)
Without titles, other than “Developer” or "Team Member"
Without sub-teams (e.g. testing team, BA Teams, etc.)
Responsible for forecasting and planning the work to correctly transform PBIs into increments of releasable functionality every Sprint

They are Responsible for the “how”.

Because our team is cross-functional, they are responsible for HOW the work is done. This includes how we are going to develop it, test it, automate its delivery, and operate it in production. These are the questions the development team must ask itself as it refines each backlog item. Any gap in the answers indicates a lack of cross-functional ability on the team and/or a lack of understanding of the definition of done.

Collective Ownership

The developers collectively own several aspects of the development process, including:

Sizing
Sprint Backlog
Code
Writing Tests
Failing tests
Failing builds
Definition of Done
Failure
Success

In my post about The Definition of Ready, we determined that the development team collectively owns the implementation of the answer to the question “How will we test this?” AND the fixing of broken tests and code pursuant to that answer.

Agile Testing Manifesto

To build a more complex answer to the question, let's review the Agile manifesto, which is a set of value expressions to guide decisions within any agile process. If we extend that concept to our testing strategy, then we get something like the Agile Testing Manifesto.

The Agile Testing Manifesto represents a set of value expressions regarding our approach to testing as an agile team. It emphasizes:

Testing Throughout over Testing at the End
Preventing Bugs over Finding Bugs
Testing Understanding over Checking Functionality
Building the Best System over Breaking the System
Team responsibility for Quality over Tester Responsibility

What Next?

We have our questions, a strong team of developers, and a set of values. So what? What is the role of QA in this new paradigm? Before we can answer that, we need to better define the “Q” in Quality and put it in context with the Agile Team.

Redefining Quality in the Context of Agile

In agile, QA doesn’t go away, but the idea absolutely needs to be refined to fit our model. Starting with redefining “Quality” in the context of Agile. First of all, it’s important to point out that “Quality” is difficult to define and even more difficult to measure, because it will have a different definition and set of measures for each person that you ask.

Before we begin testing, it’s imperative for the organization to define what “Quality” means to the organization and specifically to the product or platform that is being developed. This definition can (and probably should) be inspected for adaptation each sprint through retrospection as it will impact our definitions of ready and done. Quality has many faces (different people define it differently, for their purposes) and is difficult to measure. It can be quantified through the expression of what, in scrum, we call the “–ilities”.

Non-Functional Requirements (NFRs)

First, I recognize that 1.) Not all of Non-Functional Requirement (NFR) words end in “-ility” and 2.) This is far from a complete list. Both the the Product Owner and the development team need to be asked “Which Quality Attributes Do you value and how will they be measured?", and the combination of answers helps us understand the shape of our strategy.

Testing Provides Proof of Quality

Testing does NOT need to be done, nor should it be frequently done, by a human. As a matter of fact, most human-centric testing is inefficient and a gross misuse of development resources. Humans work best when testing edge cases, doing discovery testing. If humans are bad at testing, then what is good? Automation. Humans write the automation that is run quickly, efficiently AND FREQUENTLY. Repeatable, refactorable, and fast, automated testing of all forms is the foundation of a good testing strategy.

So, in general, our testing must:

Make sure our code functions as designed (functional testing)
Make sure the code performs under production-like loads (performance testing)
Make sure the –ilities are fulfilled (non-functional testing)

Agile and Scrum are based on inspection and adaptation. Automated testing of all kinds provides a steady stream of continuous inspection that is usable by both the product owner and the development team to adapt the development to better describe the product goals. The smaller the changes and the faster the feedback cycles, the more accurate and the higher the potential quality of the increment delivered at the end of each iteration.

Agile Testing Quadrants

Different types of testing have different goals and motivations in the overall strategy, and not ALL types of testing are present in all facets of development. The intent, then, is to understand each feature or story enough to understand the question from the definition of ready “How are we going to test this?” such that it fulfills our strategy and our expression of quality.

Creating Coverage that Matters

The Goal is to create enough Testing Coverage of our system to ensure both high quality, and, more importantly, confidence in our ability to refactor, change and adjust based on our most recent observations. Some areas will have more or less total coverage, be subject to more stringent security and performance, or be less likely to come under automated UI testing. But each of those are choices that can only be reliably made in the presence of an understood strategy that is developed, expressed, and implemented by the team.

Who does What?

In the past, “Quality Assurance” or “QA” was typically defined as a team of people dedicated to manually executing test processes to check the correctness of the system when it was asserted to be “Dev Complete”. In this new Agile Paradigm, then, what is the role of the “QA” team? Agile and scrum assert a unified team of cross-functional people - no silos. No Hand offs (which are just mini-waterfalls), but a unified, collaborative approach to delivery. If that's the case, then we have developers who are testing focused, working with functional developers to insure correct testing strategy implementations across the architecture. This participation as development team members encourages good refinement and estiamtion of all of the work necessary to complete a backlog item, pair development throughout the process,and insures our definiiton of done includes appropriate testing at all levels.

QA Specialist Focused

Test Strategy Development
Acceptance Test Development
Automated UI Testing
Test Harness Specification
Exploratory Testing

Everyone

Unit Testing All New Code
Integration Testing at the Boundaries of the Application Layers
Performance Testing
Acceptance Test DSL Creation
Acceptance Test Code Implementation
Test Harness Development

On the teams we now have embedded testing professionals which allows for:

No testing Crunch
No Handovers
Localized Testing Expertise
Developers work on Test Automation Together

Managing Cognitive Load in Scrum Teams

Sat, 08 Jul 2023 21:03:00 GMT

Understanding Cognitive Load Theory

Cognitive Load Theory (CLT) is a concept that educational psychologists have developed to understand the load that performing a particular task places on a learner's cognitive system. The theory was developed by John Sweller in the late 1980s. The central tenet of CLT is that the quality of instructional design can be raised if greater consideration is given to the role and limitations of working memory.

Types of Cognitive Load

There are three types of cognitive load:

Intrinsic cognitive load: This is the effort associated with a specific topic. It cannot be altered by an instructor.
Extraneous cognitive load: This is generated by the manner in which information is presented to learners and is under the control of instructional designers. Extraneous cognitive load can be reduced by designing instructional materials that do not involve problem solving.
Germane cognitive load: This refers to the work put into creating a permanent store of knowledge, or schema. Instructional designers should aim to limit extraneous load and promote germane load.

Effects of Heavy Cognitive Load

Heavy cognitive load can have several potential effects on individuals and teams:

Decreased Productivity: When cognitive load is high, individuals may struggle to process information efficiently, leading to slower work rates and decreased productivity.
Increased Errors: High cognitive load can lead to increased errors as individuals may overlook details or make mistakes due to the overwhelming amount of information they are trying to process.
Burnout: Over time, consistently high cognitive load can lead to burnout. This is a state of chronic physical and emotional exhaustion, often accompanied by feelings of cynicism and detachment from work, as well as a sense of ineffectiveness and lack of accomplishment.
Impaired Decision-Making: High cognitive load can impair decision-making abilities. When the brain is overloaded with information, it can struggle to effectively weigh options and make sound decisions.
Reduced Creativity: High cognitive load can also stifle creativity. When the mind is preoccupied with processing a large amount of information, there is less mental energy available for creative thinking and problem-solving.
Poor Memory Retention: When cognitive load is high, individuals may struggle to retain new information. This is because the working memory has a limited capacity and can only hold a certain amount of information at once.
Impaired Learning: High cognitive load can interfere with learning. When the working memory is overloaded, it can be difficult to absorb new information and integrate it with existing knowledge.
Reduced Engagement and Satisfaction: High cognitive load can lead to reduced engagement and satisfaction at work. When work consistently demands a high level of cognitive effort, it can become exhausting and frustrating, leading to lower job satisfaction.

In the context of a Scrum team, these effects can lead to lower team performance and morale, and potentially result in higher turnover rates. Therefore, it's important for Scrum teams to be mindful of cognitive load and take steps to manage it effectively.

How Scrum Addresses Cognitive Load

The Scrum framework, as outlined in the Scrum Guide, provides several mechanisms that can help manage and reduce cognitive load:

Sprint Planning: During Sprint Planning, the team plans the work for the upcoming Sprint. This includes breaking down tasks into manageable chunks, which can help reduce cognitive load by allowing team members to focus on one piece of work at a time.
Daily Scrum: The Daily Scrum is a short meeting where the team inspects the work done on the previous day and plans the work for the current day. This regular inspection and adaptation can help manage cognitive load by providing a clear focus for each day's work.
Sprint Review: The Sprint Review is a chance for the team to inspect the Increment and adapt the Product Backlog. This can help manage cognitive load by providing an opportunity to reflect on the work done and to adjust the plan for future work.
Sprint Retrospective: The Sprint Retrospective is an opportunity for the team to inspect itself and create a plan for improvements to be enacted during the next Sprint. This can help manage cognitive load by providing a space for the team to reflect on their processes and to make changes that can reduce complexity and streamline work.

Additional Strategies for Managing Cognitive Load

In addition to the mechanisms provided by Scrum, teams can employ additional strategies to manage cognitive load:

Limit Work in Progress: Limiting work in progress (WIP) can help reduce cognitive load by allowing team members to focus on a smaller number of tasks at a time.
Use Visual Management Tools: Visual management tools, such as Kanban boards, can help reduce cognitive load by making the state of the work visible and easy to understand.
Invest in Continuous Learning: Regularly investing time in learning and improvement can help manage cognitive load by increasing the team's knowledge and skills, making complex tasks easier to handle.

The Five Dysfunctions of Team and Scrum

Sat, 08 Jul 2023 19:22:00 GMT

Addressing the Five Dysfunctions of a Team with Scrum Values

Team dysfunctions can significantly hinder the progress and success of any project. However, the core values of Scrum provide a robust framework to directly address these dysfunctions and foster a healthy, productive team environment. Here's how:

1. Absence of Trust — Respect

Scrum Team members are implored to respect each other as capable, independent people. In Scrum, respect is one of the five values that guide teams in their work, actions, and behavior. Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. This respect fosters an environment of trust, where each team member feels valued and acknowledged for their contributions.

2. Fear of Conflict — Courage

Scrum Team members are called on to have the courage to do the right thing when called upon. This courage extends to addressing conflicts head-on, rather than avoiding them. The Scrum Guide emphasizes the importance of courage in Scrum Teams, stating that team members have the courage to work on tough problems and to confront issues directly. This courage, combined with the trust and respect within the team, helps to mitigate the fear of conflict.

3. Lack of Commitment — Commitment

In Scrum, commitment is not just about agreeing to a task, but it's about being personally committed to achieving the goals of the Scrum Team. The Scrum Guide states that the Scrum Team commits to achieving its goals and to supporting each other. This commitment is not just to the work, but to each other, which helps to foster a sense of shared responsibility and dedication.

4. Avoidance of Accountability — Openness

Openness is another core value in Scrum. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. This openness fosters a culture of accountability, where everyone is aware of their responsibilities and the progress of the work. The Scrum Guide emphasizes the importance of transparency, inspection, and adaptation, all of which encourage accountability.

5. Inattention to Results — Focus

Scrum promotes a strong focus on the work of the Sprint and the goals of the Scrum Team. The Scrum Guide states that the primary focus of the Scrum Team is on the work of the Sprint to make the best possible progress toward these goals. This focus, combined with the commitment to the team's goals, helps to ensure that everyone is attentive to the results of their work.

By embracing these Scrum values, teams can effectively address common dysfunctions and create a collaborative, productive, and successful work environment.

Aligning Risk Management in Agile Delivery with PMBOK Principles

Sat, 08 Jul 2023 18:01:00 GMT

The Project Management Body of Knowledge (PMBOK) outlines 12 principles of risk management. Here's how we can align these principles with Agile delivery:

1. Organizational Context

Each organization is unique, influenced by different Political, Economic, Societal, Technological, Legal, and Environmental factors (PESTLE). Understanding the current Agile maturity, improvement plan, and flow is crucial in developing a risk management vocabulary that fits the organization's context. This includes understanding the organization's Agile practices, the level of Agile adoption, and the existing risk management processes. This context helps in tailoring the risk management approach to the organization's specific needs and circumstances.

2. Stakeholder Involvement

Product owners should be directly engaged in the evolution of the Risk Assessment and Risk Management Strategy. They should involve their network of stakeholders in identifying risks and possible mitigations. This involvement should be continuous throughout the risk management process: Identify, Assess, Respond, and Review. Stakeholder involvement is crucial in Agile, as it ensures that the risk management process is aligned with the needs and expectations of the stakeholders.

3. Organizational Objectives

Risks should be assessed and responded to with the overall organizational objectives in mind. This perspective helps in understanding the impact of task-level risks on User Stories, Sprint Objectives, Themes, Epics, and the overall Programme of works. In Agile, the focus is on delivering value to the customer, and this should be the guiding principle when assessing and responding to risks.

4. Management of Risk Approach

While the PMBOK's specific risk management approach may not be directly applicable to Agile, it's important to define and implement a risk management approach as part of the definition of done. This approach should be iterative and incremental, reflecting the Agile principle of continuous improvement. It should also be collaborative, involving all team members in the risk management process.

5. Reporting

Reporting should be more than just a cover-your-own function. It should be a part of the communication plan, addressing how risks are raised at all levels of the Sprint - Daily, Review, and Retrospective. Transparency and visibility are key in keeping everyone informed. In Agile, information is shared openly and regularly, ensuring that everyone is aware of the risks and can contribute to their management.

6. Roles & Responsibilities

Everyone should understand their role in each stage of the Risk Management Life cycle. This includes how risks are identified, escalated, documented, and reviewed. In Agile, roles and responsibilities are clearly defined, and everyone is empowered to take ownership of their part in the risk management process.

7. Support Structure

Everyone should understand how risk is managed through the Risk Management Life cycle and who to go to if they have any questions. This includes understanding the process for identifying, escalating, documenting, and reviewing risks. In Agile, the support structure is collaborative and team-oriented, with everyone working together to manage risks.

8. Early Warning Indicators

Communication is key in forecasting the transition of a Risk to an active Issue. Any potential issues should be highlighted in the Daily Scrum. It's also important to have a plan for reacting when a risk is realized. In Agile, early warning indicators are used to anticipate risks and take proactive measures to manage them.

9. Review Cycle

Regularly review your Risk Board. This could be done via the Retrospective and as an extension to the Daily Scrum by adding a 4th question: Any changes to the risks board? In Agile, the review cycle is continuous and iterative, ensuring that risks are regularly reviewed and managed.

10. Overcoming Barriers to the Management of Risk

Overcoming barriers to risk management includes establishing roles, responsibilities, accountability, and ownership, allocating an appropriate budget, providing adequate training, tools, and techniques, and regularly assessing the Management of Risk approach. In Agile, barriers are addressed through collaboration, empowerment, and continuous improvement.

11. Supportive Culture

Everyone on the team should feel comfortable raising, discussing, and managing risks. A supportive culture is key to effective risk management. In Agile, the culture is one of trust, openness, and respect, which supports effective risk management.

12. Continual Improvement

Use the Retrospective to review the way you manage risk and to assess ongoing risks. Learn from your mistakes and continually improve your risk management process. In Agile, continual improvement is a core principle, and this applies to risk management as well.

By aligning the PMBOK principles with Agile delivery, we can create a robust and effective risk management process that fits the unique context of each organization.

The Definition of Ready

Thu, 06 Jul 2023 20:08:00 GMT

What is the Definition of Ready?

In the simplest terms, the Definition of Ready is a checklist that determines whether a User Story is ready to be worked on during a Sprint. It ensures that the User Story is clearly defined and understood by all team members, and that it can be developed and tested within the duration of a single Sprint.

Key Components of the Definition of Ready

Here are some of the key components that make a User Story ready for development:

Clearly Defined: The User Story should be defined clearly enough that all members of the team understand what must be done. This includes any required enabling specifications, wireframes, etc.
Team-Developed Tasking: If needed, the User Story should include tasks developed by the team. This assumes some ongoing discussion to refine, coordinate, and clarify the tasks.
Business Value: The User Story should include a clear statement of the resulting business value. This allows the Product Owner to prioritize the User Story in the Product Backlog.
No External Dependencies: The User Story should be free from external dependencies. In other words, there should be nothing beyond the team's control that must be done first in order to complete the story.
Estimated and Sized: The User Story should be estimated and sized to complete easily within one Sprint.
Meets the INVEST Criteria: The User Story should fully meet the INVEST criteria for user stories, which we will discuss next.

Understanding the INVEST Criteria

The INVEST acronym stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. These are the characteristics that make a good User Story:

Independent: The Product Backlog Item (PBI) should be self-contained and it should be possible to bring it into progress without a dependency upon another PBI or an external resource.
Negotiable: A good PBI should leave room for discussion regarding its optimal implementation.
Valuable: The value a PBI delivers to stakeholders should be clear.
Estimable: A PBI must have a size relative to other PBIs. This allows the team to estimate the effort required to complete it.
Small: PBIs should be small enough to estimate with reasonable accuracy and to plan into a time-box such as a Sprint.
Testable: Each PBI should have clear acceptance criteria which allow its satisfaction to be tested.

In conclusion, the Definition of Ready is a vital tool in Agile and Scrum that helps teams ensure they are working on well-defined, valuable, and achievable User Stories. By adhering to the DoR and the INVEST criteria, teams can improve their efficiency, reduce wasted effort, and deliver value to their stakeholders more effectively.

Expanding the Definition of Ready: Writing User Stories and Acceptance Criteria

In the previous section, we discussed the concept of the "Definition of Ready" and the INVEST criteria for user stories in Agile and Scrum. Now, let's delve deeper into how to write a User Story and define Acceptance Criteria using the Gherkin model.

Writing User Stories

A User Story is a simple, concise description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. It typically follows a simple template:

    As a [type of user],
    I want [an action]
    so that [a benefit/a value]

For example:

    As a customer,
    I want to be able to reset my password,
    so that I can regain access to my account if I forget it.

This format helps to keep the focus on the user and their needs, and it encourages the team to consider the value and context of the work.

Acceptance Criteria and the Gherkin Model

Acceptance Criteria define the boundaries of a User Story. They are used to confirm when a story is completed and working as intended. A widely used format for defining Acceptance Criteria is the Gherkin syntax. Gherkin uses a set of special keywords to give structure and meaning to executable specifications. The main keywords are:

Given: Describes the initial context at the beginning of the scenario, before the action starts.
When: Describes the event that triggers the scenario.
Then: Describes the expected outcome or result.

Here's how you might define the Acceptance Criteria for our example User Story using the Gherkin syntax:

    Given I am a registered customer,
    And I have forgotten my password,
    When I request for a password reset,
    Then I should receive a password reset link in my registered email.

This Acceptance Criteria clearly defines the context (a registered customer who has forgotten their password), the action (requesting a password reset), and the expected outcome (receiving a password reset link).

Incorporating Value and Feedback into User Stories

In Agile and Scrum, User Stories are not just about defining what needs to be done. They are also about understanding why it needs to be done and how its success will be measured. This is where the concept of value and feedback comes into play. Let's expand our User Story template to incorporate these elements:

    As a ,
    I want ,
    so that ,
    as measured by .

This expanded template ensures that the User Story is not only user-focused and goal-oriented, but also value-driven and measurable.

Understanding Value in User Stories

The value in a User Story is the benefit that the user or the business will gain from the implementation of the feature. It's the answer to the "so that" part of the User Story. By explicitly stating the value, the team can understand the importance of the User Story and prioritize it accordingly.

For example, let's revisit our previous User Story and add a value statement:

    As a customer,
    I want to be able to reset my password,
    so that I can regain access to my account if I forget it,
    as measured by the decrease in customer support calls regarding password issues.

Here, the value is that the customer can regain access to their account without needing to contact customer support, which also benefits the business by reducing the volume of support calls.

Incorporating Feedback Processes

The feedback process is how the success of the User Story will be measured. It's the answer to the "as measured by" part of the User Story. By defining a feedback process, the team can understand what success looks like for the User Story and can measure whether or not they have achieved it.

In our example, the feedback process is the decrease in customer support calls regarding password issues. This is a measurable outcome that indicates whether the password reset feature is working as intended and providing the expected value.

Incorporating the Scrum Team's Understanding into the Definition of Ready

In the Scrum framework, as defined in the Scrum Guide, the Scrum Team plays a crucial role in ensuring that a Product Backlog Item (PBI) is ready for a Sprint. The team needs to understand several key aspects of the PBI to ensure it meets the Definition of Ready. These aspects can be summarized in four questions:

How will we Develop this?
How will we test this to ensure we have the right functionality?
How will we Automate the solution to production?
How will we Operate This in production, including instrumentation to evaluate the "As Measured By" criteria?

The answers to these questions are bounded by the Definition of Done, which is a shared understanding of what it means for work to be complete, used to assess when a PBI has been fully implemented.

The Scrum Team's Role in the Definition of Ready

The Scrum Team, consisting of the Product Owner, the Scrum Master, and the Developers, is responsible for all product-related activities, including stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.

The team is self-managing, meaning they internally decide who does what, when, and how. They are also cross-functional, meaning the members have all the skills necessary to create value each Sprint.

Understanding the Four Questions

Let's delve deeper into the four questions that the Scrum Team```html needs to understand for a PBI to meet the Definition of Ready:

How will we Develop this? This question is about understanding the technical aspects of the PBI. The Developers need to have a clear idea of what needs to be done to implement the PBI, including any design, coding, and integration tasks.
How will we test this to ensure we have the right functionality? This question is about defining the acceptance criteria for the PBI and planning the necessary testing activities. The team needs to understand how they will verify that the implemented feature meets the desired functionality.
How will we Automate the solution to production? This question is about the deployment of the implemented feature. The team needs to plan how they will automate the deployment process to ensure that the feature can be delivered to production efficiently and reliably.
How will we Operate This in production, including instrumentation to evaluate the "As Measured By" criteria? This question is about the operation and monitoring of the implemented feature in the production environment. The team needs to understand how they will operate the feature and how they will measure its success based on the defined feedback process.

The Scrum Team's understanding of these four questions is a crucial part of the Definition of Ready. It ensures that the team is well-prepared to start working on a PBI and that they have a clear plan for its development, testing, deployment, and operation. This, in turn, supports the team's ability to deliver valuable, high-quality features that meet the needs of the users and the business.