The Agile methodology is a project management approach that breaks larger projects into several phases. It is a process of planning, executing, and evaluating with stakeholders. Our resources provide information on processes and tools, documentation, customer collaboration, and adjustments to make when planning meetings.
Boost Chapter Performance With the Chapter Health Diagnostic (Part 1)
Jira For Product Managers: Useful Features Explained
Simply adopting the Agile process does not mean your organization becomes Agile. Many companies switched from the Waterfall methodology to the Agile methodology for project management and failed miserably. The major reasons were a lack of training of the team and management on Agile frameworks and a lack of technology, such as project management software, to implement Agile methodology. You need both the right knowledge and the right technology to truly implement Agile. In this post, we will look at both: the meaning of the Agile process and how to optimize the Agile process with project management software. What Is an Agile Process? An Agile process is an approach to project management that focuses on breaking the project into smaller phases. It involves working in small iterations. After every iteration, the work is released and reviewed. Based on the feedback, improvements are made in the next iteration. Originally, Agile was formed as a project management methodology to manage software development projects, but now, it is also used in other business operations including marketing, HR, and R&D. Every iteration in Agile follows the cycle of planning, executing, and evaluating. The purpose of doing so is to ensure continuous improvement and provide the ability to quickly adapt to changing requirements. The ability to respond to change is at the core of the Agile process. It is achieved by working in small repetitive cycles, continuous release of work after every cycle, receiving feedback on the work from interested stakeholders, and continuous improvement. Collaboration is at the heart of any Agile process that makes it possible to respond to changing needs and create work that is in the interest of all the stakeholders of a project. The Agile Manifesto is a founding document of Agile that entails four key values and 12 principles of Agile. Four Key Values of Agile Include Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change by following a plan Similarly, there are 12 principles of Agile methodology. Based on these values and principles, there are various frameworks to implement Agile. The top two frameworks for Agile process implementation are Scrum and Kanban. Each framework lays out the principles, rules, and practices to make an organization’s process truly Agile. I hope this has given you a brief idea about what an Agile process is. Now, let’s talk about how project management software helps you optimize Agile processes. 5 Ways To Optimize the Agile Process With Project Management Software Project management software plays a key role in implementing and optimizing the Agile process. It provides you with a wide array of tools to plan, execute, manage, visualize, track, and collaborate on an Agile process. Here are the five ways you can optimize an Agile process with project management software: 1. Plan Sprints and Set Goals The best way to optimize any process is to set measurable goals and track the progress. Agile involves working in a fixed-length iteration called sprint. Project management software helps you plan sprints and set goals and objectives for the sprint. This ensures every sprint is accounted for and measured for the progress. You get the tools to create a product backlog, prioritize the features, assign the story points to each story, and commit to the stories you can complete in a sprint. This all is part of effectively implementing Agile. 2. Store All the Information in a Centralized Place Project management software helps you optimize the Agile process by storing all the information related to the project in one centralized place. When everything is recorded and documented, you can easily track the progress and ensure accountability. This recorded information lays the foundation for evaluation and improvement. You can easily see who is working on what, sprint goals, and current work status to plan and optimize coming sprints. Not only that, teams find it easy to work together having all the project-related information in one place. 3. Facilitate Information Sharing, Collaboration, and Communication The Agile Manifesto says, “Business people and developers must work together daily throughout the project.” Collaboration is at the heart of the Agile process. A project management tool provides you with built-in collaboration features like real-time chat, discussions, and file sharing to facilitate seamless communication and collaboration within the team and with stakeholders. The free flow of information ensures the team collaborates effectively on all aspects of the development process. Not just that, tools for Agile process management like the Kanban board ensure transparency and enhanced visualization of the flow of the work both for developers and business people. Each team member can better understand their tasks, deadlines, and how it affects the sprint outcomes. A Scrum master can better manage tasks, track progress, and identify bottlenecks to ensure the team is effectively implementing Agile and meeting sprint goals. Business people can visualize the progress transparently which helps them build trust with the team. This results in the overall optimization of the Agile process with the involvement of all the key stakeholders. 4. Hold Sprint Retrospectives To Optimize Performance One of the 12 principles of the Agile manifesto is, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Project management software provides you with a platform to conduct regular sprint retrospectives at the end of each sprint. The purpose is to reflect on what went well, what didn't, and what can be improved in the next sprint. You get the tools to create charts and reports to get insights into project status and team performance. For example, a burndown chart can help you plot the amount of work remaining against the amount of time to monitor development. This helps in estimating when all of the work will be finished. Similarly, there are velocity charts, burnup charts, and control charts to track progress, analyze data, and solve problems effectively to optimize your project process. 5. Improve Overall Operational Efficiency A developer uses 8 to 10 different tools for a software development cycle. It includes tools for writing codes, testing, continuous integration & continuous deployment (CI/CD), end-user feedback, code repository, and bug tracking. Project management software helps you improve operational efficiency by bringing various tools used in development to one place. It helps you streamline workflows resulting in enhanced process efficiency. Apart from that, many project management software provide you with workflow automation that can help you optimize process efficiency in Agile workflows by saving you time, reducing errors, and increasing consistency. Why Should You Optimize Your Agile Process? Agile teams do not become efficient automatically. It is a process of continuous improvement. Practically when an Agile team works together, it takes one or two sprints to understand each other’s working style and project requirements to reach the optimal efficiency, which is measured using Sprint velocity. Thus, you need to optimize your Agile workflow to improve efficiency and reap the benefits of Agile. That’s why many people refer to Agile as a mindset that embraces change rather than opposing the change. Here Are the Benefits of Optimizing Your Agile Process 1. Faster Speed to Market As per the state of the Agile report, 52% of teams use Agile methodology to accelerate time to market. Optimizing your Agile process means a better understanding of project requirements and reduced wasted efforts. This helps you improve efficiency, resulting in faster speed to market the product. 2. Reduce the Risk of Failure As per the state of the Agile report, 31% of teams adopt Agile methodologies to reduce the risk of failure of the project. Agile encourages frequent testing, continuous-release, and continuous feedback to ensure issues are identified early in the development cycle. This helps you reduce the project risks. 3. Delivery Predictability 44% of the teams say they use Agile for delivery predictability. Agile optimization means effective implementation of Agile. This helps you improve delivery predictability by breaking large work into smaller pieces. The ability to move quickly yet be predictable is a key benefit of Agile. Conclusion According to Gartner, 91% of businesses are engaged in some form of digital initiative for business transformation. If you are not using the right project management software to optimize the Agile process, it will become challenging for you to implement Agile methodology and become truly Agile. Project management software provides you with the tools to implement the Agile process. Along with the right Agile practices in place, you can easily optimize the Agile process with project management software.
Welcome to Sprint anti-patterns! This article covers the three Scrum accountabilities (formerly roles) and addresses interferences of stakeholders and IT/line management with this crucial Scrum event. Moreover, I added some food for thought. For example, could a month-long Sprint be too short for accomplishing something meaningful? And if so, what are the consequences? The Purpose of the Sprint The purpose of the Sprint is clearly described in the Scrum Guide — no guessing is necessary: Sprints transform hypotheses into value. They are consistent, fixed-length events of one month or less, with new Sprints starting immediately after the previous one ends. Every activity required to achieve the Product Goal, such as Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, occurs within Sprints. Sprints foster predictability by inspecting and adapting progress towards a Product Goal at least every calendar month. If a Sprint is too long, the market may invalidate a Sprint Goal, increasing complexity and risk. Shorter Sprints, similar to short projects, promote more learning cycles and limit the risk of cost and effort to a briefer time frame. Source: Scrum Guide 2020. Scrum as a framework is mainly of a tactical nature. The Sprint is about delivering value to customers, guided by the Sprint Goal, based on previously explored and validated hypotheses. It is all about getting things out of the door, thus closing the feedback loop and starting another round of inspection and adaption. Besides working on accomplishing the Sprint Goal, a Scrum Team also allocates time to product discovery, aligning with stakeholders, and refining the Product Backlog. 29 Sprint Anti-Patterns This list of notorious Sprint Anti-Patterns applies to all Scrum roles and beyond the Product Owner, the Developers, the Scrum Master, the Scrum Team itself, as well as stakeholders and the IT/line management. Sprint Anti-Patterns of the Product Owner Absent PO: The Product Owner is absent most of the Sprint and is not available to answer questions of the Developers. (As the Sprint Backlog is emergent and the Developers may identify necessary new work or the scope of previously identified work may need to be adjusted, the Product Owner’s absence will likely leave the Developers in the dark, creating undone work that requires a decision on how to move on. No matter the reasons for the Product Owner’s absence, it displays the team’s value creation, putting the accomplishment of the Sprint Goal at risk. It is an expensive Sprint Backlog anti-pattern.) PO clinging to tasks: The Product Owner cannot let go of Product Backlog items once they become part of the Sprint Backlog. For example, the Product Owner increases the scope of a work item or changes acceptance criteria once the Developers select this Product Backlog item for the Sprint Backlog. (There is a clear line: before a Product Backlog item becomes part of the Sprint Backlog, the Product Owner is responsible. However, once it moves from one backlog to the other, the Developers become responsible. If changes become acute during the Sprint, the team will collaboratively decide how to handle them.) Inflexible PO: The Product Owner is not flexible to adjust acceptance criteria. (If the work on a task reveals that the agreed-upon acceptance criteria are no longer achievable or useful, the Scrum Team needs to adapt to the new reality. Blindly following the original plan violates core Scrum principles.) Delaying PO: The Product Owner does not provide feedback on work items from the Sprint Backlog once those are done. Instead, they wait until the end of the Sprint. (The Product Owner should immediately inspect Product Backlog items that meet the acceptance criteria. Otherwise, the Product Owner will create an artificial queue within the Sprint, unnecessarily increasing the cycle time. This habit also puts reaching the Sprint Goal at risk. Note: Inspecting Product Backlog items does not equal some sort of work acceptance or quality gate. There is no such thing in Scrum. Once a Product Backlog item meets the Definition of Done, it can be released into the hands of users.) Sprint stuffing: The Developers accomplished the Sprint Goal early, and the Product Owner is pushing them hard to accept new work from the Product Backlog to fill the “void.” (The Scrum Team decided collaboratively on the Sprint Goal, and the Developers committed to delivering. Consequently, it is the prerogative of the Developers to decide on the composition of the Sprint Backlog. Should they manage to accomplish the Sprint Goal before the Sprint’s end, it is their sole decision to fill the remaining time. Accepting new work from the Product Backlog may be one way of filling the remaining Sprint time-box. This also applies to refactoring parts of the tech stack, exploring new technology that might be useful, fixing some bugs, or sharing knowledge with fellow teammates. Scrum is not in the business of maximizing the utilization rates of team members. Achieving the Sprint Goal is sufficient as it is the most valuable addition to the product the team can accomplish during the Sprint. However, should the team regularly deliver the Sprint Goal early, the Scrum Team may want to inspect that behavior during a Retrospective. The team may be playing safe, whatever the reason. In this case, the urge of the Product Owner to stuff the Sprint Backlog is less of an anti-pattern but rather an expression that the team needs to address the elephant in the room.) Sprint cancellations without consultation: The Product Owner cancels Sprints without consulting the Scrum Team. (Technically, it is the prerogative of the Product Owner to cancel Sprints. However, the Product Owner should not do this without a serious cause. Moreover, the Product Owner should never abort a Sprint without consulting the rest of the Scrum Team. Maybe, someone knows how to save the Sprint Goal, provided it is still useful? Misusing the cancellation privilege indicates a serious team collaboration issue and a lack of commitment to living Scrum Values.) No Sprint cancellation: The Product Owner does not cancel a Sprint whose Sprint Goal can no longer be achieved or has become obsolete. (If the Scrum Team identified a unifying Sprint Goal, for example, integrating a new payment method, and the management then abandons that functionality mid-Sprint, continuing working on the Sprint Goal would be wasteful. In such a case of obsolescence, the Product Owner has to consider canceling the Sprint. If the Product Owner fails to do so, continuing the work would create waste while raking up significant opportunity costs. Moreover, nothing is more frustrating than working on something no one will use while squandering valuable time. By the way, the fact that the Developers receive payment for the wasted effort does not equalize the issue.) Anti-Patterns of the Developers No WiP limit: There is no work-in-progress limit. (The purpose of the Sprint is to deliver a potentially shippable Product Increment that provides value to the customers and, thus, to the organization. This goal requires focused work to accomplish the necessary work to meet the Sprint Goal by the end of the Sprint. The flow theory suggests that a team's productivity improves with a work-in-progress (WiP) limit. The WiP limit defines the maximum number of tasks the Developers can work on simultaneously. Exceeding this WiP number creates additional queues that consequently reduce the overall throughput of the Developers. The cycle time—the period between starting and finishing a ticket—measures this effect.) Cherry-picking: The Developers cherry-pick work. (This effect often overlays with the missing WiP issue. Human beings are motivated by short-term gratifications. It just feels good to solve yet another puzzle from the board, here: coding a new task. In comparison to this dopamine fix, checking how someone else solved another problem during code review is less rewarding. Hence, you may notice tickets queueing in the code-review column, for example. It is also a sign that the Developers are not yet fully self-organizing. Conversely, mature Scrum Teams have a shared understanding of the team goals and prioritize work that benefits the team’s objectives over individual interests. They understand the importance of finishing tasks and adhere to the agreed-upon Definition of Done.) Board out-of-date: The Developers do not update tickets on the Sprint board in time to reflect the current statuses. (The Sprint board, no matter if it is a physical or digital board, is not only vital for coordinating the Developers’ work. It is also an integral part of the communication of the Scrum Team with its stakeholders. A board that is not up-to-date will impact the trust the stakeholders have in the Scrum Team. Deteriorating confidence may then cause counter-measures on the side of the stakeholders. Consequently, the (management) pendulum may swing back toward traditional methods. The road back to PRINCE II is paved with abandoned boards.) Side-gigs: The Developers are working on issues that are not visible on the board. (While sloppiness is excusable, siphoning off resources and bypassing the Product Owner—who is accountable for the return on investment the Scrum Team is creating—is unacceptable. This behavior also signals a substantial conflict within the “team.” Given this display of distrust—why didn’t the engineers address this seemingly important issue during the Sprint Planning or before—the Developers are probably rather a group than a team anyway. However, there might be an exception that proves this rule: Suppose the Scrum Team’s Product Owner has a dominant personality and relentlessly pushes to ship as many new features as possible. Moreover, the management supports the Product Owners in their approach as they consider this an excellent way to maximize output. Consequently, there is little or no time to attend to refactoring or bug fixing unless the Developers tackle these jobs under the radar. In this situation, I would have sympathy for the approach as a stop-gap measure before solving the underlying challenge of the pushy Product Owner.) Gold-plating: The Developers increase the scope of the Sprint by adding unnecessary work to the Product Backlog items of the Sprint Backlog. (This effect is often referred to as scope-stretching or gold-plating. The Developers ignore the original scope agreement with the Product Owner. For whatever reason, the team enlarges the task without prior consulting of the Product Owner. This ignorance may result in a questionable allocation of development time. However, there is a simple solution: the Developers and the Product Owner need to talk more often, creating a shared understanding from product vision down to the individual Product Backlog item, thus improving the trust level. If the Product Owner is not yet co-located with the Developers, now would be the right moment to reconsider. Alternatively, a distributed Scrum Team may invest more time in how to communicate synchronously and asynchronously best to improve its level of collaboration and alignment.) Sprint Anti-Patterns of the Scrum Master Flow disruption: The Scrum Master allows stakeholders to disrupt the flow of the Scrum Team during the Sprint. There are several possibilities for how stakeholders can interrupt the team’s flow during a Sprint. Any of the following examples will impede the team’s productivity and might endanger accomplishing the Sprint Goal: The Scrum Master has a laissez-faire policy as far as access to the Developers is concerned. Notably, they are not educating stakeholders on the negative impact of disruptions and how those may endanger accomplishing the Sprint Goal. Note: I do not advocate that Scrum Masters shall restrict stakeholders’ access to team members in general. The Scrum Master does not oppose line managers taking team members off the Scrum Team, and assigning them to other tasks. The Scrum Master does not oppose line managers adding members to the Scrum Team without prior consultation of the team members. (Preferably, the Scrum Team members should decide who is joining the team.) Lastly, the Scrum Master allows stakeholders or managers to turn the Daily Scrum into a reporting session. (This behavior will impede the Developer’s productivity by undermining their self-management while reintroducing command & control through the backdoor.) Lack of support: The Scrum Master does not support team members who need help. Often, Developers create tasks an engineer can finish within a day during their planning sessions. However, if someone struggles with such a job for more than two days without voicing that they need support, the Scrum Master should address the issue and offer their support. Making this issue visible is also the reason for marking tasks on Sprint boards with red dots each day if work items do not move to the next column. (In other words: we are tracking the work item age.) Micro-management: The Scrum Master does not prevent the Product Owner—or anyone else—from assigning tasks to Developers directly. (The Developers organize themselves without external intervention. The Scrum Master is the first line of defense of the Developers in that respect.) #NoRetro: There is no Retrospective as the team believes there is nothing to improve, and the Scrum Master accepts this notion. (There is no such thing as an agile Nirvana where everything is perfect. As people say: becoming agile is a journey, not a destination, and there is always something to improve. Retrospectives are a critical part of Scrum’s principle of continuous improvement which, for example, the Scrum Value of Commitment reflects. A formalized event like the Retrospective allows the Scrum Team to focus exactly on this challenge.) Note: I do not believe that it is the task of the Scrum Master to maintain a Sprint board, for example, by moving tickets. The Developers should do this during the Daily Scrum if they consider this helpful. It is also not the responsibility of the Scrum Master to update an online board so that it reflects the statuses of a corresponding physical board. Lastly, if the Developers consider a burn-down chart helpful, they should also update the chart themselves. #justsaying #scrummasterisnotascribeorsecretary Sprint Anti-Patterns of the Scrum Team Not having a Sprint Goal: The Product Owner proposes a direction that resembles a random assortment of tasks, providing no cohesion. Consequently, the Scrum Team does not create a Sprint goal. (If this is the natural way of finishing your Sprint Planning, you probably have outlived the usefulness of Scrum as a product development framework. Depending on the maturity of your product, Kanban may prove to be a better solution. Otherwise, the randomness may signal a weak Product Owner who listens too much to stakeholders instead of ordering the Product Backlog appropriately.) Not delivering the Sprint Goal: The Scrum Team misses the Sprint Goal more often than delivering it. (We are not getting paid to practice Scrum. We are paid to solve our customers’ problems within the given constraints, allowing our organization to build a sustainable business in the process. Given Scrum’s delivery focus and tactical nature, agreeing on a Sprint Goal and then delivering it is the most critical contribution of the Scrum Team. While there may be many situations where the team cannot accomplish the Sprint Goal occasionally, for example, because of technical issues, skill deficits, and the complexity and uncertainty of life itself, this failure should be the exception, not the rule. If it is acceptable to fail to deliver value at the end of the Sprint, the whole idea behind Scrum is questioned. Remember, a Scrum Team trades a forecast for inclusion in decision-making, autonomy, and self-organization. Creating a low-grade time-boxed Kanban and calling it “Scrum” will not honor this deal.) The Maverick and the Sprint Backlog: Someone adds an item to the Sprint Backlog without consulting the Developers first. (Having Developers control their own Sprint Backlog helps them forecast. They may add to the Sprint Backlog, for example, when they discover they need to fix a critical bug after the Sprint’s start or when they identify new work that is vital to achieving their Sprint Goal. The Developers need to be the ones to decide they will take on this work in the Sprint since they often have to take other work off the Sprint Backlog in order to make room for the new work. Only the Developers have the knowledge to make these decisions, and the decisions are theirs alone.) Hardening Sprint: The Scrum Team decides to have a hardening or clean-up Sprint. (That is a simple one: there is no such thing as a hardening Sprint in Scrum. The Sprint’s goal is to deliver a valuable, potentially shippable Product Increment. For that purpose, the Scrum Team creates a Definition of Done to ensure that everyone understands the required quality level for a Product Increment to be “shippable” to customers. Declaring buggy tasks “done” thus violates this core Scrum principle of collaboration. Hardening Sprints are commonly a sign of a low grade of adoption of agile principles by the team or the organization. This is probably because the Scrum Team is not yet cross-functional. Or quality assurance is still handled by a functional, non-agile silo with the product delivery organization. Alternatively, the Developers might have felt pressured to deliver to meet an (arbitrary) deadline, and they decided to cut corners by reducing quality. No matter the reason, in such a situation, there is plenty of work for the Scrum Master to accomplish.) Delivering Y instead of X: The Product Owner believes in getting X. The Developers are working on Y. (This is not merely a result of an inferior Product Backlog refinement. This anti-pattern indicates that the Scrum Team failed to create a shared understanding. There are plenty of reasons for this to happen, just to list a few: The Product Owner and the Developers are not talking enough during the Sprint. Maybe, the Product Owner is too busy to answer the team's questions or attend the Daily Scrum. Alternatively, Product Backlog refinement sessions during the Sprint are inadequate. Developers don’t participate in user conversations with customers or users, so they lack understanding of the users' problems. Developers should talk to users regularly to better understand their needs. The Product Owner presented a too-granular Product Backlog item instead of seeking a discussion with the Developers about the Why and What during refinement. The Developers give the Product Owner what they asked for, not what the user really needed. Probably, the Product Backlog item was missing acceptance criteria altogether, or existing acceptance criteria missed the problem. New kid on the block: The Scrum Team welcomed a new team member during the Sprint. Unfortunately, they also forgot to address the issue during Sprint Planning, thus ending up overextended. (While it is acceptable to welcome new teammates during a Sprint, the team needs to account for the resulting onboarding effort during the Sprint Planning and adjust its capacity. The new team member should not be a surprise. However, if the newbie turns out to be a surprise, it is an organizational anti-pattern.) Variable Sprint length: The Scrum Team extends the Sprint length by a few days to meet the Sprint Goal. (Generally, if the Sprint length needs to change, the Scrum Team inspects and adapts its working practices during the Retrospective. However, during a Sprint, and contrary to all other Scrum events, the Sprint timebox is fixed. Consequently, changing it in a last-ditch effort to realize a Sprint Goal that is out of reach is another way of cooking the agile books to match a goal or metric. Extending the Sprint length is not agile; it is just inconsequential. Additionally, it devastates stakeholder inclusion, as Scrum events, for example, the Sprint Review, lack a proper cadence, reducing your stakeholders' willingness to collaborate.) Sprint Anti-Patterns of the Line Managers All hands to the pumps w/o Scrum: The management temporarily abandons Scrum in a critical situation. (This is a classic manifestation of disbelief in agile practices, fed by command & control thinking and a bias for action to feel “in control” of the situation on their side. Most likely, canceling Sprints and gathering the Scrum Teams would also solve the issue.) Reassigning team members: The management regularly assigns team members of one Scrum Team to another team. (Scrum can only live up to its potential if the Scrum Team members can build trust among each other. The longevity of Scrum Teams has proven beneficial in building that trust. Moving people between teams, on the contrary, reflects a project-minded idea of management rooted in the utilization optimization of “human resources” from the ages of the industrial paradigm. Also, it ignores the preferred team-building practice that Scrum Teams should select themselves. All members need to be voluntarily on a team. Scrum does not work if team members are pressed into service. However, it is not an anti-pattern if Scrum Teams decide to exchange teammates temporarily. It is an established practice where specialists spread knowledge this way or mentor colleagues. ) Special forces: A manager assigns specific tasks directly to Developers, thus bypassing the Product Owner and ignoring the Developer’s self-organization prerogative. Alternatively, the manager removes a Developer from a team to work on such a task. (This behavior does not only violate core Scrum principles. It also indicates that the manager cannot let go of command and control practices. They continue to micromanage subordinates, although a Scrum Team could accomplish the task self-organized. Common reasons for this behavior are trust issues, control orientation, and probably a lack of understanding of the details of Scrum.) Sprint Anti-Patterns of the Stakeholders (Regular) emergency work: Someone in your organization has sold a non-existing feature or functionality to a customer to close a deal, probably already including delivery dates and contractual penalties in the case of non-delivery. Now, they want the Scrum Team to focus on delivering this item. (There might be moments where this outside intervention in the Scrum process may be unfortunate but acceptable, such as an existential business threat, regulatory or legal compliance, a critical bug fix or security threat, or a significant market opportunity. However, the more concerning issue here is the prospect of this behavior becoming a regularity. If the leadership does not acknowledge the exceptionality of the situation, it may derail using Scrum in the organization.) Pitching Developers: The stakeholders try to sneak in small tasks by pitching them directly to Developers. (Nice try, #1. However, all suggestions for the future allocation of the Scrum Team’s time compete with each other, and the Product Owner is the referee in this process.) Everything’s a bug: The stakeholders try to speed up delivery by relabeling their tasks are ‘serious bugs.’ (Nice try, #2. A particular case is an “express lane” for bug fixes and other urgent issues that some Scrum teams establish. In my experience, every stakeholder will try and make their tasks eligible for that express lane.) Food for Thought There are some issues that are worthwhile considering as a Scrum Team regarding the Sprint: What if a month-long Sprint is still too short? There are areas where a month-long Sprint may prove to be too short, for example, in hardware development or machine learning when training new models. Would it be okay to extend the length of a Sprint? Or would such a situation signal abandoning Scrum altogether and moving to alternatives such as Shape Up? Dying in beauty? Is there a moment when circumstances become so desperate that abandoning Sprints is a valid option? For example, think of a startup running out of cash, and the only way to survive is to achieve a particular milestone defined by a prospective new investor. Would that be a moment when to abandon Scrum’s rigorous process to have a fighting chance? Conclusion Although the Sprint itself is just a container for all other Scrum events, there are plenty of Sprint anti-patterns to observe. Many of them are easy to fix by the Scrum Team or the Scrum Master when empathizing with the stakeholders’ situation and asking yourself: How did I contribute to this situation in the past? What Sprint anti-patterns have you observed? Please share those with us in the comments.
Product Ownership Is a Crucial Element in Improving Outcomes SAFe and Scrum both consider product ownership crucial to maximizing outcomes in environments of complexity and uncertainty. Teams are ideally organized around products/value streams so they can apply customer-centricity. Product people and their teams are ideally accountable for outcomes and are empowered to figure out, inspect, and adapt requirements/scope as needed. SAFe Has Multiple Product Ownership/Management Layers As organizations tackle bigger products, they have some alternatives for how to tackle product ownership/management. Scrum advises having one product owner for each product, even if multiple teams develop the product. This is at the core of scaling frameworks such as Nexus and LeSS. SAFe takes a path that is more aligned with the classic structure of product management organizations, which is to have multiple layers of product ownership/management. Product owners own the product at the Agile Team level. Product managers own product at the teams of Agile teams level (Agile Release Trains). Solution managers own products for huge teams of teams working on even larger products/solutions. Why Did SAFe Make This Choice? SAFe takes the perspective of learning from experience in the trenches and what patterns organizations are using and applying lean/Agile principles as needed to help organizations evolve. And many organizations have been struggling to scale product ownership when we're talking about multiple teams. Product management experts such as Melissa Perri also talk about multiple product management roles (see some thoughts about how this relates to SAFe below). Interestingly enough, Scrum@Scale also has product owners at every level. And LeSS/Nexus also introduce multiple product owners when you scale beyond a handful of teams. The advantage of this approach is that it aligns with the product manager/owner journey. Working closely with one or two teams, owning product choices for a couple of product features or a certain slice of the product, can be a great jumping point for junior product managers/owners (What Melissa Perri refers to as associate product managers in Escaping the Build Trap). As the product manager/owner gains experience, they can take on a whole product themselves. It takes time for a product owner/manager to gain the experience to act as the visionary entrepreneur for their product. They might start feeling more comfortable writing stories and executing experiments and, over time, learn to influence, design product experiments, and make tougher prioritization decisions with multiple demanding stakeholders. In other words, product managers/owners naturally evolve from focusing on tactics to strategy over time. What Are Some Downsides To Splitting Product Responsibilities Between the Product Owner and Product Manager? An anti-pattern we often see is that the PM/PO split allows an organization to staff the PO role with “story writers” and “project managers” — people who aren’t empowered as product owners, and that reinforce the project mindset of requirement order-taking and managing scope-budget-timeline. This lack of empowerment leads to delays and an environment where the team is focused on outputs rather than outcomes. Empowering product owners and their teams is a common challenge in SAFe AND Scrum. What I’ve seen work well is carving out an appropriate product scope within which the product owner and team are empowered to figure out what to build to achieve the desired outcomes and optimize the value of that product or that aspect of a bigger product. Doing this requires figuring out the product architecture and moving towards an empowering leadership style. As in many other areas, SAFe takes the evolutionary approach. If you’re a purist or a revolutionary, you’ll probably struggle with it. Real-world practitioners are more likely to relate to the evolutionary approach. It’s important to ensure that the PO/PM separation is not seen as an excuse to continue doing everything the same. Product Managers and Product Owners: A Collaborative Relationship Leaders implementing the PO/PM split should ensure healthy collaboration, involvement, and partnership across the product ownership/management team. Product managers should internalize the SAFe principles of unleashing the intrinsic motivation of knowledge workers, in this case, product owners. Product managers have a role as lean/Agile leaders to nurture the competence, awareness, and alignment in the product team that would enable them to decentralize control and let product owners OWN a certain slice of the product. Product managers and product owners should discuss what decisions make sense to centralize and which should be decentralized. The goal of product managers should be to grow product owners over time so they can make more and more decisions — and minimize the decisions that need to be made centrally. This is key to scaling without slowing down decision-making while maintaining and ideally improving outcomes aligned with strategic goals. Increased Risk of Misunderstandings Around Product Ownership With Product Roles Filled by Non-Product People One very specific risk of the SAFe choice to split the PM and PO roles is that it creates the need for many more people in a product role than the number of people in the product organization. This vacuum pulls people like business analysts, project managers, and development managers into the product owner role. Some people can become great product owners but come with very little product (management) experience. Business analysts, for example, are used to consider what the customers say as requirements. They are used to the “waiter” mindset. They struggle to say no or to think strategically about what should be in the future or what should be in the product. Development managers are used to being subject matter experts, guiding their people at the solution level, and managing the work. Project managers are used to focusing on managing scope/budget/timeline rather than value and outcomes. Use the Professional Scrum Product Ownership Stances to Improve your SAFe Product Ownership One technique I found very useful is to review the Professional Scrum Product Ownership Stances with SAFe product owners and product managers. We try to identify which misunderstood stances we’re exhibiting and what structures are reinforcing these misunderstood stances/behaviors. For example — what’s causing us to be “story writers”? We explore the preferred product owner stances and discuss what’s holding us back from being in these stances. Why is it so hard to be an “experimenter,” for example? An emerging realization from these conversations is that SAFe structurally creates a setup where team-level product owners play “story writers” and “subject matter experts” more often. It’s non-trivial to switch to an environment where they are a “customer representative” and a “collaborator” with the space to “experiment” with their team towards the right outcome rather than take requirements as a given. It’s hard to get SAFe product managers to be the “visionary,” “experimenter”, and “influencer”. The issue here isn’t unique to SAFe. Product owners struggle to exhibit these behaviors in most Scrum environments as well. What I find useful is to align on a “North Star” vision of what we WANT product ownership to look like at scale and take small steps in that direction continuously, rather than settle for “project management” or “business analysis” called a new name. SAFe Product Management: Providing Vision and Cohesion in a Pharma IT Environment Let’s close with an example of how this can play out in practice. I'm working with the IT organization of a pharmaceutical company. As they were thinking about how to help their Enterprise Applications group become more agile, one of the key questions was how do we create product teams that are empowered to directly support the business — by minimizing dependencies and creating real ownership of each of the enterprise applications as a platform that other IT functions can more easily build off of and leverage. Several Enterprise Applications have multiple teams working on different aspects of them. We created stream-aligned teams, each owning and managing that aspect as a product. The product owners and their teams are empowered to consider needs and wants coming in from other IT functions and the business and shape the future of their product. Most of these product ownership decisions happen at the team level. Product managers focus on alignment and cohesion across the platform. We are still working on establishing the right mechanisms to balance vision/alignment with local initiatives at the team level. So, Now What? SAFe’s approach to product ownership is a frequent target of criticism in the hard-core Agile community. Some of it is pure business/commercial posturing (aka FUD), and some of it is fair and constructive. My aim in this article was to help practitioners explore the rationale, the potential, and the risks behind SAFe’s approach to product ownership, as well as some patterns and models, such as the Professional Scrum Product Ownership stances, that can be used to inspect and adapt/grow the effectiveness of your product ownership approach. As an individual product owner or product manager, you can use these models/patterns to drive your learning journey and help you structure your organization's conversation around creating the environment that empowers you to be a real product owner or product manager. As leaders of product organizations in a SAFe environment, I hope this can help you establish a vision of how you want your product organization to look like and guide you on the way there.
Joining the Agile framework provides access to resources and support that can help your organization maximize the benefits of Agile. It also provides a platform to connect with other Agile practitioners to share best practices and learn from each other. Practicing Agile working methods allows teams to pursue their goals at their own pace and with as much creativity as they want, and they're also a great way to bond as a team. Agile teams are also better able to respond to changes in the market quickly and efficiently, which is essential for success. Agile teams also tend to be more motivated, as they feel they are in control of their destiny. So, if you are wondering how to encourage your team to embrace Agile values and principles, Agile games are one of the best options to get started with. What Are Agile Games? A major benefit of Agile games is that they support team building through new learning activities and iteration. As a result, Agile games support the communication and self-organization capabilities of DevOps teams. As a result, your team members will be better able to learn Agile software more rapidly. This will lead to better collaboration between teams, more efficient development, and faster time to market. Agile games also help teams to identify potential risks and issues early in the development process. This allows them to quickly adjust and course-correct as needed. Agile games also help teams build trust, foster collaboration and encourage creativity. This in turn leads to better problem-solving, increased team morale, and a greater sense of ownership. What Agile Games Are Best for Team Building? Here you can find some of the best Agile games that help boost team effort and support. Murder Mystery Play murder mystery games to boost team communication and thinking skills. Participants need to work together to solve the case and uncover the murderer. The game encourages collaboration and creativity as players need to think outside the box and come up with unique solutions. It also tests participants' problem-solving skills and their ability to think critically. The Paper Airplane Another great Agile game is the paper airplane game, and it can be played by any team. As a basic premise, each member of your team must construct a paper airplane. The catch is that each member is only permitted to fold the plane one time before handing it over to the next member. In addition to increasing team bonding, this is an effective way to teach team members how their contributions contribute to the project as a whole. Ball Point This ball-based game follows the same principles as most Agile games, in which team members communicate and formulate strategies. The game consists of teams passing a ball around, and each time a member touches the ball, a point is scored, but points are accumulative when the last member touches the ball and is also the first one to touch it. Marshmallow Tower A marshmallow serves as the crown of a tower in this game. As simple as it may sound, the "building materials" given to teams are often fairly flimsy; spaghetti, for instance, or even string have been used as "building materials" in Agile games. This is another great Agile game for teaching teams agility since it rewards the team with the most structurally sound marshmallow tower, although speed and specifications are also important factors. Chocolate Bar A great way to get a better understanding of iterations and customer feedback for teams is through this game. It can be played in person, or with a Miro board. Your goal is simple (and delicious): you are building a chocolate bar based on customer input. One person will be designated to perform the role of the product manager or product owner, and everyone else will serve as a customer. The Emoji Game This emoji game is an excellent way to facilitate communication when it comes to Agile games. Team members must interpret what the messenger means by using emojis. The catch is that the messenger can only communicate using emojis. A favorite film or album, for example, or a message describing the messenger's characteristics might be appropriate. Conclusion These are the best Agile games for team building as they provide moral support and better communication and delivery skills. Team mates can collaborate more in a better way to solve the game and that also helps them boost These games also help increase the morale of the team and build trust between the team members. They can also help in creating better problem-solving skills and critical thinking. Lastly, these Agile games can help in breaking the monotony of the workplace and having fun while working together.
In the Oxford Dictionary, the word agility is defined as "the ability to move quickly and easily." It is, therefore, understandable that many people relate agility to speed. Which I think is unfortunate. I much prefer the description from Sheppard and Young, two academics in the field of sports science, who proposed a new definition of agility within the sports science community as "a rapid whole-body movement with a change of velocity or direction in response to a stimulus" [1]. The term “agility” is often used to describe “a change of direction of speed.” However, there is a distinct difference between “agility” and “a change of direction of speed.” Agility involves the ability to react in unpredictable environments. Change of direction of speed, on the other hand, focuses purely on maintaining speed as the direction of travel is changed. Maintaining a speed while changing direction is usually only possible when each change of direction of travel is known in advance. Using a sports analogy as an example, in soccer, we can say that a defender’s reaction to an attacker’s sudden movement is an agility-based movement. The defender has to react based on what the attacker is doing. Compare this to an athlete running in a zig-zag through a course of pre-positioned cones, and the reactive component is missing. There are no impulsive or unpredictable events happening. The athlete is trying to maintain speed while changing direction. Often, when leaders of organizations want to adopt Agile, they do so for reasons such as “to deliver faster.” In this case, they are thinking of agile as a way to enable a change of direction of speed like the athlete, and not in the sense of agility needed by the soccer defender when faced with the attacker. This may explain why agile ways of working do not always live up to expectations, even though more and more companies are adopting it. Sticking with the sports analogy, the athlete running through the cones tries to reach each one as quickly as possible and then runs in the direction of the next until the end of the course. This works as a metaphor for defining the scope of a project and has teams work in short iterations in which they deliver each planned feature as quickly as possible and then move on to the next. This may be fine in a predictable environment, where the plan does not need to change, where requirements stay fixed, where the market stays the same, and where customer behaviors are well understood and set in stone. In many environments, however, change is a constant: customer expectations and behavior, market trends, the actions of competitors, and more. These are the VUCA environments (volatile, uncertain, complex, and ambiguous) where there is a need to react or, to put it another way, where agility is needed. Frameworks such as Scrum are meant to support agility. Sprints are short planning horizons, and the artifacts and events in Scrum are there to provide greater transparency and opportunities to inspect and adapt based on early feedback, changes in conditions, and new information. It gives an opportunity to pivot and react in a timely manner. However, Scrum is unfortunately often misunderstood as a mechanism to deliver with speed. Focusing only on speed and delivery and not investing in the practices that enable true agility is likely to actually slow things down in the long run. When the focus is only on speed, it becomes harder to maintain that speed, let alone to increase it, and any semblance of agility is a fantasy. Let me talk about a pattern that I see again and again as an example. Company A has a goal to build an e-commerce site through which they can sell their goods. Their first slice of functionality is delivered in a 1-month Sprint and consists of a static catalog page in which the company can upload its products with a short description. The first delivery is received by happy and excited stakeholders who are hungry for more. The team keeps on building, and the product keeps growing. Stakeholders make more requests, and the team works harder to keep up and deliver at the pace that stakeholders have come to expect from them. The team does not have time to invest in improving their practices. Manual regression testing becomes a bigger and bigger burden and is more challenging to complete within a Sprint. The codebase becomes more complex and brittle. The more bloated the product becomes, the more the team struggles to deliver at the same pace. To try to meet expectations, the team begins to cut corners. They end up carrying testing work over from one Sprint to the next. And there is no time for validating if what is being delivered actually produces value. This is just as well, as no analytics have been set up anyway. In the meantime, whilst the team is so busy trying to build new features and carrying out manual integration and regression testing, they do not have time either to look at improvements to their original build pipeline or to build in any automation. A release to production involves several hours of downtime, so this has to be done overnight and manually. To make matters worse, the market has been changing. The sales team has made deals with new suppliers, but this means further customizations to the site are needed for their products. Finally, the company has pushed for the platform to be available in different timezones, so the downtime for a release is a big problem and must be minimized, so they are only allowed to happen once every six months. Progress comes to a standstill. The product is riddled with technical debt. The team has lost the ability to get early feedback and the ability to react to what their attackers are doing, i.e., customers' changing needs, competitors’ actions, changing market conditions, etc. Just implementing the mechanics of a framework like Scrum does not ensure agility and does not automatically lead to a more beneficial way of working. The Agile Manifesto includes principles such as “continuous delivery of valuable software,” “continuous attention to technical excellence,” and “at regular intervals, the team reflects on how to become more effective.” Following these principles is a greater enabler of agility than following the Scrum framework alone. One effective way of enabling greater agility is to complement something like Scrum with agile engineering practices to get those expected benefits that organizations are looking for with agile. Over the years, I have encountered many Agile adoptions at companies where a lot of passion, energy, focus, and budget went into training and coaching people in implementing certain frameworks such as Scrum. However, what I do not encounter so much are companies spending the same amount of passion, energy, focus, and budget into implementing good Agile engineering practices such as Pair Programming, Test Driven Development, Continuous Integration, and Continuous Delivery. When challenged on this, responses are typically something like “We don’t have time for that now," or “Let’s just deliver this next release, and we’ll look at doing it at a later date when we have time." And, of course, that time usually never arrives. Now, of course, something like Scrum can be used without using any Agile engineering practices. After all, Scrum is just a framework. However, without good engineering practices and without striving for technical excellence, a Scrum team developing software will only get so far. Agile engineering practices are essential to achieve agility as they allow the shortening of validation cycles and get early feedback. For example, validation and feedback in real-time on quality when pairing, or that comes with proper Continuous Integration being in place. Many of the Agile engineering practices are viewed as daunting and expensive to implement, and doing so will get in the way of delivery. However, I would argue that investing in engineering practices that help to build quality or allow tasks to be automated, for example, enables sustainable development in the long run. While investing in Agile engineering practices may seem to slow things down in the short term, the aim is to be able to maintain or actually increase speed into the future while still retaining the ability to pivot. To me, it is an obvious choice to invest in implementing Agile engineering practices, but surprisingly, many companies do not. Instead, they choose to sacrifice long-term sustainability and quality for short-term speed. Creating a shared understanding of the challenges that teams face and the trade-offs for short-term speed without good engineering practices in place versus the problems that can arise without them can help to start a conversation. It is important everyone, including developers and a team’s stakeholders, understands the importance of investing in good Agile engineering practices and the impact on agility if you don’t do it. These investments can also be thought of as experiments — trying out or investigating a certain practice for a few iterations to see how it might help can be a way to get started and make it less daunting. Either way, it is questionable that an Agile process without underlying agile practices applied can be agile at all. For sustainability, robustness, quality, customer service, fitness for purpose, and true agility in software development teams, it is important for continuous investment in agile engineering practices. [1] J. M. Sheppard & W. B. Young (2006) Agility literature review: Classifications, training and testing, Journal of Sports Sciences, 24:9, 919-932, DOI: 10.1080/02640410500457109
Test automation is essential for ensuring the quality of software products. However, test automation can be challenging to maintain, especially as software applications evolve over time. Self-healing test automation is an emerging concept in software testing that uses artificial intelligence and machine learning techniques to enable automated tests to detect and self-correct issues. This makes test automation more reliable and cost-effective and reduces the amount of time and resources required to maintain test scripts. In this article, we will discuss the benefits of self-healing test automation, how it works, and how to implement it in your organization. What Is Self/Auto-Healing Test Automation? Self-healing test automation is a new approach to test automation that uses artificial intelligence (AI) and machine learning (ML) to make test scripts more robust and adaptable. With self-healing test automation, test scripts can automatically detect and repair themselves when changes are made to the application under test, including shifting layouts and broken selectors. This makes it possible to automate tests for complex applications with frequently changing user interfaces without having to constantly maintain and update the test scripts. Why Is Self-Healing Test Automation Necessary? Test automation scripts can easily break when changes are made to the user interface. This is because test automation scripts are typically designed to interact with specific elements on the screen, such as buttons, text fields, and labels. When these elements change, the script may no longer be able to find them or interact with them correctly. This can lead to test failures and false positives, which can be time-consuming and frustrating to resolve. Also, the user interfaces are constantly evolving, with new features and bug fixes being added frequently. This means that test automation scripts need to be updated regularly to adapt to these changes. However, updating test automation scripts can be a manual and time-consuming process, which can be challenging to keep up with the pace of change. Self-healing test automation addresses this fragility of traditional test automation scripts by adapting to changes in the user interface automatically to make test scripts more robust and adaptable. Self-healing test scripts can automatically detect and repair themselves when changes are made to the application under test, which can help to reduce test maintenance costs, improve test quality, and increase test coverage. How Does Self-Healing Mechanism Work? Step 1: The self-healing mechanism gets triggered whenever “NoSuchElement” or a similar error occurs for an element mentioned in the automation script. Step 2: The algorithm analyzes the test script to identify the root cause of the error. Step 3: The algorithm uses AI-powered data analytics to identify the exact object in the test script that has changed. An object can be any interface item like a webpage, navigation button, or text box. Step 4: The algorithm updates the test script with the new identification parameters for the affected object(s). Step 5: The updated test case is re-executed to verify that the remediation has been successful. How Self-Healing Test Automation Adds Value to Your Software Delivery Process Leveraging self-healing capabilities allows test automation to adapt to changes, improving test coverage, reducing maintenance efforts, and enabling faster feedback. Saves Time and Effort Self-healing test automation can save organizations a significant amount of time and effort in software testing. Traditional test automation approaches require manual intervention to fix errors or failures that occur during test execution. This can be a time-consuming and error-prone process, especially when dealing with large and complex test suites. Self-healing test automation eliminates the need for manual intervention, allowing tests to recover automatically from failures or errors. Improves Test Coverage Self-healing test automation can help to improve test coverage by allowing testers to focus on writing new tests rather than maintaining existing tests. This is because self-healing tests can automatically adapt to changes in the software under test, which means that testers do not need to spend time updating their tests every time the software changes. As a result, testers can focus on writing new tests to cover new features and functionality. Self-healing automation can improve test coverage by 5-10% by eliminating unnecessary code, resulting in shorter delivery times and higher returns on investment. Prevents Object Flakiness Object flakiness is a common problem in test automation, especially for GUI testing. Object flakiness occurs when a test fails because it is unable to locate an object on the page. This can happen for a variety of reasons, such as changes to the UI, changes to the underlying code, or network latency. Self-healing test automation can detect and prevent object flakiness by analyzing test results and identifying patterns that indicate flaky tests. By preventing object flakiness, teams can reduce the number of false positives and negatives, improving the overall accuracy and reliability of test results. Faster Feedback Loop Self-healing test automation also enables a faster feedback loop. With traditional test automation approaches, tests are often run manually or through a continuous integration pipeline. However, with self-healing test automation, tests can be run continuously, providing immediate feedback on the quality of the application under test. This enables teams to identify and fix issues faster, improving the overall quality and reliability of the application. Conclusion In Agile methodology, applications are continuously developed and tested in short cycles. This can make it difficult to maintain test cases, as the application is constantly changing. Self-healing test automation can help to overcome this challenge by automatically updating test cases when the application under test changes.
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.
In software testing, we have traditionally grouped requirements into two main areas: functional and non-functional. Commonly, people define functional requirements as to how the system should work. In contrast, non-functional requirements refer to how well the system should behave or perform. But let’s discuss the big elephant in the room. The name “non-functional requirements” is terrible. The name has been a source of confusion and may not accurately convey the essence of what these requirements encompass. When working on software projects, teams put less emphasis on non-functional requirements, which is a grave mistake. If you quickly browse articles online related to non-functional requirements, some authors even mention that non-functional requirements are optional. Non-functional requirements become “non-important requirements,” but I can argue that they are just as important, if not more important, than functional requirements since they can impact the overall quality of your application. Neglecting the prioritization of non-functional requirements has tangible repercussions, especially on the user experience. This is exemplified in real-world scenarios such as: Amazon encountered system issues during Prime Day in 2018, struggling to handle a substantial surge in traffic, resulting in a compromised user experience. Nationwide, a major bank in the UK, experienced a payday payment outage in 2022. This unfortunate incident left thousands of customers unable to access their accounts and fulfill essential financial transactions, underscoring the critical importance of robust non-functional considerations. Pokemon Go, a popular game released in 2016, still gets reports of their application crashing from gamers. How can we ensure that non-functional requirements deserve the spotlight they deserve? In this article, I’ll talk about the naming nuance of non-functional requirements and explore if there is a better terminology for the dreaded term “non-functional.” Focusing on this terminology shift is not merely about semantics but aims to reflect better the comprehensive nature of these requirements and their impact across various system dimensions. Naming Nuance It is no secret that the tech industry has had its share of horrible naming conventions, one example being the slave and master terminologies used widely for decades in technical contexts. The naming for non-functional requirements is also another example. If you look up the term non-functional in a dictionary, the Cambridge Dictionary defines non-functional as “not working, or not working in the correct or usual way.” If non-functional refers to something that is not working, why did we adopt non-functional requirements as an industry-wide term in the first place? Most users will deem the functional requirements unusable without the so-called non-functional requirements. Suppose your application has a login feature that works well from a functionality perspective but is not keyboard-accessible or responsive when the incoming traffic is higher than usual. In that case, the login functionality will be unusable to most users. We work on projects where performance, scalability, availability, accessibility, and security, qualities that fall under the umbrella of non-functional requirements, are essential. However, this slight naming nuance is more harmful than good, especially when educating people about this topic, since it leads people to believe these qualities are less important. Functional requirements are important, and non-functional requirements are considered less important or optional. Non-functional requirements remain a widely accepted and recognized term in the industry, and teams understand the importance of neglecting these requirements. But, as an industry, we should frame non-functional requirements better, even though we do not intend to treat non-functional requirements as less important. Naming Alternatives Non-functional requirements often encompass the whole system rather than specific behavior. For example, backend performance refers to how well your backend application can process user requests under a given workload. Scalability attribute refers to how well your system can expand its capacity to handle growing demands. In contrast, the resiliency attribute refers to how well your system reacts to failures. These non-functional requirements, just like any other non-functional requirements, look at a system as a whole. Cross-Functional Requirements A better naming alternative is to call them “cross-functional” requirements, which Sarah Taraporewalla coined in her blog post I don’t believe in NFRs, which has been adopted widely in Thoughtworks. By adopting the term cross-functional requirements, there is a deliberate shift in perspective. Cross-functional emphasizes that these requirements are not secondary or less important but are integral to the entire functioning of the system. The cross-functional name implies that these requirements cut across various functions and aspects of the system, ensuring it performs well as a cohesive unit. In addition, changing the name to cross-functional communicates a holistic approach to system development, encouraging teams to prioritize and integrate these considerations from the outset, ultimately leading to a more robust and reliable end product. Human Qualities Apart from cross-functional, Jeff Nyman proposed to call non-functional “human qualities” instead when he crafted this insightful article on “reframing non-functional as human qualities” to represent the different human feelings that we feel when using the system and how it would negatively make us feel when so-called non-functional requirements are not prioritized. Similar to how a person's qualities collectively shape their character, non-functional requirements also shape the character of a system as a whole. Naming non-functional as human qualities emphasizes their impact on the overall user experience and system quality from a user's perspective. In addition, the term human qualities can make these technical aspects more relatable and understandable to a broader audience, including non-technical stakeholders. Quality Aspects Beren Van Daele refers to all requirements as “quality aspects” as part of the RiskStorming workshop to force testers to think about all the aspects that can impact the quality of your application. Each non-functional requirement represents a specific aspect that, when fulfilled, enhances the system's overall quality. Here is an illustration created by software tester Jędrzej Kubala. Quality aspects represent the requirements important to your projects, including the common attributes grouped as part of non-functional requirements. Beyond the Name Personally, I prefer the term cross-functional requirements since it’s more apparent that there are requirements that cross multiple areas of your application. Whichever naming alternative you use, teams should still make a lot of effort to ensure that these requirements are prioritized and treated the same way we discuss functional requirements. For example, from a performance perspective, one way to do this is to have a continuous testing approach, where various performance activities are embedded throughout the software development lifecycle. Framing non-functional requirements as cross-functional requirements, human qualities, or quality aspects is a great way to remove the stigma that non-functional requirements are unimportant. It may be a name, but this can frame our mindsets differently when we use the correct term.
Hello DZone Community! 2023 was certainly an exciting year for us here at DZone, and I hope it was filled with lots of love, laughter, and learning for you as well! One of the coolest things we did during the year was our latest DZone Community Survey! At DZone, our community is the heart and soul of who we are and what we do. We literally would not exist without each and every one of you, and the strength of our community is what sets us apart and makes us the go-to resource for developers around the world. And as with any relationship, the best way to grow and improve is to learn more about each other. That was our goal with the 2023 DZone Community Survey: to learn more about you, our community, so we can better serve you content that is relevant, helpful, and engaging for you while continuing to build the best platform on the planet for software developers to grow, connect, and share knowledge. We learned quite a lot about our community from the survey, and I wanted to share some of the highlights with you: Java is still the most dominant language, with Python being a close second. AI and applications for automating code processes are the topics of greatest interest. 90% of respondents prefer to learn through online communities like DZone and StackOverflow. This is just a small preview of what we learned, but what this means for you is that Java and AI content is continuing to see a lot of engagement on DZone, and AI specifically will be a hot topic to discuss on the site this year. (Read: If you’re looking for a topic to write about, Java and AI would be a great place to start.) It also reiterates why DZone is such a great place for developers to gather and share knowledge. We also saw some interesting changes from our last survey in 2020, such as nearly double the number of respondents working at the C-suite level and that 60% of you have a significant impact on the technology your company purchases and implements. We love that the DZone community is filled with so many expert, experienced developers. The level of knowledge here is unmatched, so when you add your voice to the conversation, you know you’re in strong company. In conclusion, we’re really excited about the results of our 2023 Community Survey, mainly because what we learned will help us continue to improve the content and experience we provide on DZone. We can’t tell you how much we appreciate everyone who took the time to respond to our survey, and we look forward to the 2024 DZone Community Survey! Thank you and Happy New Year! -The DZone Team
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.
Jasper Sprengers
Senior Developer,
Team Rockstars IT
Alireza Chegini
DevOps Architect / Azure Specialist,
Coding As Creating
Stelios Manioudakis, PhD
Lead Engineer,
Technical University of Crete
Stefan Wolpers
Agile Coach,
Berlin Product People GmbH