Agile Resources

DZone's Featured Agile Resources

Getting Hired as a Scrum Master or Agile Coach

By Stefan Wolpers

CORE

TL; DR: Getting Hired as a Scrum Master or Agile Coach Are you considering a new Scrum Master or Agile Coach job, but you are not sure that it is the right organization? Don’t worry: there are four steps of proactive research to identify suitable employers or clients for getting hired as a Scrum Master and avoid disappointment later. I have used those four steps for years to identify organizations I would like to work with, and they never failed me. Read on and learn how to employ search engines, LinkedIn’s people search, reach out to peers in the agile community, and analyze the event markets in the quest for your next Scrum Master job. The Scrum Master Job Market Is Challenging We have all heard the news that organizations question the usefulness of employing Scrum Masters and cutting back on offering job opportunities. In some cases, they even laid off all Scrum Masters and Agile Coaches. Times are challenging, and many peers must make ends meet, considering more “tolerance” regarding job opportunities. While I understand the approach, I like to advocate for preparing yourself properly in advance of getting hired as a Scrum Master to avoid future disappointment with new clients or employers. Therefore, if looking for a new Scrum Master job, consider two questions: Do I want to work for a developing agile organization (of the late majority) where my work will likely be met with resistance at multiple levels? Alternatively, how do I identify an organization that established agile practices compatible with my mindset? The two questions are relevant to applying to available positions and identifying suitable employers or clients for a proactive application. How To Get an Idea of an Organization’s Maturity Regarding Scrum or “Agile” While it is impossible to assess an organization’s “agile maturity” — if there is such a thing — solely from the outside, it is possible to acquire enough of an understanding of its agile practices this way. That understanding would allow for asking the right questions at a later stage; for example, during an initial job interview. Or, you may conclude after your research — thus early in the assessment process (see below) — that the organization is not compatible with your expectations of a future employer or client. (Consider the popular saying: "There is no job interesting enough that you just couldn’t walk away from it.") The good news is that all organizations that genuinely embrace agile practices are usually openly talking about their journeys (unless they need to honor compliance rules) and are transparent and actively supporting the agile community. The reason for this support is simple: being transparent and supportive is the best way to pitch the organization (and its agile culture) to prospective new team members. The war for talent is even more imminent for agile practitioners. The necessity of critical information is the basis for all research activity during the three distinct phases of your assessment process prior to getting hired as a Scrum Master: Proactive research Job advertisement Job interview Getting Hired as a Scrum Master, Phase 1: Proactive Research The proactive research comprises four elements: search engines (Google, Bing, YouTube, etc.), LinkedIn people search, reaching out to peers in the industry or communities, and analyzing the event markets. Source 1: An Opportunistic Search via Google, Bing, or YouTube As a first step, always search the organization’s name in combination with a variety of agile-related keywords, such as: Agile Lean Scrum Scrum Master ScrumMaster Product Owner Kanban SAFe LeSS Nexus DevOps Continuous integration Continuous delivery Design thinking Lean startup Tip Use additional search parameters to narrow down the search results. For example, the query "scrum master" site:age-of-product.com will return all articles on Age-of-Product.com that include the term “scrum master.” (Learn more about advanced search on Google.) The purpose of this exercise before getting hired as a Scrum Master is to discover an organization’s use of agile practices and the associated fluency level by shedding some light on questions such as: Scrum, Kanban, XP, Lean UX, Design Thinking — What are they practicing? Are the current Scrum Masters or Agile Coaches working at the organization? How many engineers or engineering teams are working for the organization? What is the size ratio between the product management and engineering teams? Is the organization practicing continuous product discovery? Is the organization practicing DevOps? The initial search results will provide a first impression, directing further searches of blog posts, videos of conferences or local meetups, slide decks, podcasts, or threads in communities. A truly agile organization will leave traces of a large variety of content. The mere quantity of results, though, does not signal that the organization in question has already passed the test, so to speak. There is no way to avoid checking the content. Here’s an example: InfoQ — a community news site facilitating the spread of knowledge and innovation in professional software development — has a rigorous editorial process and focuses on delivering quality content to its audience. Contrary to InfoQ’s standards, there are quite a few articles on Medium.com, for example, that could raise eyebrows for scrutiny. A good rule of thumb when scanning search results is noting the diversity of sources. If you find content only on the company blog, and it has barely been shared or commented upon, it might hint that the content is not relevant enough to be of interest within the Agile community. Advanced Tips Search for the title of a particular content piece on X or Twitter and have a look at the search results: Who from the Agile community is sharing this content? Use sites like BuzzSumo for content research. While BuzzSumo is a paid service, they offer a generous 30-day free trial period. Source 2: LinkedIn’s People Search Another good source for research on the target organization before getting hired as a Scrum Master is LinkedIn’s people search. You can list results by search term and then filter them, for example, by company name and location. (Here is an example of Scrum Masters working for Accenture in North America which lists currently about 2,800 results.) And while you’re at it, why not reach out to someone listed in the search results who is in your LinkedIn network? Or ask someone from your network who may introduce you to a person from the target organization you would like to interview about their Agile mindset? Please note, though, that internal job titles may differ from your vocabulary and impact the accuracy of the search results. Source 3: Ask Peers for Help via Reddit, Hacker News, the Hands-on Agile Slack Community, and LinkedIn Groups It is also beneficial to extend the initial Google search to online communities such as Reddit or Hacker News (HN), to name a couple. Both communities allow for posting articles as well as questions. The archive of HN is of particular interest. It is not just because of the sheer number of available articles or threads there but also the partly heated discussions going on in the comments. Be aware, though, that "Scrum" as a concept is challenged by a lot of outspoken community members (namely, independent developers) both on Reddit and HN. Beyond passively scanning the archives, posting a direct question to peers is an alternative. HN is likely a waste of time, and if using Reddit – choose the Subreddits r/agile and r/scrum for a possibly better outcome. Note: Don’t forget – haters will hate, and trolls just want to play. Do not take it personally if your search on Reddit or HN is not taking the direction you desire. You can probably expect more support by asking the 19,000 members of the "Hands-on Agile" Slack community for help on getting hired as a Scrum Master. This is a worldwide community of Scrum Masters, agile coaches, and Product Owners that has proven to be very supportive. There are also LinkedIn groups available that focus on Scrum and agile practices — some with more than 100,000 members. After having joined them, post your question(s), remembering to be compliant with the group rules. Expect your first posts to be moderated, though. Some recommended LinkedIn groups — in no particular order — getting hired as a Scrum Master are: Agile Clinic Scrum Practitioners Agile World Group Scrum.org Agile Agile Project Management Agile Coaching Scrum Practitioners, Scrum Masters If posting a question to a LinkedIn group, expect to monitor it carefully and interact with answering members in a timely manner: not interacting with responding group members may be considered rude and possibly lead to being banned from posting in the group again. (Read More: Etiquette in technology (Netiquette).) Also, try Quora, directing a question on getting hired as a Scrum Master to Quora members active in the agile realm as to whether the organization of interest has an agile mindset. (Note: In doing so, avoid asking anonymous questions — which tend to have a significantly lower answering rate.) Lastly, the two main Scrum certification bodies — Scrum.org and ScrumAlliance — provide access to directories of certificate holders. In both cases, you need the certificate holder’s email address access to a public profile via the search function. A faster way to access a known individual’s public profile is often the advanced Google search, see above. Source 4: Is the Organization Sponsoring or Organizing Meetups, Barcamps, or Conferences? In my eyes, supporting public or virtual events is the highest form of contribution to the agile community by an organization. There are four different levels of engagement — no matter whether the event is a virtual event or an in-person event: Organizing conferences (or Barcamps) Sponsoring conferences Providing speakers at conferences Sponsoring local Meetups and Barcamps by providing a venue Suppose an organization provides this level of support to the agile community. In that case, the talk about this will undoubtedly be on the company blog, an engineering or product-management-related blog, or in a press release in their public relations section. In the unlikely case that any reference cannot be found, just contact the Public Relations department who will provide the required information. A. Browsing Conference Sites for Sponsors Conference sites are a good ground for identifying prospective organizations when considering applying for a Scrum Master position. Check carefully for two things: sponsors and speakers. Search for sponsors that are practicing agile in their daily operations. Usually, a larger sponsor package will also include a speaking slot at the conference. Attending such a session — whether in person or virtually — will provide direct access to the speaker and thus a first contact in the inner circle of that organization’s agile practitioners. This tends to be valuable: People departments often rely on the private networks of the organization’s available agile practitioners to identify suitable candidates for job openings as a Scrum Master. (Accordingly, attending local Meetups can also be a worthwhile investment for job seekers.) B. Browsing Conference Sites for Speakers Personally, a more promising approach, by comparison, is to search for non-professional speakers who are aligned with an organization that is not sponsoring the conference. These speakers may indicate a suitable prospective employer or client after already having gone through the selection process for speaking proposals and vetting their contribution for originality. The same approach can apply to contributions at Barcamps, although a disadvantage is that the critical information is only available during an event. While the speaker list of a conference is available in advance to stimulate ticket sales, it is the nature of a Barcamp that the schedule, and hence the speaker list, is available only on the day of the Barcamp. If you are already planning to attend a Barcamp, it may just be an inconvenience and not a concern. Timing is crucial, though, so please keep in mind that tickets for Barcamps are often sold out within minutes. (For example, the 600-plus tickets for the UXCamp Europe were regularly gone in a few minutes until the organizers switched to a lottery.) There are numerous conferences regarding agile practices, so here are just some of the listings: Agile Alliance Agile Testing Days Agile on the Beach QCon New York For an additional listing of conferences, check the Top 10 Agile conferences to attend in 2024. Lastly, the big conferences are often considered must-attend events — useful, for example, to gain or improve professional visibility within the agile community. Alternatively, smaller conferences often prove to be more effective by providing information that helps identify a suitable, prospective agile organization. The larger the conference, the more possibility of noise camouflaging that information, complicating getting hired as a Scrum Master. C. Browsing Meetup.com Meetup.com is a great site to discover which events of the Agile community are happening locally and who is organizing them. There are thousands of meetups worldwide covering the topics of agile frameworks and practices, software engineering, and product development in general. Since the pandemic, many Meetup groups switched to virtual events, attracting more members from outside their original reach. For example, the Hands-on Agile Meetup community has grown from about 1,500 members in March 2020 to more than 6,500 members worldwide in February 2024. The new members from all over the globe — from Vietnam to Brazil to the United States — added tremendous expertise and diversity, making the events more inclusive and a much better experience for everyone. Therefore, Meetup.com is an excellent place to look for answers and peer support. Conclusion: Getting Hired as a Scrum Master Suppose you are looking for a Scrum Master job. In that case, it is possible to understand the agile mindset of an organization in advance by applying the research approaches sketched above. Investing a few hours in advance may save you from later disappointment when your Scrum Master job may turn out to be vastly different from what was pitched or promised to you before. More

