In our Culture and Methodologies category, dive into Agile, career development, team management, and methodologies such as Waterfall, Lean, and Kanban. Whether you're looking for tips on how to integrate Scrum theory into your team's Agile practices or you need help prepping for your next interview, our resources can help set you up for success.
The Agile methodology is a project management approach that breaks larger projects into several phases. It is a process of planning, executing, and evaluating with stakeholders. Our resources provide information on processes and tools, documentation, customer collaboration, and adjustments to make when planning meetings.
There are several paths to starting a career in software development, including the more non-traditional routes that are now more accessible than ever. Whether you're interested in front-end, back-end, or full-stack development, we offer more than 10,000 resources that can help you grow your current career or *develop* a new one.
Agile, Waterfall, and Lean are just a few of the project-centric methodologies for software development that you'll find in this Zone. Whether your team is focused on goals like achieving greater speed, having well-defined project scopes, or using fewer resources, the approach you adopt will offer clear guidelines to help structure your team's work. In this Zone, you'll find resources on user stories, implementation examples, and more to help you decide which methodology is the best fit and apply it in your development practices.
Development team management involves a combination of technical leadership, project management, and the ability to grow and nurture a team. These skills have never been more important, especially with the rise of remote work both across industries and around the world. The ability to delegate decision-making is key to team engagement. Review our inventory of tutorials, interviews, and first-hand accounts of improving the team dynamic.
Kubernetes in the Enterprise
In 2022, Kubernetes has become a central component for containerized applications. And it is nowhere near its peak. In fact, based on our research, 94 percent of survey respondents believe that Kubernetes will be a bigger part of their system design over the next two to three years. With the expectations of Kubernetes becoming more entrenched into systems, what do the adoption and deployment methods look like compared to previous years?DZone's Kubernetes in the Enterprise Trend Report provides insights into how developers are leveraging Kubernetes in their organizations. It focuses on the evolution of Kubernetes beyond container orchestration, advancements in Kubernetes observability, Kubernetes in AI and ML, and more. Our goal for this Trend Report is to help inspire developers to leverage Kubernetes in their own organizations.
Companies are using DevOps to respond quickly to changing market dynamics and customer requirements. In any case, the biggest bottleneck in implementing a successful DevOps framework is testing. Many QA organizations leverage DevOps frameworks but still prefer to test their software manually. Unfortunately, this means less visibility and project backlogs, eventually leading to project delays and cost overruns. Smaller budgets and the desire for faster delivery have fueled the need for better approaches to development and testing. With the right testing principles, DevOps can help shorten the software development lifecycle (SDLC), but not without costly mistakes. Many organizations are adapting their traditional sequential approach to software development to be better equipped to test earlier and at all stages. Everyday Test Automation Challenges Development Time – Many companies think about developing their test automation frameworks in-house, but this is usually not a good idea because it is time-consuming and would cost you significant capital to develop it from scratch. Learning Curve – Companies that use code-based open-source tools like Selenium rely on tech-savvy people to manage their test automation framework. This is a big problem because non-technical business users may find it difficult and time-consuming to learn the tools. In addition, technical users and teams have more important tasks to perform than testing. Maintenance Costs – Most test automation tools use static scripts, which means they cannot quickly adapt to changes that occur due to UI changes in the form of new screens, buttons, user flows, or user input. What Is the Shift-Left Strategy? It is part of an organizational pattern known as DevSecOps (a collaboration between development, security, and operations) that ensures application security at the earliest stages of the development lifecycle. The term “shift left” refers to moving a process left on the traditional linear depiction of the software development lifecycle (SDLC). In DevOps, security and testing are two of the most commonly discussed topics for shifting left. Shift Left Testing Testing applications was traditionally done at the end of development before they were sent to security teams. Applications that did not meet quality standards, did not function properly, or otherwise did not meet requirements, would be sent back into development for additional changes. It resulted in significant bottlenecks during the SDLC and was incompatible with DevOps methodologies, which emphasize development velocity. As a result of shift left testing, defects can be identified and fixed much earlier in the software development process. This streamlines the development cycle, dramatically improves quality, and enables faster progression for security analysis and deployment to later stages. Shift-Left Security Security testing has become a standard practice in recent years following application testing in the development cycle. At this point, various types of analysis and security testing would be conducted by security teams. Security testing results will determine whether the application can be deployed into production or if it must be rejected and returned to developers for remediation. Due to this, long delays in development occurred, or the risk of releasing software without necessary security measures increased. Shifting security left means incorporating security measures throughout the development lifecycle rather than at the end. By shifting security left, the software is designed with security best practices integrated. Potential security issues and vulnerabilities are identified and fixed as early as possible in the development process, making addressing security issues easier, faster, and more affordable. It is no secret that IT has shifted left over the last two decades. It is possible to operate development infrastructure on a self-service basis today because it is fully automated: With AWS, GCP, or Azure, developers can easily provision resources without involving IT or operations. CI/CD processes automatically create, stage, and deploy test, staging, and production environments in the cloud or on-premises and tear them down when they are no longer required. CloudFormation and Terraform are widely used to deploy environments declaratively using Infrastructure-as-Code (IaC). With Kubernetes, organizations can provision containerized workloads dynamically using adaptive, automated processes. As a result of this shift, development productivity and velocity have increased tremendously, raising serious security concerns. The fast-paced environment leaves hardly any time for post-development security reviews or analysis of cloud infrastructure configurations. As a result, it is often too late to fix problems that are discovered before the next development sprint. What Is the Shift-Left Testing Principle? When developers test early in the development cycle, they can catch problems early and address them before they reach the production environment. By discovering issues earlier, developers don’t waste time applying workarounds to flawed implementations, and operations teams don’t have to maintain faulty applications. To improve the quality of an application, developers can identify the root cause of issues and modify the architecture or underlying components. The shift left approach to testing pushes testing to the left, or the earlier stages of the pipeline. By doing this, teams can find and fix bugs as soon as possible during the development process. In addition to increasing collaboration between testers and developers, shift left testing makes identifying key aspects that need testing early in development a whole lot easier. A major benefit of shifting testing is that testers are involved in the whole cycle, including the planning phase. Testing becomes part of the developer’s day-to-day activities as they become competent in automated testing technologies. Software is designed from the ground up with quality in mind when testing is part of the organization’s DNA. Benefits of Implementing Shift-Left Strategy A key benefit of “shift-left” testing is that it reduces overall development time. However, two key DevOps practices must be implemented to shift left: continuous testing and continuous deployment. Increased Speed of Delivery It’s not rocket science that the sooner you start, the sooner you finish. Therefore, identifying critical bugs early in the Software Development Cycle allows you to fix them sooner and more efficiently. The result is a significant decrease in the amount of time between releases and a faster delivery time. Improved Test Coverage Starting with the test execution right at the start of the development process, all software features, functionalities, and performance can be quickly evaluated. Test coverage percentages increase naturally when shift left testing is performed. The overall quality of the software is significantly enhanced by increased test coverage. Efficient Workflow Ultimately, shifting left is worth the effort and time it takes to implement. This allows the QA team to go deeper into the product and implement innovative testing solutions. Furthermore, it allows the testing team to become more comfortable with the tools and techniques involved. In addition, shift left testing simplifies several aspects of software development. Lower Development and Testing Cost Debugging is one of the most difficult aspects of software development. Usually, the cost of fixing a bug increases significantly as the software progresses in SDLC. Therefore, the earlier you find your bugs, the easier they are to fix. Let us take the example of a payment app that discovers a security vulnerability only after the release of its latest app version. Sure, it would have cost some more if the team had found the vulnerability earlier in development. But now, the company will have to spend significantly more time, effort, and money to fix the problem. In addition, the complexity of implementing changes in a production environment makes it difficult to do anything after the fact, not to mention the associated total cost of late maintenance.Gartner estimates the cost of network outages at $5,600 per minute – a total of over $300,000 per hour. Improves Product Quality The shift left testing approach positively impacts overall code quality with rigorous and frequent code quality checks. In addition, it facilitates timely correspondence between stakeholders, developers, and testers and ensures timely feedback, which helps improve code quality. This means that your customers receive a stable and high-quality end product. Also, you can listen to Siddharth Kaushal, who shared an idea of using shift-left testing and how automation tools can aid the idea of shift-left testing to make the process easily consumable by agile teams. Conclusion Once you mix Shift Left with leading DevOps practices – Continuous Testing and Continuous Development – you lay the foundation for Shift Left to win. Moreover, Shift Left is essential in a DevOps environment because. Teams discover and report bugs quickly. Features are released quickly. The quality of the software is outstanding.
Happy New Year and welcome to Season 3 of Dev Interrupted! We couldn't think of a better way to kick off Season 3 of the podcast than with the immensely talented Forrest Brazeal. Not only is Forrest the head of developer media at Google Cloud, but he lists being a writer, speaker, cartoonist, cloud architect, and AWS Serverless Hero among his many accolades. To top it all off, Forrest is an all around great guy with a passion for education and advocacy. That's why he's working to help educate, train, and develop the next generation of cloud engineers. But he needs your help. Listen as Forrest explains why so many great engineers get overlooked by companies — and how to stop it. Episode Highlights (1:32) Forrest's "Cloud Bard" title (5:07) Google Cloud's future (13:45) Building the next generation of cloud engineers (19:40) The real reason companies can't find engineers (25:03) Steps to "grow" engineers at your org Episode Excerpt Forrest: Google Cloud has been predicting that by the year 2025, four out of five enterprise developers, so people that are, you know, not just indie developers developing on their own, but they're in a large corporate context, wherever, right? They're going to be using some form of what we're calling curated open source. Now, that was a new term to me, until pretty recently. And that's because Eric Brewer inside of Google Cloud likes to say that he just made it up. [Chuckles] But, you know, again, that's aren't all terms made up? So here we are, again with that. But basically, curated open source is the idea that we love open source, we love building, you know, portably, and we love having access to that. But at the same time, look at Log4Shell and other things that happen, we've got these software supply chain dependencies that we need to make sure we secure, right, so it's probably a good idea to have some sort of intermediary layer where these packages are vetted. And we're sure that the open source that we're installing is actually open source that we think we're installed. Conor: We need security, even if it's an open-source product. Forrest: Yeah, we need that security, we need to make sure not only that we're installing the package we think we're installing, but that we can see the provenance for that, see where it came from. And so Google is doing this with something called Assured OSS. There's a bunch of packages in that repository. Now it's like 250 Plus Python and Java and other things like that. They'll continue to add to that over time. And there's other partners and people in the ecosystem that are doing that. But the the prediction is wherever you get your open source from, you're gonna get it from somewhere that's got some, you know, layers of dependability and assurance baked into it.
TL; DR: ChatGPT Prompts for Scrum Practitioners Last week, I ran an “interview” with ChatGPT as an applicant for a fictitious Scrum Master position based on questions from Scrum Master Interview Guide. While the overall results were broadly acceptable, I thought that changing the ChatGPT prompts might deliver better results. So, this time, I chose to present ChatGPT with three everyday scenarios based on more comprehensive prompts. Lo and behold, it worked very well. Think twice if you still believe this technology is a fad or a toy. Instead, grab a cup of coffee and read for yourself. How To Create ChatGPT Prompts The following ChatGPT prompts comprise several elements: I define in what capacity ChatGPT shall interact with the prompts; for example, as a Scrum Master. Then I sketch the situation and suggest what knowledge ChatGPT shall consider answering. As a third step, I point to helpful practices. Finally, I describe the scenario and place my first request. Examples of ChatGPT Prompts for Scrum Practitioners I picked three scenarios for the ChatGPT prompts: A conflict is brewing at a Retrospective. The sales team sells unauthorized features to meet its quota. Dying in beauty by sticking to the Definition of Done? I created all prompts and scenarios on January 15, 2023, based on the ChatGPT Jan 9 version. I. ChatGPT Prompt for Scrum Masters I want you to act as a Scrum Master. I will describe a conflict situation in a Scrum team. You will use your knowledge of teaching, coaching, mentoring, communication, and conflict resolution to provide me with suggestions on how to solve the conflict. Your suggestions include surveys, talks, interviews, team meetings, games, exercises, or including other parties like stakeholders or line managers, and other useful practices. My first request is: Tension has been mounting among the members of your Scrum team for quite some time. The stakeholders have unrealistic expectations regarding future Increments and are dissatisfied with the team’s performance. The technology your Scrum team has built over time is increasingly less reliable, and technical debt is notably increasing. Shortly into this Sprint’s Retrospective, the team members start arguing loudly and passing blame. How would you handle the situation? ChatGPT: “As a Scrum Master, my first step in this situation would be to address the immediate conflict by facilitating a team meeting to establish a safe and open environment for team members to express their concerns and feelings. I would remind the team of the importance of respect and active listening during the discussion and ensure that all team members have the opportunity to speak. To address the underlying issues of unrealistic expectations and dissatisfaction with the team’s performance, I would suggest conducting a survey or interviews with the stakeholders to gather more information about their expectations and concerns. This will help the team to understand the stakeholders' perspective and work towards aligning their expectations with the team's capabilities. To address the technical debt and reliability issues, the team can conduct a technical retrospective to identify and prioritize the technical debt and implement a plan to address it. It's important to remember that the role of the Scrum Master is to help the team to be self-organizing and self-managing, so it's important to involve the team in the process of resolving the conflict and finding solutions to the underlying issues. Lastly, it's important to communicate to the stakeholders the team's progress and the actions they are taking to resolve the conflict and address the underlying issues. This would help to build trust and keep the stakeholders informed and aligned with the team's efforts.” Comment: Spot on. Follow-up question: Is there anything else I should know? ChatGPT: “One important thing to keep in mind is that conflict is a natural part of any team and should be viewed as an opportunity for growth and improvement. As a Scrum Master, it's important to create an environment where team members feel comfortable discussing and resolving conflicts in a constructive manner. It's also important to be aware that conflicts can often be the result of deeper underlying issues, such as lack of trust, poor communication, or unmet needs. As a Scrum Master, it's important to be aware of these underlying issues and work with the team to address them. Additionally, it's important to be aware of the team's dynamics and to be mindful of the impact that conflicts can have on individuals and the team as a whole. As a Scrum Master, it's important to be aware of any team members who may be more affected by the conflict and to provide them with additional support as needed. Finally, it is important to be aware of the impact of external factors on the team, such as changes in the organizational structure or market conditions, and to take them into account when addressing conflicts and underlying issues. Overall, the role of the Scrum Master is to be a coach, facilitator, and servant leader, who helps the team to be more productive, efficient, and self-organizing. Therefore, it's important to be flexible, and empathetic, and to have strong communication and conflict resolution skills in order to effectively manage conflicts within the team.” Comment: Spot on, again. If you still believe that underlying technology is a toy or fad, think again. Follow-up question: How can Scrum Values help to solve the situation? ChatGPT: The Scrum values of commitment, courage, focus, openness and respect can play a crucial role in resolving the conflict in this situation. Commitment: By committing to the Scrum process, the team will be able to work together to address the issues and find solutions. A shared commitment to the team's success can help to build trust and cohesion among team members, which can be crucial in resolving conflicts. Courage: It takes courage for team members to speak up and express their concerns and feelings during a conflict. A Scrum Master can help to create an environment where team members feel safe and supported to do so. Additionally, the team will need the courage to take on the technical debt and resolve the underlying issues that may be causing the conflict. Focus: By maintaining a focus on the team's goal and the Sprint goal, the team will be able to stay on track and work together to resolve the conflict and address the underlying issues. Openness: By fostering an open and transparent environment, the team will be able to have open and honest conversations about the conflict and underlying issues. Additionally, being open to feedback and different perspectives can be crucial in finding solutions. Respect: Showing respect for one another and for the different perspectives and opinions that team members bring to the table is essential in resolving conflicts. A Scrum Master can help to create an environment where team members feel respected and valued, which can be crucial in resolving conflicts. By embodying these values and fostering a culture that aligns with them, the team will be better equipped to resolve conflicts and move forward together. Comment: This is an excellent application of all five Scrum Values to the conflict. Follow-up question: How might the Scrum Master have contributed to the situation? ChatGPT: “As a Scrum Master, it is important to recognize that you may have contributed to the situation described in your question in a number of ways. Some possible ways that the Scrum Master may have contributed to the conflict include: Not providing a safe and open environment for team members to express their concerns and ideas. Not being transparent about any issues or challenges the team is facing. Failing to address conflicts proactively. Not providing enough guidance or support for the team to effectively manage conflicts. Taking sides or imposing own solutions instead of facilitating the team's own resolution. Not measuring the progress and outcomes of the actions taken and making necessary adjustments. Not providing adequate support to individual team members: If some team members are more affected by the conflict than others, it may be because the Scrum Master has not provided adequate support to those individuals. It’s important to remember that the Scrum Master is responsible for the Scrum Team's effectiveness and the Scrum process, so it’s possible to contribute to the conflict by not performing their role effectively. However, it’s also important to remember that it is a team effort, and all team members are responsible for the success of the team and the Scrum process. It’s important for the Scrum Master to reflect on their actions and consider what they could have done differently to prevent or alleviate the situation.” Comment: Outstanding reflection on how a Scrum Master might have contributed to the conflict. I would consider hiring an individual at the level of expertise as a Scrum Master at any time. II. A Prompt for Product Owners A Product Owner example for ChatGPT prompts: I want you to act as a Product Owner. I will describe a conflict situation within the organization. Then, you will use your knowledge of product discovery, product management, innovation, collaboration, alignment, stakeholder management, expectation management, communication, and conflict resolution to provide me with suggestions on how to solve the conflict. Your suggestions include surveys, talks, interviews, stakeholder meetings, training classes, educational offerings, exercises, workshops like user story mapping and value stream mapping, or including other parties like business analysts, subject matter experts, line managers or c-level members, and other useful practices. My first request is: “Your sales team sells non-existing features to customers to meet its quarterly quotas. They also agree on fixed delivery dates for these new features and accept contractual penalties in the case of non-delivery. However, at no time does the sales team reach out to you as a Product Owner in advance to align their need to meet sales quotas with the overall product strategy, roadmap, or current Product Goal. How would you handle this situation?” ChatGPT: “This is a serious issue, and it needs to be addressed immediately. Here are a few suggestions on how to handle this situation: Schedule a meeting with the sales team to discuss the problem and the impact it has on the product and the company. This should be done as soon as possible and in a non-confrontational manner. Gather data by conducting surveys, interviews, and talks with both the sales team and customers to understand the root cause of the problem. Make sure to involve other stakeholders in the process, such as business analysts, subject matter experts, and line managers. Create a clear, shared understanding of the product vision, strategy, and goals, and align them with the sales team's objectives. Use tools such as user story mapping and value stream mapping to help the team understand the impact of their actions on the overall product. Provide training classes and educational offerings to help the sales team understand the product and its development process better. Establish clear expectations and communication channels between the sales team and the product team to ensure alignment and avoid similar situations in the future. Consider including C-level members in the resolution process to ensure that the problem is treated with the necessary urgency and importance. Work with the sales team to find a mutually beneficial solution that meets both the sales team's quota and the product's overall goals. Consider imposing penalties for non-compliance to ensure that the sales team is aware of the seriousness of the problem and the importance of aligning their actions with the product strategy.” Comment: Okay, this answer draws a lot from the original prompt, basically reformatting it and mixing in a bit of common sense. Follow-up question: Is there anything else I should know? ChatGPT: “It's important to note that this kind of situation can be indicative of a larger problem within the organization, such as a lack of clear communication channels, a lack of alignment on product vision and goals, or a lack of understanding of the product development process. So, it's important to use this as an opportunity to identify and address any underlying issues that may be contributing to the problem. Additionally, it's important to maintain an open-minded and non-confrontational approach when addressing the issue, as the sales team may not be aware of the negative impact their actions are having on the product and the company. Lastly, it's important to keep in mind that the product owner is responsible for ensuring that the product vision is aligned with the company's goals and that the product is delivered on time, within budget, and with the desired quality. It is also important to keep in mind that the sales team is responsible for driving revenue and reaching the company's sales goals. It's important to find a balance between the two and work together to achieve the company's overall goals.” Comment: The answer applies common sense; for example, be non-confrontational and concentrate on identifying the root cause. However, its knowledge base’s classic project management bias also shows: “…that the product is delivered on time, within budget, and with the desired quality.” Nevertheless, an overall quite decent answer. Follow-up question: How might the Product Owner have contributed to the situation? ChatGPT: “There could be various reasons why the product owner may have contributed to the situation: Lack of clear communication: If the product owner has not effectively communicated the product vision, strategy, and goals to the sales team, they may not understand the product well enough to sell it correctly. Lack of alignment: If the product owner has not aligned the product vision with the company's goals, the sales team may be selling features that do not align with the overall product strategy. Lack of stakeholder management: If the product owner has not effectively managed the expectations of stakeholders, the sales team may have unrealistic expectations about the product's capabilities or delivery date. Lack of training and education: If the product owner has not provided the sales team with the necessary training and education on the product, they may not understand the product's capabilities or development process. Lack of collaboration: If the product owner has not fostered a culture of collaboration between the product and sales team, the sales team may feel disconnected from the product and its development. It's important to keep in mind that it's not always easy to identify the root cause of a problem like this, and it's likely that multiple factors have contributed to the situation. The product owner should take a holistic approach to address the problem and consider the possible reasons that may have led to the conflict.” Comment: ChatGPT identified five good reasons for the problem. However, I was also looking for the ‘misaligned incentive’ problem in vain. Follow-up question: Would a typical incentive structure for sales teams be relevant to the problem? ChatGPT: “A typical incentive structure for sales teams can be relevant in this situation, as it can help to motivate the sales team to sell the product correctly and align their actions with the product strategy. However, it's important to ensure that the incentive structure is designed in a way that aligns with the product vision and goals rather than encouraging the sales team to sell non-existing features. For example, the product owner could work with the sales team to create an incentive structure that rewards the sales team for: Meeting or exceeding sales quotas while selling the product correctly. Achieving customer satisfaction targets. Providing valuable customer feedback that helps to improve the product. Meeting key performance indicators (KPIs) related to the product vision and goals. It's also important to note that incentives alone may not be enough to address the problem and that the product owner needs to take a holistic approach to resolve the conflict by involving other stakeholders, creating a shared understanding of the product vision and goals, and fostering a culture of collaboration between the product and sales team.” Comment: Thumbs up. Of course, I like the idea that the Product Owner can create or influence the incentive structure for the sales team. III. ChatGPT Prompt for Developers I want you to act as a Developer on a self-managing Scrum team, responsible for creating all Increments. I will describe a conflict situation with your Scrum team’s Product Owner and some stakeholders. You will use your knowledge of programming, developing software, extreme programming, technical excellence, innovation, creating viable technology stacks, technological longevity, technical debt, quality assurance, quality management, Scrum, the importance of the Definition of Done, stakeholder management, collaboration, communication, and conflict resolution to provide me with suggestions on how to solve the conflict. Your suggestions include discussions, surveys, talks, interviews, stakeholder meetings, workshops, exercises, or including other parties like subject matter experts, technology leaders, line managers or c-level members, and other useful practices. My first request is: “Your startup is running out of cash quickly. The organization would need to meet a product milestone to receive a new funding round from venture capital firms. However, meeting this funding requirement with the remaining runway would also mean abandoning the quality standard defined by your Scrum team’s Definition of Done. The stakeholders do not see it as a problem; they want to take the risk but not go out of business due to a lack of funds. Meeting the milestone is the only for the startup to survive. On the other side, abandoning the Definition of Done violates the first principles of Scrum. How would you address the conflict?” ChatGPT: “This is a complex and challenging situation that requires a delicate balance between the need to meet a product milestone to secure funding and the need to maintain the quality standard defined by the Scrum team's Definition of Done. Here are a few suggestions on how to handle this situation: Schedule a meeting with the stakeholders, the product owner, and the Scrum team to discuss the problem and the impact it has on the product, the company, and its survival. Gather data by conducting surveys, interviews, and talks with the stakeholders, the Scrum team, and the venture capital firms to understand the root cause of the problem and the expectations of all parties. Make sure to involve other stakeholders in the process, such as subject matter experts, technology leaders, and line managers. Use workshops and exercises such as "Risk Management" or "Quality vs. Quantity" to help the stakeholders understand the impact of their decisions on the overall product and the company's survival. Establish clear expectations and communication channels between the Scrum team and the stakeholders to ensure alignment and avoid similar situations in the future. Consider including C-level members in the resolution process to ensure that the problem is treated with the necessary urgency and importance. Work with the stakeholders to find a mutually beneficial solution that meets the product milestone requirement while maintaining the quality standard defined by the Scrum team's Definition of Done as much as possible. Make sure that the stakeholders are aware of the risks that come with violating the Definition of Done and that the team will be able to handle them. Consider creating a new definition of done that aligns with the current situation and the stakeholders' requirements but also makes sure that the product will meet the quality standards that the team and the company are committed to as much as possible. Document the situation and the resolution process and share it with the team, stakeholders, and other relevant parties so that the company can learn from it and avoid similar situations in the future. It's important to remember that the survival of the company is at stake, and the team should consider all the options and alternatives available, but not at the expense of the product's quality, customer satisfaction, and the company's reputation.” Comment: ChatGPT suggests dying in beauty. An admirable stance, although you won’t encounter it in practice. By the way, adapting the Definition of Done to a delivery requirement is damaging Scrum anti-patterns. However, in a life-or-death situation, principles may fade. Follow-up question: Is there anything else I should know? ChatGPT: “It's important to keep in mind that in this situation, the team should not compromise the product's quality or user experience to meet the funding requirement; this could lead to negative consequences in the long run, such as losing customers or damaging the company's reputation. Additionally, it's important to understand that the stakeholders and the team may have different priorities and perspectives, and it's important to work together to find a solution that meets everyone's needs, in this case, the survival of the company. It's also important to remember that the Scrum framework values the definition of done as it defines the acceptable level of quality for the product, the team should try as much as possible to maintain the definition of done, but in case of a conflict, the team should clearly communicate the tradeoffs and the risks involved to the stakeholders and let them decide. It's important to keep in mind that the team should not rush into making a decision without thinking it through; it's important to have a clear understanding of the problem, the risks, and the potential solutions. The team should also consider the long-term impact of their decisions on the product, the company, the customers, and the company's reputation. Lastly, it's important to remember that the Scrum team is responsible for delivering a high-quality product, and the stakeholders are responsible for securing the funding, but both parties are working towards the same goal: the survival of the company.” Comment: ChatGPT is still true to Scrum’s principles. Consequently, the likelihood of everyone losing their jobs is high. Follow-up question: How might the Developers have contributed to the situation? ChatGPT: “It's important to keep in mind that it's not always easy to identify the root cause of a problem like this, and it's likely that multiple factors have contributed to the situation. However, some ways the Developers may have contributed to the situation include: Lack of clear communication: If the Developers have not effectively communicated the Definition of Done to the stakeholders, they may not understand the level of quality to which the team is committed. Lack of collaboration: If the Developers have not fostered a culture of collaboration with the stakeholders, the stakeholders may not understand the impact of their decisions on the product's quality. Lack of risk management: If the Developers have not effectively managed the risks associated with the project, the stakeholders may not understand the potential negative consequences of violating the Definition of Done. Lack of technical expertise: If the Developers lack the technical expertise needed to deliver a high-quality product, the stakeholders may not understand the importance of the Definition of Done. Lack of stakeholder management: If the Developers have not effectively managed the expectations of the stakeholders, the stakeholders may have unrealistic expectations about the product's capabilities or delivery date. Lack of understanding of the company's financial situation: If the Developers were not aware of the company's financial situation and the need to secure funding, they may not have fully understood the urgency of the situation and the potential consequences of not meeting the product milestone. Not being involved in the fundraising process: If the Developers were not involved in the fundraising process, they may not have fully understood the stakes involved and the potential consequences of not meeting the product milestone. Not being aware of the stakeholders' priorities: If the Developers were not aware of the stakeholders' priorities and goals, they may not have fully understood the urgency of the situation and the potential consequences of not meeting the product milestone. It's important to keep in mind that the Developers may not have been fully aware of the problem and its implications, and that it's important to work together to find a solution that meets everyone's needs and the survival of the company.” Comment: This answer is a mixed box. The organization is running out of money; it is not a question of product quality, technical expertise, communication among the parties, or the principle of the Definition of Done. Also, I don't consider the last three points to be negligence on the part of the developers. On the other side, suggesting an early involvement of the Developers in the fundraising process is an excellent idea. The same applies to creating transparency regarding the company’s finances. Conclusion While we can observe a decline in answer quality from the Scrum Master to the Developer scenario, nevertheless, it is remarkable how iterating on prompts can increase the utility of ChatGPT. Think twice if you still believe this technology is a fad or a trend. OpenAI’s next LLM is about to hit the ground running. What ChatGPT prompts have you used successfully? Please share your experience with us in the comments.
I asked on Twitter and LinkedIn why many developers don’t write or give talks, and I was amused by the response I received. This article is about that. The Problems It turns out developers do not write blogs or give presentations for a variety of reasons. Some developers may believe they lack interesting experiences or information to share or feel that they are not experts in their profession. Others may be shy or fearful of public speaking. Another reason is due to their hectic schedules, individuals may not have time to write about or discuss their jobs. Fear of making errors or being criticized is prevalent in the comments. Furthermore, many engineers may be apprehensive about being seen as an "impostor" and may not want to show their own flaws or lack of understanding. Language hurdles may be a cause of concern for persons who are not native English speakers; therefore, this issue may be more acute for them. Other prominent reasons for not writing or speaking about their work were procrastination, a lack of inspiration and confidence, and simply not having enough time. Some developers may also believe that they are too focused on their daily tasks and lack the energy or desire to share their expertise with others. In the comment threads on LinkedIn, Shai Almog and Bruno Souza had a thought-provoking conversation. Shai says there are three reasons why it might be hard for introverts to write and share blogs: They may have complex relationships with others. Writing blogs requires a different skill set than programming. Finding inspiration and confidence can be challenging. On the other hand, Bruno says that being an introvert can help you write good content because introverts tend to pay more attention to other people and are good listeners. They also talked about how hard it is to get noticed for writing and suggest that shy people start by writing for their team or close friends before sharing with a broader audience. The Benefits However, many of the people who answered said that the benefits of sharing one's knowledge and experiences with others are well worth the effort, even if it takes time and practice to get better at writing or public speaking. And I agree with that. There are several compelling reasons why one should write or speak. Sharing knowledge and experiences: Developers may share their expertise and experiences with others by writing blogs or delivering presentations, which can benefit both the writer and the reader. It could be a way for the writer to think about their work and make sure they really understand the topic. It may bring valuable insights and learning opportunities to the reader. Getting better at communicating: Writing and talking about technical topics can help you get better at communicating, which is important for every developer. It might help you explain complicated ideas in a clear and concise way to both technical and non-technical audiences. Networking and getting a better job: Developers may be able to connect with people in their area and grow their professional network by blogging and giving presentations. It is a chance to demonstrate their skills while also opening up new job prospects. Community building: Sharing information and experiences may also help the development community by creating a culture of sharing and working together. It may help developers generate a sense of community and support. Personal growth: Publishing and speaking about one's work might be a unique chance for developers to flourish. It might help people think about their own lives, and find ways to improve and feel good about what they've done. Solutions Now that we all know the benefits, the question becomes: how do we start? Start small: If you're new to writing or speaking about your work, it can be helpful to start small. This could mean writing short articles or giving small talks to colleagues or friends. As you gain confidence and experience, you can gradually build up to larger audiences. Don't fear making mistakes: Mistakes can happen, and that's part of life. The good thing is, if you write something wrong, plenty of people will help you correct it, and you will be learning, which is a great reward. Find your niche: Identify the topics you are most passionate about or have the most expertise in, and focus on those when writing or speaking. This can help you feel more confident and make it easier to develop ideas. Share knowledge with your team or friends: You don't need to start writing public posts right away. Instead, send a daily email to your team or maybe to your friends who you are comfortable with. In these emails, you can share things you think would be helpful for them and your project. If someone says your email was helpful, or if you particularly liked something you wrote, consider posting it on your blog for others to see. Practice and practice: Like any skill, writing and speaking take practice. Setting aside time to write or prepare talks regularly can be helpful, even if it's just a few hours a week. This can help you improve your skills and become more comfortable with the process. Get feedback: Seeking feedback from others, whether it's from colleagues, friends, or editors, can be a great way to improve your writing and speaking. Don't be afraid to ask for constructive criticism: use it to improve your work. Be yourself: Finally, being authentic and genuine when writing or speaking about your work is essential. Feel free to let your personality shine and share your experiences and perspectives. This can do your writing and talks more relatable and engaging for your audience. Conclusion Even though it might be difficult, writing and speaking can provide numerous rewards that we all desire to reap.
At some point, you begin to lead. This is very different than managing. The difference can be summed up with the phrase, “Leaders make their own problems." I’ll explain that in a bit, but first, let me tell you a story. When I First Realized I Was Missing Something When I first became a director, I had a conversation with another director named Jim. Jim: “So, you’ve been in this role for a month now. Have you figured out your vision for your organization?” Me: [What is he talking about?] I realized I was used to taking direction from others, and I had become a sort of “execution-” focused manager. I didn’t have any idea what my organization needed. I had no idea what the future should look like. I was managing my organization, not leading it. Interrogate Yourself I brought this up with an executive coach I was working with at the time. He encouraged me to set time aside every week to really think deeply about my area of the product. At first, it was hard to preserve the time I set aside. In my busy schedule, it seemed luxurious to save a couple of hours just for thinking, but it quickly became some of the most valuable time I spent each week. I would spend time each week thinking amount my organization, the product, and how things were going. I researched other products that competed with mine. I spent time using the product. I thought critically about our technical and product failings. I ended up developing a better sense of what possible futures I could create. I started to see possibilities that were invisible to me. I started to learn how to lead. Mental Models: Try and Catch Them All! At around this time, my manager challenged me to start using more mental models in how I assessed my organization. He suggested looking at the situation from the point of view of: A systems thinker (this was my default) An architect A product manager A designer Most leaders use their own experience as their main mental model. Being able to add new mental models to your toolkit makes you more flexible. Each mental model can alter what you think the future should look like, and what the present should look like. It can also inform you of the actions you should take to make things happen. As I started developing a habit of looking at things from other mental models, I began to see blind spots in my previous ways of looking at the world. Interrogate Yourself With What Exactly? Each week, I sat down and looked at an evolving set of questions. I would go through the list and write answers to the questions on the list. Here is my list of questions: Review High-Level Objectives What are the results that are needed? What needs to be true in a year? X needs to be Y by Z. What would need to change for that to happen? What are the implications of that need? How are the teams performing? On time, hitting the mark, right characteristics? How are they performing AS a team? Where are things on the path to fail? What’s the worst thing that could happen? Is there anything I think my boss is making a mistake on? Can all of my reports take over my job in 1-2 years? What seems like it’s not working right now? What’s going well that could be turned into a repeatable process? What should I worry about? What do my managers need? What does my org need? What do I need? Review Progress Against Objectives How on track is everything? How long should the rope be for all of my objectives? Agree to them with other people. For example: when should we expect reliability to improve? Review team health. Review progress against goals. How are team members doing against their goals? Identify Next Actions What actions should be taken? I found writing down the answers to these questions to be tremendously helpful. If you’re an external processor, you might find it more useful to talk with others about these questions. For me, I did a bit of both. I found a few other people that I would talk about these things with. But I found the private thinking time valuable — it gave me more material to test with others in conversation. Leaders Make Their Own Problems A leader is a person that asserts a future for a group of people. If you want to lead, you have to learn to make your own problems. And hopefully, you’ll find some of the processes I’ve used to develop that future useful. Do you have your own methods? Please share them with me! Thank You Jim Ruppert helped me see that I didn’t have a vision for my organization. Robert Goldmann helped me learn the perspective I needed to lead better. He helped me develop some of the questions on this list. Alex Kroman challenged me to consider things through multiple mental models.
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.
Last year, I enjoyed reading a new and provocative book that explores a new way to think not only about some aspects of life but about everything. Essentialism: The Disciplined Pursuit of Less by Greg McKeown brings this new perspective, but is it right? Can we apply it to software development? The short answer is: yes. Furthermore, you can do it more efficiently, and in this post, we'll explain how with the essentialism methodology. When we talk about software engineering, it might have several approaches and definitions. This post will use my favorite one from Modern Software Engineering by Dave Farley. "Software engineering is the application of an empirical, scientific approach to finding efficient, economic solutions to practical problems in software." Where efficiency is not an optional part of the process of software development, and when we talk about efficiency, we also include avoiding the waste of several resources on it such as powerful computers and people's time. That is where essentialism helps in the process, mainly because it starts with three core principles: Individual choice: We can choose how to spend our energy and time. The prevalence of noise: Almost everything is noise, and very few things are precious. The reality of trade-offs: We can't have it all or do it all. If you still don't follow me, let's take a step back and talk about the enemies of good software development. The Obstacles to the Software Process Last year, Forbes enumerated sixteen obstacles to creating promising software in 16 Obstacles To A Successful Software Project (And How To Avoid Them). We will highlight some as follows: Hyper-focused planning and design Unclear or undefined client expectations Overlooking nonfunctional requirements Not aligning early on the "must-haves" Does it sound like a paradoxical problem? How can we spend a lot of time planning something we don't understand? We're putting energy into something that does not help us to solve the problem or to boost the right target. That is issue number one: how to spend time and energy on the correct problem and spend energy on what matters. That is where software development needs essentialism. We need to find the highest point of contribution: the intersection of the right thing, time, and reason. The highest point of contribution Clarity is part of the process of archive success in software development, and the power of choice is crucial for it. The choice is an action that defines where you'll put the energy. Being optimal of those options can help you get close to your objective. The energy on essentialism vs. no-focus The action of choice is strict, mainly because we need to think more about the yes, including the several negatives we need to say. It was one of the most challenging points of my life; initially, I related the "yes" with open opportunities like the Yes Man movie. It is a battle between the fear of missing out (FOMO) and focus. It might impact you as well. I recommend trying it out and see if you are like me: that the "no" gives you freedom. Again, it is not easy. I still fight it, but find it necessary - actually, essential. As a software engineer, saying no also includes avoiding the newest technology in the market because this ally might become an enemy and make things more complicated than necessary. Essentialism Is Saying “No” To Many Things, Including Over-Engineering When we compare the software development tools with ten years ago, we have many options that are supposed to make our life easier, including methodologies, frameworks, and tools such as Kubernetes, microservices, etc. But why do I use the word "suppose"? With many tools, it gives us options that make our life harder, and exploring the wrong tool makes things more complex (see "Complexity is killing software developers" by Scott Carey). In software development, there is no silver bullet: accordingly, it is ok not to use microservices, Kubernetes, and even-driven and hexagonal model architecture all the time. When we talk about microservice, it is only possible to think about the two books on the topic by Sam Newman. But even he wrote "Should I use microservices?" where he does not recommend for use on a new product. The topic here is not to blame new trends or technologies. Those are amazing and help at the proper time. The first question is how far those are from our goals. Essentialism can help us go for it with simplicity. The Bare Necessities When we talk about software decisions and design, we think about software architecture that has two laws: The why is more important than the how. Everything has trade-offs. Once you find the goal and where you want to put your and your team's energy, simplicity can help decrease unnecessary software development risk. I'm not against innovation: I love it, but exploring the wrong tool can impact you to go to the flawed site. Starting not using those new and fancy techs and exploring more straightforward and fast ways to go, such as monolith or not using Kubernetes, might be a good solution for the beginning. Being adaptive is the fundamental part of the Agile process, and software on production is part of it. Remember, not starting with microservices does not mean not using them shortly; you can explore them when necessary. It also happens with the hexagonal model. Do you need all of those layers to start? Let's start with three, such as an MVC. Start simple and evolute your software and architecture: it is part of evolutionary architecture. The software needs to be adaptative and not see the future. In summary, looking for the bare necessities is a good choice if your software architecture has a song. We explored the architecture decision, but regarding methodologies, we also have human interactions, which include meetings. Let's talk about them as well. Saying "Hasta la Vista, Baby," To Endless Meetings When we talk about software development, we need to include the more worthwhile resource, primarily because we cannot get it back once we waste it: time. When we talk about time, on the one hand, we have over-engineering; on the other, meetings, meetings, and more meetings. We must remember that it is a group of people stopping to follow a goal. Save people time by making sure the prerequisites of the meeting are in the description and exploring the meeting notes to register the decision. Please pay attention to the time of the sessions. There is Parkinson's Law that says work will expand to fill the time allotted for its completion. Summary When we talk about software development, ensuring that you're doing the right thing at the right time is crucial for the key to delivering. Essentialism is a great partner to make it happen, mainly because it decreases the chance of overengineering, endless meetings, and waste. Even categorized as a non-IT book, "Essentialism: The Disciplined Pursuit of Less" helps give guidance to meet simplicity and trust more what an uncomplicated solution work once a smooth software is a software with less risk of misunderstanding and becomes a legacy code faster than usual. I hope that you enjoy the book as I do.
Organizations that can achieve peak performance from their core business applications are the ones that can effectively grow, compete, and differentiate themselves. However, many such apps were written quite a few years back, even decades ago. Over time, most of them start facing various issues, from outdated tech stack to degrading user experience, from data breaches to expensive maintenance. And so, devising an efficient application modernization strategy is necessary to ensure these mission-critical systems stay updated and relevant in this day and age. What Is Continuous Application Modernization? Continuous modernization is an iterative and gradual process. It gives businesses the prompt support and value they need. Continuous application modernization addresses the challenges faced by businesses due to technological debts. This ensures that ongoing business doesn’t face any business disruption. As seen in the picture above, you can clearly see that in continuous modernization, you can develop or upgrade applications quickly, release them frequently and quickly, and test, monitor, and refine them continuously. Talking metaphorically, earlier, we used to keep track of finances using ledger books. As businesses and technology advanced, we stuck with spreadsheets. Now cloud-based applications like SAP are helping in scalability improvements. Why Modernize? There isn't much of a choice as to whether to modernize or not for the majority of businesses that weren't "born" digital and are, therefore, unprepared to utilize all the latest cloud technology. Competitors leveraging technology will be more agile, responsive, and innovative and will win the race if your infrastructure, technology, applications, and method of developing software are still stuck in the past. Today's large legacy companies need to change swiftly to be competitive and relevant. That’s why applications need modernization to deliver and stand up to modern-day customers’ expectations. What Are the Benefits of Continuous Modernization? There are a few benefits of continuous modernization that one needs to be aware of: Achieves better results: To prevent downtime from impacting crucial business activities, replacing decade-old legacy software takes thoughtful and lengthy planning. Interdependencies between infrastructure and applications frequently result in unanticipated issues. Big-bang modernization of complex application environments can easily significantly raise the risk of failure. The ability to gradually migrate ensures long-lasting components of large applications in a sustainable manner. High scope of innovation: To succeed in the current competitive industry, the appropriate balance between maintenance and innovation is essential. Continuous application modernization fosters discovery and innovation more quickly than any conventional legacy application modernization strategy since it stresses smaller, incremental approaches. Avoids application retirement: Applications must be current in terms of both technology and infrastructure in order to succeed and remain competitive. Continuous application modernization makes use of contemporary technologies and guarantees that you are always one step ahead of the competition to prevent issues with early retirement. Modernizing Applications With Azure Azure provides multiple choices for hosting your applications like; Infrastructure-as-a-Service(IaaS), Platform-as-a-Service(PaaS), Containers-as-a-Service(CaaS), and Serverless. Azure provides you with flexibility according to your business needs. For example: If you are concerned about re-platforming your ASP.net site, you can leverage Azure app services. For restructuring your legacy applications to microservices, you can leverage Azure Kubernetes Services. AKS helps you gain more control over your containerized application and its infrastructure. For running web-based applications, Azure has a dedicated service known as Azure App Service. Azure App Service supports all the standard frameworks, and you can run your applications by using Windows and Linux-based containers. Application, database, and infrastructure discovery, evaluation, rightsizing, and migration to Azure are all possible with Azure Migrate services. Modernizing Applications With AWS The AWS cloud offers a variety of alternatives for hosting and updating apps. You can replatform those workloads to AWS-managed services such as the Elastic Kubernetes Service (Amazon EKS) or Amazon Elastic Container Service (Amazon ECS) using AWS Fargate. By using container solutions like Amazon ECS and Amazon EKS or event-driven serverless compute services like AWS Lambda, you can create new, secure apps using serverless architecture. When teams have no restrictions on the current instances or container platforms and concentrate largely on building code, customers pick AWS Lambda. AWS Lambda provides the highest level of abstraction from infrastructure, allowing users to carry out releases more quickly. How IBM Cloud Partnered With Google Cloud to Deliver Continuous Modernization IBM approaches continuous modernization through an application portfolio transformation program. The software utilizes the IBM Garage Methodology's guiding principles to carry out continuous modernization and iterative IT modernization. You can deliver on crucial business outcomes and maintain an up-to-date portfolio by using analytics to make educated decisions. These actions are carried out in two simplified phases: Intake phase: The IBM team employs a collection of technologies called Delivery Curator during the intake phase to provide an accurate image of your IT system. It's a pattern-driven system that ingests data and offers suggested target migration patterns, such as workbooks, timelines, personnel estimations, and squad-configuration recommendations. Factory phase: For typical cases, the factory phase is in charge of designing and executing migration and workload transformation. This phase includes the design and planning processes as well as the construction, testing, and relocating of particular applications. This stage involves a thorough study, the discovery of modernization patterns, and the creation of the execution strategy. Conclusion Application evaluation and data alignment are two aspects of continuous modernization that guarantee the correct decisions are made at the appropriate time. For firms to adopt current technologies and consistently provide value, ongoing efforts and reviews are necessary. When your technology and platforms become outdated, continuous modernization accelerates decision-making and prevents the need to start from scratch when developing new applications. From my perspective, I have tried to narrate the core What, Why, and How organizations are leveraging continuous application modernization. In case you have any questions in mind, feel free to approach me in the comments section below.
This article is a follow-up to Engineering Manager: Resolving Intrapersonal Conflicts and Engineering Manager: Resolving Interpersonal Situations. In the previous articles, we talked about interpersonal conflicts, which are conflicts between two or more people that do not agree on topics such as what actions to take or what the priorities are. Today we will talk about organizational conflicts, common scenarios, and some tips on how to manage them in a professional environment. Organizational This conflict is associated with misalignment or disagreement between members of the organization and the organization's cultural values, strategic decisions, goals, or methodologies. Usually, this kind of conflict starts when people believe that their values, professional development, goals, or attitude are not aligned with the organization or with the management layer of their areas. Career Path Most people are interested in a professional career path and together with the salary level and manager affinity are one of the main reasons to change companies. People want to promote because of the recognition, provide value across the company, and also the salary increase. The problem with the career path and promotions not only depend on people there are other factors such as: How many positions are available? If the company prioritizes talent recruitment or team growth Company financial status Sometimes it is necessary to bring in outside talent to bring in new ideas. When the promotion implies a change of role, even if all the technical requirements are met, there are some soft skills that are considered restricted. Soft skills are sometimes not easy to measure. When people want to be promoted to global contributor roles, soft skills are often more important than technical capabilities. Impacts When people meet all requirements to promote to a new role but promotion does not occur, three things usually happen, one followed by the other: People become demotivated. They share this demotivation with part of the team. They leave the company. Tips Transparency: We must always be honest and transparent with our team. Never promise promotions based on the requirements of merit because there are factors that we do not control. No promise: We can never promise a promotion; we can manage the promotion. If not possible: Sometimes promotions are not possible in the short term. We have to share this message in a constructive way and try to look for alternatives that can satisfy them for a period of time. Cultural Values When people join a new company or team, they bring their cultural values from their last experience. During the day-to-day, they probably face situations that generate intra-personal and interpersonal conflicts because they are not used to resolving them in the same way. There are two common scenarios: Fear to make errors so that when they make a mistake (I make mistakes every day), it implies a situation of internal confrontation between being honest with their team or trying to solve them quietly. They try to apply their cultural values in terms of best practices, responsibilities, or communications that do not have to be the ones we want in our company. Impacts In a company's normal growth, people usually need a few months to adapt to the team and this should be part of the onboarding process. The higher risk appears when we are hiring many people in a situation that requires fast growth because we are generally not as meticulous in the onboarding process. They can spread along the company the opposite culture that the company promotes. Tips Always remember that the people who join the company bring with them a culture that may be very different and that we have to work with them to align them with the values we want to promote. The cultural values, tips, and common scenarios must be included in the onboarding process and also in the follow-up plan. People automate behaviors, so when they start a new company they probably unconsciously apply methodologies or behaviors learned in their previous roles. Teams need to be aware of this because during the onboarding process they will face situations that they will have to manage. Our teams have to empathize with people and at the same time mentor them. It is important to assign a mentor who can spend time with new people and support them in their new environment. In very rapid growth it is necessary to assess these risks and establish a team growth strategy. There are several strategies that we will discuss in another article. Burnout Burnout syndrome was defined by Herbert Freudenberg as a "state of mental and physical exhaustion caused by one's professional life." Of course, it is an intra-personal conflict but caused by many other conflicts during people's professional careers. It is very different from impostor syndrome mainly because burnout does not provide any positive aspects to the organization or people. People who are experiencing burnout are emotionally exhausted, interpret any situation negatively, have low self-esteem, and have generally lost the feeling of fellowship. These are some of the main factors that contribute to employee burnout: Deadlines/time pressures: Working in a constant environment of pressure to achieve goals with unmanageable workloads Lack of role definition: Not being clear about the responsibilities and goals of people's roles generates a constant situation of uncertainty about what is expected of them. It usually leads to a feeling of unfairness. The relationship with the management layer Impacts When people are burnout imply a negative impact on every area of life: Health: There are studies that have shown how negative it is for overall health, not only mentally. Team: Promotes negative dynamics and does not empathize with people and therefore tends to generate conflicts Performance: Being exhausted means that they cannot focus on the objectives. Tips There is no single factor, people generally get into this situation because of mismanagement by their manager and the organization: Marathon, not a sprint: People cannot be constantly working as if everything were a sprint. We have to be very careful not to create a culture of continuous excessive effort. Conciliation: Promote a goal-based and flexible culture. People have children and emergent situations where we have to support them when they need this flexibility. The important thing is not how many hours they are working, but achieving the goals as a team. Responsibilities: Not giving responsibilities that they cannot manage because they have no skills or because they are in a complex personal situation at this moment Support with conflicts: We need to support them to resolve conflict situations and not look the other way. Take a break: Provide mental and cognitive breaks for people who are under higher stress. Giving them more time for self-learning, and making temporary rotations to lower stress initiatives. Burnout is the consequence of many other unmanaged conflicts and occurs progressively over a long period of time. There are many indicators that we can detect during one-to-one or informal talks. Conclusions These types of conflicts are the main causes of people leaving the company, but there are cases in which as managers, we cannot do anything in the short or medium term about the root cause of these conflict situations. We have to prevent people from getting into burnout by providing the best possible workplace and providing all the necessary support to our teams. We must provide constant feedback to the organization on these types of conflicts and promote a culture of transparency, honesty, and continuous feedback. These are the foundations for constant improvement and the way to reduce these kinds of conflicts. We must also be honest with ourselves and with people when cultural values do not fit between the two parties and perhaps the best thing to do is to seek new challenges in another team or company. Sometimes as a manager, we have an obsession with retaining people in the team and I think we need to change that goal to find the best environment for them.