Agile

Developer teams are no strangers to daily standup meetings. Their success in increasing collaboration and visibility has led to their adoption in different types of teams and projects. Every day the whole team has a standup agenda meeting where developers and other team members proactively align with the project and delivery goals, share progress with the team, and be on top of blockers. There are, however, developers who despise standup meetings because they are hyper-vigilant about even the most subtle indicators of unproductivity. They dislike regular standup meetings because they see no advantage to their work. Instead, they think that the daily meeting has little use to their skills and productivity, and they choose to work on projects rather than attend meetings. However, when run effectively, daily standups can be a huge factor in making significant progress in projects and eliminating blockers quickly. This is certainly a more proactive approach to leading dev teams rather than waiting for things to happen and then realizing things are going bad and having to fix them with no time in hand. Whether you are a scrum master or an engineering manager, or a developer, we have created a guide on how to run a short and effective standup and things to avoid while running standups in great detail in this blog. Keep on reading! What Occurs at a Standup Meeting Every Day? A daily standup meeting mostly lasts about 15 minutes and is often held at the beginning of the working day. Daily scrum meetings are attended by the development team, the scrum master, and the development manager in most cases. The participants vary for different teams and organizations depending on the structure of teams and how they define roles within the organization. Many teams may also not follow scrum and hence will have no scrum masters. Essentially all stakeholders involved in the day-to-day activities of a project must be present in the standup to make it effective. This also enables everyone to have clear action items after the standup. Each team member responds to the following three questions at the daily scrum: 1. What Did You Do Yesterday? This is nothing but providing an update on what progress you made yesterday on the tasks assigned to you. You shouldn’t go in too deep and too technical while providing this update. Given this is a place where most of your team will be present, it should be looked at as an opportunity to increase visibility within the team and, at the same time, help managers and other stakeholders understand the progress on different tasks. 2. What Will You Do Today? By answering this question, you are essentially laying out your plan for the day. Firstly, and importantly it brings clarity to you because when you are answering this question, you are putting in the effort to think about what should be done today. Secondly, it also makes the managers and other stakeholders understand what progress to expect in all the tasks today and helps them re-prioritize tasks if needed. 3. What Is Blocking Your Progress? Answering this will help to identify what will block the task that you are working on from going to completion or progress today. Eliminating these blockers is essential to help manage feature deliveries and to keep them on track. This helps stakeholders to gauge whether things are going on as planned and what needs to be done if they are not going on as planned. Any sort of simple realignment that needs to be done can be done here. When and Where Should You Run Daily Scrum Meetings? For teams that are working out of the same office, it is better to have standups at the same place and time every day. Ideally, it should take place in the morning so that everyone can start their days with this. But this gets tricky with remote teams post-pandemic and for teams with members from different time zones. In these cases, you may be tempted by the idea of having asynchronous standups. But we think it shouldn’t be done even though the benefits of doing so :). For the simple reason that standups give a great opportunity to increase visibility within the team and help to keep everyone in the loop. You involve everyone in decision-making by doing standups and fostering a collaborative environment within the team. Efforts should be made to work out a convenient time for everyone on the team for a standup meeting, and it should be done virtually through zoom/meet if needed. Seven Tips for Making the Most of Your Daily Standup Meetings 1. Start With Clearing Out What a Standup Meeting Is and Is Not The standup’s primary goal is to improve visibility and project flow through faster feedback. Every 24 hours, feedback boosts project velocity and allows the team to make immediate modifications to keep the project running smoothly. On the other hand, it is too late if you wait a week to get the inputs you needed seven days ago. It is supposed to be short and not meant to run more than 15-20 mins. Any longer discussion can be done with subsequent meetings with a limited set of people who are needed for the discussion. 2. Stick to the Start Time Meetings should start at the scheduled time every day, and the schedule should be strictly followed even if some team members are late. That team member could also be you as a manager. It just doesn’t make sense to have the whole team waiting on a single member, and all the more reason for you to be punctual in these meetings. Additionally, accommodate team members for whom the standup time is inconvenient and who are not able to attend standup meetings regularly due to this. 3. Prepare Your Questions To Ask During the Meeting As a manager or a scrum master, you should decide beforehand what questions you need to get answered in the standup in addition to the standup agenda. Additionally, throughout the meeting, also try to figure out blockers and how to resolve them. Furthermore, meetings post the standup is better for in-depth technical conversations. You should intervene when the discussion goes on for long and facilitate meetings post the standup for these critical discussions. 4. Keep the Meeting Interesting Since it's crucial to keep meetings brief and to the point, it's crucial for the success of the meeting that every participant participates fully and sincerely throughout. Each meeting should begin by making everyone at the meeting relaxed and included. You might employ a set of rules to choose who would speak next. This would ensure that everyone has an equal opportunity to speak while still having a good time. 5. Prioritize Workload Everyone aspires to do well. But the workload from competing initiatives frequently overwhelms team members. Daily meetings help make sure priorities are clear and accurate. A team member may be working on the incorrect thing, and important tasks may be unduly delayed if they are overburdened. Make sure team members' priorities are clear, accurate, and manageable at the daily scrum meeting. 6. Prioritize Unresolved Issues The daily scrum meeting is primarily intended to inform team members about what is being done, what needs to be done, and what obstacles prevent those tasks from being completed. Anything else has to be taken care of apart from this. Define a "parking lot" and list the problems that need to be resolved afterward. Set up a follow-up meeting with just the attendees who have a direct stake in that topic after the initial one has ended. You might keep track of the subjects that should be covered by each sub-division and require a longer discussion. The team members should have access to these "parking lots" outside the daily standup sessions so they may list the issues that need to be resolved. This keeps them present and prevents them from thinking about unrelated things during their regular standup sessions. 4. Keep the Meeting Interesting This will act as a day starter for most team members. Nothing kills the enthusiasm of team members more than a dull and boring standup meeting. Your job as a manager or scrum master is to also make sure that everyone feels motivated to complete the tasks assigned to them quickly and to collaborate with team members in the meeting. This is one of the things that, if done right, can create a close-knit and cohesive team. Three Things To Avoid in Daily Standup Some individuals may feel that standup meetings are a waste of time; however, holding effective standup meetings among teams instills team spirit, enhances productivity, and allows you to discuss challenges you're encountering in order to achieve your goals. If you go further, you'll find that this is typically a result of teams needing to use stand-up meetings effectively, which should be a systematic and quick approach to get a solid feel of what's happening with the team, coordinate work, and eliminate any obstacles. Numerous factors can cause standup meetings to derail and be badly handled. Still, over the years, we've discovered that most of these "bad habits" can be reduced to one of the crucial standup mistakes listed below. 1. Misalignment Discussing for long periods about topics that are in no way connected to the work of others. Or maybe something that concerns one colleague in a group of six people. As a result, other team members need more time to listen to unimportant information instead of concentrating on important tasks that can be time-sensitive. Additionally, if you listen to a coworker discuss something for long, for which you are not required to be there, in this case, you risk cognitively disengaging for the remainder of the standup and missing crucial information. 2. Inconvenient Meeting Time For instance, the daily scrum might be scheduled when you're coding or making progress on a difficult task, which would be disruptive or unpleasant. Coordinating schedules and accounting for calendar conflicts and time zone variances is challenging. Getting the complete crew to arrive at a standup simultaneously should be prioritized at all costs. 3. Too Lengthy People could have side chats or water cooler banter (instead of work-focused updates). Someone may begin to ramble and take five minutes to finish their thought (it's rather usual for people to offer too much information and support their actions with unnecessary details to sound more impressive). Final Thoughts Thanks to the daily standup meeting, your team and you will benefit from having common knowledge of your goals. You can ensure that your team is productive by holding this meeting to ensure everyone is working toward the same objective. Daily scrum meetings are an efficient approach to ensure that everyone on your team is committed. You will have the opportunity to point out issues and suggestions at the meeting.

TL; DR: A ChatGPT Job Interview for a Scrum Master Position Can a large language model, not specializing in anything “agile,” pass a screening interview for a Scrum Master position? In this ChatGPT job interview, I put OpenAI’s latest generative AI to the test. I took several questions from the 73 Scrum Master Interview Questions guide (see below), covering the whole spectrum from the broad picture to more specific questions, only answerable with hands-on experience on the interviewee’s side. So, read on and learn whether Scrum Masters will soon be replaced with a chatbot. Interviewing ChatGPT The task for this ChatGPT job interview session was to create a screening interview of about 30 minutes to decide whether to proceed with a fictitious application for a Scrum Master position by ChatGPT. All questions are from the 73 Scrum Master Interview Questions guide, including guidance on suitable answers. (For example, “Q 03” refers to the third question of the guide.) I ran the ChatGPT interview session on two days: On 2022-12-18, from 4:00-4:40 pm CET, and on 2023-01-08, from 6:10-6:45 am CET. I did not edit ChatGPT’s answers. I used follow-up questions to explore the model when ChatGPT did not provide obvious answers. The Opening Question of the ChatGPT Job Interview Question: Thank you for your application as a Scrum Master! Why would you be a good fit for the position? ChatGPT’s answer: Thank you for considering me for the Scrum Master position! I believe I would be a good fit for the role because I have a strong understanding of Scrum and the Agile framework, and I am able to communicate and facilitate effectively with team members and stakeholders. I am also able to handle conflicts and facilitate discussions to find solutions, and I am skilled at helping teams adhere to Scrum values and practices. In addition, I am able to adapt to new situations and environments, and I am committed to continuous learning and improvement. Comment: Thumbs up; we just ignore the lack of working experience. Follow-up question: Why is it beneficial that the team adheres to the values and practices of Scrum? ChatGPT’s answer: Adhering to the values and practices of Scrum can provide a number of benefits to a development team, including: Increased transparency: Scrum emphasizes transparency and openness, which can help team members better understand what their colleagues are working on and how their work fits into the overall project. This can help improve communication and collaboration within the team. Improved adaptability: Scrum emphasizes the importance of being able to adapt to change and respond to new information as it becomes available. This can help the team be more agile and responsive to changing circumstances or requirements. Enhanced focus: By following the Scrum framework, the team can focus on delivering value in small increments, rather than trying to complete all the work at once. This can help the team stay motivated and make progress more consistently. Increased accountability: Scrum requires team members to take ownership of their work and be accountable for meeting their commitments. This can help improve the overall quality of the team's work and ensure that the team is meeting its goals. Overall, adhering to the values and practices of Scrum can help a development team work more effectively and efficiently, and deliver better results. Comment: I am starting to like this! Q 03: The Scrum Master as a Problem Fixer Question: Should a Scrum Master remove problems on behalf of the Scrum Team? Guidance: A Scrum Master should not be concerned with removing problems that the Scrum Team can solve themselves, no matter how often this requirement is mentioned in job advertisements. If a Scrum Master acts like a "Scrum parent," their team will never become self-organizing. A Scrum Team must learn to make its own decisions. Typically, this inevitably results in failures, dead-ends, and other unplanned excursions when the team is learning something new. Consequently, in the beginning, a team will need more guidance than usual from the Scrum Master. Such advice should not, however, become an exercise in protective “parenting” — a team must be allowed to learn from their failures. That being said, there is one area where the Scrum Master is indeed removing problems on behalf of the team. This Scrum Master stance applies when the Scrum Team cannot solve the problem themselves, for example, because the issue is an organizational problem. Now we are talking about “impediments.” In this situation, the Scrum Master becomes the impediment remover of the Scrum Team. ChatGPT’s answer: It is not the responsibility of the Scrum Master to remove problems on behalf of the Scrum team. The Scrum Master's primary role is to serve the Scrum team and protect it from external interruptions and distractions. However, the Scrum Master can assist the team in finding ways to resolve problems and remove barriers to progress. The Scrum team is responsible for solving their own problems and finding ways to improve their processes and work. The Scrum Master can help by coaching the team, facilitating discussions, and providing support and guidance as needed. However, it is important for the Scrum team to take ownership of their own problems and work together to find solutions, rather than relying on the Scrum Master to remove problems on their behalf. Comments: ChatGPT’s answer is a reasonable interpretation of a Scrum Master’s accountabilities, stressing the importance of helping the team to support themselves. A team must embrace ownership of its problem and solution space and its way of working. Q 10: Overcoming Stakeholder Resistance Question: You’ve already provided your product’s stakeholders with training in Scrum. However, after the initial phase of applying the concepts, when the first obstacles are encountered, some of these stakeholders begin to resist continued adoption. What is your strategy for and experience in handling these situations? Guidance: This question is meant to encourage an exchange of ideas and lessons learned when overcoming resistance to Scrum within an organization. In addition, familiarity with agile failure patterns common to many organizations will demonstrate your candidate’s experience. Your candidate should also be familiar with the challenge middle managers face in any transition to agile practices. For example, moving from a command-and-control style (i.e., managing people and telling them what to do) to a servant-leadership kind — thus abandoning Taylor’s principles — is not for everyone. ChatGPT’s answer: As a language model, I don't have personal experience in handling situations where stakeholders resist the continued adoption of Scrum. However, here are some strategies that a Scrum Master might consider when faced with this challenge: Identify the root cause of the resistance: It's important to understand why the stakeholders are resisting the continued adoption of Scrum. Are they unsure of the benefits, or do they have concerns about the impact on their work? Understanding the root cause can help the Scrum Master address the issue more effectively. Communicate the benefits: The stakeholders may not fully understand the benefits of Scrum, or they may be skeptical about its value. It can be helpful to communicate the benefits of Scrum in a way that is relevant to the stakeholders and addresses their concerns. Encourage stakeholder involvement: Involving stakeholders in the Scrum process can help them see the value of the framework and feel more invested in its success. The Scrum Master can encourage stakeholder participation in Scrum events, such as the sprint review and retrospective. Provide ongoing support and education: It can be helpful to provide ongoing support and education to help stakeholders understand the Scrum process and how it can benefit them. This could include regular check-ins, training sessions, or one-on-one coaching. Be flexible: It's important to remember that every team and organization is different, and the Scrum process may need to be adapted to fit the specific needs and challenges of the team. The Scrum Master should be open to making adjustments as needed to ensure the continued success of the framework. Regenerated Response: There are a few strategies that a Scrum Master might use when stakeholders resist the continued adoption of Scrum: Educate stakeholders about the benefits of Scrum: It's possible that some stakeholders may not fully understand the benefits of Scrum or how it can help the team and the organization. In these cases, it may be helpful to educate stakeholders about the specific ways in which Scrum can improve the team's performance and deliver value more quickly. Communicate the team's progress: One way to demonstrate the value of Scrum is to regularly communicate the team's progress to stakeholders. By showing stakeholders the progress that the team has made and the value that has been delivered, you can help them see the benefits of Scrum and the value it brings to the organization. Address concerns and challenges: If stakeholders have specific concerns or challenges with Scrum, it's important to listen to their concerns and work with them to address these issues. This may involve finding ways to address their concerns or adapting the way the team is using Scrum to better meet their needs. Emphasize the importance of following the Scrum framework: Ultimately, it's important to remind stakeholders that Scrum is a proven framework that has helped many teams and organizations succeed. By following the values and practices of Scrum, the team can work more effectively and efficiently, and deliver better outcomes for the organization. As a language model, I do not have any personal experience with handling these types of situations. However, I can provide general guidance based on my understanding of Scrum and the principles of effective communication and conflict resolution. Comment: This answer is an exciting moment in the ChatGPT job interview! ChatGPT admits having no first-hand experience in the situation. (Which would be surprising, to say the least.) However, ChatGPT also manages to overcome the awkward “I do not know” situation by moving to the metalevel and applying general communication and conflict resolution principles to a Scrum team’s stakeholder relations. Q 19: The Feasible Sprint Goal Question: What factors should a Scrum Team consider at the Sprint Planning to determine a feasible Sprint Goal? Guidance: Typical criteria for a Scrum team to consider are, for example: Who will be present during the Sprint; is there anyone on holiday or sick leave? Do people leave the team that requires a last-minute knowledge transfer, or do new team members need proper onboarding? Will there be public holidays during the Sprint? Do we have all the tools necessary, and are we familiar with those? Are we familiar with the part of the application we will work on? Or is this terra incognita? Are we facing any dependencies on other teams? What level of address technical debt do we need to address? What was the Scrum team’s past performance? As any Scrum team plays an infinite game, there are no winners. Most likely, Stakeholders will regard a Scrum team as successful when it creates value for customers and the organization every single Sprint. Therefore, from a team perspective, building rapport and trust with stakeholders requires more Wall Street-like expectation management: stakeholders value a reliable delivery more than a sporadic outburst of productivity. This understanding should guide the Scrum team in determining feasible Sprint Goals. ChatGPT’s answer: There are a number of factors that a Scrum team should consider when determining a feasible Sprint Goal during the Sprint Planning event. These factors include: The team's capacity: The team should consider how much work they can realistically complete during the sprint, based on their capacity and available resources. It's important to set a goal that is challenging but achievable, given the team's capacity. The work required to achieve the goal: The team should consider the work that will be required to achieve the goal, including the complexity of the tasks and the amount of effort that will be needed. Dependencies: The team should consider any dependencies that may impact the ability to achieve the goal, such as work that needs to be completed by other teams or external factors that may impact the team's progress. The team's previous performance: The team should consider their past performance and how much work they have typically been able to complete in previous sprints. This can help the team set a realistic goal for the current sprint. The team's long-term goals: The team should consider the long-term goals of the project and how the work completed during the sprint will contribute to those goals. By considering these factors, the team can set a feasible Sprint Goal that is challenging but achievable, and that will help the team make progress towards the long-term goals of the project. Follow-up question: What about technical debt and available skills? ChatGPT’s answer: Technical debt and available skills are also important factors to consider when determining a feasible Sprint Goal. Technical debt refers to the accumulation of technical challenges and problems that a team has not yet addressed. These challenges can slow down the team's progress and make it harder to achieve the Sprint Goal. When determining a feasible Sprint Goal, the team should consider the amount of technical debt that needs to be addressed and whether they have the capacity to address it within the sprint. Available skills are another important factor to consider. The team should consider the skills and expertise of each team member and how they can be leveraged to achieve the Sprint Goal. If the team lacks certain skills that are needed to complete the work, they may need to adjust the goal or find ways to acquire the necessary skills. By considering technical debt and available skills, the team can set a feasible Sprint Goal that takes into account the challenges and constraints that may impact their ability to achieve it. This can help the team work more effectively and efficiently, and ultimately deliver better outcomes for the project. Comment: Okay, this part of the ChatGPT job interview needed a follow-up question to also identify existing technical debt and the team’s skill sets as determining factors for the Sprint Goal determination. Otherwise, identifying five out of eight factors straight away is not bad either. Q 27: The "Definition of Ready" Question: Is it okay to use a "Definition of Ready" as a Scrum Team? Guidance: Using a "Definition of Ready" depends on the Scrum team’s situation. For example, suppose it is a junior team still struggling with the mechanics of Scrum. In that case, it might be a temporarily helpful way of taking some of the pressure off the team during Product Backlog management, refinement, and Sprint Planning. On the other hand, a senior Scrum team will have found its mojo and won’t need to rely on training wheels. However, suppose the "Definition of Ready" is used dogmatically as a checklist, rejecting all work items during Sprint Planning that are not 100 percent covered by this new standard. In that case, you are reintroducing waterfall through the backdoor; only the Developers are doing that this time. Even worse would be the organization’s use of a "Definition of Ready" as a team metric or indicator for a Scrum team’s “fluency” in agile product development. ChatGPT’s answer: Yes, it is generally acceptable for a Scrum team to use a "Definition of Ready" (DoR) to guide their work. A DoR is a set of criteria that a team defines to determine when a product backlog item is ready to be included in a sprint. The purpose of a DoR is to ensure that the team has a clear understanding of the work that needs to be done and is fully prepared to complete it. By having a DoR, the team can avoid starting work on items that are not fully understood or that are not ready to be completed, which can help them work more efficiently and effectively. A DoR should be specific to the needs of the team and the project, and may include criteria such as: The item is clearly defined and understood by the team The item has all necessary acceptance criteria defined The item has been properly sized and estimated All necessary dependencies have been identified All necessary resources (e.g. tools, data, etc.) are available. Using a DoR can help a Scrum team ensure that they are working on the right items at the right time and that they have the necessary information and resources to complete the work. However, it's important to note that the DoR should be a living document that the team continually updates and adjusts as needed to meet the changing needs of the project. Comment: While I am not generally supportive of applying a DoR as these kinds of training wheels can quickly turn into something malicious, ChatGPT delivered the positive aspects of having one. In a ChatGPT job interview, though, I would appreciate a hint that the DoR concept extends to Scrum. Q 41: Luring Stakeholders to the Sprint Review Question: What can a Scrum team do to get stakeholders to attend the Sprint Review? Guidance: In my experience, you need to “sell” the Sprint Review within the organization, at least at the beginning of using Scrum: Help the stakeholders understand the Sprint Review’s importance by educating them properly: Organize workshops, run office hours, etc. Provide regular, helpful communication to stakeholders, for example, a newsletter detailing the Scrum team’s work that proceeds the Sprint Review. Try and convince higher management to regularly attend the team’s Sprint Reviews. The prospect of having face-time with this individual is often highly motivating for stakeholders to attend, too. Choose a stakeholder-friendly calendar slot for the Sprint Review. Scheduling Sprint Reviews on a Monday morning or Friday afternoon is a rookie mistake. The same applies to the location of the Sprint Review. Consider in advance how to provide the best experience for a hybrid setting. (In-person and remote attendees.) Advertise your Sprint Review; for example, place leaflets in the canteen or cafeteria or communication the date & time in corporate messaging channels or networks. Be creative! Tackle the problem by addressing it at the next Retrospective and ask for the support of the whole Scrum team to remedy the issue; it is not just something between the Product Owner and the Scrum Master. ChatGPT’s answer: There are a few things that a Scrum team can do to encourage stakeholders to attend the Sprint Review: Communicate the value of the Sprint Review: Stakeholders may be more likely to attend the Sprint Review if they understand the value it brings to the project. The team can communicate the benefits of the Sprint Review, such as the opportunity to see the team's progress and provide feedback, and the opportunity to align on the direction of the project. Invite stakeholders in advance: It's important to give stakeholders enough notice of the Sprint Review so they can plan to attend. The team can send out invitations well in advance of the meeting and follow up with reminders as the date approaches. Make the Sprint Review engaging and interactive: Stakeholders may be more likely to attend if they find the Sprint Review engaging and interactive. The team can use techniques such as demonstrations, demos, and interactive presentations to make the meeting more interactive and engaging. Encourage participation: The team can encourage stakeholders to participate in the Sprint Review by asking for their feedback and input. This can help stakeholders feel more invested in the project and more motivated to attend future Sprint Reviews. Overall, it's important for the team to communicate the value of the Sprint Review to stakeholders and make the meeting as engaging and interactive as possible to encourage attendance. Comment: Another acceptable ChatGPT job interview answer. I would give bonus points for pointing to the necessity to educate stakeholders on how Scrum as a framework is supposed to work and how stakeholders can contribute to a Scrum team’s success; for example, by attending the Sprint Review and providing feedback. Q 52: Volatile Velocity Question: Your Scrum Team consistently fails to meet forecasts and Sprint Goals, and their velocity is volatile. What are the probable reasons for this problem, and how would you address it with the team? Guidance: Your candidate should discuss the notoriety of ‘velocity’ as the industry’s most prevalent metric for measuring a team’s progress. They should further be able to explain why velocity is altogether a doubtful agile metric and point out that quantitative metrics are not ideally suited to measuring a team’s progress in mastering Scrum. Many factors contribute to a Scrum Team’s velocity volatile: New team members being onboarded; Experienced members leaving the team; The team working in uncharted territory; The team working with legacy code, probably undocumented; The team running into unexpected technical debt; Holidays and sick leave reducing the team’s capacity; An executive intervention changing Sprint’s scope; and The team is addressing unplanned priority bugs. Another common cause for a Scrum Team to consistently fail in meeting their forecasts is that the team’s Product Backlog items are poorly prepared, thus making the work items difficult for the team to understand. Conversely, the projects given to the team might suffer from poorly documented legacy code, excessive technical debt, or too much buggy and badly written code — all of which make estimation a gamble. Finally, your candidate should not align themselves with the fallacy that a team’s adoption of Scrum is working only because a Scrum Team’s forecasts and velocity are aligned. Cooking the agile books is easy to do! ChatGPT’s answer: There are a number of reasons why a Scrum team may consistently fail to meet forecasts and Sprint Goals, and their velocity may be volatile. Some possible reasons for this problem include: Lack of clear goals: If the team does not have clear goals or a clear understanding of what they are trying to achieve, it may be difficult for them to make progress or accurately forecast their work. Poor estimation: If the team is not accurately estimating the size and complexity of their work, they may not be able to accurately forecast their progress or set realistic goals. Scope creep: If the team is not effectively managing scope and the scope of their work is constantly changing, it may be difficult for them to make progress or accurately forecast their work. Poor collaboration and communication: If the team is not effectively collaborating and communicating with each other, it may be difficult for them to coordinate their work and make progress towards their goals. To address these problems with the team, the Scrum Master could: Help the team define clear goals and objectives for each sprint, and make sure that everyone on the team understands what they are trying to achieve. Work with the team to improve their estimation skills, and help them understand how to accurately estimate the size and complexity of their work. Help the team effectively manage scope by setting clear boundaries and establishing a process for managing and prioritizing changes to the scope of their work. Encourage the team to improve their collaboration and communication skills, and facilitate discussions and problem-solving sessions to help them work more effectively as a team. By addressing these issues and helping the team develop the necessary skills and processes, the Scrum Master can help the team make progress towards their goals and improve their velocity. Comment: ChatGPT mentioned a few general things that help with predictability. However, insisting on an “accurate[ly] forecast” is problematic, as there is no such thing in a complex environment. Also, there is no mention of the importance of Product Backlog refinement and the early involvement of team members in the general product discovery progress, all of which help to improve forecasting. The ideas of how a Scrum Master could support their team are merely a repetition of the first list and thus not helpful with the ChatGPT job interview in general. So far, this is the weakest answer of the ChatGPT job interview for a Scrum Master position. Q 56: Creating the First Scrum Team Question: How would you create the first Scrum Team in your organization? Guidance: When an organization is transitioning to Scrum and at the same time dealing with significant organizational, business, and technical problems, the founding members of its Scrum Teams should be volunteers who fully understand the challenge ahead of them rather than people pressed into service. The best volunteers are those eager to prove that becoming agile is the most effective way to reach an objective. Candidates for the role of Scrum Master should be astute enough to suggest inviting every member of the product delivery team, as well as the C-level executives sponsoring the transition, to a kickoff meeting. The objective of a transition kickoff meeting is to support the members of the engineering and product teams in how they choose to self-organize into the first cross-functional Scrum Teams. Transition kickoff meetings can last a few hours or several days, depending on the circumstances of a particular organization. Despite the importance of the kickoff meeting to a Scrum transition, going much deeper into its structure will take too much time from the interview. So instead, it’s more important that your candidates embrace the idea of team self-selection and present a brief roadmap of what should happen next for the newly formed Scrum Teams. Although somewhat dependent upon the existing skills, experience, and training of the members of an organization’s new Scrum Teams, your candidates should anticipate having to teach the very basics of Scrum following a kickoff meeting. They might propose doing this through a series of workshops or on-the-job training with exercises in Product Backlog refinement, writing user stories, estimating, creating boards, and setting up collaboration software. ChatGPT’s answer: To create the first Scrum team in an organization, there are a few steps that can be followed: Identify the team's goals and objectives: It's important to start by identifying the goals and objectives of the team, and what they are trying to achieve. This will help the team understand their purpose and focus their efforts. Assemble the team: The next step is to assemble the team. This should involve selecting team members who have the necessary skills and expertise, and who are committed to working together towards the team's goals. Train the team in Scrum: It's important for the team to have a deep understanding of the Scrum framework and how to apply it effectively. The team should receive training in Scrum, including the values, principles, and practices of the framework. Establish the team's working agreements: The team should establish working agreements that define how they will work together, including how they will communicate, collaborate, and make decisions. Set up the team's work environment: The team should set up their work environment in a way that supports the Scrum framework and helps them work effectively. This may involve establishing a physical workspace, setting up communication and collaboration tools, and establishing processes for managing work and tracking progress. Start working: With the team in place, trained in Scrum, and with a clear understanding of their goals and how they will work together, the team can start working using the Scrum framework. It's important to be flexible and adapt as needed, as the team may need to adjust their processes and practices as they learn and grow. By following these steps, the team can effectively establish themselves as a Scrum team and begin working using the Scrum framework. Regenerated response: To create the first Scrum team in an organization, the following steps could be taken: Identify the purpose of the team and the goals it will be working towards: It's important to have a clear understanding of what the team will be working on and what it is trying to achieve. This can help guide the selection of team members and the processes that will be used. Select team members: The team should be made up of individuals who have the necessary skills, expertise, and experience to complete the work. It's important to consider the diversity of skills and perspectives within the team and ensure that the team has a balance of different roles and expertise. Establish the team's processes: The team should establish processes for how they will work together, including how they will communicate, collaborate, and make decisions. It's important to involve all team members in the process of establishing these processes to ensure that they are effective and meet the needs of the team. Set up the team's work environment: The team should have a suitable work environment that is conducive to effective collaboration and productivity. This may include physical space, tools, and resources. Provide training and support: It may be helpful to provide the team with training on the Scrum framework and any other tools or processes that they will be using. The team should also have access to the support they need to be successful, such as access to subject matter experts and resources. By following these steps, the organization can create a strong and effective Scrum team that is well-equipped to work effectively and deliver value to the organization. Comment: This ChatGPT job interview answer is mainly unrelated to Scrum but is general project management best practice to get started. It completely ignores the idea of self-management and Scrum Values, which ChatGPT previously put on a pedestal. Regenerating the reply did not help either. Follow-up question: Shouldn’t members of a Scrum team self-select? After all, Scrum teams are self-managing. ChatGPT’s answer: In Scrum, the team is responsible for self-organizing and self-managing its work. As such, it is generally best practice for team members to self-select onto the team, rather than being assigned to the team by someone outside the team. This is because self-selection allows team members to choose to work on the team based on their skills, interests, and availability, and can help create a sense of ownership and commitment to the team's success. However, there may be cases where it is necessary for someone outside the team to play a role in selecting team members. For example, if the team is working on a project that requires specialized skills or expertise that are not available within the team, it may be necessary for someone outside the team to help identify and bring in team members with those skills. In these cases, it is important to involve the existing team members in the selection process and ensure that their input is considered. Overall, it is generally best practice for Scrum teams to be composed of team members who self-select onto the team, but there may be cases where outside input is necessary to ensure that the team has the necessary skills and expertise to be successful. Follow-up question: Why can’t Scrum team members identify what skills they miss and a suitable expert to compensate for that lack of expertise? ChatGPT’s answer: Scrum team members are responsible for self-organizing and self-managing their work, and as such, they are generally expected to identify any skills or expertise that they may be lacking and find ways to compensate for those gaps. This may involve seeking guidance or support from subject matter experts, or acquiring the necessary skills through training or other means. There may be cases where the team is unable to identify the specific skills or expertise that they are lacking, or where they are unable to find a suitable expert to compensate for those gaps. In these cases, it may be necessary for someone outside the team, such as the Scrum Master or a manager, to help identify the skills or expertise that are needed and to assist in finding a suitable expert to fill those gaps. Overall, it is important for Scrum teams to be proactive in identifying and addressing any skills or expertise that they may be lacking, and to seek out the support and resources they need to be successful. Comment: ChatGPT believes in the benefits of “guidance from the management” in setting up Scrum teams or from the Scrum Master, as the Scrum team may be unable to identify what skills it is lacking. While our language model is still “convinced” of the benefits of managerial caste, it is my experience that the most skilled Scrum teams very well understand what they do not know (yet) and where they need support from outside experts. In no case, they required their managers to tell them. ChatGPT Job Interview — Conclusion The ChatGPT job interview is a mixed bag. The more specific the questions get, the further away from the Scrum Guide and Scrum’s first principles they move ChatGPT increasingly starts to fail. This failure should not be a surprise as we do not know on what content this LLM was trained. So, based on these few example questions, 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. Not yet. However, this ChatGPT job interview also allows a glimpse into the future: What if we could train ChatGPT 4.0 ourselves? Of course, I am not referring to the whole model, but the agile and Scrum specifics parts, respectively. How much training effort does it take to get ChatGPT to a level that would make us interviewers engage in the next step with the model? Moreover, what documents would you choose to train ChatGPT 4.0 in Agile and Scrum? Please share your suggestions with us in the comments.

Today, I’ll share a few thoughts on what makes a good project plan. And I’ll provide a sample project plan. Why Have Project Plans Many agile teams focus on sprints or chunks of work. But they don’t really plan — instead, they do what they can each sprint, plot out their velocity, and determine what they can accomplish over the next sprints. This is fine, but project plans are a tool for getting you to think about the contours of your projects. They have the following advantages: You can play with different ways of structuring the project, so you can sequence the value of delivery easier. This makes it easier to play with scope, and incremental delivery, and adjust to changes. You think through risks better with a project plan. You have to explicitly list things like when people are on vacation or on call. This can result in better planning. Many teams use sprint cycles or kanban cycles that are longer than a week. Weekly project plans give you more frequent signals if you’re on track or not. Sprint plans track all the work, which is useful. But that also makes the plan harder for stakeholders to understand. Keep Your Project Plans Simple Typical failure modes for project plans are no project plans at all or overly complex project plans. Complex project plans… can have many project artefacts. require time to keep up to date. can be brittle, requiring fixes or maintenance. They are highly dependent on the person who made the plan. sometimes create the illusion of more certainty. For example, the project “will be done in 23.53 to 27.55 days”. I know a project plan is in dangerous territory when I see people allocated as fractional “resources”. Or when the plan is something that only one person can update. Why Keep It Simple One of the dangers of plans is that they can cement things into place. You want a project plan that allows you to make changes in seconds, not minutes or hours. Most complex project plans disincentivize change. You also want a project plan that clearly communicates. An outside observer should be able to look at your project plan and figure out what will happen and when. This requires the right attitude. Keep it simple. Qualities of a Simple Project Plan Here are some things I recommend in a simple project plan: Make it week by week. List out what should happen each week, with a couple of bullet points. Doesn’t need to be more complex than that. What should the bullet points be? Things you will demo at the end of each week. Estimate milestones, not projects. You should plan milestones, not projects. Yes, a high-level project plan can be important, but you also shouldn’t overinvest in it by planning out the whole project in advance. That prevents you from making changes to sequencing or adapting based on things you’ve learned. You should make a high-level technical plan, and make a list of sequenced milestones. And to estimate the overall project, you might do some high-level estimates. But I recommend only having a week-by-week plan for the current milestone. [Does that mean these are really milestone plans? Yes, but I call them project plans anyway because that’s what people are used to.] Milestones should be less than a month in length. See the milestones post for more details. The key insight here is that small projects typically go way better than large projects, so make all the projects small projects. Combine plans with weekly communication. It’s helpful to combine project plans with project reporting. Use a style of communication that is concise, represents the state of things dispassionately, and surfaces risks, but maintains an “I’m taking care of things” tone. Combining plans with project reporting ensures the plan will be updated at least once a week. I’ll write about project reporting soon. Make text-based plans. I’ve found it more useful to have project plans be text-based, rather than tied to tooling like Jira. Tooling-based approaches are fine. But text-based approaches force people to really think through everything in a different way. You can use links to link to sprint plans or individual stories, or whatever. But it keeps it easy to understand for someone not aware of the project. I sometimes don’t insist on this, but it depends on the circumstances. Weekly Project Plan Template This is for a milestone within a larger project Week of Jan 4th A single chart shows up in Slack. Data is canned. Schedule risk: we’re validating that our list of chart types is all technically feasible. We’ll demo the outcome of that investigation. Week of Jan 11th Chart data reflects live information, and is functional in Slack chart. Additional chart type shows in Slack room, with most basic visual design. We’ve shown this to at least one alpha customer for feedback. We start sharing with them every week from here on out. Jessica is on-call and doing interrupt-driven work for the week. Week of Jan 18th The most important feedback from alpha customers is incorporated. Other work is prioritized for future milestones. The last chart type was added. Week of Jan 25th Holiday Jan 26th. The charts look great and are thoroughly tested, and instrumented. We’ll show usage dashboards. Release end of the week.

Life means dealing with bad things that may or may not happen. We call them risks. We assess, evaluate, mitigate, accept, and sometimes blithely ignore them. Building complex and original software are inherently risky and the Agile way of working does not fix that. That’s why we need to be true to the value of courage. I’ll start my argument with a refresher on the topic and some practical examples. The dictionary defines risks as the likelihood of bad things happening. Equally important is the nature and extent of the damage when the risk becomes a reality. The exact balance between probability and consequences is the bread and butter of actuaries at insurance companies. Their models inform them how likely it is that an average dwelling goes up in flames, so they can put a price on the collective risk of their millions of customers. Several houses are certain to burn down each year and their owners need to be reimbursed. It’s a predictable risk. The Scala World Hiking Trip This won’t do in aviation or civil engineering. Every lethal incident prompts an investigation to raise the standard and reduce risk up to the point where we are left with black swans only, events so rare and unpredictable you can’t possibly prepare for them. Most airline crashes are the result of these unknown unknowns. Here’s a more mundane example. At Scala World 2019 I joined the attendees for the traditional pre-conference hike in the English Lake District. I had visited the area before and arrived with waterproof gear and sturdy boots, knowing the terrain and the unpredictable British weather, which even in September can be brutal. We set off in the sunshine and of course, it had to rain for much of the walk. Several walkers had not read or minded the instruction email, or even checked the weather forecast. Arriving woefully unprepared in cotton jeans and t-shirts, they got thoroughly soaked and a little miserable. But there was safety in numbers. Spare ponchos were shared, and nobody would have been in mortal danger if they had sprained an ankle while clambering over slippery boulders with their inadequate footwear. Four Ways of Doing Nothing The literature distinguishes five ways to manage risks. Funnily enough only one deals with facing the risk head-on. The other four strategies are variations of doing nothing. And the hiking trip covers all five. The proactive way to tackle a risk is to make sure it is less likely to happen and/or make the consequences less unpleasant when they do happen. This is called mitigation. You can’t stop the clouds from raining, but you don’t need to get soaked and cold. Sturdy boots, Merino undergarments, head torch, Garmin GPS device, emergency rations. You keep mitigating until you’re at ease (or broke). Then you pick an option from the remaining four. Accept - After careful consideration, you decide the risk is acceptable. You’re prepared for what might happen. Yes, it will be cold and wet, but you’re all Gore-Tex-ed up and with experienced ramblers. Cancel - You’ve done what you can to mitigate but decide the risks are still not acceptable. You call the whole thing off, so you’re no longer exposed to the risks. Transfer - What if you break a leg and need to be airlifted to the hospital? That will cost a fortune. You take out premium daredevil insurance to cover this unlikely event. Ignore - Not much of a strategy at all, this one. You don’t know and don’t seem to care. You think the Lakes are mere picture postcard cuteness, where you couldn’t possibly die of hypothermia when injured on a solitary winter hike, unable to call for help. You didn’t check the weather forecast, went out in jeans and trainers, and your phone charged 20%. Now let’s see how these five strategies apply to software risks: Mitigation We are good boy/girl scouts. We write clean, well-tested and peer-reviewed code and are in close contact with the business to make sure expectations are aligned. If we feel that our code is of sufficient quality and we have a good system to deal with bugs in production, we accept the risks. Or, if we’re working on a self-driving car, an A minus is still not good enough. While the risks may be more about liability and legislation than about the autonomous driving skills themselves, they are still too great to accept. Remember when each IT outfit had its own server room and surly sysadmin? We’ve transferred the troubles of maintaining bare metal (and much more) to one-stop-shop Cloud providers. Last but not least, there’s the cowboy mentality of throwing your code at the wall and seeing if it sticks, which was not the idea behind continuous delivery. Still, one person’s enterprising spirit is another one’s cavalier ignorance. The Proof Was Always in the Pudding Not every bug costs life, but some of them do. And while all bugs are expensive, so is not shipping, or gold-plating to perfection. The world of software is too vast for a single risk management strategy. Yet despite the variety, software risks come in two predictable categories: the wrong thing done right, or the right thing done wrong. We may deliver a product that does a terrific job of what the customer doesn’t need. Alternatively, we may understand the customer perfectly, but botch up the implementation. Both are bad, and combinations of the two are common. This is a disheartening prospect, but building original software means finding novel solutions, which means dealing with the unknown. Things will go wrong. We can mitigate the heck out of our code with more and better design documents, testing and peer reviews, but eventually, it needs to prove itself in the real world. In civil engineering or the Artemis space project, big up-front designs make sense. You can’t make a bridge two feet wider once it’s built. When going back to the drawing board is crushingly expensive, thorough risk minimalization is called for. We used to make software in the same fashion, and it didn’t work. The Waterfall approach tried to mitigate the risk of building the wrong thing before any working code was shared with the user. Well, good luck with that. No putative interpretation of what the user wants ever proved capable of predicting exactly what they needed. The proof has always been in the pudding. The Agile Compromise We cannot eliminate the risk of building the wrong thing with better design and more focus groups. We can only do it by shorter and more frequent iterations of a working product that is incomplete and maybe not that great yet. That’s the Agile compromise. Shorter cycles decrease the risk of building the wrong thing but increase the risk of degrading the process. Accruing technical debt is one. Not a necessary consequence, just a standard price to pay for quicker deliveries. No pundit with stories about the constant commitment to quality will convince me otherwise. If you want greater speed, accept more risks. The Agile compromise towards risk-taking also recognizes that software, as a creative discipline, by nature exposes black swans: the risks we didn’t know we would ever run into. No engineering approach provides full reassurance against them, nor can testing and validation ever give you full peace of mind. It’s a little bit scary, but if you pride yourself on an Agile mindset, you must embrace it. Software is complex rather than complicated. Its many moving parts behave in unpredictable ways when unleashed on the world. Risks are a natural part of that property. Recognizing and embracing them with courage is the only way in a team that bears joint responsibility for fixing the consequences and doesn’t point fingers.

As an engineering leader, one of your top priorities is improving the effectiveness and productivity of the developers on your team. The first step to managing and improving your engineering team is adopting a metric-driven approach to identifying the problem areas that threaten your team’s performance. Successful teams keep track of their performance through a set of chosen indicators called software engineering metrics. With these metrics, engineering leaders can visualize progress, identify bottlenecks, watch for anomalous trends, and predict when something’s off before a deadline is missed. One such important but often overlooked metric in software development is code churn. In this guide, we’ll unpack what code churn is, why high levels of churn can be detrimental to a project, and what to do when you notice an unexpected spike in churn. What Is Code Churn? Code churn, also known as code rework, is when a developer deletes or rewrites their own code shortly after it has been composed. Code churn is a normal part of software development and watching trends in code churn can help managers notice when a deadline is at risk, when an engineer is stuck or struggling, problematic code areas, or when issues concerning external stakeholders come up. It is common for newly composed code to go through multiple changes. The volume and frequency of code changes in a given period of time can vary due to several factors and code churn can be good or bad depending upon when and why it is taking place. For example, engineers frequently test, rewrite, and examine several solutions to an issue particularly at the beginning of a new project or task when they are experimenting with solutions to the task at hand. In this case, code churn is good, because it is a result of creative problem-solving. Code churn can be good or bad depending upon when and why it is taking place. Code Churn Metric Breakdown RefactorCode that is modified after 21 days of committing is called refactored code. Refactored code is usually an acceptable change that is needed for maintenance hence, is distinct from code churn so as not to raise any red flags. New WorkCode that is newly added and that is not replacing or rewriting existing code. Help othersCode that is replaced by engineers other than the author of the original code within 21 days of authoring. This helps you measure to what extent developers are helping their teammates to improve code quality and delivery. Watching trends across this spectrum of metrics during a development lifecycle creates a better ground for effectively debugging the root cause and gaining potential insights such as: Which team members are spending more time helping others, than perhaps working on their own work? The percentage of time engineers spend on new features (new work) vs. application maintenance (refactoring) Anomaly alerts when any or all of these indicators trend out of the anticipated range can equip managers to combat challenges, preempt risks to delivery, and gain visibility into critical processes that might require an improvement. How to Detect Unproductive Code Churn Code churn varies depending on many factors. For instance, when engineers work on a fairly new problem, churn would most likely be higher than the benchmark, whereas when developers work on a familiar problem or a relatively easier problem, churn could most likely be lower. Churn could also vary depending on the stage of a project in the development lifecycle. Hence, it is important for engineering managers and leaders to develop a sense of the patterns or benchmarks of churn level for different teams and individuals across the organization. While code churn, by itself, is neither good nor bad, there is a cause for concern only when churn levels digress from team or individual benchmarks for the particular project that is being worked on. When such digression occurs, it is important to identify the factors contributing to unproductive code churn. What Can High Code Churn Indicate? Complicated Tasks A higher level of churn is to be expected when an engineer is exploring and backtracking with a particularly challenging problem at hand. It is when the exploration has gone on for too long that it is a call for concern. An unusual high churn level might indicate that an engineer did not completely understand the assignment, or neglected to fully comprehend the issue, or didn’t have the expertise to address the assignment. In many cases, engineers feel that they have successfully handled the issue, perhaps even sending it off for review, and then finding that significant areas of it needed to be changed. Unclear Requirements or Changing Requests from External Stakeholders Factors outside the normal development process such as a poor PRD (product requirements document) or unclear or indecisive stakeholders can also lead to high code churn. A sudden increase in churn or a sudden spike in new work, especially in the final phases of a project, is usually an indication that a miscommunication between the stakeholders or new requirements led to the final code undergoing changes. When this pattern is seen sprint over sprint with the same team it can damage both morale and progress and can lead to frustration in the team over time. An Indicator of Future Quality Problems Measuring code churn equips managers with foresight to predict and preempt potential future problems. The most problematic code is the one that is complicated to grasp and altered frequently. A high level of churn exposes potential code hotspots, and if these frequent changes are performed on complicated and critical code, the code tends to be more error prone. Hence, code churn can be a predictor of high-risk code.These code hotspots, if not recognized early during refactoring efforts, can result in developers accumulating huge amounts of technical debt. This debt grows as more opportunities for code refactoring are missed and, as a result, new development becomes difficult, especially when features are built upon legacy code. Deadline Is At Risk A higher percentage of reworking and code deletion resulting from experimentation is commonly seen at the beginning of a project — especially when a project is new or unfamiliar. A similar trend, sometimes called “exploratory churn,” is expected in the case of particularly challenging problems. Although code churn resulting from creative problem solving is a positive outcome, it becomes a risk to meeting project deadlines when such experimental coding continues for a long period of time, risking the timeline of the development cycle. Similarly, churn should stabilize as a project nears the release timeline. An early indication that the delivery ought to be pushed back is when you start seeing a high volume of churn leading up to a release. How to Prevent High Code Churn When faced with high unproductive code churn, here are some potential actions managers can implement. Better Planning Managers should assign developers to projects and tasks based on programming language and code complexity. Using data-driven and factual insights for planning team and task allocation can improve instances of unproductive code churn. High rates of churn in particular code hotspots can likely be an instance where an engineer, for a prolonged period of time, remains unwaveringly focused on a particular region of the codebase, making just little tweaks here and there. This could be an early sign of a burnout. Data-driven planning provides managers the opportunity to assign a new set of tasks or projects to such engineers which would help them navigate to new areas of the codebase. Training Leaders should ensure that their developers receive the right training and learning so that they have the right skillset to create the features that the application requires. A widely used and successful training method pairs programming sessions with senior engineers who naturally tend to help others. Such pair-learning exercises also help in boosting the morale and effectiveness of the team. Clear Requirements If the specs are poorly defined or inadequate, the developer is forced to work with hazy requirements, forcing them to rely on their best reasonable guess to decode and fill in any gaps. To avoid this, managers have to ensure that their developers get the most up-to-date requirements so that they can create appropriate solutions and avoid rework. Conclusion For far too long, engineering leaders have relied on limited signals and their own intuition to assess the performance of and adequately help their teams. The aim of tracking code churn and other metrics is to enable fact and data-driven decision-making. Data-driven feedback loops assist in identifying process improvement possibilities and tuning engineering routines in real-time. Code churn is frequently ignored and underutilized by several software organizations. However, tracking and managing churn can lead to teams discovering severe issues not just inside their codebases but also in their developer education and in engineering routines. Measuring code churn will certainly help engineering leaders to manage and optimize their team’s performance and productivity.

In 1924, W. A. Shewhart of Bell Telephone Laboratories developed a statistical chart to control product variables. This chart is the beginning of statistical quality control as we know it. After the second world war, engineers W. Edwards Deming and Joseph M. Juran, who worked as consultants in the Japanese manufacturing industry, created the concept of Total Quality, in which quality extends beyond the manufacturing process to all organizational processes and instills the values of quality in every worker called – Total Quality Management (TQM) Since 2000, TQM has evolved to meet the needs of a changing marketplace. Universalization and emerging technologies have exploded in both the scope of quality and the tools used to meet Quality standards. New methodologies like Six Sigma have achieved higher productivity and services free from defects. Quality can now be applied to any organization, including benefits, government, healthcare, education, and even new technologies like Bitcoin and Blockchain. Testing Over the Years When people mainly followed the waterfall methodology, the business analysts wrote the requirements, the developers coded the criteria, and the Testers tested the criteria. Each of these people was responsible for different silos and did what they expected. Quality was thought to be analogous with testing and therefore was considered the Tester’s responsibility solely. But nowadays, when the world has moved on to agile methodology, the barriers have been broken down – quality is not just a tester’s responsibility anymore. The whole team owns quality. The best agile teams have a mindset that everyone is responsible for quality. There are multiple ways that the team maintains quality. It is supported from the very beginning and not just measured with testing. Because testing only detects defects, quality assurance prevents defects. Teams that own quality is willing to contribute to it in any way they can. Making Quality Everyone’s Responsibility People usually believe that project managers and other leaders are less educated about testing. So misconceptions are usual. However, if you ask today, they would tell you quality is everyone’s responsibility. But no one will tell you how it is everyone’s responsibility. What role does everyone play in making a quality product? A product owner translates user needs into user stories and works with developers. Developers who develop these user requirements and features and make them more user-friendly. Testers understand what needs to be solved and what needs to be tested to satisfy the customer. A tester with facts can influence the decisions about a product but ideally should not be making decisions about the product. It’s not that testers cannot give their opinion, but coming up with solutions and features for the product should be left to product managers. Although we have changed our opinions towards the roles with quality and now believe quality is everyone’s responsibility, we should recognize the necessity for engineers with a quality emphasis. Having engineers focused on product performance, user experience and customer scenarios, internal development, and security ensures that these areas prioritize the product and that any issues in those areas will have a voice. We don’t look to these teams to handle scale, UX, security, etc.; we expect these teams to deepen their understanding in these areas. Quality is not a one-off process, it is a continuous process. It is not the result of efforts from a single person, but it is the team’s effort. We have to make it a habit of delivering a quality product; that is how a new brand is born into the market and known for its standards. Quality is not an act! It is a habit! Communication Is the Key Good understanding between the teams is one way to ensure quality. Creating cordial relations between QA and Development will minimize the difference between the two groups. Testers can work with scrum masters for advice and input. They can work with Product managers to give and receive feedback on acceptance Criteria or test cases and defects. The result will be ensured quality in testing teams. Opportunistic pairing is another technique for ensuring quality. The pairing could be Developer with Developer, Tester with Tester, Developer with Tester, or even the Developer, Tester, and Product manager. Pairing reduces post-implementation code reviews and reworks in many cases. Each person in a team will get visibility into the other person’s tasks and processes. With good understanding and freedom within the teams comes the ability to question and even disagree. So it might mean some features need to be redesigned around testability, testers need to shift on what they think the most critical tests are, or the team takes a calculated risk around what will be validated. The crucial point is understanding the risk and discuss what tests are essential for today and the sprint. Engaging everyone in the conversation helps shift more toward the idea that quality is everyone’s responsibility. Conclusion When the project team correctly describes quality specifications, and the organization has set up a procedure to ensure quality control and assurance measures are taken care of, the project is more likely to be delivered of better quality and hence more likely to succeed.For Instance: During the Planning Stage of a Project Life Cycle, documents are the majority component of the deliverables. Ensuring the teams submit quality documents will influence the project’s success. Similarly, during the Execution Stage, the team should ensure appropriate quality control and influence its success. Quality is just like security. Every person can contribute to having a safer product by identifying threats or ensuring the necessary actions are taken when they see any danger. So, every person can contribute to having a higher quality deliverable by understanding the project’s quality expectations and delivering up to its standard.

No project is complete until it’s been thoroughly planned and executed in Agile style. If you’re new to agile software development, or simply want to improve your team’s agility skills, this guide is for you. In this article, we’ll outline the basics of agile planning, discuss how agile teams interact with other departments, and agile team management, and provide tips on creating an effective agile software development plan. By the end of the reading, you’ll have a better understanding of how agile project planning helps create software that’s both high quality and on time. So start planning today! What Is Agile Planning? Agile planning is a process that helps businesses plan and manage their projects in a way that best suits the needs of the project. It emphasizes collaboration, feedback, and continuous adaptation to changes. Instead of following a rigid plan or schedule, agile planners use iterative methods to develop plans that are flexible and responsive to change. The goal of agile planning is to allow teams to work rapidly on small pieces of a project until they are complete, then move on to the next piece. This allows for better communication and coordination between team members, as well as faster completion times for projects. How Agile Teams Interact With Other Departments? Agile teams interact with other departments in a variety of ways. Some agile teams work closely with their product owner to create an accurate and user-focused vision for the product. They also communicate frequently with stakeholders, including customers and executive management, to ensure that all parties are on the same page and understand what is being planned. Other agile teams may delegate authority to various members of the team so they can focus on implementing features or resolving technical issues independently. Regardless of how agile teams interact with other departments, it is important that everyone understands each others’ roles and responsibilities so projects stay on track. 4 Essential Agile Components A good agile software development plan is essential for any project. It helps to ensure that project goals are met, deadlines are met, and expectations are managed. To create an effective agile development plan, you need to have a clear vision for the project. Additionally, you need to define the scope of the project and the specific areas that will be covered. Once you have a clear idea of what you’re trying to achieve, set realistic deadlines and manage expectations throughout the process. There are four essential elements to any successful Agile project planning: 1. An Agile Project Plan Is Divided Into Releases and Sprints A project plan is an essential tool for an agile software development plan. It helps to track progress and risk management, while also ensuring that the team meets deadlines and maintains quality. A release is a milestone in the project plan and outlines what has been achieved so far. Sprints are short periods of work during which the team completes tasks within defined timesheets. The goal of agile project planning is to move from one release to the next while maintaining quality and deadlines. 2. Working Software Over Comprehensive Documentation A project that delivers working software over comprehensive documentation is known as agile. It has become the most popular method of project management due to its ability to deliver quick, effective results. In order to achieve this goal, an agile project management framework and practices such as story mapping, sprint planning etcetera are essential. Communication between all stakeholders must be regular in order for everyone involved in the project to understand what’s happening at any given time. This way there are no surprises and everyone can work productively towards a common goal. 3. Customer Collaboration Over Contract Negotiation Collaborative development is the key to success when it comes to an agile software development plan. By involving customers in the process from early on, team members can develop a better understanding of their needs and work together harmoniously towards a common goal. In this way, project delivery will be smoother and more efficient. However, achieving customer collaboration requires that everyone on the team makes an effort – even those who are not directly involved in software development. This way, everyone will have the incentive to work together constructively and productively towards a common goal – agile software development! 4. Responding To Change by Following a Plan When it comes to responding to change, following a plan is key. A well-defined vision and goal will help you stay on track as project deadlines approach. In addition, by following a systemized process, you can ensure that everyone involved (stakeholder) is aligned with your plans and goals. This way, there’s less chance of project failures or delays caused by disagreements over what needs to be done or how things should be done. Conclusion As software development becomes increasingly agile, it is important to have an effective agile software development plan in place. By understanding the four essential agile components of the agile project management framework listed above, you can create a roadmap that will help your team achieve its software development goals. Make sure to consult with your team and stakeholders to ensure that everyone is on the same page, and you’ll be on your way to developing an agile software development plan that works!

With DevOps and Continuous Delivery gaining traction, are the principles behind Lean and Agile still relevant? How do they compare to the 5 Continuous Delivery principles, and what do any differences mean for software development teams? The Beginnings of Lightweight Software Delivery Throughout the 1990s, a revolution was brewing in the software development industry. The early phased models divided the delivery process into skill-based steps, with designs and documents used to run approval processes to control a project. The process for delivering software was heavyweight and slow, with little indication that the overheads reduced the risks they tried to mitigate. A collection of lightweight methods emerged, designed to generate fast feedback and iteratively adapt the plan based on new information. Rather than controls and approvals, developers used small batches to manage the risk and provide frequent opportunities to change direction. The Agile Manifesto emerged from this adaptive and lightweight methods community in 2001, with Lean Software Development arriving a couple of years later. Agile and Lean provided values and principles-based approaches to software development. You could test whether an approach was Agile or Lean by testing it against a set of core statements defining each method's philosophy. Continuous Delivery emerged from the Lean and Agile communities, providing the most concrete practices and capabilities to achieve frequent and safe software delivery. Apart from Extreme Programming, most software development methods deal with requirements management and communication structures. Continuous Delivery takes on the rest of the value stream and provides a pathway to an efficient and reliable delivery pipeline. InfoQ publishes an annual report on software development culture and methods. They style the report after Geoffrey Moore's Crossing the Chasm concept. Moore famously visualizes a technology adoption lifecycle as a bell curve spread across 3 standard deviations. The chart is divided into 5 groups with different attitudes to new technology: Innovators (-3) Early adopters (-2) Early majority (-1) Late majority (+1) Laggards (+3) The early majority and late majority represent two-thirds of the adoption lifecycle. Still, for new technology (or, in the case of InfoQ, a new idea) to move into the majority, it must cross the chasm from the early adopters to the mainstream majorities. Source: InfoQ Software Development Culture and Methods 2022 While adaptive modes of software delivery are embedded in the late majority, the capabilities needed for continuous modes of delivery are still making their way across the chasm. Some practices (such as DevSecOps) have made the leap, while other key elements, like team topologies and empowered teams, remain at the early adopter stage. So, with DevOps and Continuous Delivery gaining traction, it's a great time to compare the 5 principles of Continuous Delivery with the 12 Agile principles and the 7 Lean principles. Comparing Agile, Lean, and Continuous Delivery Principles Agile, Lean, and Continuous Delivery each provide a set of principles. This helps us compare their fundamental structures. There are other techniques and capabilities in Lean and Continuous Delivery that don't have comparable elements in Agile. The Agile Manifesto was intended to be a broad litmus test of the agility of other specific methods, such as Extreme Programming, Scrum, and Disciplined Agile, so it didn't define further details. Lean expands on its principles by describing techniques covering the whole software development process with advice on planning, design, testing, and maintenance. Continuous Delivery uses the deployment pipeline to focus efforts on improving the flow of change, from the code commit to the software running in production. Specific technical capabilities are described in detail to enable the early and continuous delivery of valuable software. The principles are the only directly comparable elements of these 3 approaches. Continuous Delivery principles There are 5 principles of Continuous Delivery: Build quality in Work in small batches Computers perform repetitive tasks, and people solve problems Relentlessly pursue continuous improvement Everyone is responsible The principles can be arranged into a reinforcing relationship, where the first 3 principles act as drivers of continuous improvement, for which everyone involved is responsible. Agile Principles Comparison In general, Continuous Delivery principles are consistent with The Agile Manifesto. For example, working in small batches is widely understood to help achieve several of the Agile principles: Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for a shorter timescale. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Simplicity - the art of maximizing the amount of work not done - is essential. The phrasing of the principle "work in small batches" is concise and easy to follow in practice. This Continuous Delivery principle contributes to the attainment of half of the Agile principles. There is also an amplification effect when you combine the 5 principles. To "deliver working software frequently", you need to work in small batches, increase automation, and build quality in. Two Agile principles are not covered by Continuous Delivery: Business people and developers must work together daily throughout the project. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Continuous Delivery is centred on the delivery pipeline, which means the process of identification, inception, and initiation aren't a direct concern of Continuous Delivery. Additionally, in the front matter of the Continuous Delivery book, the authors highlight that the book was created according to the ideas it contained. The contributors and editors worked using different tools and from separate locations. They used version control and automated builds to form a delivery pipeline for the book. They didn't work together daily or convey information face-to-face. As an industry, many organizations that hadn't attempted to work remotely are now ready to experiment with distributed working. This will further challenge the need for real-time face-to-face coordination as asynchronous communication becomes more common and familiar. Regarding word counts, Continuous Delivery principles are conveyed in 21 words, rather than 180 words for Agile principles. A combination of hindsight and incisive editing has given us a compass to check our direction, with the detail provided in the specific practices of Continuous Delivery. It's easy to get bogged down in the details of implementing Continuous Delivery — tools, architecture, practices, politics — if you find yourself lost, try revisiting these principles and you may find it helps you re-focus on what's important." — Jez Humble You don't have to throw out The Agile Manifesto to move forwards; it's part of the geography that Continuous Delivery and DevOps are building on. The industry will continue to discover new and better ways of developing software. It's increasingly evident that technical practices and cultural capabilities are vital. Lean Principles Comparison The Lean principles are already brief and actionable. There's complete alignment between Lean and Continuous Delivery, with no unmapped areas. With Agile, Continuous Delivery offered a concise alternative to 10 Agile principles. In the case of Lean, Continuous Delivery aligns entirely with the principles. Each approach provides a different perspective that applies to various organization segments. In an organization that has fully adopted both Lean and Continuous Delivery, the respective principles are helpful to different groups. Lean principles and techniques are leadership tools, while Continuous Delivery provides an approach specific to the individual contributors' delivery efforts. For example, automation is a practical attack vector for eliminating waste, delivering quickly, and building integrity into the system with Continuous Delivery. Conclusion Continuous Delivery provides a concise set of principles that align with 10 of the 12 Agile principles and complement Lean, providing a different perspective on achieving similar goals. All 3 sets of principles are consistent with modern management philosophy and provide different ways to review and re-focus your software delivery efforts. You can use the Continuous Delivery principles to guide your software delivery efforts and refer back to Agile and Lean principles to find further inspiration for your improvement efforts. Happy deployments!

Today, 94% of organizations are using cloud technology, and this swift evolution to the cloud means security teams are handling more data and more alerts than ever. Additionally, threats and attacks are only increasing in frequency — it’s estimated that a cyber attack occurs every 11 seconds — and sophistication. But more often than not, security teams are overwhelmed because they don’t have the right tools and approaches to handle modern threat detection at scale. Security team leaders should have updated tools and approaches to help them protect their organization, and the best approach they can take is to adopt detection-as-code. Here's more about detection-as-code and its benefits, as well as some best practices to help you gain success as you begin to use detection-as-code in your security approach. The Benefits of Detection-as-Code What if threat detection could be flexible, tailored to your organization's needs, scalable, testable, and more? That's what detection-as-code is: An approach to writing detections that employs a universal programming language and software engineering best practices. Detection-as-code brings a number of benefits to your organization, starting with the ability for your team to write custom, high-quality detections that are tailored to what you need to be alerted to. By using a universal coding language like Python, you're moving away from restrictive domain-specific languages. As you build detections, you can reuse the code across workflows without having to start from scratch. Detection-as-code allows you to automate your work as well, decreasing human error and streamlining response time. As you increase automation, your team can focus more on fine-tuning alerts. Finally, utilize version control systems to help you know which version of detection you're currently working with or to revert to a previous version. Ultimately, detection-as-code offers standardization, sustainability, and reliability and is a forcing function for security teams to automate by default, operate at a higher scale, and improve team efficiency. So how can you get better at it? Four Best Practices If you're just starting to use detection-as-code or want to improve your approach, here are four best practices to help you grow and evolve your skills in leveraging detection-as-code for your organization. 1. Test, Test, and Test Some More One of the best things you can do as you build detections is to ensure that all of your detections are well-tested! Take a test-driven development (TDD) approach to your detection-as-code. You’ll discover blind spots early on, cover testing for false alerts, and evolve and improve your detection efficacy. Test for syntax and with real data to ensure you are able to check how these detections behave in the wild. 2. Learn Your Language One of the advantages of detection-as-code is that it frees you from restrictive domain-specific languages to use one that’s more universal. Security practitioners are already familiar with Python as a scripting language, and basic Python can be learned by anybody. The best way to help improve your threat detection is to become skilled at writing in Python. This ensures that you are writing code in ways that are sustainable, correct, and aligned with other software developers, which makes it easier to collaborate with your team. Use CI tools to make this easier for you, such as formatters, linters, and more. Learn from your team’s detection requirements; over time, you’ll improve your intuition, improving your security game. 3. Adopt a CI/CD Mindset Adopting a CI/CD mindset and responding more like software engineers can go a long way toward streamlining your detection processes. Continuously iterating on detection rules and alerts, testing those detections, and quickly deploying them not only allows you to be responsive in your improvements but allows you to leverage version control, unit testing, and other benefits. Above all, it allows you to leverage the power of automation in your workflows. 4. Get Creative With Code Writing code allows you to be creative because coding is problem-solving and unlocks new ways of approaching old problems. As such, teams who are writing sophisticated detections can begin to test more advanced methods of analysis, such as statistics, machine learning, graphs, and more. However, increasing sophistication doesn’t have to mean increasing complexity, as writing tailored code for your detections will actually simplify your approach. Modernizing Threat Detection Detection-as-code is the approach that will elevate your threat detection and make your security team better prepared, more efficient, and more creative with their response. But be sure that you're learning all the best practices around detection-as-code in order to make your efforts more pointed and successful.

Quality assurance (QA) is the act or process of certifying that a company’s quality criteria are met. Planning, completing, and monitoring tasks are all part of managing quality in production. The monitoring aspect is the essence of what quality assurance is. The techniques and procedures that systematically monitor multiple aspects of a service or facility make up the quality assurance process. Quality assurance activities uncover and fix faults or deviations from defined standards or requirements through audits and other forms of assessment. In other words, quality assurance ensures high standards during the development of products or services. Any startup — from packaged food manufacturers to software development firms — and almost every company uses some type of quality assurance in their production. Some businesses even have a quality assurance department with people entirely dedicated to the task. How QA Works Rather than going through an unmonitored production process and trying to “inspect the quality” of a finished product, quality assurance test methodologies focus on developing good procedures to generate quality goods. Today, there are different ways to carry out quality assurance, depending on the industry. Because product development for a healthcare company is unique to a SaaS company that is creating a customer onboarding template, their methods to ensure quality will differ. A healthcare company's practices could be guided by active pharmaceutical ingredient criteria, but a SaaS firm’s processes will be guided by different standards. In this article, we’ll focus on QA for software companies. Here are five vital steps in setting up your startup’s QA process. 1. Define Your Testing Goals Quality assurance is frequently carried out before the software has been created. The documentation and requirements for the final product are checked by QA professionals to ensure that they are clear, consistent, and testable. Repairing problems during the testing stage is up to 15 times more expensive than fixing faults during the design and development stages; therefore, these preventative practices can help businesses save money. At this point, you should decide which areas and functionalities will be the focus of your testing. You could be looking at the present performance of your connector, or the features users are looking for based on the reviews they left on PCMag or Capterra. Both will offer good insights into what area you can start testing. Whichever that may be, QA specialists usually go over the program documentation and write a plan that specifies the scope of the testing, whether it should be automated testing, and which aspects will be examined. Software is generally tested for the following: Consistency Stability Executability Clarity Completeness Performance accuracy Your specific testing requirements will be determined by your product, how it will be distributed, your target audience, and your post-launch software support strategy. 2. Identify the Best Startup QA Testing Approach for You To begin, select a software testing technique that will help your QA team to complete your software development QA process as efficiently as possible. Employing a software testing technique that elevates your project management style can help you overcome difficulties that arise during testing cycles. Which software testing approach is best for your in-house team and startup QA outsourcing? Take into consideration the following methodologies for your quality assurance process: Agile Methodology QA teams can manage a project using exploratory testing in an agile approach by dividing it down into sprints. When preparing each sprint stage — including planning, requirements analysis, and testing — the QA team may consider using an Agile QA process to expedite the process. Each sprint concludes with a review meeting in which the team discusses their success and plans for future testing sprints. The QA team uses their previous knowledge to reduce risks and improve efficiency with each new iteration. Waterfall Methodology This software development quality assurance process is based on QA teams’ step-by-step testing progress. Before developing sequential steps for QA testers to follow, a QA team documents and plans the entire project. The team must follow the steps in sequence with no deviations. Many testing teams like the waterfall methodology — including QA outsourcing for startups — because it is simple and straightforward to execute within the development cycle. But, because of the strict structure, teams are unable to make quick changes to the testing process. Verification and Validation Methodology Like the waterfall methodology, this method takes a step-by-step approach to software testing. However, the development process runs concurrently with the testing phase, which makes it unique. When a development stage is completed, startup QA testing for that product element begins immediately. This approach to QA for startups allows teams to implement product improvements sooner, which frees up time and resources for other projects. Incremental Methodology This software testing process comprises various iterations, each of which has several stages. Each iteration tries to improve the product’s value by adding new features or improving quality. The incremental methodology involves the following three stages: Design and development Testing Final implementation This approach to QA testing is adaptable, allowing QA teams to modify the testing process in real-time. Regardless of Your Chosen Methodology... These four parameters should be the foundation of your tests: Component tests: to assist your development team and their processes. Business scenarios: to test the end-to-end business systemization and processes, starting with the customer’s perspective and ending with the end user’s perspective. User tests: to test the product from the user’s point of view. These are largely manual tests, which demand a full-time QA engineer or the use of QA outsourcing for startups. Technical tests: to assess the product’s performance, load, and security. Connectivity, performance, and recovery testing are all of these tests, which focus on the product’s infrastructure and platform. 3. Acquire QA at the Best Time Regarding acquiring QA for startups, it all comes down to how much risk you can tolerate. Getting your first paying client, having your first serious complaint, or noticing a lot of churn with your product are all good reasons to start developing your QA staff right now. When resources are limited, many startups benefit from outsourcing QA. So, how can you know when it’s time to recruit a quality assurance partner? When you are going through one (or all) of these problems: Your time to market is down You’re trying to integrate new tools and technologies Your team is constantly missing deadlines and pushing back launch dates to fix product flaws that may have been detected earlier by QA testers You’re implementing an agile methodology You’re receiving poor customer reviews 4. Analyze the Results After testing results have been obtained and any defects have been rectified, QA specialists rerun the identical test cases to ensure that the issues have been resolved effectively. The QA process is regressive, which means that the bulk of tests is repeated. Always incorporate regression testing into your QA process to ensure that one fix does not affect the normal operation of other features. It’s also crucial to retest your application using the integration testing approach because bug fixes might occasionally affect the behavior of several capabilities rather than merely breaking them. When you reach the deployment stage, the QA team creates and executes tests in line with the development team’s release documentation. For instance, the Azure data lake documentation contains all established functionalities, all conducted repairs, and software constraints that took place. This stage is referred to as smoke testing. During smoke testing, test case sets are used to confirm that the final build is functional, stable, and ready to deploy. 5. Make Adjustments and Tell Your Team Adjustments should be made when needed after listening to feedback and reviewing initial aims. While many people recommend doing a plan audit every two to three months, it can be done sooner if necessary. If a mistake is discovered or issues arise, implementing changes as quickly as possible is beneficial in reaching the company’s aim — particularly if it is an SMB — and saving or growing sales by introducing a better product or service. Also, employees want to know if what they’re doing is effective. Let them know if the QA approach has helped the company. Positive or constructive feedback helps to build a stronger team and shows employees that they are contributing to the company’s success. The fact that you are empowering employees to make a difference motivates them to keep doing a good job and provides valuable input into the QA process. As a result, have employees stick to the plan, provide both positive and negative feedback, and listen so that changes may be implemented. Conclusion As they say, preparation is key, like how reviewing the qualities of your standard operating procedure can make a difference to your business. The same goes for planning for quality assurance, as it saves your firm both time and money. Quality assurance is vital to maintaining high product quality standards and continued business success. Software is a rapidly evolving industry, and there are always efficiencies to be made and processes to be optimized. Follow these steps, and don’t forget to customize them for your business.