Sprint Retrospective Meeting: How To Bring Value to the Table

By Sandeep Kashyap

A sprint retrospective is one of the four ceremonies of the Scrum. At the end of every sprint, a product owner, a scrum master, and a development team sit together and talk about what worked, what didn’t, and what to improve. The basics of a sprint retrospective meeting are clear to everyone, but its implementation is subjective. Some think the purpose of a sprint retrospective meeting is to evaluate work outcomes. However, as per the Agile Manifesto, it is more about evaluating processes and interactions. It says, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Many scrum teams are not making most of the sprint retrospective meetings due to a lack of understanding. In this post, we will look at what to avoid in a sprint retrospective meeting and what to do to run an effective sprint retrospective meeting. What To Avoid in a Sprint Retrospective Meeting? A sprint retrospective meeting is an opportunity for the scrum team to come together and discuss the previous sprint with the purpose of making improvements in processes and interactions. But scrum teams often end up making a sprint retrospective meeting a negative talk of beating one another and less interesting due to the lack of implementation of outcomes of sprint retrospective meetings. Here are a few things that you need to avoid in a sprint retrospective meeting: 1. Focusing on the Outcomes The end goal of a sprint retrospective is undoubtedly increasing the sprint velocity of the team, but the process to do so is not talking about the outcome of the sprint. The focus is on finding areas that can be improved in processes and people to make it easy and efficient for the scrum team to work together. 2. Not Involving All Team Members’ Voice The output of a scrum team is evaluated as a team, not as each individual. Therefore, it is important that each member of the Scrum team is heard. Thus, the equal participation of the team members is required in retros. If someone has issues and they are not addressing them, it is going to impact the sprint output as the members of the sprint team are highly dependent on each other to achieve sprint goals. 3. Talking Only About What Went Wrong The purpose of a sprint retrospective is to make improvements, but it does not mean you do not talk about good things. We all are human beings and need appreciation. If you talk only about what did not work, a sprint retrospective will become more of a tool of blaming and beating each other rather than an instrument of improvement. Above all, it is important to talk about what went well so that you can replicate good things in the next sprint. 4. Not Taking Action on Retro Outcomes The worst thing that can happen for a sprint retrospective is not taking action items derived from it. This will lead to a loss of interest and trust in sprint retrospectives as it sends a message to the team that their feedback is not valuable. What To Do To Run an Effective Sprint Retrospective Meeting There are some basics you can follow to run an effective sprint retrospective meeting. Have a look at them. 1. Create a Psychologically Safe Space for Everyone To Speak It is the responsibility of a product owner and a scrum master to create a psychologically safe environment for everyone to speak up in the meeting to make a sprint retrospective successful. If you are asking questions like what went well during the last sprint, what didn’t go well, and what should we do differently next time, everyone should feel safe to share their views without any repercussions. 2. Use a Framework The best way to conduct an effective sprint retrospective meeting is to follow a template. Experts have created various frameworks for conducting effective sprint retrospective meetings. The top frameworks include: Mad, Sad, Glad Speed car retrospective 4 L's Retrospective Continue, stop, and start-improve What went well? What didn't go well? What is to improve? These frameworks help ensure that you are talking about processes, not people. For example, the Mad, Sad, Glad framework talks about asking what makes the team mad, sad, and glad during the sprint and how we can move from mad, sad columns to glad columns. Use a framework that works for your scrum team. 3. Have a Facilitator-In-Chief Like any other meeting, a sprint retrospective meeting needs to have a goal, a summary, and a facilitator. Have a facilitator-in-chief to make sprint retrospectives valuable. Usually, the role is dedicated to the scrum master whose responsibility in sprint retrospective is to: Set the agenda and goals of the sprint retrospectives. Collect feedback from all the team members on the action items to talk about in the retro. Defining the length of the meeting. Follow up with action items implemented in the last sprints. Summarizing the key action items for the next sprint. 4. Implement the Action Items The responsibility of the scrum master does not end with a sprint retrospective. A scrum master needs to make sure that action items found in the sprint retrospective are implemented in the upcoming sprint. Daily stand-up meetings are a great tool for the scrum master to ensure that the team is implementing what is agreed upon & discussed and making improvements. Also, you can see the results of sprint retrospectives in tangible terms with metrics like sprint velocity. 5. Positivity, Respect, and Gratitude for Everyone Lack of engagement is the biggest challenge of sprint retrospectives in the long run. It occurs when action items are not worked on, people are not heard, and the focus is on negatives. Cultivate positivity and have respect and gratitude for everyone. Talks about what can be improved rather than blaming individuals. Listen to others to mark respect and express gratitude to address everyone’s contributions. Paired with the implementation of action items, you can ensure that your scrum team sees sprint retrospectives as an opportunity to improve. Conclusion Sprint retrospective is a great opportunity to look past what worked well, what went wrong, and what we can do ahead to improve. It is a great instrument for a business to improve efficiency, keep its workforce happy, and build products that both clients and end-customers love. The only challenge is you need to utilize it appropriately. With insights shared in this post, there are high chances you will be able to run effective sprint retrospective meetings and bring actual value to the table. More

Sunsetting Scrum Masters

By Stefan Wolpers

CORE

The Naming Nuance of Non-Functional Requirements

By Marie Cruz

Research Report: DZone 2023 Community Survey

By Jason Cockerham

Agile Methodologies for Edge Computing in IoT

In the fast-evolving landscape of the Internet of Things (IoT), edge computing has emerged as a critical component. By processing data closer to where it's generated, edge computing offers enhanced speed and reduced latency, making it indispensable for IoT applications. However, developing and deploying IoT solutions that leverage edge computing can be complex and challenging. Agile methodologies, known for their flexibility and efficiency, can play a pivotal role in streamlining this process. This article explores how Agile practices can be adapted for IoT projects utilizing edge computing in conjunction with cloud computing, focusing on optimizing the rapid development and deployment cycle. Agile in IoT Agile methodologies, with their iterative and incremental approach, are well-suited for the dynamic nature of IoT projects. They allow for continuous adaptation to changing requirements and rapid problem-solving, which is crucial in the IoT landscape where technologies and user needs evolve quickly. Key Agile Practices for IoT and Edge Computing In the realm of IoT and edge computing, the dynamic and often unpredictable nature of projects necessitates an approach that is both flexible and robust. Agile methodologies stand out as a beacon in this landscape, offering a framework that can adapt to rapid changes and technological advancements. By embracing key Agile practices, developers and project managers can navigate the complexities of IoT and edge computing with greater ease and precision. These practices, ranging from adaptive planning and evolutionary development to early delivery and continuous improvement, are tailored to meet the unique demands of IoT projects. They facilitate efficient handling of high volumes of data, security concerns, and the integration of new technologies at the edge of networks. In this context, the right tools and techniques become invaluable allies, empowering teams to deliver high-quality, innovative solutions in a timely and cost-effective manner. Scrum Framework with IoT-Specific Modifications Tools: JIRA, Asana, Microsoft Azure DevOps JIRA: Customizable Scrum boards to track IoT project sprints, with features to link user stories to specific IoT edge development tasks. Asana: Task management with timelines that align with sprint goals, particularly useful for tracking the progress of edge device development. Microsoft Azure DevOps: Integrated with Azure IoT tools, it supports backlog management and sprint planning, crucial for IoT projects interfacing with Azure IoT Edge. Kanban for Continuous Flow in Edge Computing Tools: Trello, Kanbanize, LeanKit Trello: Visual boards to manage workflow of IoT edge computing tasks, with power-ups for automation and integration with development tools. Kanbanize: Advanced analytics and flow metrics to monitor the progress of IoT tasks, particularly useful for continuous delivery in edge computing. LeanKit: Provides a holistic view of work items and allows for easy identification of bottlenecks in the development process of IoT systems. Continuous Integration/Continuous Deployment (CI/CD) for IoT Edge Applications Tools: Jenkins, GitLab CI/CD, CircleCI Jenkins With IoT Plugins: Automate building, testing, and deploying for IoT applications. Plugins can be used for specific IoT protocols and edge devices. GitLab CI/CD: Provides a comprehensive DevOps solution with built-in CI/CD, perfect for managing source code, testing, and deployment of IoT applications. CircleCI: Efficient for automating CI/CD pipelines in cloud environments, which can be integrated with edge computing services. Test-Driven Development (TDD) for Edge Device Software Tools: Selenium, Cucumber, JUnit Selenium: Automated testing for web interfaces of IoT applications. Useful for testing user interfaces on management dashboards of edge devices. Cucumber: Supports behavior-driven development (BDD), beneficial for defining test cases in plain language for IoT applications. JUnit: Essential for unit testing in Java-based IoT applications, ensuring that individual components work as expected. Agile Release Planning with Emphasis on Edge Constraints Tools: Aha!, ProductPlan, Roadmunk Aha!: Roadmapping tool that aligns release plans with strategic goals, especially useful for long-term IoT edge computing projects. ProductPlan: For visually mapping out release timelines and dependencies, critical for synchronizing edge computing components with cloud infrastructure. Roadmunk: Helps visualize and communicate the roadmap of IoT product development, including milestones for edge technology integration. Leveraging Tools and Technologies Development and Testing Tools Docker and Kubernetes: These tools are essential for containerization and orchestration, enabling consistent deployment across various environments, which is crucial for edge computing applications. Example - In the manufacturing sector, Docker and Kubernetes are pivotal in deploying and managing containerized applications across the factory floor. For instance, a car manufacturer can use these tools for deploying real-time analytics applications on the assembly line, ensuring consistent performance across various environments. GitLab CI/CD: Offers a single application for the entire DevOps lifecycle, streamlining the CI/CD pipeline for IoT projects. Example - Retailers use GitLab CI/CD to automate the testing and deployment of IoT applications in stores. This automation is crucial for applications like inventory tracking systems, where real-time data is essential for maintaining stock levels efficiently. JIRA and Trello: For Agile project management, providing transparency and efficient tracking of progress. Example - Smart city initiatives utilize JIRA and Trello to manage complex IoT projects like traffic management systems and public safety networks. These tools aid in tracking progress and coordinating tasks across multiple teams. Edge-Specific Technologies Azure IoT Edge: This service allows cloud intelligence to be deployed locally on IoT devices. It’s instrumental in running AI, analytics, and custom logic on edge devices. Example - Healthcare providers use Azure IoT Edge for deploying AI and analytics close to patient monitoring devices. This approach enables real-time health data analysis, crucial for critical care units where immediate data processing can save lives. AWS Greengrass: Seamlessly extends AWS to edge devices, allowing them to act locally on the data they generate while still using the cloud for management, analytics, and storage. Example - In agriculture, AWS Greengrass facilitates edge computing in remote locations. Farmers deploy IoT sensors for soil and crop monitoring. These sensors, using AWS Greengrass, can process data locally, making immediate decisions about irrigation and fertilization, even with limited internet connectivity. FogHorn Lightning™ Edge AI Platform: A powerful tool for edge intelligence, it enables complex processing and AI capabilities on IoT devices. Example - The energy sector, particularly renewable energy, uses FogHorn’s Lightning™ Edge AI Platform for real-time analytics on wind turbines and solar panels. The platform processes data directly on the devices, optimizing energy output based on immediate environmental conditions. Challenges and Solutions Managing Security: Edge computing introduces new security challenges. Agile teams must incorporate security practices into every phase of the development cycle. Tools like Fortify and SonarQube can be integrated into the CI/CD pipeline for continuous security testing. Ensuring Scalability: IoT applications must be scalable. Leveraging microservices architecture can address this. Tools like Docker Swarm and Kubernetes aid in managing microservices efficiently. Data Management and Analytics: Efficient data management is critical. Apache Kafka and RabbitMQ are excellent for data streaming and message queuing. For analytics, Elasticsearch and Kibana provide real-time insights. Conclusion The application and adoption of Agile methodologies in edge computing for IoT projects represent both a technological shift and a strategic imperative across various industries. This fusion is not just beneficial but increasingly necessary, as it facilitates rapid development, deployment, and the realization of robust, scalable, and secure IoT solutions. Spanning sectors from manufacturing to healthcare, retail, and smart cities, the convergence of Agile practices with edge computing is paving the way for more responsive, efficient, and intelligent solutions. This integration, augmented by cutting-edge tools and technologies, is enabling organizations to maintain a competitive edge in the IoT landscape. As the IoT sector continues to expand, the amalgamation of Agile methodologies, edge computing, and IoT is set to drive innovation and efficiency to new heights, redefining the boundaries of digital transformation and shaping the future of technological advancement.

