Containers Trend Report. Explore the current state of containers, containerization strategies, and modernizing architecture.
Securing Your Software Supply Chain with JFrog and Azure. Leave with a roadmap for keeping your company and customers safe.
The Agile methodology is a project management approach that breaks larger projects into several phases. It is a process of planning, executing, and evaluating with stakeholders. Our resources provide information on processes and tools, documentation, customer collaboration, and adjustments to make when planning meetings.
Previously, I tested how ChatGPT would answer questions from the Scrum Master Interview Guide; see below. Back in January 2023, I would not have taken the next step in the Scrum Master interview process, inviting ChatGPT to a full-size interview with several Scrum team members. So, if the GPT 3.5 or 4.0 models still need to be better to pass the interview hurdle, what about their capability to create similar interview questions? Enjoy the following article on my excursion into creating Scrum Master interview questions with ChatGPT. Setting up the Session for the Scrum Master Interview Questions I ran the session on ChatGPT on Sunday, May 28, 2023, from 7:05 am CEST to 8:55 am CEST on the model GPT-4. (This requires upgrading to ChatGPT Plus.) I did not apply Grammarly to ChatGPT’s answers. Prompt Design I used the following prompt to trigger the session: As Scrum Master GPT, your task is to generate five unique interview questions to identify talented Scrum Masters and Agile coaches. Each question should address a specific topic related to Scrum events, roles, or artifacts. Your questions should be open-ended and provide room for discussion while avoiding trick questions or those that can quickly be answered by browsing the Scrum Guide. Your interview questions should adhere to specific criteria, including being less than 400 characters in length and comprising four paragraphs: Question headline, The question itself, Background on the topic of the question based on the Scrum Guide 2020 or Agile Manifesto, Suggestions for suitable answers from candidates. You should focus on thought-provoking and actionable content beyond usual interview patterns. Your goal is to identify knowledgeable candidates among applicants who know about Scrum or Agile product development. Additionally, please refer to relevant information about yourself provided in the prompt when crafting your questions. ChatGPT Response Comment SW: This is only the first of five suggested Scrum Master interview questions: 1. Question headline: Driving Adoption of Scrum in an Organization. 2. Question: How have you promoted and supported the adoption of Scrum in a traditionally non-Agile environment? 3. Background: Introducing Scrum in a traditional, non-Agile environment can be challenging. Scrum Masters are often responsible for driving this change, promoting Scrum’s benefits, and coaching the organization through the transition. 4. Suitable answers: Candidates should share specific examples of strategies they’ve used and challenges they’ve overcome. Responses could include: “I facilitated workshops and training sessions to educate teams and stakeholders about Scrum.” “I worked closely with leadership to help them understand and support the benefits of an Agile transformation.” “I acted as a change agent, promoting Scrum values and principles, and helped teams navigate through the transformation.” Comment SW: The suggestions regarding acceptable answers are way too superficial, merely some vague, meta-level sequence of words—I was about to say: LLM-ish—and thus unsuited to distinguish a talented candidate from competing applicants. Let’s fine-tune the prompt. Follow-up Prompt Elaborate on #4 “suitable answers” of the last response, “Driving Adoption of Scrum in an Organization:” The current answer is superficial and lacks hands-on examples of accomplishing the outlined tasks. What workshops and training sessions may be helpful to educate teams and stakeholders? What did you do to “work closely with leadership?” How did you promote Scrum values and principles? ChatGPT Response Suitable answers: Expanding on the previous response, candidates should share specific examples of strategies they’ve used and challenges they’ve overcome. Here’s a more in-depth look at suitable responses: “I organized workshops and training sessions covering the basics of Scrum, its roles, events, and artifacts. I also included hands-on exercises, such as creating a mock Product Backlog, running a Sprint simulation, and conducting Retrospective meetings. Additionally, I provided training on Agile values and principles, emphasizing their importance in the Scrum framework.” “Working closely with leadership involved regular meetings to discuss the progress of Scrum adoption, addressing any concerns or issues they may have had. I also helped them understand their role in the Scrum framework. For example, I emphasized the importance of respecting the Scrum Team’s decisions and not interfering with the Sprint once it has started.” “To promote Scrum values and principles, I consistently modeled them in my interactions with the team and stakeholders. For example, I made sure to maintain transparency in all processes, fostered an environment that encouraged inspection and adaptation, and emphasized the importance of individuals and interactions over processes and tools. I also facilitated a session with the team to discuss these values and principles and how we could better embody them in our day-to-day work.” Comment SW: That is looking much better. Next step: merge the answer fragments. Follow-up Prompt #2 Based on the last response, go back and regenerate question #5, “Driving Adoption of Scrum in an Organization,” from the previous answer and merge it with the extended section 4, “Suitable answers.” ChatGPT Response Comment SW: Here comes our first ChatGPT-generated question for the Scrum Master Interview Guide: Scrum Master Interview Guide — ChatGPT Question #1 1. Question headline: Driving Adoption of Scrum in an Organization. 2. Question: How have you promoted and supported the adoption of Scrum in a traditionally non-Agile environment? 3. Background: Introducing Scrum in a traditional, non-Agile environment can be challenging. Scrum Masters are often responsible for driving this change, promoting Scrum’s benefits, and coaching the organization through the transition. 4. Suitable answers: An ideal candidate should provide detailed examples of their previous experiences. Here are acceptable responses, merging the previous and revised suitable answers: “I organized workshops and training sessions about Scrum. They covered Scrum basics and involved hands-on exercises such as creating a mock Product Backlog, running Sprint simulations, or conducting Retrospective meetings. Training on Agile values and principles was a core part of these sessions.” “To work closely with leadership, I scheduled regular meetings to discuss the progress of Scrum adoption, where I addressed their concerns or issues. I also helped them understand their roles in the Scrum framework, especially the importance of respecting the Scrum Team’s decisions and the sanctity of the Sprint.” “I demonstrated the principles of Scrum by modeling them in my interactions. I maintained transparency in all processes, fostered an environment that encouraged inspection and adaptation, and emphasized the importance of individuals and interactions over processes and tools.” Follow-up Prompt #3 Repeat the last exercise: go back to your initial responses, comprising the following questions: Facilitating Conflict Resolution as a Scrum Master Building a High-Performing Scrum Team Handling External Interference in the Scrum Process Scrum Master’s Role in Product Backlog Management I want you to elaborate on every section 4, “suitable answers,” of the respective interview questions 1 to 4. Then, add more lessons learned and practical examples of accomplishing the tasks the candidate may share. Finally, merge the newly generated responses for section 4 with the original four questions to deliver well-rounded Scrum Master interview questions. ChatGPT Response Of course, here are the four interview questions with elaborated suitable answers: Scrum Master Interview Guide — ChatGPT Question #2 1. Question headline: Facilitating Conflict Resolution as a Scrum Master. 2. Question: Can you describe a situation where you had to facilitate conflict resolution within the Scrum Team? What was the conflict about, and how did you handle it? 3. Background: Conflict is inevitable in any team. As a Scrum Master, facilitating conflict resolution is crucial to maintain harmony and productivity in the team. 4. Suitable answers: A candidate should emphasize their ability to maintain neutrality, foster open communication, and help the team come to a resolution: “I ensured a safe space for the team members to express their concerns and feelings without fear of backlash. We then tried to find common ground, ensuring everyone feels heard and respected.” “I facilitated a workshop on effective communication and conflict resolution techniques. This training allowed the team to navigate conflicts independently over time.” “For a particularly complex conflict, I brought in an external mediator. This decision helped us find a resolution and learn more about handling such situations in the future.” Comment SW: You cannot “ensure a safe space” as the team needs to create it over time within the existing culture. Nevertheless, the “suitable answers” section contains several valuable hints for spotting talent. Scrum Master Interview Guide — ChatGPT Question #3 1. Question headline: Building a High-Performing Scrum Team. 2. Question: As a Scrum Master, what steps would you take to transform a newly formed group of individuals into a high-performing Scrum Team? 3. Background: Scrum Masters are crucial in building high-performing teams. They help foster an environment of trust, collaboration, and continuous improvement. 4. Suitable answers: Candidates should demonstrate an understanding of Scrum values and how they contribute to high-performing teams: “I fostered a culture of trust and collaboration within the team, using team-building exercises and workshops on effective communication and feedback.” “I regularly checked in with each team member individually, helping them overcome obstacles and addressing their needs and challenges.” “To foster continuous improvement, I made sure the team understood the value of the Retrospective meeting. We used these sessions to identify areas for improvement and create actionable plans.” Comment SW: Again, the “suitable answers” section points in the right direction but ultimately falls short. I want more concrete suggestions like pointers to Liberating Structures, Core Protocols, or working agreements. It is a start, though. Scrum Master Interview Guide — ChatGPT Question #4 1. Question headline: Handling External Interference in the Scrum Process. 2. Question: Can you share an experience when you had to handle external interference during a Sprint? How did you protect the team, and what was the outcome? 3. Background: It is part of the Scrum Master’s role to shield the team from disruptions during the Sprint and maintain focus on the Sprint Goal. 4. Suitable answers: Candidates should demonstrate how they’ve protected the Scrum team and facilitated their ability to focus on the Sprint Goal: “I held a meeting with the interfering stakeholder, clarifying the Scrum rules and the importance of respecting the team’s focus during the Sprint.” “I collaborated with the Product Owner to manage stakeholder expectations, ensuring changes were appropriately prioritized in the Product Backlog for future Sprints.” “I introduced a Stakeholder Engagement Plan that defined the stakeholder’s input process, which helped reduce disruptions during the Sprint.” Comment SW: This time, the “suitable answers” section contains a lot of garbage: Scrum Masters, for example, do not ensure “changes were appropriately prioritized in the Product Backlog.” Moreover, a “Stakeholder Engagement Plan that defined the stakeholder’s input process” is classic project management speak. Instead, multiple other ways of aligning with stakeholders exist, starting with the Sprint Review at the Scrum level or practices like user story mapping during product discovery. Scrum Master Interview Guide — ChatGPT Question #5 1. Question headline: Scrum Master’s Role in Product Backlog Management. 2. Question: How do you support the Product Owner and the Developers in Product Backlog refinement? 3. Background: The Scrum Master supports the Product Owner and Developers in managing the Product Backlog, ensuring it is transparent, visible, and clear to all stakeholders. 4. Suitable answers: Candidates should highlight their understanding of the Scrum Master’s supportive role: “I facilitated Backlog refinement sessions, ensuring they were time-boxed and focused, which helped the Product Owner in refining the Product Backlog.” “I trained the Developers on writing good User Stories and Acceptance Criteria, improving the quality of items in the Backlog.” “I hosted a workshop on prioritization techniques, such as MoSCoW and Value vs. Effort matrix, to support the Product Owner in effectively prioritizing the Product Backlog. These techniques were then used in our refinement sessions to decide which items should be considered for the next Sprint planning.” Comment SW: Hm. The magic about Product Backlog refinement is that the Product Owner brings the Why, the Developers decide on the How, and both haggle about the What, creating a shared understanding of why the team is heading where. Also, I do not know why the Scrum Master would organize a workshop on prioritization techniques; that is a core domain of the Product Owner, assuming they are capable. The suggestions are way too process-focused; however, the Scrum Master is not a project manager in disguise. Let’s follow up and see if we can resolve this (I also shared my previous comment with ChatGPT.) Follow-up prompt: Regenerate the response by eliminating the project management language and perspective and apply Scrum and agile principles to the task. ChatGPT Response: Suitable answers: Candidates should highlight their understanding of the Scrum Master’s supportive role: “During the Backlog refinement sessions, I ensured an environment that promotes the discussion between the Product Owner and Developers. The Product Owner would explain the ‘Why’ behind the user stories, which would lead to the Developers brainstorming ‘How’ to implement them. This process would foster a shared understanding of the direction we’re heading.” “I supported the Developers in learning to ask the right questions about User Stories and Acceptance Criteria. This helped them gain a clearer understanding of each item’s purpose, increasing the quality of our implementation.” “To make sure that we maintain a Product Owner-led environment, I worked on empowering the Product Owner to own their role effectively. I would support them in understanding and applying prioritization techniques; however, I made sure to respect the boundaries of their role. I also helped to create a collaborative environment where the Product Owner and Developers could effectively negotiate the ‘What’ in the Backlog refinement sessions.” Comment SW: ChatGPT tries hard to please; unfortunately, to little avail, as the answers are only marginally better than someone parroting some phrases. Food for Thought Regarding the Scrum Master Interview: Is GPT 4.0 the Right Model for the Task? I used the prompt also with GPT 3.5 instead of GPT 4.0. This is one of the suggestions: Scrum Master Interview Guide — ChatGPT Question #6 (GPT 3.5) Question headline: Scrum Artifacts — Definition of Done Question: How do you establish and maintain a clear Definition of Done (DoD) to ensure the team consistently delivers high-quality, releasable Increments, as emphasized by the Scrum Guide? Background: The Definition of Done is a shared understanding within the Scrum Team about what it means for a Product Backlog item to be complete. The Scrum Guide highlights the importance of a well-defined DoD to ensure consistent quality and releasable Increments. Suitable Answers: Demonstrating knowledge of the purpose and benefits of a Definition of Done in ensuring the quality of delivered Increments. Discussing techniques for collaboratively establishing and evolving the Definition of Done, such as team workshops, continuous improvement practices, or retrospective discussions. Explaining how they would enforce adherence to the DoD, such as through peer reviews, automated tests, or code reviews. Sharing examples of how they have worked with teams to refine and improve their Definition of Done over time, resulting in higher-quality deliverables. Comment SW: Not bad, given that it took GPT 3.5 less than 30 seconds to create all five questions. Admittedly, words like “enforce” or “deliverables” would not be my choice; nevertheless, I will need to return to the idea later. Conclusion The outcome of the session based on the GPT 4.0 model is mixed at best. The prompt design turned out to be significantly more challenging than expected, resulting in a poor, barely usable outcome. Interestingly, the older model is pretty close, with much less effort regarding prompt creation. I will need to come back to this question later, then use an extended prompt creation approach. Somewhere in GPT 4.0, there are fantastic questions worthy of becoming part of the Scrum Master Interview Questions Guide; I just need to unearth them. Have you used a GPT model to help you organize or augment the Scrum Master interview process? If so, please share your learning with us in the comments.
The scrum master simplifies the scrum process, which includes assisting the team in expanding and improving their task management. They are responsible for providing emerging Scrum team members with real leadership and coordinating them to deliver high-quality products on time. So companies that are keen on providing digital assurance services can help their digital teams look into such processes. An Increase in Scrum Masters Working in Digital Assurance During the pandemic, every sector moved into a digital environment. During this phase, the scrum master played a vital role and delivered a high-quality product on time to the customer. Here we will see what challenges a scrum master faces in the world of digital assurance and how they bring out a quick fix to each day-to-day incident. Key Responsibilities of the Scrum Masters in Digital Assurance Facilitating communication: The Scrum Master acts as a mediator between the development team, product team, and digital assurance team, ensuring that all sides have a clear understanding of each other's needs and goals. This involves facilitating regular meetings between the three teams and ensuring that information is shared effectively. Encouraging collaboration: In an Agile environment, collaboration is key. The Scrum Master should encourage the development team and the digital assurance team to work together throughout the project, sharing knowledge and insights to ensure that the software meets quality standards. Managing the testing process: The Scrum Master is responsible for managing the testing process, including ensuring that tests are conducted in a timely and effective manner. They should also be aware of any issues or roadblocks that arise during testing and work with the development team to address them. Ensuring compliance: Digital assurance is essential for ensuring compliance with industry standards and regulations. The Scrum Master should work closely with the digital assurance team to ensure that all necessary compliance requirements are met. Continuously improving processes: Finally, the Scrum Master should work to continuously improve the digital assurance process, identifying areas for improvement and implementing new strategies and technologies to enhance quality and efficiency. Real-Life Challenges Faced by Scrum Masters in Digital Assurance Introducing Scrum to a Team When SCRUM is introduced to a new team, they face many challenges in adapting to the process. Individual members of a team will be in a different mindset; in this case, the scrum master will guide them and provide a proper roadmap. For instance, setting up meetings, understanding the procedure, assigning tasks to the team, and appreciating each other's work. Scrum Process can take an example from an old process called Shu Ha Ri, which is a Japanese martial art. Shu: This is the first phase of the agile process when a team is being formed or switching from waterfall to agile. Ha: They continue observing team ways of working. They would give clues and occasionally give advice, but they would mostly let the team self-evolve. Ri: The team is self-organized and self-evolving. If the team needs his or her advice, they will come to him, but SM is no longer observing the team. To better comprehend the steps, let's use the football team Gryffindor as a real-world example. Each member of a team will bring distinct skill sets and ways of thinking to the table. If a team is dispatched on the pitch without a coach, the team loses the game because there is an imbalance in the management of skills. Let's introduce a coach who serves as the scrum master in order to solve the aforementioned issue. a coach who is knowledgeable of each skill and directs players appropriately to achieve the team's objectives. Scrum Ceremony: Every member of the team will face questions and numerous obstacles when the aim is set. During this stage, some team members will work longer hours than others, which causes an uneven distribution of workloads. Sometimes teams are overworked, which leaves more tasks incomplete. A scrum process will have a list of meeting activities in the order in which they are to be taken up in order to avoid a gap between the team as a result of this. It must schedule daily and weekly general meetings (ex. Sprint Call). In my experience, there was a Digital Assurance issue. Since the crew interacted very little with one another, many of the problems were not appropriately tackled. Here, the scrum master encouraged everyone to ask questions and acquire confidence. People will eventually be able to conquer all of their obstacles and fears. They dealt with all the problems. Team Adapts to the Scrum (Mature Team) At this stage, the team offers suggestions for various implementation strategies. Transformation is more of a culture shift that involves well-balanced, unconventional thinking as well as delivery techniques. In order to achieve high-quality delivery, the scrum master gathers all of the ideas and works as a team to identify the finest ones. In Digital Assurance, a real-world Team adds innovative concepts or user-friendly elements to the product. This assists the client in putting their ideas into practice and bringing them into the digital realm. As a result, the application is as current and open as feasible. General Issues Faced by a Mature Team The team has general issues regarding the product, who shall do what work, etc. Sometimes there is a greater chance of bigger conflict in the team, which causes a lot of misunderstanding. In reference to the aforementioned problems, the expression "Too many cooks spoil the broth" is a perfect illustration. Because everyone is aware of the process at this point, they all attempt to assign tasks and overwhelm one another. To avoid controversy, the scrum master steps in and allocates the assignment to the team in accordance with their best judgment. Being productive in this situation is a challenge for the scrum master. Despite wanting to safeguard them, the team makes blunders. In conclusion, the Scrum Master is a key player in Agile development projects' digital assurance. He or she is a person who takes part in each stage of the process's execution. They are accountable for managing the testing process, guaranteeing compliance, and continuously improving processes, as well as promoting communication and collaboration between the development and digital assurance teams. Scrum masters can assure the success of Agile projects and the delivery of high-quality software by utilizing their experience.
In the constantly evolving world of software product development, agility isn't just an advantage; it's a necessity. Agile software development, with its dynamic methodologies and iterative approach, has revolutionized how software is developed and delivered. Understanding Agile Software Development Agile software development is an approach that promotes iterative development throughout the software lifecycle, encouraging active user involvement, collaboration, and adaptation to changing requirements. It is rooted in the values and principles expressed in the Agile Manifesto, which emphasizes individuals and interactions, working software, customer collaboration, and responding to change. The Agile Manifesto, introduced in 2001, outlines the core principles of Agile software development: Individuals and interactions over processes and tools: Agile places high emphasis on people and their collaboration over rigidly following procedures and using specific tools. This focus improves communication and collaboration, leading to innovative solutions. Working software over comprehensive documentation: Agile methodology values functional software over elaborate documentation. While documentation is essential, the focus is on delivering a working product incrementally. Customer collaboration over contract negotiation: Agile encourages constant collaboration with customers throughout the project. It allows for a better understanding of client needs, leading to a product that better fits the requirements. Responding to change over following a plan: Agile is adaptive rather than predictive. Changes are welcome even in the late stages of development, ensuring the product remains relevant and useful. Agile Methodologies There are several methodologies that fall under the Agile umbrella. Each of these methodologies may have its unique approach but all adhere to the core principles of Agile. Some of the most popular ones include: Scrum This is an iterative and incremental approach to software development, which is done in short cycles or "sprints," typically lasting 2-4 weeks. Kanban This approach visualizes the entire workflow, from conception to delivery, allowing teams to limit the amount of work in progress and identify bottlenecks. Extreme Programming This methodology emphasizes customer satisfaction and aims to improve software quality and responsiveness to changing customer requirements. Lean Software Development Inspired by lean manufacturing principles, this approach focuses on the elimination of waste, amplifying learning, deciding as late as possible, delivering as fast as possible, empowering the team, building integrity, and seeing the whole. Feature Driven Development FDD aims to deliver tangible, working software repeatedly in a timely manner. It involves domain walkthroughs, developing an overall model, building a feature list, planning by feature, and designing and building by feature. How Agile Ensures Quality Quality is an integral part of Agile software development, and agile methodologies incorporate practices that help ensure the quality of the product: Continuous testing: In Agile, testing is conducted throughout the development process, not just at the end. This approach enables early identification and rectification of issues, thereby ensuring high-quality output. Incremental development: Agile practices encourage developing and delivering software in small, manageable increments. Each increment is thoroughly tested, which helps maintain quality throughout the development process. User stories and acceptance criteria: Agile teams often work with user stories and predefined acceptance criteria to guide development. This approach ensures that the developed features meet the user's needs and maintain quality standards. Frequent feedback: Regular feedback is a crucial part of Agile. Whether it's through daily stand-ups, reviews, retrospectives, or client interactions, this feedback loop allows the team to improve continuously, leading to better quality over time. Pair programming: Utilized in Extreme Programming, pair programming involves two developers working on the same code simultaneously. This practice helps catch mistakes early and improve code quality. The Benefits of Agile Software Development According to the 14th annual State of Agile Report, 95% of organizations practice Agile development methods. Here are some compelling reasons for Agile's popularity: Improved product quality: The Agile principles and practices promote high-quality software development. Continuous testing, regular feedback, and incremental development all contribute to improved product quality. Enhanced customer satisfaction: Agile allows for regular communication with customers, ensuring that the product is being developed in line with their expectations. Its focus on customer collaboration leads to a better understanding of customer needs, resulting in higher satisfaction with the final product. Better project control: Daily meetings (stand-ups) provide visibility and allow issues to be addressed promptly. By breaking the project into smaller increments, Agile enables faster delivery of functional software, providing a competitive advantage in the market. Increased project predictability: With set timelines and iterative processes, project timelines and budgets can be predicted more accurately. Now that you are familiar with the basics, types of methodologies, and benefits of Agile software development, let us understand how Agile is implemented in a software development process to achieve quality. Implementing Agile: A Step-By-Step Guide Adopting an Agile approach requires a fundamental shift in how a team operates. Here are some steps to guide you through the process: Educate and train the team: Everyone involved needs to understand Agile principles and methodologies thoroughly. Choose the right project: Not all projects may benefit from Agile. Projects with unclear requirements and potential for change are often suitable for Agile. Define Product Backlog: Create a prioritized list of features (user stories) that need to be developed. Plan your Sprints: Decide on the duration of your sprints and the features to be developed in each. Conduct regular Stand-ups and Reviews: Daily stand-ups to discuss progress and end-of-sprint reviews are crucial. Foster open communication: Encourage feedback, collaboration, and adaptation. Regularly review and adapt: Agile is all about learning and adapting. Regularly review your processes and make necessary changes. Best Practices in Agile Software Development To maximize the benefits of Agile, consider these best practices: Agile is all about adaptability. Don't resist changes; instead, consider them opportunities to create a product that better serves the customer's needs. It thrives in a collaborative environment. Encourage open communication, teamwork, and collective problem-solving. Everything in Agile is about delivering value to the customer. Prioritize features that bring the most value to the customer and aim to deliver them as early as possible. Make sure everyone on the team has a clear understanding of the project, its progress, and any issues. Use tools like Kanban boards to visualize workflow and promote transparency. Agile emphasizes sustainable development. Avoid overburdening your team; instead, establish a sustainable pace of work that can be maintained indefinitely. Implement rigorous testing procedures to ensure high-quality software. Use continuous integration and test-driven development to identify and fix issues early. Regularly reflect on the team's performance and look for ways to improve. Use Agile ceremonies like retrospectives to discuss what's working and what isn't and make necessary adjustments. To Wrap It Up Agile software development is a powerful approach that emphasizes flexibility, customer collaboration, and high-quality software production. By understanding and applying Agile principles and methodologies, teams can adapt to changes more efficiently, meet customer needs more accurately, deliver products faster, and ensure high quality throughout the software product development process. By incorporating best practices and fostering an environment that embraces Agile values, organizations can fully leverage the potential of Agile to achieve superior results in their software development efforts.
So, you’re a day one Scrum Master, and you’ve landed your first job! Congratulations, that’s really exciting! This is an exciting time, but it can also be a bit daunting. There are a lot of things to learn in your first month on the job. In this blog post, we will provide you with a guide to help you hit the ground running. We will discuss essential tips for setting up your environment, getting started with sprints, and building relationships with your team. Let's get started! Starting a new job as a Scrum Master can be overwhelming. There's so much to learn and absorb before you can start making changes. The key to establishing yourself as a trusted member of the team is to listen and learn during your first sprint. It's important to get to know your team members and what motivates them, to understand how they work together and where there may be challenges. By taking the time to soak up all this information, you'll be better positioned to suggest changes that will be both productive and well-received. Remember, the first few weeks are about learning, not changing. When it comes to being the new kid on the block, feeling like a 'noob' is expected, but it's not always a bad thing. In fact, embracing your lack of experience can help you identify the areas where you may need to improve, but also the unique strengths you bring to the table. When you first start with a new team, your number one rule should be to get to know them in their environment. Your main priority should be getting to know your team in their environment. Observe their behavior and communication style to understand how they work together. It's important to focus on the individuals and not just their work product. Don't rush to make changes right away; take the time to learn what works and what doesn't, establishing trust with your team. By showing that you care about them as individuals, you can build a strong foundation for a successful and productive team. Use Your First Sprint To Learn How the Team Works As a Scrum Master, it is your job to learn as much about the team as you can. During your first sprint, spend time observing their process, tracking what tasks they are working on and how quickly or slowly work is progressing. Try to identify any areas where the team may be struggling or could use improvement. Be sure to take notes and ask questions, but don’t come into the sprint with preconceived notions about how things should be done. It is also important to remember that relationships are key to successful Scrum teams. This means taking the time to get to know your team by talking to them and getting their feedback on the Scrum process. Be sure to take note of individual strengths and weaknesses, so you can better understand what roles each team member can best play in the Scrum process. Get To Know What Makes Each Team Member Tick and What Drives Them You need to get to know each person as individuals, not just as members of the team. Learn their strengths, opportunities, and weaknesses. Find out what their chief concerns are and learn how you can help them grow. As a Scrum Master, it’s important to lead by example. Show your team that you are willing to take initiative and make the most out of each sprint. Be open to their suggestions and ideas, but also be sure to provide constructive feedback when needed. The first few sprints will be a test of your skill as a Scrum Master, so take the time to get it right. Listen and observe carefully, learn what works for your team, and establish yourself as a leader. Learn Your Team’s Existing Process for Working Together When you’re first getting started with a new team, it’s important to be respectful of their existing processes. While you may want to make changes, it’s important to understand how they already do things and why they do them. Take the time to observe their process during your first few sprints, taking notes on what works and what doesn’t. Talk to the team members about their experience with Scrum and ask for any suggestions on how the process can be improved. By understanding their existing process and taking their feedback into account, you’ll be better able to identify areas of improvement without disrupting the team’s flow. This will also help build trust between you and your team, which is essential for successful Scrum implementation. Examine How the Team Is Working In Comparison to the Scrum Guide As a Scrum Master, you should always be looking for ways to improve the team and its performance. One way to do this is by examining how the team is working in comparison to the Scrum Guide. Look for areas where the team may be struggling or areas that could use improvement. Are they following all of the Scrum events and activities? Are their estimates realistic? Is there enough time for retrospectives, demos, and planning sessions? Are the team members communicating effectively? Once you’ve identified areas where the team could use improvement, it’s time to come up with a plan of action. Try using retrospectives and other feedback mechanisms to help the team identify and address their issues. And don’t forget to ask for input from your team members! Get To Know the People Outside of Your Scrum Team One of your major responsibilities as a Scrum master is to help your team be effective and successful. It’s not enough to just focus on the people who are part of your Scrum team. You need to be aware of the larger context in which your team is working. Take the time to get to know other stakeholders, such as product owners and executives, who may have an impact on the success of your team’s work. This could involve attending meetings, reading reports, or simply taking the time to listen and understand their perspective. By building relationships with these other stakeholders, you’ll be better equipped to anticipate potential issues and help your team navigate them successfully. Conclusion As a Scrum Master, you play an important role in ensuring that your team is successful. To do this, it’s essential to understand the individual strengths and weaknesses of each team member, as well as the larger context in which they are working. By taking the time to get to know each person on the team, examining how they are working in comparison to the Scrum Guide, and building relationships with other stakeholders, you can foster an environment of collaboration and growth that will help your team succeed. By understanding these various aspects of Scrum and applying them effectively, you’ll be able to help your team reach its full potential. Good luck!
Most Software Developers in Test are familiar with Test-Driven Development, or TDD, but Behavior-Driven Development, or BDD, is often misunderstood. The truth is that both of these approaches have advantages and disadvantages to consider. This blog deep dives into TDD vs. BDD comparison by looking at both these approaches individually. Later, we would compare them to functionalities, supported frameworks, and more.I could say BDD is merely the evolution of TDD. What Is Test-Driven Development (TDD)? Test-Driven Development is a programming practice implemented from a developer’s perspective. In this process, a QA engineer begins designing and writing test cases for every small functionality of an application. This technique tries to answer a simple question — Is the code valid? The primary purpose of this practice is to modify or write a new code only when the tests fail. Consequently, it results in lesser duplication of test scripts. This technique is mainly popular in agile development ecosystems. In a TDD approach, automated test scripts are written before functional pieces of code. How To Implement Test-Driven Development (TDD) Test-driven development gives preference to testing instead of the implementation phase. As all the tests pass, it signals the end of the first iteration. However, if more features have to be implemented, all the phases must be repeated with new feature tests. The figure below summarizes the flow of TDD: Pros and Cons of Test-Driven Development (TDD) TDD is a test-first approach, where automated test scripts are typically written before implementing the product’s actual features. However, TDD has its own share of advantages (or pros) and disadvantages(or cons) Advantages of Test-Driven Development (TDD) Reduced cost of development: The development process in TDD is divided into smaller chunks to simplify the detection of issues at the early stages of design and development. Focus on design and architecture: Writing tests before the implementation makes the development process more seamless and efficient. Improved code coverage: Through TDD, a well-designed system can achieve 100 percent code coverage. Code visibility: Tests are written to verify smaller functionalities, making it easy to refactor and maintain the code. Detailed documentation: Since tests are written for verifying micro-level functionalities, writing documentation becomes an easy task. Disadvantages of Test-Driven Development (TDD) Bugs leading to faulty code: Tests could contain bugs which in turn results in faulty implementation. This can be averted by using the right BDD framework, performing detailed code reviews, and more. Costly architectural mistakes: If the generated test code is not in line with the desired architecture, it could result in huge losses. Slowness in development: Creating test cases before code development slows product development. In addition, framing test cases may take a huge amount of time as the actual implementation is not available at that time. Requires prior experience: Prior experience with TDD is a must since many teams commit the mistake of not running tests at the Red Stage. In this section, we have covered what TDD is, including its advantages and disadvantages. In the next section, we will look into BDD. What Is Behavior-Driven Development (BDD)? Behavioral-Driven Development (BDD) is derived from the Test-Driven Development (TDD) methodology. In BDD, tests are based on systems behavior. The BDD approach describes different ways to develop a feature based on its behavior. In most cases, the Given-When-Then approach is used for writing test cases. You can learn more about Gherkin by reading the article on Behavior Driven Development By Selenium Testing With Gherkin. Let’s take an example for better understanding: Scenario: User Can Sign In Given a valid user with username “lambdatest1.” When I log in as “lambdatest1.” Then I should see the message “Welcome, lambdatest1” Here is the overall approach to BDD: Debugging the errors in the latter stages of the development life cycle often proves to be very expensive. In most cases, ambiguity in understanding the requirements is the root cause behind this. Therefore, one must ensure that all the development efforts remain aligned toward fulfilling pre-determined requirements. BDD allows developers to do the above by: Allowing the requirements to be defined in a standard approach using simple English. Providing several ways to illustrate real-world scenarios for understanding requirements. Providing a platform that enables the tech and non-tech teams to collaborate and understand the requirements How To Implement Behavior-Driven Development (BDD) As we know, BDD is an extension of TDD. BDD plays a crucial role in cutting back on the bugs and errors you would encounter at later stages of product development. Effective test automation strategy, including scenarios, can be developed by involving different teams (e.g., engineering, product management, marketing, etc.). The BDD approach accords technical and non-technical teams with the collaboration of knowledge and ideas. It’s time for some action. Cucumber is a tool that supports BDD; anyone can write specifications in plain English using Gherkin. It is as simple as adding a test from the business value point of view, as I like to call business-centric Test Automation. If you are new to Cucumber, you can also check out the step-by-step tutorial on Selenium Cucumber with examples. Let’s start by adding the Cucumber plugin using npm to our current Cypress Testing project. 1. Please install the plugin. JavaScript npm install --save-dev cypress-cucumber-preprocessor 2. The following dependency with the latest version will be added to your package.json of the project. At the time of writing this recipe, the version of cypress-cucumber-preprocessor is 4.1.4. JavaScript devDependencies": { "cypress-cucumber-preprocessor": "^4.1.4" } 3. To make it work, we would need to add it to Cypress plugins as part of Cypress Configuration under cypress/plugins/index.js JavaScript const cucumber = required('cypress-cucumber-preprocessor').default JavaScript module.exports = (on, config) => { on('file:preprocessor', cucumber()) } 4. Next, we need to add cosmiconfig configuration to the package.json. Cosmiconfig searches and loads the required configuration of the project. In this case, we are defining to locate the step definitions by setting up the below property. JavaScript "cypress-cucumber-preprocessor": { "nonGlobalStepDefinitions": true } 5. Let’s create a new folder under Cypress -> Integration directory as ‘cucumber-test’ and then create a new feature, “Home.feature.” JavaScript Feature: Home / Landing Page Scenario: Navigating to E-commerce Store Given I open home page Then I should see Homepage 6. For step definition location, let’s create a folder named “home.” Let’s create a step definition file ‘homeSteps.js.” JavaScript import { Given } from "cypress-cucumber-preprocessor/steps"; Given('I open home page', () => { cy.visit('https://ecommerce-playground.lambdatest.io/') }) Then('I should see Homepage', () => { cy.get('#search').should('be.visible') }) 1. The folder structure should be as the following: 7. Now, let’s run using the following command in the Terminal or command console to execute the test: JavaScript npx cypress open 8. On Cypress Test runner, select ‘home.feature.’ And you should see the results correctly: Note: You can download the code from the GitHub Repository. Gherkin Keywords Keywords are used to give structure & meaning to the executable specifications. Every specification or a feature file starts one of the keywords as: Feature Scenario Scenario Outline Background Feature: It is the primary key in the Gherkin; it is used to describe the specification name. Gherkin Feature: Hello In order to start a conversation with someone chat bot needs to start with greetings so the user gets the interactive feel. Scenario: It is the collection of actions or steps that need to be performed to fulfill a test objective. Gherkin Feature: Greetings In order to start the conversation with someone chat bot needs to start with greetings so the user gets the interactive feel. Scenario: example Given greeting has been set to "hello" When name is "Frank" Then greetings equals "Hello Frank" Scenario Outline: is used when the same scenario needs to be executed with multiple data sets. Scenario Outline is always defined with the Examples keyword. That’s where data sets can be defined to execute the same scenario multiple times. Scenario Outline is used for Data-driven tests. Gherkin Feature: Greetings In order to start the conversation with someone chat bot needs to start with greetings so the user gets the interactive feel. Scenario Outline: example Given greeting has been set to"" When name is "" Then greetings equals "" Examples: | greeting | name | conversation | | Hello | Frank | Hello Frank | | Hi | Maria | Hi Maria | | Hey | Johnny | Hey Johnny | Implementation example: Gherkin let myName, greeting, finalword Given("greeting has been set to {string}", setGreeting => { greeting = setGreeting + ' ' }) When("name is {string}", setName => { myName = setName finalString = greeting.concat(myName) }) Then("greetings equals {string}", expectedValue => { expect(finalword).to.equal(expectedValue) }) Background: It is used to define a step or series of steps common to all the tests included in the feature file. The steps defined as part of the background get executed before each scenario. Adding the Background section is helpful to avoid duplication of feature steps. Gherkin Feature: Background Example Background: Given greeting has been set Scenario: example1 When name is "Frank" Then greetings equals "Hello Frank" Scenario: example2 When name is "Maria" Then greetings equals "Hello Maria" Pros and Cons of Behavior-Driven Development (BDD) BDD is an approach that involves managers, testers, developers, etc., in the whole process. As a result, BDD offers a huge number of benefits. Let’s look at some of the major ones in this section. Advantages of Behavior-Driven Development (BDD) Improved Communication: Creating scenarios requires close coordination between clients, managers, developers, testers, etc. This unifies the team in understanding the product behavior. Reduced cost of Quality Control: Automated acceptance tests are used to depict the scenarios, which in turn helps in reducing the costs involved in inspecting the product quality. Accurate task estimation: Since the expected behavior is predicted before, there are few chances to change the software application’s architecture. Better user experience: The scenarios and tests written before development take the user’s perspective into account. The focus is on the desired behavior rather than on implementing features. Excellent documentation: When a certain test fails, the specification is updated, resulting in detailed documentation. Challenges of Behavior-Driven Development (BDD) Requires more involvement from all the stakeholders: Putting all the people together becomes difficult for teams. Is it the three amigos sitting down together, talking, collaborating, and leaving with a common language around the system requirements? BDD tools struggle with parallelization: Cucumber and SpecFlow do parallelization or support parallel testing in a sub-optimal manner. They parallelize at the feature file level. It implies that if you want to run 50 tests in parallel, you need to have 50 feature files. That’s a lot of feature files. Writing incorrect Gherkin syntax: The issue is that most of us do not follow the correct Gherkin syntax as prescribed by the BDD creators. Just remember Given-When-Then steps must appear in order and cannot repeat. TDD vs. BDD: The Final Showdown TDD vs. BDD is a quest for some developers. Even experienced developers find it difficult to differentiate between these approaches. Now that we have touched upon the working and implementation of TDD and BDD let’s deep dive into the major differences in this epic TDD vs. BDD clash: Criteria Test-Driven Development(TDD) Behavior-Driven Development(BDD) Language Test cases designed in TDD are Technical. These are similar to the test cases that are normally written during the testing phase. The test scenarios designed in BDD are written in simple English language. Implementation Level There is a low-level implementation in TDD. The scenarios are easy to understand and implement, making BDD a high-level implementation with regard to test case development. Key Stages Test case development is the major phase in TDD. Discussion and creation of scenarios are the major stages in BDD. Stages involved in Development TDD involves three main stages, Test creation, implementation, and code refactoring are the major stages in TDD. BDD involves a number of stages like feature discussion, scenario creation, testing, implementation, and code refactoring. Participants Only technical teams like development teams take part in TDD processes. BDD involves many teams, right from client to business analysts, testers, developers, etc. Primary Focus Development of required functionality based on test cases is the primary focus in TDD. BDD focuses on the correspondence between implemented features and expected behavior. Documentation TDD requires documentation for the creation of accurate test cases. Thrust is laid on documentation created during the scenario creation process. Tools The tools (or frameworks) used in TDD involve JUnit, TestNG, NUnit, etc. These are used to run test cases. Gherkin is used for writing scenarios in BDD. Cucumber, SpecFlow, etc., are some of the widely used test automation frameworks. Applicable Domain The main focus in TDD is to get appropriate functionality through implementation. BDD has the defined domain as “Behavior.” This focuses on the product’s behavior at the end of implementing the product functionality. Bug Tracking Bug tracking is easier in TDD, as the tests indicate whether they have passed or failed. Bug tracking in BDD requires integration between multiple tools across the organization. So, these were the key differences as far as TDD vs. BDD is concerned. So, make sure to look at these differences when you have to decide between TDD and BDD. Can TDD and BDD Work Together? So far, we have seen what is different as far as TDD vs. BDD is concerned. The best part is that these processes are not mutually exclusive. While it’s not unusual for Agile teams to use one without the other, making these two work together can ensure a higher degree of efficiency in testing use cases, thereby bringing confidence in the performance. TDD, when used alongside BDD, gives importance to web testing from the developer’s perspective, with greater emphasis laid on the application’s behavior. To implement the specifics, developers can create separate testing units to get robust components. This is beneficial since the same component can be used in different places across the software development process. You can use cloud tools like LambdaTest to leverage the capabilities of both TDD and BDD frameworks and perform live testing. LambdaTest is a cross-browser testing platform that enables you to run your test scripts on an online device farm of 3000+ real browsers and real operating systems. LambdaTest integration with tools like Slack, Microsoft Teams, etc., makes discussions between the teams efficient and easy. TDD or BDD, the choice is governed by the individual needs of an application or the enterprise. The combination of TDD and BDD frameworks can add more value to the software development process. This is where automation testing tools like LambdaTest can be beneficial since they can be integrated with major TDD and BDD frameworks. TDD vs. BDD: Which Approach Is Best for Your Project? BDD and TDD have differences and similarities. Although, at the same time, it’s not unusual for Agile teams to use one without the other, making the two work together can guarantee a higher degree of efficiency in testing application use cases, thus obtaining greater confidence in their performance. TDD vs. BDD, an Agile team, alongside TDD, can use the BDD approach to put in place a higher level of testing that takes care of technical nuances from the Agile team’s point of view and assesses the application’s behavior. To implement the specifics, we can create separate testing units to maintain the robustness of different components. It can be beneficial, considering that the same component can be used in other places across an application. The testing process is based on specifying test scenarios in simple language. Then, Automation Engineers add TDD parts for testing certain specific components. Whether to choose BDD over TDD or use a combination of the two methods is a choice ruled by the needs of an application or organization. Experimenting with BDD if you’re already doing TDD testing can add value to the Agile process. Using the two together is more accessible, and you don’t need to change or rework the existing approach. All it takes is updating the testing framework to adjust the other. Selenium 101 certification from LambdaTest is a great way to validate your expertise in Selenium automation testing. There are plenty of good reasons to get Selenium certified. You can use it to prove that you’re on top of things, or you can use it as a way to help yourself learn. Final Thoughts In this TDD vs. BDD article, you can always view the big picture and decide which approach is best for your software requirements. However, whether you choose to implement test-driven or behavior-driven development, you will require strong QA and testing skills and tools. Understanding TDD vs. BDD approaches work can help Agile teams and other stakeholders improve the development process by zeroing in on the best test strategy for their needs. Then, depending on the nature of the project and the desired result, you can choose between a mix of the two techniques to enhance test coverage efficiency. Thus, till then, Happy Testing!
Jira is one of the most flexible and customizable Project Management tools on the market. It’s also built from the ground up with Agile in mind making it one of the best solutions for managing Sprints in Scrum. What Is Scrum, and How Does It Fit Into Jira? Scrum is a lightweight Project management framework. It is designed to break down a large body of work into iterative increments. Scrum was initially introduced as a way of improving collaboration in teams that are working on solving complex problems. In essence, the Scrum team breaks down the entire project into Sprints – short, time-boxed periods during which a Scrum team is to deliver an agreed-upon number of increments, AKA functional features. All five of the scrum events, such as sprint planning, daily Scrum, sprint review, and retrospectives, take place during the Sprint. The Scrum framework is incomplete by design. However, it encourages the process of continuous learning and improving through your work. Your decisions will be based on observation, ability to adapt, and a fair bit of common sense. You can learn more about Scrum from the Scrum guide and on Scrum.org. For now, I’ll assume you know the basics and focus on the elements directly applicable in your Jira instance. The Scrum Team The average Scrum team has three roles: Product owner, Scrum master, and Developers. The Product Owner is accountable for the product value a Scrum team delivers. This person shares the goals of Sprint and should answer any questions the dev team might have regarding the product or users. PO is also responsible for Jira Themes & initiatives, Epics, and User Stories. Regarding Jira, the Product Owner is responsible for translating the project plan into Jira, Jira roadmap design, backlog management, and prioritization. The Scrum Master acts as the team’s coach. This person observes everyone’s activities and helps deliver a successful result. In addition, Scrum Master facilitates standups, helps to keep the scope in check during sprint planning, and hosts retrospectives. Regarding Jira, the Scrum Master is responsible for the Sprint board. He is usually the admin on the project and helps ensure that the cards are updated and flow through the established Jira workflow. Developers deliver the work during the active Sprint. First, they have to determine what they can deliver during a Sprint. To them, Jira is a board with tasks they can contribute to. Product Backlog Typically, the Product Owner creates the first batch of User Stories that are added to a backlog. These stories will be generalized as their main goal is to introduce a certain vector to the development process. Think of it as a place to store concepts and ideas. They may (or may not) become TODOs that will shape the product. You can access your backlog in Jira from the backlog tab in the sidebar. You’ll then have to scroll down past planned sprints. Sprint Backlog According to Jira best practices, after the initial user stories are refined, the team can agree to add them to the Sprint backlog. This is a separate pool of tickets that you’ll be working on during one Sprint. You’ll only want to add those stories that are immediately actionable. You don’t have to cover 100% of the acceptance criteria at this stage, but make sure that the team understands the story well enough to be confident in their ability to deliver the result. Many companies use the INVEST method to set this Definition of ready in stone. You’ll want to move your issues from the backlog to the Sprint backlog in Jira after the Sprint planning session. Story Points Jira issues have a custom field for Story Points. Engineers use them to measure the complexity of a story. The discussion regarding how many stories point a story is worth happens during the Sprint Planning meeting, and the complexity is based on effort, uncertainty (engineers not being sure how they can deliver a feature), and risk. The team will be burning these story points by completing the issues. How does this work? The team discusses the work they need to do before the Sprint begins. Then, all of the stories are reviewed and assigned story points based on their complexity. When the team commits to a Sprint, we know the stories we will be working on and their “worth” in points. The team burns down stories that have met the Definition of Done by the end of the Sprint. Any stories that have not been completed are moved back to the backlog, refined, and potentially re-estimated. These stories can then be moved back to Sprint if the team decides to do so. When this practice is consistent for each Sprint – the team will learn their velocity (the number of story points they typically burn during a Sprint) over time. How Long Should a Sprint Take? A Sprint is always fixed in time. Teams do this to create consistency and accurately estimate the scope they can deliver throughout one Sprint. The nature of Scrum encourages teams to decide the perfect length of a Sprint that works for them based on Empiric evidence. The main point is to understand why you need a time-boxed Sprint. Force prioritization. You start thinking about what is the most important feature you want to deliver when you have a defined time frame to complete a body of work. Demonstrate progress. The timeboxed iterations give an opportunity to regularly demonstrate progress on completed work. This gives a clear understanding of what’s going on in the project to the business side and boosts team morale. Avoid perfectionism and motivate closure. When you have an established deadline for the Sprint, you plan things accordingly. You won’t have the time to try to make things perfect. Improve planning. It’s easier to plan things for an established duration, especially if you have a couple of completed Sprints under your belt and know the scope the team can handle. Continuous feedback. You have an opportunity to constantly give and receive feedback in an iterative and time-boxed Sprint. You can decide on the optimal length of a Sprint. Base this decision on the specifics of the product/project, team maturity, team size, and the factors mentioned above. I would say that the optimal sprint length is when you can deliver a feature within your defined timebox. In this way, all the factors above start working for your team, and you are making the most value of your sprints. Sprint Planning We’ve touched on the subject of Sprint Planning before. So let’s look at it in more detail. The Sprint capacity planning session is the meeting when you decide which tickets should make their journey from the product backlog and into the Sprint backlog. Every Sprint planning session is unique, but all must focus on answering three primary questions: Why is THIS Sprint valuable? What can we deliver during this Sprint? How will we deliver the work we’ve planned? Answering these questions will help you refine your stories. You’ll know their priorities and have an approximation of how much work each of them will require. The trick to Running a Sprint Planning session successfully is making sure that the whole team is prepared. The Product Owner needs to have a clear understanding of Sprint’s goals. They should select the stories for the Sprint Planning session with this concept in mind. The Scrum Master can help by asking probing questions and ensuring the scope doesn’t end up overblown. And the developers can use their analytical skills to try to understand stories, potential solutions, and the complexity of implementation. How To Set up Sprints in Jira Let’s face it, Jira has many issues with its UI. Sometimes finding the right button to enable or start something can be nothing short of a herculean feat. Case in point: finding closed Sprints is a hustle. Luckily, starting a new Sprint is as simple as ABC. Navigate to the backlog from the sidebar and click the bright blue “Start Sprint” button once the issues from your Project backlog are refined, prioritized, and moved to the Sprint backlog. Clicking on the “Start Sprint” button will open a pop-up window where you’ll fill in the details of your Sprint, such as: Name of the Sprint Duration: You can select a desired duration from the drop-down menu Start date/end date And the goal of the Sprint. Note that fields that are marked with a red asterisk are mandatory. Parallel Sprints in Jira Parallel Sprints can be a useful tool when you’d like to run several Sprints from the same backlog. This functionality can come in handy when you want to separate your teams, like developers and designers, while still working on the same goal. Running parallel Sprints is slightly easier in team-managed projects. You can create as many of them as you need from the backlog. Once you’ve created your parallel Sprint – click on the “Start Sprint” button. This will create a new active Sprint in Jira simultaneously. You can then select the Sprint you want to see on the board from the drop-down sprint selector. Setting up parallel sprints in a company-managed project is a bit trickier. You’ll need a user with global Jira Admin permissions. This user can do the following if you are running your instance on Jira Data Center: Select Administration (⚙️) > Applications, then scroll down the page to the Jira Software section. Under Jira Software configuration, select the Parallel Sprints checkbox. And the following steps apply to Jira Cloud: From the global navigation, select Settings () > Products. Under Jira Software configuration, select the toggle for Parallel sprints. ‼️Note: The velocity chart will not show the velocity per team. How To List All Sprints? I’ve seen people trying all kinds of crazy things with “Sprint JQL.” Sometimes it works for them; sometimes, it doesn’t. In my experience, JQL is best used for issues only. However, based on the Sprint field, you can use the following string to list all Sprints and the issues within them. This can be handy when you are looking to review previously closed Sprints. Sprint in (closedSprints(),openSprints()) AND project = “XYZ” Yet, there’s a much simpler way of listing and reviewing your sprints – the Sprint report. The limitation to this convenience comes from the fact that the report is limited to company-managed projects, and it is also board-specific. That being said, it will show you the list of your Sprints along with associated issues. You can use the Sprint Burnup Chart in team-managed projects to achieve the same goal. How To End a Sprint in Jira? Technically, ending a Sprint is a matter of two clicks. First, go to your backlog tab and click on the “Complete Sprint” button. Clicking this button kicks off a different Sprint event – the Sprint Retrospective. This is a meeting where the whole Scrum team inspects how the Sprint went. Use this time to talk about individual performance, interactions, and processes. Try to find ways where you can improve or optimize something or maybe even adjust your Definition of Done. We typically follow a format where each team member lists the “goods” and the “improves.” This format of feedback works wonders as it gives everyone a chance to cherish a job well done while offering an opportunity to voice their opinion on things that might have been smoother. Once you complete a Sprint, your incomplete issues will be moved into the backlog. How To Measure Relevant Sprint Metrics in Jira? While we are on the subject of reports, Jira offers a handy selection to help you analyze your team’s performance to adjust scope or make more accurate plans and estimates for the future Sprint. When talking about Sprints, there are three major reports you should focus on: Burndown chart: This report compares the number of Story Points that are left versus an approximation of an ideal burndown rate. Burnup report: This report is the opposite of the burndown chart. It compares completed work (the number of burned Story Points) versus an ideal burndown rate and the scope. Velocity chart: You can use this chart to plan your future sprints based on the amount of work that is typically done during a sprint. Apps That Help Run Sprints Smart Checklist: A Jira Checklist allows you to build actionable checklists and checklist templates. You can use them to enforce accountability and standardization. The app shines when you need to design and refine your stories allowing you to add clear and visible Definition of Done and Acceptance Criteria checklists to your issues. Planning Poker Online: This tool helps the team assign story points to their issues. The trick is that each member of the team assigns a certain value to an issue incognito. Then, when the cards are revealed, you’ll see whether the team has achieved a consensus regarding the complexity of the task. If you have different opinions – great. There’s room for discussion. The app has a Jira integration which makes it easy to include it in your process. Easy Retro: This App helps run Sprint retrospectives. It offers a board that’s similar to the one you are used to seeing in Jira. The difference is that the lanes are dedicated to things that went well, things that require improvements, and to actionable items or the things you can improve in the next Sprint. Easy Retro also offers surveys that help with gathering feedback.
TL; DR: Life Is a Negotiation; Why Would Scrum Be Different? Life is a negotiation. Why would Scrum be different, particularly given its egalitarian nature? As you may recall, no one on a Scrum team can tell anyone else what to do, how to do it, or when to do it. Instead, solving your customers’ problems in a complex environment requires communication skills, empathy, patience, diplomacy, and professionalism. So let’s have a look at some typical agile negotiation scenarios. Agile Negotiation Levels For Scrum to work well, it’s essential that the Scrum Team and stakeholders continuously discuss how to align their objectives, expectations, practices, and principles. These conversations guarantee the team can deliver customer value within the given constraints while contributing to the organization’s sustainability. While the Scrum Guide mentions several examples of this agile negotiation, many others derive from practicing agility in established organizations. There are different agile negotiation scenarios, the most prominent being the team-internal and team-stakeholder levels: Examples of Team-Internal Negotiations These areas cover the practical work of a Scrum team, from Product Backlog refinement to the Sprint to the Retrospective. As a result, the lists are far from comprehensive. However, they should allow for the discovery of additional scenarios to help prepare for them: The Product Backlog and Refinement Level Scope negotiation: The Product Owner, team members, and stakeholders discuss the project’s or product’s scope, negotiating any adjustments or changes that might be necessary. Product Backlog refinement: The Product Owner and Developers collaborate to refine, estimate, and order the Product Backlog items based on value, risk, and dependencies. Balancing technical debt and new features: The Scrum team needs to negotiate how to balance addressing technical debt while delivering new features, considering quality, maintainability, and customer and business needs, respectively. Acceptance Criteria: The Product Owner, Developers, and probably stakeholders negotiate the specific requirements that need to be satisfied for a Product Backlog item to be accepted. Estimating Effort: The Developers may negotiate the effort required to complete each Product Backlog item using techniques such as Planning Poker, T-Shirt Sizing, or the Bucket System. The Sprint Planning Level Sprint Goal: The Scrum team members align on a Sprint Goal, defining what the team aims to achieve based on the current Sprint’s business objectives. Technical decisions: Developers negotiate architectural choices, design patterns, and code practices to implement the best technical solutions. Allocating tasks and responsibilities: Developers negotiate the allocation of tasks and responsibilities based on their skills, expertise, and capacity among themselves. The Sprint Level Resolving conflicts and issues: Disagreements and conflicts may arise during the Sprint, requiring team members to negotiate and find solutions. Clarification of requirements: Developers may need further clarification or details on Product Backlog items from the Sprint Backlog. They might negotiate with the Product Owner to refine the acceptance criteria or other specifications to ensure a clear understanding of what they need to deliver. Changes in priority: Unforeseen events or changing business needs might lead to the Product Owner reevaluating the priority of certain Product Backlog items during the Sprint. The Developers and the Product Owner have to negotiate whether the team can accommodate the changes given the current Sprint Goal or whether they should be deferred to a future Sprint. On rare occasions, the outcome of this discussion may be a Sprint cancellation. Scope adjustments: Developers may discover that a Product Backlog item is more complex than initially estimated, requiring additional effort or time. The Developers and the Product Owner may need to negotiate a scope adjustment, such as deferring part of the work to a future Sprint. Technical decisions and trade-offs: Developers may encounter technical challenges or constraints that require them to make trade-offs between different solutions. They may need to negotiate with the Product Owner to align on the best approach, considering cost, time, maintainability, and performance factors. Impediments and blockers: Developers may encounter impediments or blockers during the Sprint that impact their ability to complete their work. They may need to negotiate with the Product Owner to find solutions, for example, reprioritizing tasks. Release Planning: The Scrum team members need to negotiate what the team will release to whom and when. The Sprint Review Level Sprint Review: During Sprint Review, the Scrum team and stakeholders review the work completed during the Sprint, discussing any potential improvements or changes to the product. Prioritization of feedback: Stakeholders may provide feedback on the Increment(s), and the Scrum team may need to negotiate the priority and urgency of addressing this feedback. This discussion could involve adding new Product Backlog items, modifying existing items, or ordering the backlog in alignment with the Product Goal. Timeline and release expectations: Stakeholders might have expectations about when certain features or capabilities will be available in the product. Consequently, the Scrum team may need to negotiate changes to their release timeline. Risk mitigation: Stakeholders might identify new risks or raise concerns about existing risks during the Sprint Review. The team and stakeholders will need to negotiate strategies for mitigating these risks and balancing them against other priorities. The Sprint Retrospective Level Reflecting on process improvements: During Sprint Retrospectives, the Scrum team discusses and negotiates potential process improvements and experiments for the next Sprint, aiming to optimize their way of working. Balancing improvement actions with Sprint work: The team may need to negotiate how much time and effort they can allocate to implementing improvement actions during the next Sprint, considering their other commitments and priorities. Prioritizing improvement actions: The Scrum team may identify several potential actions to address the improvement areas. They will need to negotiate and prioritize these actions based on impact, effort, and dependencies. Assigning responsibility and ownership: The team members may need to negotiate who will implement specific improvement actions and ensure their completion during the upcoming Sprints, a directly responsible individual (DRI). Reviewing past decisions and agreements: The team may revisit decisions or agreements made in previous retrospectives, evaluating their effectiveness and discussing whether they should be adjusted or maintained. They may need to negotiate any changes to these past agreements. Deciding on team norms and practices: The Scrum team members negotiate and agree on their working agreement, including communication norms, tools, and techniques that best support their collaboration and productivity. Addressing team dynamics and interpersonal issues: The team may discuss concerns about communication, collaboration, or trust among team members. They may need to negotiate how to address these issues through team-building activities, conflict resolution, or coaching. Definition of Done (DoD): The Scrum team negotiates and agrees upon the criteria a Product Backlog item must meet to be considered “done.” Agile Negotiation Examples at the Team-Stakeholder Level The agile negotiation scenarios between Scrum teams and stakeholders are significantly less obvious, as they largely depend on organizational and cultural conditions. Moreover, they rely on the kind of product or service offered. To provide minimum structure, I differentiate between three basic scenarios, from product alignment to coordination (of everyday work) to line management. Of course, there are multiple other areas a systematic approach to cataloging scenarios needs to consider: The Product Alignment Level Aligning on product vision and Product Goals: Stakeholders and the Product Owner may need to negotiate and align on the overall product vision, goals, and strategic direction, ensuring that the Scrum Team’s work supports the organization’s objectives. Prioritizing organizational initiatives: The Scrum team and stakeholders need to negotiate the prioritization of various organizational initiatives that may impact the team’s focus and capacity. Establishing a release plan: The Product Owner, management, and stakeholders collaborate and negotiate a release plan, balancing expectations, resources, and time constraints. Balancing stakeholder interests: The Scrum team must negotiate and manage the interests of multiple stakeholders, ensuring that they address their needs and concerns while focusing on delivering value. Setting and managing expectations: The Scrum team must negotiate with management and stakeholders to establish and manage expectations around delivery timelines, scope, and quality. Quality and compliance: The Product Owner and Developers may need to negotiate with stakeholders to define quality standards, regulatory requirements, or other compliance criteria that the Scrum Team must adhere to during product development. Risk management: The Product Owner and stakeholders may need to collaborate in identifying, assessing, and mitigating risks that might impact the project, negotiating risk prioritization and response strategies. The Coordination Level Stakeholder involvement and communication: The Product Owner and Scrum Master may need to negotiate the level and frequency of stakeholder involvement in the Scrum process, ensuring that stakeholders are informed and engaged while minimizing disruptions to the Scrum team’s work. Resource allocation: The Scrum team may need to negotiate with stakeholders to secure the necessary resources, such as equipment, tools, or budget, to deliver the product effectively. Managing organizational change: The Scrum team may need to negotiate with management and stakeholders to drive and support organizational change, such as adopting agile practices like Scrum, new tools, or structural changes. Reporting and metrics: The Scrum team and stakeholders may need to negotiate the types of reports, metrics, or KPIs used to track the Scrum Team’s progress and performance, ensuring that they provide valuable insights and support decision-making without creating undue overhead. Handling escalations and critical issues: When critical issues arise, the Scrum team, management, and stakeholders must negotiate and collaborate to address the situation, balancing the need for swift action with the team’s autonomy and process. Managing dependencies: The Scrum team may need to negotiate with other Scrum teams or departments to manage dependencies, coordinate work, and ensure a smooth delivery process. The Line Management Level Team composition: Scrum Team members and the management may need to negotiate the optimal team composition, considering factors such as skill sets, experience, and team dynamics. Moreover, they need to agree on how to identify new team members. Balancing individual and Scrum team goals: Team members may need to negotiate their personal development goals and aspirations with the collective goals and needs of the Scrum Team with the management. Career development: Line managers and Scrum team members may need to negotiate career development plans, including goals, training opportunities, and potential career paths within the organization. Compensation and benefits: Line managers and Scrum team members may need to negotiate whether existing individual compensation packages, including salary, bonuses, and other benefits, align with the needs of the Scrum team to work as a cohesive unit, not as a group of individuals. Performance management: Line managers, Scrum Masters, or agile leaders may need to negotiate performance expectations, feedback mechanisms, and evaluation criteria for team members. Conclusion Trying to exercise presumed authority over teammates or stakeholders or taking a crowbar as your tool of choice to solve problems and accelerate decisions won’t get you anywhere when working in a complex environment with agile teams. Instead, you better get good at continuous agile negotiation, as solving your customers’ problems in a complex environment requires communication skills, empathy, patience, diplomacy, and professionalism. How are you negotiating with teammates, stakeholders, and the management? Please share your experience with us in the comments.
As an executive leader, I know Agile can produce great results. Why would I not want to jump on board the bandwagon? My organization can do more with the same amount of people. All we need to do is change some processes that we use. I encourage or direct my groups to implement a new framework to accelerate all the above improvements and come back to me with a budget for what it will take. The opposite side of the coin can also be proper. Why would executives expect that implementing Agile would take this level of change? Did anyone tell them how the organization needs to change and how much they will need to be involved in the transformation? Probably not. Leaders usually request funds for training but need help getting the education behind what it will take to succeed. At a high level, the executives expected that they would have to train their people and they would instantly become Agile. They didn’t know that a mindset from the executives down to the recently hired needs to change, and it’s the executive's job to lead that transformation. The executives are the only people in the organization that can pivot without mercy or guilt and steer the ship in a new direction. Leadership participation is necessary; however, comprehending the change management that needs to occur is paramount. Many organizations will start small and implement Agile or Scrum in a few teams to see how it works. There are many eyes on this in these experiments. You have two specialty roles in Scrum: the Product Manager and the Scrum Master. The rest of the team members are called developers. A developer is an all-encompassing, cross-functional name that covers development, design, and testing. The Scrum team is supposed to be self-organizing and self-leading. This is fine until external dependencies with other teams are not working on the same priority or schedule. This is an example where if the organization was all on the same page and the leadership led the transformation, the scrum teams could work much better and not be slowed down by these impediments. The scrum teams continue to work well until the point where the organization has not changed slows them down. This is also where the naysayers, even those in the Agile Teams, say Agile will not work.Another example is the product owner (PO), who should own the team's backlog of work. The PO will create stories and prioritize the work the team should be working on. Unfortunately, they could be working in a functional silo and be unaware or not in sync with the Product Management team's needs and priorities. On top of the impediments already identified, the team will still be required to follow the governance around deployment and release. The beauty of a Scrum team is that the team should be able to make the decisions and deploy their work. The organization's release management may be set up to only minor monthly releases and quarterly product updates. This again adds more delays to the overall cycle time of the team. Additionally, the metrics the team may need to capture for the enterprise may no longer align with their framework. The Scrum teams feel powerless and unable to communicate upward to effect the necessary change. If someone is brave enough to address the concerns of the Scrum teams with the executives, they will most likely state that they have always supported what the team has asked for. In the mind of the executives, they paid for the retraining of the Scrum teams to act differently. The executives had no concept that they would need to change and effect it across the ecosystem to allow these Scrum teams to succeed. The Scrum teams see the executives as not supporting them. The executive feels that they did what was asked for. Where is the disconnect? The Executives were at A, and the Scrum Teams were at Z, but the organization never went through B to Y, nor did anyone tell them they needed to. What would be worse is that the organization knew they needed to do B to Y but chose not to because the executives were not leading them to do so. The most important question is, how do you make the executives want to lead the organization through steps B to Y? That is an easy answer, find out what is most valuable to them that you know you can deliver by implementing Scrum. For instance, SAFe promotes implementing the outcome of predictability above everything else. If you have predictability, you will naturally improve the speed to market, engagement, productivity, and quality of the products you deliver. If you take a lean approach to eliminate or lessen waste in our processes, productivity and market speed will increase. How do you lessen or eliminate waste? An example may be empowering your Scrum teams to deploy on their own. Another example may be having dependent teams working together in cadence and synchronization. The Scrum teams see the executives as not supporting them. The executive feels that they did what was asked for. Where is the disconnect? The Executives were at A, and the Scrum Teams were at Z, but the organization never went through B to Y, nor did anyone tell them they needed to. What would be worse is that the organization knew they needed to do B to Y but chose not to because the executives were not leading them to do so. Leaders must pay more attention to how long these process changes can take. Every organization is different, and no exact estimate works well across all. Bringing in trainers is an excellent first step, but what do you do once the team is out of training? The organization needs to understand that a rebuild of the way the organization works may be in order. A coaching group that leads organizations through what needs to be done and what needs to be accomplished is paramount. Please reach out to an experienced Agile Coaching organization.
AI's impact on Agile Project Management and Scrum Mastery will go from "interesting" to "total game-changer" faster than you think. My team and I have spent years at the intersection between AI and software creation. As a result, we have some fascinating conversations with product managers, product owners and project managers, Scrum masters, and the like. Probably people like you. So I wanted to write about the direction in which AI is taking agile, scrum, and project management. Excellent AI is still very green. Not all this tech is ready, but I will stick my neck out and say it will be in the next six months. TL;DR: Don't leave it until it's too late to explore how to integrate AI safely. Agile Planning Your development team is in the middle of a crucial sprint, and suddenly, an unforeseen issue arises, disrupting the entire project timeline. In tech, such hiccups can cost you dearly in terms of time and resources. Plus, you must figure out how to explain this to management and potentially your customer. But what if AI could help you anticipate and mitigate potential challenges before they even occur? Enter AI-powered predictive analytics. By tapping into historical data and employing advanced machine learning algorithms, predictive AI solutions can analyze patterns, identify trends, and forecast potential obstacles in your project's path. Let me give some examples. Estimations: Human estimates are flawed by nature. We're just not wired to do it. AI will enable realistic sprint planning, release planning, and better resource allocation. Risks: AI will be able to spot risks and bottlenecks far more consistently and – on average – faster than humans can. That means you can mitigate them before they cause problems. Prioritization: AI-powered analytics will be able to prioritize and adaptively reprioritize your product backlog efficiently. There will be far fewer overheads to this process when driven by AI, and it'll spot dependencies and keep everybody strategically aligned on what matters automatically. Collaboration The backbone of any successful Agile team lies in collaboration and effective communication. But keeping everyone on the same page is a huge time drain. Miscommunication (and its consequences) is among the most-mentioned frustrations of the PMs I speak to. That grows exponentially as the complexity (of projects and teams) increases. And that is not to mention the hours out of every day that engineers and PMs spend catching up on Slack or Teams, fishing through old messages to find resources, or working out what work has been done on other areas of the project. That time spent on information-seeking is, for most teams, necessary. But I think AI will turn that "time spent" into "time wasted." Let me illustrate: No more trawling. AI will be able to understand everything happening on every project you're working on and surface the important information from the tools you use, like Jira, Slack, Teams, and GitHub. All-knowing AI. LLMs are now more than good enough to allow you to ask any question you like about project progress, risks, or the like and give you a concise, actionable answer. Fewer, better meetings. For one thing, there should be no need in an AI world to spend time in meetings on progress updates or summarizing data. Instead, meetings will be more strategic and creative. I don't know many people in software who wouldn't leap at this one. Continuous improvement Continuous improvement is inherent to the agile methodology, the agile manifesto. It's all about enhancing your team's efficiency, productivity, and effectiveness with each sprint. I think AI represents an opportunity for a significant shift – or "step up," if you like – in how continuous improvement happens. Let's look at what this could look like for your team. 1. Quality: It's already possible to support processes like code review and deployment with AI, and the development process itself has a wealth of tools available. 2. Performance insights: AI is already available to help you understand your team's performance, identify patterns, and make data-driven decisions to improve your processes. It will be far more adept than humans at everything from high-level insights to highly granular and specific insights. Use them to pinpoint areas for improvement. In addition, it’s real-time and has almost no time overheads, which speeds the whole thing up and means the agile planning process can be far more dynamic. 3. Resource allocation: Make sure everyone is working on the tasks that align with their skills and strengths – or even their opportunity for growth. It's a win-win. You boost productivity, and your foster a more supportive culture. What Next? Let's turn down the hype for a moment. Right now, embracing AI to overhaul traditional project management and Scrum practices isn't an absolute must-have. After all, much of the tech is very green, with many AI tools in Beta or still using old underlying models (like GPT-3, which is fine but isn't going to change the world.) So you’re probably not losing significant ground over your competitors. However, This clock is ticking faster than any figurative time bomb I can remember. It will be a matter of months, not years, before at least partial adoption of AI software development tools is no longer a luxury but a necessity. Adopting and integrating the right tools safely will be the greatest challenge for team members who make decisions about tools for the agile cycle. It's pretty much a full-time job to keep up with advancements in AI.
When it comes to online services, uptime is crucial, but it’s not the only thing to consider. Imagine running an online store — having your site available 99.9% of the time might sound good, but what if that 0.1% of downtime happens during the holiday shopping season? That could mean losing out on big sales. And what if most of your customers are only interested in a few popular items? If those pages aren’t available, it doesn’t matter that the rest of your site is working fine. Sometimes, being available during peak moments can make or break your business. It’s not just e-commerce — a small fraction of airports handle most of the air traffic, just a tiny minority of celebrities are household names, and only a handful of blockbuster movies dominate the box office each year. It’s the same distribution pattern everywhere. To be successful, it’s important to not only maintain uptime but also be ready for significant events. Some teams implement change freezes before key times, such as Prime Day, Black Friday, or Cyber Monday. This approach is reasonable, but it can be limiting as it doesn’t allow teams to quickly respond to unexpected opportunities or critical situations. Additionally, not all demand can be predicted, and it’s not always clear when those high-impact events will happen. This is where “Reliability when it matters” comes in. We need to be able to adapt and respond quickly to changes in customer demand without being held back by code freeze periods and being prepared for unforeseen situations. By considering time as a valuable resource and understanding the relative significance of different moments, organizations can better translate customer value and adjust risk and availability budgets accordingly. This approach allows organizations to be flexible and responsive to changes in demand without missing out on crucial features or opportunities. In the end, it’s about being ready when luck comes your way. It’s important to note that a system is not static and is constantly changing. The system itself, the infrastructure it’s hosted on, and the engineering organization all change over time. This means that knowledge about the system also changes, which can impact reliability. Besides that, incidents and outages are inevitable, no matter how much we try to prevent them. Bugs will be shipped, bad configurations will be deployed, and human error will occur. There can also be interdependencies that amplify outages. An incident rarely has a single cause and is often a combination of factors coming together. The same goes for solutions, which are most effective when they involve a combination of principles and practices working together to mitigate the impact of outages. Operating a system often means dealing with real-world pressures, such as time, market, and management demands to deliver faster. This can lead to shortcuts being taken and potentially compromise the reliability of the system. Growth and expansion of the user base and organization can also bring additional complexity and result in unintended or unforeseen behaviors and failure modes. However, by adopting a holistic approach and utilizing the principles and practices of engineering I’m going to cover below, we can have the best of both worlds — speed, and reliability. It’s not an either-or scenario but rather a delicate balance between the two. What Is Reliability? Reliability is a vital component of any system, as it guarantees not only availability but also proper functioning. A system may be accessible, yet if it fails to operate accurately, it lacks reliability. The objective is to achieve both availability and precision within the system, which entails containing failures and minimizing their impact. However, not all failures carry equal weight. For instance, an issue preventing checkout and payment is far more crucial than a minor glitch in image loading. It’s important to focus on ensuring important functions work correctly during critical moments. In other words, we want to focus on being available and functioning correctly during peak times, serving the most important functionality, whether it be popular pages or critical parts of the process. Making sure systems work well during busy times is tough, but it’s important to approach it in a thoughtful and thorough way. This includes thinking about the technical, operational, and organizational aspects of the system. Key parts of this approach include: Designing systems that are resilient, fault-tolerant, and self-healing. Proactively testing systems under extreme conditions to identify potential weak spots and prevent regressions. Effective operational practices: defining hosting topology, auto-scaling, automating deployment/rollbacks, implementing change management, monitoring, and incident response protocols. Navigating the competing pressures of growth, market demands, and engineering quality. Cultivating a culture that values collaboration, knowledge sharing, open-mindedness, simplicity, and craftsmanship. It also requires a focus on outcomes in order to avoid indecision and provide the best possible experience for customers. Further, we’re going to expand on the concept of “Reliability when it matters” and provide practical steps for organizations to ensure availability and functionality during critical moments. We’ll discuss key elements such as designing systems for reliability, proactively testing and monitoring, and also delve into practical steps like automating deployment and incident response protocols. Reliability Metrics: A Vital Tool for Optimization When optimizing a service or system, it's essential to initially define your objectives and establish a method for monitoring progress. The metrics you choose should give you a comprehensive view of the system’s reliability, be easy to understand, share, and highlight areas for improvement. Here are some common reliability metrics: Incident frequency: the number of incidents per unit of time. Incident duration: the total amount of time incidents last. While these metrics are a good starting point, they don’t show the impact of incidents on customers. Let’s consider the following graph: Blue — the number of requests per five minutes, Red — errors, Green — reliability in 0..1 Suppose we have two incidents, one at 1 am and one at 2 pm, each causing about 10% of requests to fail for an equal duration of 30 minutes. Treating these incidents as equally impactful on reliability wouldn’t reflect their true effects on customers. By considering traffic volume, the reliability metric can better show that an incident during peak traffic has a bigger impact and deserves higher priority. Our goal is to have a clear signal that an incident during peak traffic is a major problem that should be fixed. This distinction helps prioritize tasks and make sure resources are used effectively. For example, it can prevent the marketing team’s efforts to bring more visitors from being wasted. Additionally, tracking the incident frequency per release can help improve the deployment and testing processes and reduce unexpected issues. In the end, this should lead to faster delivery with lower risks. Digging Deeper Into Metrics To get a deeper understanding of these metrics and find areas for improvement, try tracking the following: Time to detection: how long it takes to notice an incident. Time to notification: how long it takes to notify relevant parties. Time to repair: how long it takes to fix an incident. Time between incidents: this can reveal patterns or trends in system failures. Action item completion rate: the percentage of tasks completed. Action item resolution time: the time it takes to implement solutions. Percentage of high-severity incidents: this measures the overall reliability of the system. Finally, regularly reviewing these metrics during weekly operations can help focus on progress, recognize successes, and prioritize. By making this a regular part of your culture, you can use the data from these metrics to drive better decisions and gradually optimize the system. Remember, the usefulness of metrics lies in the actions taken from them and their ability to drive progress. It’s a continuous feedback loop of refining both the data and the action items to keep the system improving. Designing for Resilience A system that isn’t designed to be resilient probably won’t handle peak times as smoothly. Here are some considerations that can help ensure a system’s reliability under a variety of conditions: Do’s: Prepare for component failure: By partitioning the service or using isolation, you can limit the blast radius and reduce the impact of failures. Implement fault-tolerance: Implementing mechanisms like retries, request hedging, and backpressure will improve the system’s availability and performance. Use rate-limiting and traffic quotas: Don’t rely solely on upstream dependencies to protect themselves. Use rate-limiting and traffic quotas to ensure that your system remains reliable. Categorize functionality: Prioritize functions by categorizing them into “critical,” “normal,” and “best-effort” categories. This will help keep essential functions available at all costs during high demand. Implement error-pacing and load-shedding: These mechanisms help prevent or mitigate traffic misuse or abuse. Continuously challenge the system: Continuously challenge the system and consider potential failures to identify areas for improvement. Plan for recovery: Implement fail-over mechanisms and plan for recovery in the event of a failure. This will help reduce downtime and ensure that essential services are available during challenging conditions. Make strategic trade-offs: Make strategic trade-offs and prioritize essential services during challenging external conditions. Dont’s: Don’t assume callers will use your service as intended. Don’t neglect rare but potential failures; plan and design prevention measures. Don’t overlook the possibility of hardware failures. I explored some of the ideas in the following blog posts: Ensuring Predictable Performance in Distributed Systems Navigating the Benefits and Risks of Request Hedging for Network Services FIFO vs. LIFO: Which Queueing Strategy Is Better for Availability and Latency? Isolating Noisy Neighbors in Distributed Systems: The Power of Shuffle-Sharding Reliability Testing Reliability testing is essential for maintaining the availability and functionality of a system during high demand. To ensure a reliable system, it is important to: Design for testability so each component can be tested individually. Have good enough testing coverage as a prerequisite for being agile. Calibrate testing by importance, focusing on essential functions and giving a bit of slack to secondary or experimental features. Perform extensive non-functional testing, such as load testing, stress testing, failure-injection testing, soak testing, and fuzzing/combinatorial testing. It’s crucial to avoid: Blindly pursuing high coverage numbers. Assuming that a single data point provides a comprehensive understanding. Ensure that results are robustly reproducible. Underinvesting in testing environments and tooling. Proper testing not only ensures correctness, serves as living documentation, and prevents non-functional regressions but also helps engineers to understand the system deeper, flex their creative muscles while trying to challenge them, and ultimately create more resilient, reliable systems for the benefit of all stakeholders. Remember, if you don’t deliberately stress test your system, your users will do it for you. And you won’t be able to choose when that moment comes. Reliability Oriented Operations Operating a distributed system is like conducting an orchestra, a delicate art that requires a high level of skill and attention to detail. Many engineers tend to underestimate the importance of operations or view it as secondary to software development. However, in reality, operations can have a significant impact on the reliability of a system. Just like a conductor’s skill and understanding of the orchestra is vital to ensure a harmonious performance. For example, cloud computing providers often offer services built on open-source products. It’s not just about using the software but how you use it. This is a big part of the cloud computing provider business. To ensure reliability, there are three key aspects of operations to consider: Running the service: This involves hosting configuration, deployment procedures, and regular maintenance tasks like security patches, backups, and more. Incident prevention: Monitoring systems in real-time to quickly detect and resolve issues, regularly testing the system for performance and reliability, capacity planning, etc. Incident response: Having clear incident response protocols that define the roles and responsibilities of team members during an incident, as well as effective review, communication, and follow-up mechanisms to address issues and prevent similar incidents from happening or minimize their impact in the future. The incident response aspect is particularly crucial, as it serves as a reality check. After all, all taken measures were insufficient. It’s a moment of being humble and realizing that the world is much more complex than we thought. And we need to try to be as honest as possible to identify all the engineering and procedural weaknesses that enabled the incident and see what we could do better in the future. To make incident retrospectives effective, consider incorporating the following practices: Assume the reader doesn’t have prior knowledge of your service. First of all, you write this retrospective to share knowledge and write clearly so that others can understand. Define the impact of the incident. It helps to calibrate the amount of effort needed to invest in the follow-up measures. Only relatively severe incidents require a deep process, do not normalize retrospectives by having them for every minor issue that doesn’t have the potential to have a lasting impact. Don’t stop at comfortable answers. Dig deeper without worrying about personal egos. The goal is to improve processes, not blame individuals or feel guilt. Prioritize action items that would have prevented or greatly reduced the severity of the incident. Aim to have as few action items as possible, each with critical priority. In terms of not stopping at the “comfortable answers,” it’s important to identify and address underlying root causes for long-term reliability. Here are a few examples of surface-level issues that can cause service disruptions: Human error while pushing configuration. Unreliable upstream dependency causes unresponsiveness. Traffic spike leading to the temporary unavailability of our service. It can be difficult to come up with action items to improve reliability in the long term based on these diagnoses. On the other hand, deeper underlying root causes may sound like: Our system allowed the deployment of an invalid configuration to the whole fleet without safety checks. Our service didn’t handle upstream unavailability and amplified the outage. Our service didn’t protect itself from excessive traffic. Addressing underlying root causes can be more challenging, but it is essential for achieving long-term reliability. This is just a brief overview of what we should strive for in terms of operations, but there is much more to explore and consider. From incident response protocols to capacity planning, there are many nuances and best practices to be aware of. The Human Factor in System Reliability While procedures and mechanisms play a vital role in ensuring system reliability, it is ultimately the humans who bring them to life. So, it’s not just about having the right tools but also cultivating the right mindset to breathe life into those mechanisms and make them work effectively. Here are some of the key qualities and habits that contribute to maintaining reliability (and not only): Collaboration with other teams and organizations in order to share knowledge and work towards a common goal. A degree of humility and an open-minded approach to new information in order to adapt and evolve the system. A focus on simplicity and craftsmanship in order to create evolvable and maintainable systems. An action-driven and outcome-focused mindset, avoiding stagnation and indecision. A curious and experimental approach akin to that of a child, constantly seeking to understand how the system works and finding ways to improve it. Conclusion Ensuring reliability in a system is a comprehensive effort that involves figuring out the right metrics, designing with resilience in mind, and implementing reliability testing and operations. With a focus on availability, functionality, and serving the most important needs, organizations can better translate customer value and adjust risks and priorities accordingly. Building and maintaining a system that can handle even the toughest conditions not only helps drive business success and pleases customers but also brings a sense of accomplishment to those who work on it. Reliability is a continuous journey that requires attention, skill, and discipline. By following best practices, continuously challenging the system, and fostering a resilient mindset, teams, and organizations can create robust and reliable systems that can withstand any challenges that come their way.
Jasper Sprengers
senior developer,
Team Rockstars IT
Alireza Chegini
DevOps Architect / Azure Specialist,
Smartwyre
Dr. Srijith Sreenivasan
Director,
Schneider Electric
Martin Fowler