By Deep Manishkumar Dave

C4 Model Perspective: The Different Types of Software Architects

Software architecture is a critical aspect of software development. It involves the high-level structuring of software systems to meet technical and business requirements. Software architects play a pivotal role in this process by making design choices, dictating technical standards, and leading implementation efforts. This paper proposes a description of different architecture types. However, as this has been done many times before, I want to add the perspective of the C4 model to help understand who will intervene and at each level and with whom they will have to interact. There are various types of software architects, each specializing in different aspects of software systems. This article analyzes the standard types of software architects, highlighting their roles, responsibilities, and impact on software development processes. Types of Software Architects Enterprise Architect The Enterprise Architect ensures that the organization’s technological infrastructure aligns with its business strategy. This role integrates the IT strategy with business goals and governs compliance with company policies and regulations. Their role involves overseeing the integration of various IT components to ensure they function cohesively in support of organizational objectives. Broad Vision: Focuses on aligning IT strategy with business goals. Governance: Ensures that all aspects of the technological environment adhere to the company’s policies and regulations. Integration: Oversees the integration of various IT aspects to ensure they work harmoniously towards the organizational objectives. Key Differences with the CTO: I have been asked many times what is the difference between the Enterprise Architect and the CTO. The key differences between these roles lie in their organizational hierarchy, focus, responsibilities, and approaches. As a top-level executive, the CTO directs the broader business strategy and technological vision, engaging in strategic decision-making, innovation, and external advocacy for technology. In contrast, the Enterprise Architect, typically occupying a senior-level management position within the IT department, concentrates more internally on the design, governance, and optimization of IT infrastructure, ensuring its alignment with business processes. While the CTO adopts a strategic view, focusing on technology in the context of business growth, the Enterprise Architect takes a more tactical stance, dealing with the specifics of IT infrastructure and its operational effectiveness. Both roles are vital for an organization’s technological success, with the CTO shaping the overarching technology direction and the Enterprise Architect focusing on the practical design and efficiency of IT systems in support of the company’s strategy. The Enterprise Architect could be seen as the technical right hand of the CTO. Solution Architect The Solution Architect acts as a link between business challenges and technological solutions. They design and lead the implementation of solution architecture across projects or programs, providing essential technical guidance and coaching to developers and engineers. Additionally, they manage project scope, ensuring that solutions align precisely with specific business requirements. Solution Development: Designs and leads the implementation of a solution architecture across a project or program. Technical Guidance: Provides technical guidance and coaching to developers and engineers. Project Scope Management: Ensures that the solutions meet the specific business needs within the defined scope. Technical Architects Technical Architects are experts who possess in-depth knowledge in a specific domain and specialize in specific areas of expertise, often functioning within the broader framework of the Enterprise Architecture Team or contributing to various delivery projects. The term “domain” in this context refers to a niche area of knowledge, encompassing a range of specialized skill sets. These architects play critical roles in different aspects of software architecture, each focusing on a unique domain: Application Architect: Concentrates on the design and structure of individual applications, ensuring they meet both technical and business requirements. Technical Architect: Deals with the technical infrastructure and hardware aspects, ensuring that the technology infrastructure supports the specific requirements of the domain. Data Architect: Responsible for managing, strategizing, and structuring the organization’s data architecture, ensuring data accuracy, and integrity. Security Architect: Focuses on designing robust security structures, ensuring that the domain’s architecture is safeguarded against potential threats and vulnerabilities. Business Architect: Focuses on aligning business strategy with technological solutions, ensuring that business processes are optimally supported by technology. Data Architect: Plays a crucial role in ensuring effective leverage of data assets to support the organization’s decision-making processes. They develop and manage the data strategy, policies, standards, and practices, design data models and structures to support business operations and ensure data accuracy and integrity across systems. Cloud Architects: They are key in facilitating an organization’s transition to cloud computing, optimizing cloud solutions for performance, cost, and scalability. This role involves designing cloud architecture strategies, developing cloud solutions, overseeing the migration of systems to cloud platforms, and managing relationships with cloud service providers. Summary In essence, the field of software architecture is defined by three primary types of architects: Enterprise Architects, Solution Architects, and a diverse group of Technical Architects. Each type focuses on different aspects of software development, with some emphasizing strategy and others delving into technological details. Enterprise Architects align the organization’s technology with business goals, whereas Solution Architects bridge business needs with technical solutions. Technical Architects, encompassing roles like Application, Data, and Security Architects, specialize in various domains, providing depth in specific technical areas. Together, these architects create a comprehensive approach to software architecture, ensuring both strategic alignment and technical excellence across multiple fields. Focus by architect type The Business Architect is not focused on technology but rather on the business domain . They are a particular case.Parallel with the C4 model The C4 Model for software architecture provides a framework for visualizing and documenting the software architecture of a system at different levels of abstraction. It consists of four hierarchical levels: Context, Containers, Components, and Code. Each level targets a specific set of concerns, and different types of architects can play key roles at each of these levels. You can read my paper on the C4 model here if you are not familiar with C4 model : Architecture Patterns: C4 Model Let’s parallel this with the roles of various architects and see where they might intervene. Context Focus: The highest level shows how the system in focus interacts with users and other systems. Relevant Architect: Chief Technology Officer (CTO) and Enterprise Architect. Role: The CTO ensures that the system aligns with the broader business and technological strategy. The Enterprise Architect focuses on how the system fits within the wider IT landscape and its external interactions. Containers Focus: Zooms into the system to illustrate the high-level technology choices, showing how responsibilities are distributed across it. Relevant Architect: Enterprise Architect and Solution Architect. Role: The Enterprise Architect designs the high-level structure and identifies integration points with other systems. The Solution Architect defines the technology stack and oversees the architectural decisions for each container (e.g., web applications, mobile apps, databases). Components Focus: Delves deeper into the containers to reveal the internal components and their interactions. Relevant Architect: Solution Architect and Technical Architect. Role: The Solution Architect structures the components within a container, ensuring they align with the solution’s goals. The Technical Architect details the specific technologies and patterns used, focusing on aspects like scalability, reliability, and performance. Code Focus: The lowest level, detailing the implementation of individual components. Relevant Architect: Application Architect and Technical Architect. Role: The Application Architect is involved in defining the code structure, frameworks, and coding standards. The Technical Architect ensures that code-level decisions align with the technology strategy and standards. Summary C4 perspective of Architect types CTO: Involved at the Context level, aligning the system with business strategy and technological innovation. Enterprise Architect: Active from the Context to Containers level, focusing on system integration and alignment with enterprise IT strategy. Solution Architect: Engages primarily at the Containers and Components level, designing the solution architecture within the system. Application Architect: Primarily active at the Code level, ensuring best practices in software development and implementation. Business Architect: Although he may be considered a “Technical Architect”, his domain skills enable him to integrate the context level and assist in decision-making for his specific business domain. He may also appear at other levels under particular conditions. Each architect plays a particular role at different levels of the C4 model, ensuring that the architecture is robust, scalable, and aligned with both the technical and business objectives. This layered approach allows for a clear separation of concerns, making complex software systems easier to understand, communicate, and manage. Conclusion This analysis of the different types of software architects, enriched by the perspective of the C4 Model, not only clarifies their roles and areas of expertise but also opens up a broader understanding of how these roles interconnect and contribute to the overall success of software development. It highlights the essential nature of collaboration and the importance of having diverse architectural expertise within a project. Architects are seekers of solutions, which inherently means they are adept describers of problems. Despite the varied roles and specializations of different types of software architects, there are core attributes and approaches common to all. Primarily, they must embody pragmatism, steering clear of dogmatism in their methodologies. This pragmatism is key in balancing ideal architectural models with the practical constraints and realities of business and technology environments. Furthermore, they are seekers of solutions, which inherently means they are adept describers of problems. Their ability to accurately identify and articulate challenges is as crucial as their skill in devising effective solutions. This dual role of problem identifier and solution provider underpins their effectiveness in driving technological advancements and ensuring the alignment of IT strategies with business objectives. Their expertise not only lies in creating robust architectures but also in foreseeing potential pitfalls and proactively addressing them, thereby ensuring sustainable and adaptable software systems. These common traits form the backbone of their roles, making them indispensable in the ever-evolving landscape of software architecture.

By Pier-Jean MALANDRINO

DevOps Nirvana: Mastering the Azure Pipeline To Unleash Agility

What if you could eliminate productivity obstacles and accelerate delivery from code to production through automated Azure pipelines? The promise of cloud-powered DevOps inspires, yet its complexities often introduce new speed bumps that hamper release velocity. How can development teams transcend these hurdles to achieve continuous delivery nirvana? This guide will illuminate the path to mastery by unraveling the mysteries of Azure Pipelines. You’ll discover best practices for optimizing build and release workflows that minimize friction and downstream delays, unlocking your team’s true agile potential. Simplifying Continuous Integration/Continuous Delivery (CI/CD) Progressive teams once struggled to harness ad hoc scripts, brittle optimizing integration and delivery machinations managing software projects at scale. Azure Pipelines delivers turnkey CI/CD, automating releases reliably through workflows, portably abstracting complexity, and saving hundreds of hours better spent building products customers love. Intuitive pipelines configure triggers, setting code commits or completion milestones into motion, executing sequential jobs like builds, tests, approvals, and deployments according to codified specifications adaptable across environments standardizing engineering rhythm. Integration tasks compile libraries, run quality checks, bundle executables, and publish artifacts consumed downstream. Deploy jobs, then release securely on-prem, multi-cloud, or Kubernetes infrastructure worldwide. Configurable settings give granular control, balancing agility with oversight throughout The software lifecycle. Syntax options toggle manual versus automatic approvals at stage gates while failure policies customize rollback, retry, or continue logic matching risk appetite to safeguard continuity. Runtime parameters facilitate dynamic bindings to frequently changing variables. Azure Pipelines lifts engineering out of deployment darkness into a new era of frictionless productivity! Embedding Quality via Automated Testing Processes Progressive teams focused on chasing innovation often delay hardening software vital to preventing downstream heartaches once systems touch customers. Azure Test Plans embeds robust quality processes directly within developer workflows to catch issues preemptively while automated testing maintains protection consistency, guarding against regressions as enhancements compound exponentially over time. Test plans manage test cases, codifying requirements, validation criteria, setup needs, and scripts developers author collaboratively while sprinting new features. Execution workflow automation links code check-ins to intelligently run related test suites across browser matrices on hosted lab infrastructure without occupying local computing capacity. Tests also integrate within pipelines at various test/staging environments, ensuring capabilities function integrated end-to-end before reaching production. Rich analytics dashboards detail test pass/fail visualizing coverage and historical trends and prioritize yet-to-be mitigated defects. Integrations with partner solutions facilitate specialized test types like user interface flows, load testing, penetration testing, and rounding out assessment angles. Shipping stable and secure software demands discipline; Azure DevOps Server Support Test Plans turn necessity into a habit-forming competitive advantage! Monitoring App Health and Usage With Insights Monitoring application health and usage is critical for delivering great customer experiences and optimizing app performance. Azure Monitor provides invaluable visibility when leveraged effectively through the following approaches: Configure app health checks: Easily set up tests that probe the availability and response times of application components. Catch issues before customers do. Instrument comprehensive telemetry: Trace transactions end-to-end across complex Microservices ecosystems to pinpoint frictions impacting user workflows. Aggregate logs centrally: Pull together operational signals from networks, web servers, databases, etc., into intuitive PowerBI dashboards tracking business priority metrics from marketing clicks to sales conversions. Analyze usage patterns: Reveal how customers navigate applications and uncover adoption barriers early through engagement telemetry and in-app surveys. Tying app experiences to downstream business outcomes allows data-driven development that directly responds to real customer needs through continuous improvement. Collaborating on Code With Azure Repos Before teams scale delivering innovation consistently, foundational practices optimizing productivity and reducing risks start with version-controlling code using robust repositories facilitating collaboration, backed-up assets, and reproducible builds. Azure Repos delivers Git-based repositories securing centralized assets while supporting agile branch management workflows, distributing teams’ access projects in parallel without colliding changes. Flexible repository models host public open source or private business IPs with granular permissions isolation. Developer clones facilitate local experimentation with sandbox branch merging upon review. Advanced file lifecycle management automates asset cleanup while retention policies persist historical snapshots cost-efficiently. Powerful pull requests enforce peer reviews, ensuring changes meet architectural guidelines and performance standards before being accepted into upstream branches. Contextual discussions thread code reviews iterating fixes resolving threads before merging, eliminating redundant issues escaping the down cycle. Dependency management automatically triggers downstream builds, updating executables ready for staging deployment post-merge publication. Share code confidently with Azure Repos! Securing Continuous Delivery With Azure Policies As code progresses, staged environments ultimately update production, consistency in rollout verification checks, and oversight access prevent dangerous misconfigurations going uncaught till post-deployment when customers face disruptions. Azure Pipelines rely on Azure Policies extending guardrails and portably securing pipeline environments using regularization rules, compliance enforcement, and deviation alerts scoped across management hierarchies. Implementing robust security and compliance policies across Azure DevOps pipelines prevents dangerous misconfigurations from reaching production. Azure Policy is invaluable for: Enforcing pipeline governance consistently across environments. Automating Cloud Security Best Practices. Monitoring configuration states against compliance baselines. Codify Pipeline Safeguards With Azure Policy Specifically, leverage Azure Policy capabilities for: Restricting pipeline access to only authorized admins. Mandating tags for operational consistency. Limiting deployment regions and resource SKUs. Policies also scan configurations alerting when controls drift from the desired state due to errors. Automated remediation then programmatically aligns resources back to compliant posture. Carefully Orchestrate Production Upgrades Smoothly rolling out updates to mission-critical, global-scale applications requires intricate staging that maintains continuity, manages risk tightly, and fails safely if issues emerge post-deployment: Implement canary testing on small pre-production user cohorts to validate upgrades and limit blast radius if regressions appear. Utilize deployment slots to hot-swap upgraded instances only after health signals confirm readiness, achieving zero downtime. Incorporate automated rollback tasks immediately reverting to the last known good version at the first sign of problems. Telemetry-Driven Deployment Analysis Azure Monitor plays a powerful role in ensuring controlled rollout success by providing the following: Granular instrumentation across services and dependencies. Holistic dashboards benchmarking key app and business health metrics pre/post deployments. Advanced analytics detecting anomalous signals indicative of emerging user-impacting incidents. Together, these capabilities provide empirical confidence for innovation at scale while preventing disruptions. Monitoring proves most crucial when purpose-built into DevOps pipelines from the initial design stage. Pro Tip: Perfect health signals assessing key user journeys end-to-end, combining app load tests, dependencies uptime verification, and failover validations across infrastructure tiers, detecting deterioration points before manifesting user-facing. Actionable Analytics Powering Decision-Making Actionable analytics empower data-driven decisions by optimizing software delivery by: Translating signals into insightful recommendations that focus on priorities. Answering key questions on whether programs trend on time or risk falling behind. Visualizing intuitive PowerBI dashboards aggregated from 80+ DevOps tools tracking burndown rates, queue depths, and past-due defects. Allowing interactive slicing by team, priority, and system to spotlight constraints and targeted interventions to accelerate outcomes. Infusing predictive intelligence via Azure ML that forecasts delivery confidence and risk, helping leaders assess tradeoffs. Gathering real-time pulse survey feedback that reveals challenges teams self-report to orient culture priorities. Driving Data-Informed Leadership Decisions Robust analytics delivers DevOps success by: Quantifying productivity health and assessing program timelines to meet strategic commitments. Identifying delivery bottlenecks for surgical interventions and removing impediments. Forecasting team capacity, shaping staffing strategies, and risk mitigations. Monitoring culture signals to ensure priorities align with participant feedback. Sustaining Analytics Value To sustain analytics value over time: Measure analytics usage directly in decisions assessing the utility. Iterate dashboards incorporating leader user feedback on enhancing relevance. Maintain consistency in longitudinal tracking, avoiding frequent metric definition churn. Nurture data fluency-building competencies by adopting insights trustfully. Let data drive responsive leadership sacrifice and celebration in balance. Outcomes accelerate when data transforms decisions! Onwards, creative coders and script shakers! What journey awaits propelled by the power of Azure Pipelines? Dare mighty expeditions to materialize ambitious visions once improbable before Cloud DevOps elevated delivery to wondrous new heights. How will your team or company innovate by leveraging Azure’s trusty wisdom and harnessing the winds of change? Let us know in the comments below.

By joshitha N

The Agile Scrum Ceremony Most Talked About but Least Paid Attention To

In this digital world where all companies want their products to have a cutting edge over others and they want faster go to market, most companies want their teams to follow Agile scrum methodology; however, we observed most teams are following Agile scrum ceremonies for the name sake only. Among all scrum ceremonies, the Sprint retrospective is the most important and most talked about ceremony but the least paid attention to. Many times, scrum masters keep doing the same canned single routine format of a retrospective, which is: what went well? What didn't go well? and What is to improve? Let us analyze what are the problems the team faces, their impact, and recommendations to overcome. Problems and impact of routine format Sprint retrospective: Doing a routine single format made teams uninterested, and they started losing interest. Either team members stopped attending this ceremony, kept silent, or didn't participate. Often, action items came out of retrospectives not being followed up during the sprint. Status of action items not discussed in next sprint retrospective The team started losing faith in the ceremony when they saw previous sprint action items still existed and kept accumulated This leads to missing key feedback and actions sprint after sprint and hampers the team's improvements. With this, even after 20-30 sprints, teams keep making the same mistakes again and again. Ultimately, the team never becomes mature. Recommendations for Efficient Sprint Retrospective We think visually. Try following fun-filled visual retrospective techniques: Speed car retrospective Speed boat retrospective Build and reflect Mad, Sad, Glad 4 Ls Retrospective One-word Retrospective Horizontal Line retrospective Continue, stop, and start-improve What went well? What didn't go well? What is to improve? Always record, publish, and track action items. Ensure leadership does not join sprint retrospectives, which will make the team uncomfortable in sharing honest feedback. Every sprint retrospective first discusses the status of action items from the previous sprint; this will give confidence to the team that their feedback is being heard and addressed. Now let us discuss these visual, fun-filled sprint retrospective techniques in detail: 1. Speed Car Retrospective This retrospective shows that the car represents the team, the engine depicts the team's strength, the Parachute represents the impediments that slow down the car's speed, the Abyss shows the danger the team foresees ahead, and the Bridge indicates the team's suggestions on how to overcome and cross this abyss without falling into it. 2. Speed Boat Retrospective This retrospective shows that the boat represents the team; the anchors represent problems that are not allowing the boat to move or slowing it down and turn these anchors into gusts of winds, which in turn represents the team's suggestions, which the team thinks will help the boat move forward. 3. Build and Reflect Bring legos set and divide teams into multiple small groups, then ask the team to build two structures. One represents how the sprint went, and one represents how it should be and then ask each group to talk about their structures and suggestions for the sprint. 4. Mad, Sad, Glad This technique discusses what makes the team mad, sad, and glad during the sprint and how we can move from mad, sad columns to glad columns. 5. Four Ls: Liked, Learned, Lacked and Longed This technique talks about four Ls. What team "Liked," What team "Learned," What team "Lacked," and What team "Longed" during the sprint, and then discuss each item with the team. 6. One-Word Retrospective Sometimes, to keep the retrospective very simple, ask the team to describe the sprint experience in "one word" and then ask why they describe sprint with this particular word and what can be improved. 7. Horizontal Line Retrospective Another simple retrospective technique is to draw a horizontal line and, above the line, put items that the team feels are "winning items" and below line items that the team feels are "failures" during the sprint. 8. Continue, Stop, Start-Improve This is another technique to capture feedback in three categories, viz. "Continue" means which team feels the team did great and needs to continue, "Stop" talks about activities the team wants to stop, and "Start-Improve" talks about activities that the team suggested to start doing or improve. 9. What Went Well? What Didn’t Go Well? And What Is To Improve? This is well well-known and most practiced retrospective technique to note down points in the mentioned three categories. We can keep reshuffling these retrospective techniques to keep the team enthusiastic to participate and share feedback in a fun, fun-filled, and constructive environment. Remember, feedback is a gift and should always be taken constructively to improve the overall team's performance. Go, Agile team!!

By SAMANT KUMAR

Root Cause Analysis in Software Development Teams

Picture this: your code's misbehaving, and you're knee-deep in debugging chaos. It's something that no software developer likes to phase. It's not just about slapping Band-Aids on errors; it's about digging deep, Sherlock-style, to unveil the real troublemakers. One of the great tools that can help you with that is Root Cause Analysis (RCA). Root cause analysis (RCA) is a structured and effective process to find the root cause of issues in a software project team. If performed systematically, it can improve the performance and quality of the deliverables and the processes, not only at the team level but also across the organization. It is helpful in software development because it allows teams to troubleshoot more efficiently and develop long-term solutions that prevent issues from recurring. By addressing the root causes of errors and defects, developers can ensure their systems are stable, reliable, and efficient, reducing costly downtime and speeding up the development process. This structured and effective process is not merely a reactive measure; it is a proactive approach that, if wielded with precision, can sculpt a culture of continuous improvement within software development teams. How Can RCA Help in Software Development? At its core, RCA is a systematic process aimed at excavating the fundamental factors responsible for issues within a project team. Beyond its immediate remedial impact, RCA can increase the performance and quality of deliverables and influence not just across the team but throughout the entire organization. The significance of RCA lies in its ability to troubleshoot problems, offering a surgical approach to problem-solving that goes to the very root. RCA requires following a specific series of steps to isolate and understand the fundamental factors contributing to a flaw or failure in a system. The steps involved in conducting root cause analysis in software development are: Define the problem and set up alerts (if possible): First things first, call out the problem loud and clear. No beating around the bush. And if you can set up alerts, do it! It's like having your software scream, "Hey, something's off!" before it turns into a full-blown crisis. Gather and analyze data to determine potential causal factors: Data is your superhero sidekick here. Dive into it like you're on a treasure hunt. Look for patterns, weird stuff, or anything that gives a hint. It's like CSI but for code. Determine root causes using one of several RCA methods: Now, here comes the fun part — picking your tool. You've got the "5 Whys" asking questions like a curious toddler, the Fishbone Diagram making your problem visual, and tons of other tools. Implement solutions and document actions: Implement solutions, fix the issue, and, for the love of coding, document everything. It's not just for you; it's for the future of you and your team. Some of the common RCA methods and techniques used in software development are: The 5 Whys: A simple technique that involves asking “why” repeatedly until the root cause is revealed. Fishbone Diagram: The Fishbone Diagram is one of my favorite tools. It is a visual tool that helps identify and organize the possible causes of a problem into categories. Fault Tree Analysis: A graphical method that uses logic gates to model the possible combinations of events that can lead to a failure. Pareto Analysis: A statistical technique that uses the 80/20 rule to prioritize the most significant causes of a problem. How To Add This to Agile Rhythm Agile methodologies, with their iterative, collaborative, and adaptive nature, set the stage for software development like no other. Now, when you throw RCA into this mix, magic happens. Here's why this combo is the dynamic duo your team needs: 1. Continuous Improvement Takes Center Stage Agile is all about that continuous improvement groove. It's not a one-time gig; it's a perpetual concert of getting better. Now, imagine RCA joining this party. Instead of waiting for the big issues to pop up, it becomes an ongoing feedback loop. It's like having your software on a self-improvement regimen, constantly tweaking and refining. 2. Quick Steps With Short Iterations Agile methodologies are known for their short iterations, and that's where RCA thrives. Picture this: an issue surfaces, and before it turns into a full-blown drama, RCA steps in with its investigative moves. The result? Quick, precise steps to resolution. It's like catching issues in the act and giving them a swift exit. 3. Collaboration: The Dance of Many Feet In the Agile dance, collaboration is the heartbeat. Teams work closely, feedback flows freely, and everyone's on the same rhythm. Now, bring in RCA. It's not a solo act; it's a collaboration tool too. The team comes together to unravel the mysteries, share insights, and decide on the best moves to fix things. It's the dance of many feet, each step contributing to the overall performance. 4. Adaptability: Swaying With the Changes Agile is all about adapting to change gracefully. Now, when you introduce RCA, it becomes the compass guiding your team through those changes. If a problem arises, RCA helps you pivot smoothly. It's not just about fixing; it's about adapting and evolving, ensuring your software stays in sync with the ever-changing rhythms of development. So, there you have it – Root Cause Analysis is not just a tool; it can be a lifesaver in your software team. It's the backstage pass to excellence. Embrace it, implement it, and watch your software projects hit all the high notes of success. Happy coding!

By Omid Abbasi

DZone Community Awards 2023

Dear DZone Community, This year has seen a lot of changes for the DZone team, and we’re excited to end the year on a high note with a ton of potential heading into 2024 and beyond. Throughout the year and throughout the changes, you, our community, have been right there with us and continued to support us and deliver incredible, industry-leading content making DZone one of the best places for developers to gather, learn, share, and grow. Thank you! It would be impossible for us to recognize all the great stuff that happened this year, but we wanted to take the time to recognize a few people who really went above and beyond for our community this year. So, without further ado, here are the 2023 DZone Community Award winners! Most Viewed Article of 2023 It’s clear that the author of our Most Viewed Article for 2023 has made a splash here at DZone, as her second ever article on DZone has racked up more than 108,000 page views in less than a month! She has more than 15 years of experience building software and is currently a Software Engineer for Meta. We are so thrilled for Maria Rogova and her article Demystifying Distributed Systems: A Beginner’s Guide. We look forward to reading many more fantastic articles in the future! Congratulations! Most Liked Article of 2023 We had a ton of great content posted to DZone this year, but one article in particular seemed to resonate with our readers more than any other. Building Robust Real-Time Data Pipelines With Python, Apache Kafka, and the Cloud by Dmitrii Mitiaev was the Most Liked Article on DZone in 2023! Congratulations Dmitrii and we are excited to see more of your insightful, engaging articles! Best Original Article of 2023 What makes DZone stand out as such a valuable resource to developers around the world is our industry-leading, expert content and our community. And because our content and community are the best in the world (there may be some slight bias there), it’s almost impossible to choose one we could call the Best Original Article of 2023. However, one article did stand out to us a bit more than the others this year, and that was Distributed Tracing: A Full Guide by Lahiru Hewawasam! Congratulations Lahiru! Thank you so much for your contributions this year and we look forward to even more great content in 2024! Most Viewed Writer of 2023 The winner of our Most Viewed Writer shouldn’t come as a surprise for anyone who’s been around DZone for a while. He is one of our best and most regular contributors to the site, is a Core member and has racked up nearly 30 million pageviews since joining DZone in 2014! He’s also a very active contributor for our Refcards and Trend Reports and has over 20 years of experience in software development. Please join me in congratulating John Vester! Rising Star: DZone Contributor Our Rising Star DZone Contributor this year joined our community in April, and since then has posted 11 articles and garnered nearly 50,000 page views! She is a Senior Machine Learning Engineer at Meta and obtained a Master of Science in Computer Science from Northeastern University. She clearly has a very promising future ahead of her! Congratulations to Yifei Wang! Thank you for your contributions this year and we look forward to many more insightful articles in the future! Most Published Core Contributor We have a lot of contributors that post a lot of great articles on DZone, but our Most Published Core Contributor for 2023 takes the cake when it comes to regularly posting outstanding content. I mean, the man has published more than 1,500 articles in just 8 years! Not only does he write a lot, his articles are always knowledgeable, insightful, and engaging to read. We are so grateful for all he does for DZone. Thank you and congratulations to Tom Smith! Editor’s Pick DZone Core Contributor Our Editor’s Pick for DZone Core Contributor of the year is also a name you’ve heard before. She is a Core member and has contributed so much amazing content for the website, our Trend Reports, and Refcards, and she is always happy and willing to jump in and help us with any projects or requests we might send her way. She is a thought leader in her field and an accomplished writer and speaker, but we just tend to call her Super Woman. Congratulations Kellyn Gorman! We are so incredibly grateful for you! Rising Star: Refcards Our Rising Star for Refcards winner is the Directory of Technical Advocacy at Silk and has over two decades of experience in relational database technology with a unique, unmatched knowledge of databases, particularly Oracle on Azure. She combines traditional database knowledge with an insight into modern cloud infrastructure, enabling her to bridge the gap between past and present technologies. After contributing to our Database Systems Trend Reports for the past two years, she wrote her first DZone Refcard this year: Core Postgre SQL. Congratulations Kellyn Gorman and thank you so much for your continued contributions to the DZone community! Editor’s Pick: Refcards Our Editor’s Pick for Refcards this year has been contributing to DZone both on the site and in our Trend Reports and Refcards since 2017. He is a Principal Product Security Engineer at Microsoft and has more than 17 years of experience in software development specializing in security. Congratulations Apostolos Giannakidis! Apostolos wrote two Refcards for us this year: Threat Modeling: Core Practices to Securing Applications and Identity and Access Management: Core Practices to Secure Digital Identities. Thank you for all your great contributions Apostolos! Rising Star: Trend Reports The 2023 DZone Rising Star for Trend Reports only joined the DZone community in February, but has jumped in head first and already contributed a ton of great content to DZone. She is a Senior Cybersecurity Consultant at Visa where she is a senior member of the corporate governance team. She contributed to three of this year’s Trend Reports: A Practical Guide for Container Security for the Containers Trend Report, Securing the Cluster for our Kubernetes in the Enterprise Trend Report, and Modern DevSecOps for our Enterprise Security Trend Report! Please join me in congratulating Akanksha Pathak! Thank you for being such a great contributor to the DZone community! Editor’s Pick: Trend Reports Our DZone Editor’s Pick for Trend Reports this year is an accomplished AI expert and thought leader and has been named as one of India’s Top 10 Data Scientists by Analytics India Magazine. So it’s no surprise that he would write for our Automated Testing Trend Report this year. You can check out his article on Revolutionizing Software Testing as well as his other Trend Report contribution this year, Enhancing Observability With AI/ML, in our Observability and Application Performance Trend Report now on our website. Congratulations Dr. Tuhin Cattopadhyay! In addition to his Trend Report contributions, he’s also written a Refcard and several other articles for DZone. Thank you for sharing your expertise with our community! Editor’s Pick: DZone Contributor This year’s Editor’s Pick for DZone Contributor has published 21 articles, racked up over 200,000 page views, contributed to two Trend Reports, and a Refcard in less than 3 years since joining DZone! He has over 15 years of experience developing and leading high-performance engineering teams with expertise in Big Data, Databases, Cloud Architecture, and more. Congratulations to Miguel Garcia! Thank you so much for your contributions to the DZone community! Community Pick: DZone Contributor of the Year As the name might suggest, the Community Pick for DZone Contributor of the Year is selected by you, our community members. Personally, this is my favorite award as it gives you all a chance to have a voice in selecting the community member that most impacted you in 2023. And if you’ve been around in the past couple years, then our 2023 Community Pick winner makes a lot of sense. Congratulations once again to Dr. Tuhin Chattopadhyay! Dr. Chattopahyay is not only a knowledge leader in his field and a fantastic writer and speaker, he is also an all-around wonderful human being. Thank you Dr. Chattopahyay for all you do for our community! Here at DZone, our community is who we are. We would not exist or be where we are today without all the incredible contributions from everyone in our community so sincerely… Thank you. We appreciate everything you did for us in 2023, and we look forward to an incredible 2024! Congrats again to all the winners! Happy Holidays, The DZone Team

By Jason Cockerham

New Profiles Now on DZone!

Hello DZone Community! Recently, you might have seen our announcement about the updates to the Core program. We’ve received a lot of great feedback about the new program, and we’re very excited to continue growing and expanding it to more members! But that was just the beginning. We’ve been working hard on improvements across the entire DZone community, and today, we are thrilled to announce some big improvements to your DZone profiles! There’s a lot to unpack with these new profiles, but the overall gist of it is that it gives them a fresh new look (ooh shiny!!) and adds some new features for you. Among other things, we’ve added: A section for your education, training, and credentials earned Sections for any Trend Reports and Refcards you’ve contributed to A section for any DZone events you’ve been a part of While all members will receive the above updates to their profiles, we’ve built some additional features for our Core members. They truly go above and beyond for the DZone community by being highly engaged and regularly contributing expert content to the site. These additional changes will help continue to elevate them as thought leaders both within the DZone community and across the industry at large. Core member profiles will now have: Optimized profile A place to add open-source projects they're working on or support A section recognizing when they're highlighted as a Featured Expert on DZone A new, exclusive banner showcasing their Core membership We could not be more excited to roll out these new profiles to you all. Every single one of our contributors is essential to what we do at DZone, and these new profiles will help highlight to our community and the rest of our audience just how knowledgeable and important you are to DZone. We literally would not be here without you! If you haven't already and would like to begin your contributor journey, you can start by creating your own article! Our team of editors is here to help along the way. You can reach out to editors@dzone.com with any of your content questions. Please spend some time poking around your new profile, and let us know what you think. We’re always open to feedback and new ideas! Drop us a line at community@dzone.com with your thoughts. We are so incredibly grateful for all you do for DZone! Sincerely, The DZone Team

By Jason Cockerham

Organizational Danger Zones

I’ve noticed two danger zones that organizations run into. Today, I’ll describe these two danger zones, and give some advice for navigating them. I’ll talk about this for engineering organizations. But I suspect it’s applicable to any group of humans working at these scales. Why Are These Danger Zones Important? I’ve seen several companies waste years getting trapped in these danger zones. That time is precious for a startup and can result in the business failing. I’ve seen people who are smarter than me get into these traps over and over. I believe the reason for that is that these are structural problems. Solving them requires some deep refactoring of your organization, and most people haven’t done this type of work before. So, they fail, and their company and employees suffer. The growth traps in these danger zones interact with other leadership and organizational problems in harmful ways. For example, if you have a leadership team that tends to micromanage, these growth traps will make it worse. Or if you have a lack of leadership alignment, that will be more prominent. So the traps in these danger zones have a disproportionate impact. Why Listen to Me on This? I have both breadth and depth of experience in these danger zones. At New Relic, we had an experienced leader who helped us navigate the first danger zone. However, I saw areas where we struggled and was involved throughout the process. I spent years grappling with the second danger zone at New Relic. It was the most critical deficiency in our engineering organization for years. It was something we continuously grappled with. We worked with Jim Shore, author of The Art of Agile Development, to successfully address it. I was part of the team that fixed it, and it shaped my thinking about the patterns behind how groups of humans can operate at increasingly larger scales. It has become a major theme in my leadership work ever since. I’ve since worked at almost twenty-five startups, and any of them that have grown through the danger zones have run into these same growth traps. I’ve focused a lot of my consulting practice on helping organizations get through these traps and avoid much of the suffering you would expect. Danger Zone #1: The Team Trap The first of these two danger zones is what I call the “team trap." It generally happens sometime between ten and twenty people. You start with a co-founder or leader who is in charge of engineering. The engineers all report to this person. There are lots of projects going on, and they get busier and busier as the team grows. Often, you’ll have each individual focusing on their own project! Because the team is small enough, everyone has a pretty decent sense of what is going on. You know what projects are being worked on, and how things are progressing. Priorities are fairly clear, and communication is uncomplicated. Usually, it all happens in one place, with everyone reading everything or in the same room. Communication is many to many. The future is bright. What Happens With the Team Trap As the team grows, however, things start to break down. The leader works longer and longer hours. Yet, it seems harder and harder to get work done, and execution and quality seem to be slipping. Communication seems muddled, and you hear more people wondering about priorities or what the strategy is. This is the Team Trap. You’re heading towards failure, and unless you reshape things, it will get worse and worse! Why It’s Hard To Fix the Team Trap You will face a few obstacles to make the right changes. First of all, the founders and early people are often really smart, incredibly dedicated people. They will work harder and harder, and try to brute force themselves through the Team Trap. That won’t work – it will only delay the solution. Second, some of the solutions to the Team Trap will feel like bureaucracy to the founders and early people in the company. They’ll resist the changes because they want to preserve the way the company felt early on – everything could happen quickly and effortlessly. They will often have an aversion to the changes they might need to make. What To Do About the Team Trap The changes you typically need to make at this phase are structural changes: You need to set up cross-functional teams with ownership. This is a hard thing to do well, and if done incorrectly, can actually make everything worse! I advise you to read Team Topologies, and to get help with this. You can also try an alternative approach: FAST agile collectives. You’ll need to start thinking about your organization’s design. You may need managers. But you may need a different type of manager than you think. You’ll need to think about how to design your meetings. You may need some lightweight role definition. Ultimately, someone has to start thinking about the way your organization is structured, and how all the pieces will fit together. Part of this organizational design is to also think through your communication design. You probably want to start segmenting communication, so that people know what they need to, but aren’t flooded with a lot of information they don’t need. There is a balance to this. You don’t want to over tilt towards structure, but you also don’t want to avoid necessary structure. All of this is pretty hard, and I’ve built a business helping engineering organizations with this (so definitely reach out if you need help with it, or find someone else to help you). Why Does the Team Trap Happen? Incidentally, I believe the reason this seems to happen at between ten and twenty engineers is because that’s when one person can no longer reasonably manage everyone in engineering. You have to start to split the world. And once you do that, it forces a lot of other changes to happen at the same time. It’s a little like when you have a web server that is delivering content over the internet. As soon as you want a second server for redundancy or scaling reasons, all of a sudden, you need a lot more in place to make things work. You may need a load balancer. You may need to think about state and caching since it is done independently for each server. All of these concerns happen at the same time. If you’re successful in your design, you’ll have a structure that will take you pretty far. Your teams will be autonomously creating value for the company. And things should go pretty well until you hit the second danger zone. Danger Zone #2: The Cross-Team Project Trap The next trap is with how teams work with each other. You reach a level of complexity where the primary challenge for your organization is how to ensure that anything that crosses team boundaries can be successful. As the number of teams grows, each of them delivers value. But they aren’t perfect encapsulations of delivery. Teams need things from each other. And as your product grows, you’ll need things from multiple teams. The themes for this stage are coordination and dependencies. How do you get teams to coordinate, to deliver something bigger than themselves? And how do you deal with the fact that dependencies often aren’t reasonable? How do you sort through those dependencies, and minimize them? The cross-team project danger zone occurs somewhere after about forty people. I often see it happen between forty and sixty people in an organization. At New Relic, we tried valiantly to fix cross-team projects, but we didn’t really succeed until we worked with Jim Shore, and at that time there were probably 200 engineers in the organization. It was long overdue. As an aside: It’s plausible that our failure to address this earlier was instrumental in Datadog’s ascendance. Why? We were much less effective in engineering at the time, and this slowed our ability to succeed in the enterprise market. Most of the bigger projects were enterprise features. Our focus on growing into the enterprise distracted us from Datadog’s rise and prevented us from addressing shifts in the way developers were working with microservices. It’s possible that handling this earlier could have resulted in a completely different outcome, though there were a lot of factors involved. What Happens With the Cross-Team Project Trap To understand the cross-team project trap, consider a couple of examples. First, you may want to do some work that affects many teams. For example, let’s say your customers are asking for role-based access controls. This is work that many teams will need to focus on. Yet the enabling work might be done by one team. This can require coordination. Another need you’ll see increasingly is that multiple teams need similar functionality. They might both want a similar table user interface. Or they might both require a similar API. Or they might depend on similar data. This type of work tends to require teams to depend on other teams to do work for them. This is a growth in dependencies. At some point, coordination and dependencies grow to become your most serious obstacle to delivery. You’ll know you’re in this second danger zone if you see some of these symptoms: There is a lack of confidence from the rest of the company that engineering can deliver large, important initiatives. The general track record is that engineering ships late, if at all. You see lots of heroic effort to deliver anything that crosses team boundaries. You may have a few people who are unusually good program managers, but even they have failures. You might see opposing instincts to add more structure, or operate more “like a startup." A few really experienced engineers who can get things done are held up as saviors. But the general default is that things don’t ship well. You have areas of the organization that are such hot spots that they go through waves of failure - often because they are the hot spot for dependencies. Why It’s Hard To Fix the Cross-Team Project Trap When I was at New Relic, I was leading up the engineering side of a new analytics product. It was an ambitious product. We had widespread agreement that it was a top priority. However, we needed things from many parts of engineering in order to deliver on the complete vision for the product. Those dependencies didn’t seem optional. So the way I attempted to handle this was by acting as a program manager. I tried to organize my dependencies as projects. Each of them would be updated on progress and risks. Fairly standard stuff for program management. But what I found is that the structure of the organization didn’t make the execution on this type of project possible. It was mathematically impossible. Every team had their own priorities. Even if they thought we were the top priority, that was subject to change. If they had a reliability problem, they had to do work to address that problem. Sometimes something new would come up, and bump our priority back. I was essentially making plans that weren’t based on anything structurally sound. It was difficult to fix at that point. I couldn’t tell all of engineering how to operate! At the time, I didn’t know what would fix the situation. We had tried for years at New Relic to crack the “cross-team project” problem. We rewarded people who were good at project and program management. We hired people that were good at it. We even made delivery of cross-team projects part of our promotion criteria! But ultimately, we didn’t make the structural changes we needed. The challenges you face to fixing these at this stage are mostly that there is a lot of organizational inertia. Changes can feel threatening. People can feel demotivated to make changes when they are under so much stress. Working within the existing system can take all of your bandwidth, so people will be reluctant to work extra to extricate themselves from the mess. And structural fixes can intrude on leadership turf, so you need a high level of support from the very top of the organization to make your changes. This is not something you can just ignore. It will continue to get worse and worse until any project that crosses team boundaries ends up being impossible to complete. What To Do About the Cross-Team Project Trap These are the types of changes I recommend if you run into the cross-team project trap: Centralize cross-team priorities (possibly with a product council) and teach teams how to work with those central priorities. Define organizational and team coordination models. For example, move platform teams from service model teams to self-service. Make your product teams act as independent executors, assuming no dependencies in their projects. Carefully design which teams act in an embedded model. Use program managers for cross-team initiatives. Limit the number of cross-team initiatives. Reorganize your teams mostly along cross-functional lines. Reduce dependencies between teams. Or, you might experiment with FAST agile teams. Reduce the size of projects (using milestones or increments). Ideally, get help! Why Does the Cross-Team Project Trap Happen? I have a hunch these growth traps are the result of complexity jumps that occur when you add a layer of management. The first danger zone corresponds to when you add managers, the second danger zone is often when you add directors. When you have this jump in complexity, you have to shift the structure of the organization. Otherwise, you have a mismatch between what is necessary for that structure to be successful, and the way it really is. This is not to say that adding managers or directors is what causes the problem. You can run into these growth traps even if you have managers or directors. It’s just that you need them both at the same time. Incidentally, this is why I am bullish on FAST Agile. I think it may allow you to have a simpler organizational structure for a longer period of time. Combined with some of these other structures, I think the potential benefits outweigh the fact that it is a new, less well-developed practice. Thank You I try to credit people who have influenced my thinking or directly affected my approach. Much of the first danger zone is through my own observation. I’m not sure I’ve seen anyone else articulate it. But I would guess others have seen the same thing – when I talk with other leaders or venture capitalists, they have a look of “yeah, that sounds familiar." For the second danger zone, there isn’t a place I can point to (that I remember) that highlights this as a scaling barrier for organizations. I’m pretty sure something must exist! For how to address it, my biggest source of credit goes to Jim Shore. His work at New Relic was quite effective, and it was a career highlight to work with him and the Upscale team to design and implement the solutions. While the coordination models have been my own pattern language for organizational and cross-team work, you’ll notice he is credited on many of them.

By Jade Rubick

CORE

You’re Wasting Time With Your Daily Standup

Let’s say you’ve got 8 people on one of your engineering squads. Your daily standup takes 15 minutes a day. That’s 75 minutes per week, or roughly 3750 minutes per person. You’ve got 8 people, so that’s 30,000 minutes each year for your team or 500 hours. That works out to about 12.5 weeks spent in daily standup for your team.If your average engineer is earning $75,000, then you’re spending about $18,000 each year on your daily standup (not to mention opportunity cost, which is a whole topic in itself). But if your daily standups take 30 minutes, it costs you $36,000. And if you have 10 squads like this in your company, that’s $360,000. So we sure as heck better make our standups count! Five Ways I See Companies Waste Time in Standups (There Are More) The daily standup is envisioned as a 15-minute pulse check, but it often morphs into a parade of distractions, irrelevancies, and just plain inefficiencies. Company A The back-end engineering team at Company A religiously congregates every morning around their Scrum board. The standup never exceeds 15 minutes. But their updates are a monotonous loop of "I did X, today I'll do Y" – an agile charade with zero alignment with sprint goals. The engineers don’t even have sprint goals. The product manager prioritises the backlog, but no two-way conversations are happening. Problem 1: No Alignment With Sprint Goals Anecdotally, an engineer at a FinTech firm recently told me, “Strategic alignment comes from our initiative. I take the initiative to ask about it, but not everyone does that”. Lack of alignment with sprint goals leads to a lack of direction and purpose, causing team members to operate in isolation rather than as a cohesive unit working toward a shared objective. This inefficiency wastes valuable resources and could derail other tasks that are critical to the project. It also impacts stakeholder satisfaction and puts the team out of sync with broader strategic objectives. The very foundation of the Scrum framework is to inspect progress toward the Sprint Goal. Daily Scrums are designed for task updates and as opportunities to adapt and pivot towards achieving that Sprint Goal. Without this focal point, the team misses out on critical chances to adjust course, while eroding cohesion and motivation. Company B Company B has a fully distributed, remote team scattered across 9 hours’ worth of time zones. Ada, from Poland, finds that the live standup in her afternoon takes her out of her flow at peak concentration time. Brent in San Francisco grumbles about needing to log in early while juggling kids who haven't yet been sent off to school. And Clem, who, due to caregiving responsibilities, often misses the live standup, has to catch up through meeting reruns and often misses the chance to contribute. Problem 2: Operational Inefficiencies The logistical gymnastics needed for live standups often means getting in the way of engineers’ personal lives or interrupting their workflow. Time-zone clashes? Check. Flow state broken? Double-check. Is everyone mildly irritated? Triple-check. Problem 3: Lack of Flexibility More like a one-size-fits-none. Failing to adapt the standup format to cater to diverse needs and lifestyles often leads to dissatisfaction and poor adoption. And when you're remote, that dissatisfaction can quietly fester into full-blown detachment. Company C For Company C, the “daily standup” is something of a Proustian endeavour. Complex topics are discussed ad nauseam, sometimes taking up to 45-60 minutes a day. Today, Luis and Zaynab spend 15 minutes dissecting a problem, leaving everyone else twiddling their thumbs or heading off their second screen to multitask. 15 minutes turned out not to be long enough to fix it, and they decided to continue their chat later – but not until they’d wasted a collective 120 working minutes of engineering time for everyone else. A few of the team members are introverted, and the forum doesn’t feel like a good one for them to share their thoughts. They get meeting fatigue alongside the inevitable information overload. Problem 4: Redundancy and Overload When standups turn into mini-hackathons or ad hoc troubleshooting sessions, important issues either get glossed over or spiral into time-consuming digressions. We all end up stuck in this labyrinth of futile discussion, staggering out with meeting fatigue and information overload. Problem 5: Engagement At this point, people are emotionally checked out. The more vocal become inadvertent meeting hoggers, while others feel their contributions being sidelined. It's a fertile ground for a toxic culture that breeds disengagement and kills morale. How Asynchronous Standups (Sort Of) Help None of the scenarios we covered above captures the intended spirit of a stand-up meeting, which is to streamline the workflow and foster cohesion among team members. It's time to part ways with practices that suck the productivity out of our workday. So let’s consider asynchronous stand-ups. Traditional work schedules don't account for the natural ebb and flow of human energy, let alone the strain of managing personal lives alongside work commitments. Asynchronous stand-ups check a lot of boxes for the modern workforce. Where Asynchronous Stand-Ups Shine 1. Universal Participation: Time zones become irrelevant. Whether you're dialling in from Tokyo or Texas, you have an equal seat at the virtual table. 2. Your Pace, Your Place: These stand-ups play by your rules, allowing you to time your updates according to your work rhythm, not the other way around. 3. Efficiency: Bid farewell to meetings that drag on and interrupt your flow state. Asynchronous stand-ups are short and to the point. 4. Documented Progress: Think of it as an automatic diary of team updates. No need to chase minutes or compile reports; it's all there. 5. Quality Over Quantity: The chance to craft your update promotes clear and concise communication, rather than on-the-spot, often incoherent chatter. However, relying solely on asynchronous standups might not address all the complexities of collaboration effectively. In the current landscape, artificial intelligence stands prepared to integrate into your existing communication tools seamlessly. It can adeptly monitor and comprehend your projects and objectives, capturing the essence of decisions and activities that mould them. Unlike humans, who grapple with the inability to retain every detail and extract the pertinent elements, AI remains unhindered by these constraints. Our memory is finite, we lose sight of our goals, and overlook occurrences, all due to the limitations of time. AI, on the other hand, operates outside of these confines, positioning it as a far superior contender to succinctly summarise daily events or provide insights into ongoing matters. Getting Asynchronous Stand-Ups Right Asynchronous stand-ups work when everyone’s on the same page about how to do them at your organisation. Always ensure everyone understands what’s expected of them, and how to go about their asynchronous stand-up. Stay Consistent: Insist on a clear format that focuses on completed tasks, work in progress, and any roadblocks. Flag for Follow-up: Asynchronous doesn't mean antisocial. Urgent matters should be highlighted for immediate attention. A virtual pow-wow can still happen if needed. Time Frames Matter: Establish a window within which all updates and responses should be posted to maintain momentum. Clear Paths for Emergencies: Identify a procedure for raising and addressing urgent issues promptly. Making AI Alternatives Work Human memory has its limitations. We're bound to forget, overlook, or downright miss out on crucial updates. AI doesn't share these shortcomings. To make the most out of this tool, just stick to some collaboration fundamentals: Open Dialogue: Transparency is key. Holding the majority of discussions in private channels or direct messages is generally not advisable unless there's a specific reason like confidentiality concerns or data protection. Use Your Tools Effectively: Whether it's crafting well-structured Git commits, keeping your Jira boards current, or meticulously documenting workflows in Notion, encourage correct tool usage across the board. The beauty of AI is its ability to draw smart conclusions from the data it's given. By actively participating in an AI-enhanced asynchronous stand-up, your team stands to gain significantly. AI tools can highlight important activities and provide clear answers to any queries about ongoing projects.

By Alex Omeyer

5 Steps To Tame Unplanned Work

In an ideal world, there are no zero-day security patches that absolutely must be applied today. There are no system outages - shortage never becomes full; APIs don't stop accepting parameters they accepted yesterday, users don't call support desks with tricky problems and everyone else writes code as good as you do so there are no bugs. Maybe one day, but until then, there is unplanned but urgent work. Whether you call it DevOps, support, maintenance, or some other euphemism, it is work that just appears and demands to be done. The problem is this work is highly disruptive and destroys the best-laid plans. While sticking one's head in the sand and pretending the work does not exist, it does exist and it demands attention. The question then is: how best can such work be managed? Step 1: Acceptance Despite attempts by Project Managers and Scrum Masters to keep teams dedicated to shiny new things, "Stuff happens," as they say. So to start off with, everyone needs to stop wishful thinking. Put it this way: if you come up with a way of handling unplanned but urgent work and it never happens again then you have only lost a few hours of thinking. However, if you don't plan and it does happen then it is going to take up a lot more time and effort. Let's also accept that there is no Bug Fixing Fairy or DevOps Goblin. One day ChatGPT might be able to handle the unexpected, but until then, doing this work is going to require time and effort from the people who would otherwise be doing the shiny new stuff. There is only one pot of capacity and if Lenny is applying a security patch, she isn't working on new features. Step 2: Capture and Make Visible Back in the days of physical boards, I would write out a yellow card and put it on the board. These days it is probably a ticket in an electronic system; however, you do it to make sure those tickets are easily identified so people can easily see them and they can be found later. This may sound obvious, but an awful lot of unplanned work is done under the covers; because "it should not exist," some people object to it being done. Even when the work is trivial it still represents disruption and task switching, and it might fall disproportionally on some individuals. A few years ago I met a team who were constantly interrupted by support work. They felt they couldn't do anything new because of the stream of small, and large, unexpected work. I introduced the yellow card system and with that one change, the problem went away. What happened was that it quickly became clear that the team had, on average, only one unexpected urgent request a week. But because the requests were high profile, people kept asking about them and pressure was heaped on to fix it. Once the request was a clearly identifiable yellow card on a work board, everybody in the company could see it. Anyone could walk up to the board and see the status and who was working on it. Overnight the bulk of the interruptions went away. A lot of the previous interruptions had been people asking, "What is happening?" It was that simple. Once the work is captured and made visible, people can start to see that requests are respected and action taken. Now attention can turn to priority. Step 3: Meaningful Prioritization When trust is absent, nobody believes that anything will be done so everyone demands their ask has top priority. In time, as people learn requests are respected and acted on; then meaningful priority decisions can be made. I met a company where one of the founders had a habit of picking up customer requests, walking across to a dev team member, and asking, "Can you just...?" Of course, the dev wouldn't say "no" to a founder, so their work was interrupted. In addition to the yellow card, a priority discussion was needed. The team was practicing a basic Agile system with all the work for the next Sprint listed in priority order on their Kanban board. When the founder came over, the dev would write the request on a yellow card, then walk over to the Kanban board and ask, "You can see the card I'm working on right now: should I stop what I'm doing and do the new request?" If the founder said "yes," then the dev would honor the request. But seeing what would be interrupted, the founder was likely to say, "Well, finish that first." Now the dev would put the card next to the priority work queue and ask, "Is this the new priority number one?" If it was, the card went to the top of the queue and the next available person would pick it up. If not, the dev would work down the list: "The new priority two? three? four?" We had a simple feedback process. Beforehand, the founder had no idea of the consequences of asking, "Can you just. . .?" Now they could see what work would be delayed, displaced, and interrupted. These three steps alone can manage a lot of unplanned but urgent work and improve team performance quickly, yet it can still be better provided your ticketing system is capturing all these instances physically or electronically. Step 4: Use Data To Get Better At the most basic level, count the yellow cards and count the other planned work cards. Now calculate the ratio of how much planned v. unplanned work is going on over time and feed this back into planning. For example, one development manager calculated that unplanned work accounted for 20% to 25% of the team's Sprint on average (using several months of data.) So to start with, they scheduled 20% less work per Sprint. This alone made the team more predictable. You don't even need to bother with estimates here - you can if you really want to, but this is not going to be perfect, just good enough. Simply knowing the ratio is a start. Over time you may refine your calculations, but start simple. Step 5: Fix at Source Use the yellow tickets as part of your retrospective. Start by considering if the tickets really did deserve to be fast-tracked into work. The team should talk about this with the Product Owner/Manager and other stakeholders. Now everyone can appreciate the impact you might find that some requests really shouldn't be prioritised. Next, you can look at the nature of the requests and see if there is some pattern. Perhaps many originate from one stakeholder. Perhaps somebody should go and talk with them about why they generate so many unplanned requests - maybe they can start making requests before Sprint planning. Similarly, it might be one customer who is raising many tickets. Perhaps this customer has some specific problems, perhaps they have never had training or simply don't appreciate how the system works. It could be that some particular sub-system or third-party component is causing problems. Some remedial work/some refactoring could help, or maybe the component needs to be replaced entirely. When there is data arguing for the time to do such work is a lot easier. You might find that the team lacks particular skills or needs expansion. The same manager who budgeted for 20% of unplanned work later analyzed the tickets and found that the majority of the unplanned tickets were for general IT support which didn't need specialist coding skills. These findings were taken to the big boss and permission was quickly given to hire an IT support technician. Getting a 20% boost to programmer productivity for less than the cost of another coder was too good a deal to miss! Sometimes expanding the team isn't an option, and sometimes the tickets don't point to a missing skill. Another solution is the "sacrificial one." In these cases, a team of five experiencing 20% unplanned work will have one member handle the unplanned stuff. This means one team member soaks up all the interruptions which allows the others to stay focused. Few people like being the sacrificial lamb so rotate the position regularly; say, every Sprint. In one example, team members were concerned it would not work because they each specialized in different parts of the system. They agreed to try and work on any ticket that came up during their week as on-support. Even though it would take them longer than a colleague who specialized in that part of the system, it could increase overall throughput. After a few weeks, team members found they could deal with far more tickets than they expected and were learning more about the system. If they were stuck they might get just 10 minutes of the specialist and then do it themselves. Work the Problem The thing is as much as you don't want unplanned and urgent work to exist, it does. Project Managers have spent years trying to stamp it out and, without great pain, they can't. In fact, the whole DevOps movement runs counter to this school of thought. The five steps set out here might not create the ideal world but they should make the real world more controlled and manageable. One day AI systems might take over unplanned work, but it is often in unexpected situations when things should work but don't that human ingenuity is needed most.

By Allan Kelly

CORE

Agile

DZone's Featured Agile Resources

Top Agile Experts

The Latest Agile Topics