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.
In four years, the Agile Manifesto will celebrate its silver jubilee. I want to devote another post to these sensible recommendations you find hanging in poster format on office walls the world over. Agile as a noun has become solidified in the established practice of software development to the point where many treat its values as if descended from Mount Sinai on stone tablets. They are not eternal truths and can make no such claims. They were written when Perl/CGI was the go-to stack for web apps. Agility encompasses adaptability, so the values themselves must be constantly re-evaluated and questioned. The Agile Manifesto summarizes its values and principles on a single sheet of paper. The Scrum Guide needs more space, but it’s still concise enough to be called a summary. That needn’t be a problem. Many complex cooking recipes fit on a single page. But Agile, however you define it, can at best only be a set of ideas and values, never a recipe or how-to guide for building great software – Scrum doesn’t even talk about software. That’s why the agile method is a deceptive term. The Oxford dictionary definition of method resembles that of a recipe quite well: “A particular procedure for accomplishing or approaching something, especially a systematic or established one”. It’s funny that the entry should give a method for software maintenance as an example. The lexicographer probably thought refactoring is like plastering a ceiling: something hard that requires skill, but no originality or imagination. I wrote earlier that there’s no recipe to creativity, but even recreating things you didn’t invent yourself is rarely as easy as following a description of the steps involved, except perhaps for an Ikea bookcase. People train for years to become a top chef. You can’t expect to create their haute cuisine by careful reading alone. Since developing novel software is an act of creation, there can be no cookie-cutter approach, or we would have automated it already. However, there certainly is a methodology that inspires the way we go about it. These are the more abstract principles that justify our choices, like openness to change and end-user involvement. The Agile Manifesto set out to define such a set of ideas through the condensation of a lively debate. The details of these conversations are left to the reader to fill in and interpret, but they are not incidental. They are at the heart of the methodology. It takes experience and judgment to understand and appreciate these ideas. Method and methodology – they sound like a Jane Austen novel – go hand in hand. The first concerns the how, the latter the why. A methodology explains and justifies the ideas behind the operational mechanics of a method. The method appears neutral, but it can never be uncontroversial when its underlying principles are open to different opinions. This is certainly the case with original Agile values like team autonomy and the strong preference of face-to-face communication. How many of the Manifesto’s principles for the most efficient way of working are backed up by rigid scientific evidence? Maybe some are, but most are at best tenuous, and some no better than personal preference, probably unrecognized as such at the time because of the very homogenous nature of the original brotherhood of men who expressed them. “We all think so, therefore it must be true”. That is dangerous groupthink. When you’re considered an expert in the field and people adopt your opinions, you bear a great responsibility to separate personal taste from proven facts. The values and assumptions behind the original Agile ideas lead to a rather rigid method for building any type of software. But a single method can never be equally suited to every product in every industry. Agile values must be generic enough so they can allow for multiple methods. Since we all love the movies, please indulge me in an analogy with another method, i.e. The Method. I’m sure you’ve heard of it. The Method is an approach to stage and film acting based on the ideas of Russian actor/director Konstantin Stanislavksi. It encourages sincere and expressive performances through identifying with, understanding, and experiencing a character's inner motivation and emotions. Its gained global influence through Lee Strasberg’s Actor’s Studio in New York in the 1950s and the generations of legendary film actors who trained there. An actor must understand how the writer and director intend to convey to the viewer the plot of the story and the emotions of the character. The Method has practical instructions to help the actor. Its methodology is opinionated about the purpose of acting, which is to approach as truthfully as possible the emotional life of the character. There is no better way to do that than becoming the character. Some actors go to extreme lengths in that quest and there are plenty of popular Hollywood legends about self-inflicted hardship. Most famous is the story surrounding the infamous torture scene in Marathon Man between Dustin Hoffman and Laurence Olivier. To get in character and look suitably haggard, Hoffman had deprived himself of sleep, at which Olivier asked with amused surprise why he didn’t just act it. As a veteran of the British stage, Olivier had a different artistic outlook. The Method is grounded in a naturalistic philosophy of acting. There is also the school of Michael Chekhov, which favors the power of imagination over perfect realism. Two different philosophies with very different methods and radically different results. Sometimes a role demands a pure, naturalistic approach. Think of Oscar winners Brie Larson in Room, or (again) Dustin Hoffman in Kramer vs. Kramer: completely different films and actors, but with the same approach to realism. But sometimes real isn’t interesting, in the words of Stanley Kubrick (I mentioned him before – I’m a fan). To play a proper baddie, you need to push beyond real. Think of Jack Nicholson in The Shining, Christian Bale as American Psycho Patrick Bateman, Anthony Hopkins as Hannibal Lecter, and the two Jokers Heath Ledger and Joaquin Phoenix. They are mesmerizing performances, but their characters are not true to life. They are over the top, which makes them scary and funny. Truly great actors know that they must sometimes change their customary approach to do full justice to a part. Method devotee Al Pacino portrayed drug kingpin, Tony Montana, quite differently from his earlier roles. Why? Because Scarface was not your average gritty gangster movie. It was an outrageous drama, like Shakespeare’s Macbeth set in Florida, and it called for a character larger than life. Different vision calls for a different character and a different method. I hope you find this analogy to the craft of building software useful. Substitute the artistic vision of a writer/director with the product vision of the organization, and add to the mix the prospective end-users, restrictions of time and money, and the diversity of the people involved. Suddenly, “working software," like “good acting," is too generic to be useful. The context determines and refines how we should define working software, and what’s the appropriate method to attain it. What works for an online game would be completely unacceptable for the James Webb telescope. How could there ever be one effective practical method applicable to all? Few Agile values are non-negotiable, besides honesty, respect, and everything it takes to be a good person. If a single set of immutable values doesn’t even work for multiple projects in a single organization, it’s naïve to expect that it should work for the industry as a whole. Yet this is what we keep doing. The wisdom we like to call our experience is weighed down as much by the baggage of our preconceived notions. You just can’t take on a new project or job and shoehorn your old routines to fit new circumstances and requirements. Be more like Tony Montana next time – well, Al Pacino’s interpretation of the monster, obviously.
Agile practices have been adopted worldwide. Many companies are proud of being agile. Each of them implements it in a different way, which is good because there is no single way to do it, and it needs to be adapted to each scenario. From my point of view, too much focus is set on some aspects of Agile while a key one is forgotten. It is nothing new, but if this aspect is not considered, releasing new versions of your software can be a never-ending story. This is what I will tackle in this article.But before digging into that, I would like to do a small recap about the evolution of software development, starting with Waterfall and the birth of Agile. You may want to skip it if you already know about it. A Long Time Ago, There Was Waterfall Many developers who started their careers in the last 10 years have probably only worked in Agile environments. However, Agile was not always there. Waterfall was a common practice when I started my university education back in 2003. In Waterfall, the applications were often planned as a whole (or at least in big chunks that were difficult to manage). It could take many months before the customer saw some working software. The development was planned as a project, with a beginning and, theoretically, an end (the end of the company, sometimes). The project was divided into phases similar to these: Requirement collection System design Task planning Development Testing and delivering Every stage was often carried over by different people. The customer was involved in signing the contract at the beginning, and at the end. If the project finished successfully, the application was deployed to production and often handed over to a different team, which would be in charge of keeping the lights on. As many of you know, those practices caused many problems. Some of them were: Collecting all the requirements, designing the system upfront, and planning the tasks was almost impossible and would take many weeks. Handovers at every stage would lead to miscommunication. It would take a lot of time to deliver something. Many times, much more than expected. And you know: while there is no software, there is no money. It was also difficult to end within budget and scope. There was no feedback loop between stages. Many times, there was feedback only at the end. If the feedback was negative, the whole investment failed. Agile Has Come to Save Us When I started working, I heard about a new concept: Agile. For a while, I didn't know what was it about. At that time, I was focused on improving my development skills and didn't care that much about software development methodologies. Agile appeared to fix the many problems that Waterfall presented, and it became rapidly adopted. But many took it as a dogma, thinking that adopting some rituals would solve all of their problems. What I mostly heard was a bunch of buzzwords such as: "Scrum," "eXtreme Programming (XP)," "Sprint," "Retro," "Grooming," and some others (which later I found were more related to Lean) such as "Kanban," "Work In Progress (WIP)." Most of those words didn't tell me a lot on their own. After some time, I became interested in understanding why a lot of companies were embracing these practices, so I started digging into the topic. In my initial research, I could understand the meaning of some of those words, and I saw a lot of discussions: Should the team do Scrum, Kanban, XP, or other? How long should the team spend per sprint on each of the rituals? What should we talk about during standup? And so on. I found very superficial information and was missing something. Maybe it was my research skills. I wouldn't ever be Indiana Jones. Looking backward, I think that it was not only that. When I read the Agile Manifesto, one of the things I read was: "Individuals and interactions over processes and tools". During my research, I had the impression that too much focus was set on processes and rituals. This was the first sign that either Google's algorithm or some parts of the software industry were focusing on the less important topics. It is also worth clarifying that some read these principles as "the second part is not important." However, as I've heard many times, the principles are meant to be read as: "even though the second part is important, the first one is more." Focusing on the main points of Agile, one of the main differences with Waterfall was the organization of the development in increments: An application was to be divided into small, prioritized chunks. Each chunk was developed within a sprint (regularly 1 or 2 weeks). After each sprint, a functional version of the application should be available for the customers. The customers (or, in some cases, business representatives) were actively involved during the process, so feedback was available early on. You can see how these ideas tackled some of the problems that Waterfall presented by delivering fast and failing fast by having feedback earlier. To continue with the Manifesto, one of the values says "Welcome changing requirements, even late in development". In the beginning, I couldn't understand how that could be possible. I was not sure if that was a good idea. However, after thinking about it and after having different experiences in Agile environments, I consider it one of the most important parts. It is important to consider that changes can involve new features and new concepts for the domain, but also changes in existing behaviour, changes in the market, etc. So not only was it important to move fast in Agile (deliver early the value that the customers need, fail fast with early feedback), but it was also important to react quickly to changes in the environment. They are not the only important aspect but I want to focus on these 2 in the rest of the article. So let's continue in this evolution of software development practices, mentioning some of the improvements that contributed mainly to moving fast. Move Fast: The Evolution of Software Coding and Shipping Practices The tools at the time didn't make it easy to adopt Agile practices, such as frequent deployments. Some practices and technologies appeared in the last 25 years to help teams ship software faster. Some of them appeared as a consequence of Agile, and some of them appeared independently. I will just briefly mention some of them and their benefits without going into details. I consider that most are broadly known, but if one is new for you, there are many resources online to find out more: Test automation gave developers confidence by preventing lots of bugs and reducing the need for debugging. Version control helped developers track changes back to when they were added, revert them easily, solve conflicts in a much easier way, and it was the base for many other improvements. Feature branches or working in parallel with branches. Parallelism is always good, right? Well, this also presented in many cases a new problem: When doing a large number of changes or keeping branches open for a long time, developers would need to spend a lot of time integrating those changes. This practice doesn't work well with some of the other practices mentioned next. Feature flags. An option if teams need to work on several initiatives in parallel for a long time but want to avoid the conflicts that often appear with long-living branches. CI-CD (Continuous Integration-Continuous Delivery/Deployment). By integrating the changes, running the tests, and deploying often, the big barrier of delivering to production is disappearing. Code reviews/Pair programming. Years ago, everybody was developing on their own, even critical code. Reviewing code helped us not only code better but also to share knowledge, learn, and reduce the possibility of missing something important. I would argue it is not always needed, but it can provide advantages in comparison to doing big pull requests for long-lived branches, since the feedback is provided while coding, avoiding having to re-write code. You build it, you run it. The development team became also responsible for maintaining the application. This makes sense because the team that develops the application can understand it better than anybody else, and it brings several benefits: Less time to identify issues. Fewer mistakes made when fixing issues. In addition, dealing with issues in a production environment brings the most valuable lessons. These can benefit further developments. Also, a lot of time is saved because no handover meetings are needed anymore. If the team does on-call work, the quality of the software can benefit further, since everybody will do their best to not get paged at an inappropriate time. Changes in team structure: having small, independent, cross-functional product teams to break the IT silo. Removing handovers between development phases speeds up delivery and avoids miscommunications. Keeping teams closer to the domain experts will have a positive effect on the quality of the solutions and boost focus by reducing context switches, among others. It also promotes a modularization of systems (Conway's law). Be aware that, by cross-functional, I don't mean full-stack individuals, which I consider very difficult and even counter-productive. The idea of "T-shaped developer" might be more interesting. DevOps, containers, service meshes, distributed architectures, and the cloud. The infrastructure becomes self-service (the team can deploy without waiting for server allocation). It also becomes immutable, easy to replace, increases security, and much more. Automatic dependency updates. Better monitoring and incident management, such as SLI/SLO, DORA metrics, and other,s to close the feedback loop and take more informed decisions. Apart from those practices, new tools, IDE improvements, frameworks, libraries, and language evolution allowed us to speed up the development of software. If your company embraces most of the practices mentioned above, it probably means that software can be delivered much faster than before. And the changes are not only faster but also safer, since many tasks got automatized or delegated. Some could think that software delivery is as fast as lightning, right? In my experience, it still can take sooooooooo long to deliver VALUE, even when those practices are followed. And here are some cases: Example 1: It took us three days to understand the code that had to be adapted. It was the first time I touched that code. Thankfully, I was working with people that knew a lot about the application. Implementing the main changes with the corresponding tests took us two weeks. Finally, we spent around 16 weeks doing bug hunting throughout the code and implementing the fixes. As you can see, a lot of time was spent on the third point. Of those 16 weeks, around 70% was hunting the bugs, around 20% was understanding the logic we found and thinking about how to adapt it to the new behaviour, 3% was spent writing automated tests, and 1% implementing the changes themselves. Some reasons that explain why it took us so long: The service was doing way too many things. The code was quite tightly coupled because many things broke in different parts of the code. At the same time, the code was not very cohesive. The logic that managed the same concern was spread around. Example 2: We spent three days understanding what we needed to change. It took us one day to implement the changes and seven days for making tests pass again. In this case, there was a large number of hacks in the code to fix previous bugs. Some of them were not even totally fixed. It was clear that some developers weren't familiar enough with the technologies. Luckily, the problems were not critical and the customers didn't notice. The bad part is that they popped up when applying the new changes, making testing almost impossible, so we had to fix them before finishing our task. Another problem was that the stacks were not up to date, so many solutions that we wanted to implement wouldn't work. In these cases, you can see that a lot of time was wasted in debugging and understanding the code that needs to be adapted. Apart from those, there were build lanes that would run forever (lots of code in the same application, slow and/or flaky tests, etc.). So maybe you see where I'm heading. Otherwise, continue reading. And the Forgotten Part Is... In the previous sections, you saw that many practices around software development were adopted to make it faster: Agile, CI/CD, DevOps, team structure, etc. However, keeping existing code working while changing it can be a nightmare. A huge amount of time is still wasted in understanding code and chasing bugs around, even though a bunch of practices that would help have existed for ages. In the meantime, there is a lot of noise around Scrum, Kanban, independent teams, etc., and, as I mentioned above, the Agile Manifesto doesn't focus that much on specific processes or rituals; it just gives some general ideas. So this leads me to say that: Code (and test) quality (especially flexibility) is one of the most important parts of Agile that is being ignored or forgotten. Code quality is not an exclusive problem of Agile, but it is especially important here, even more than in traditional projects. And there is the misconception that, in Agile, there is no need to plan anything or invest effort in software architecture and design, but it is actually the opposite. The code is expanded and adapted very often, so it is critical to make systems easy to change or they will make future development very slow. So, as for developing in Agile, the next iteration of the sentence could be: System flexibility is one of the most important parts of Agile that is being ignored or forgotten. And this is nothing new. It is mentioned in the Agile Manifesto as we saw in a previous quote, but there is more: "Continuous attention to technical excellence and good design enhances agility.” “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” How can a team keep a constant pace if the code is messy, difficult to understand, and change? And keep in mind that quality doesn't mean complexity. Simplicity is also important: “Simplicity--the art of maximizing the amount of work not done--is essential.” Architecture is normally associated with rigidity and planning ahead because we often think of buildings, which are difficult to change. From that point of view, it would make no sense to invest time in architecture or design in an Agile context because things change often. But in the software world, we can choose architectures that leave options open and make changes easier. And we don't need to think far ahead. In fact, Agile promotes thinking in the short term. It is well known that predictions are not easy and in the end, we pay the price. We don't know what the customer will need even in two days. For people who don't do Agile, there is another quote: “High performers understand that they don’t have to trade speed for stability or vice versa, because by building quality in, they get both.” Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. Consequences of Slow Development Development gets slower as we add more code, and this is not only a problem for developers. Every stakeholder speaks in their own terms and has a slightly different meaning: For lovers of UX experiments: Experiments can take weeks instead of days. For product lovers: Reacting to market/meeting customer needs in time… will it happen? For managers: Missing goals, work accumulating. For DORA metrics lovers: Deployment Frequency (DF) is reduced, Mean Lead Time for changes (MLT) increases, Change Failure Ratio (CFR) increases. For the company: Even if we have great ideas, if they cannot be converted easily into software, the company will get stuck. Code will be a liability instead of an asset and in the meanwhile, competitors may take advantage. For developers: Having to deal with bad code can lead to burnout, or a laptop flying through the window. So it is clear that development will get slower, but thankfully, you know that if you invest in flexible code, you can save some time. However, it is not easy to convince some people of this. There is still a problem: The effects of rigid code are not seen immediately. They are visible in the long term. Also investing in developing flexible code might seem slower in the short term. So who would want to invest in something that doesn't have an immediate effect? We know that people think mostly in the short term. We need to give more visibility to how the quality of code will affect future development. Connecting the Effect of Rigid Systems With the Business The effect of rigid code in how long it takes to develop something is not easy to spot. Thus, the effect on the business is also not obvious. Without a connection between both, it will be difficult to convince people of the importance of having flexible systems. It is a very complex topic but the gap needs to be filled. The DORA metrics fix that, at least partially. Code is not homogeneous, code routes slowly, and the problems might be detected too late. TCP (Technology Capability Plan) introduced by Glenn Engstrand in his talk Managing Tech Debt in a Microservice Architecture could be a starting point. I don't know an ideal solution for this. I dream of having a score that gets updated after every commit, which could be used as a multiplier for the estimation of how long a future task will take to be completed. However, I would like to finish with some simple ideas about how to improve the flexibility of code. Ideas for Improving the Flexibility of Code There are many books and resources online about the quality of code, so I won't go into many details: Code needs to be easy to understand. By reading the method name, it should be clear what it does. Understanding one method should not take more than, for example, 10 seconds. Code needs to be modular. Small pieces, loosely coupled, encapsulated. This applies at every level: system, library, package, class, and method. Code needs to be cohesive. Each piece needs to do only one thing and all the code that does that one thing needs to be close together. It is especially important to separate business logic from framework constructs like controllers, listeners, filters, etc. Code needs to be simple (don’t over-engineer, do not force design patterns in). Develop for current needs. When you think: "What if we need X functionality?", apply YAGNI (You Are not Going to Need It). For tests, keep in mind that they grant safety but they resist changes and can eat up your time more than the production code itself, so: They need to bring enough value. Doing TDD (Test Driven Development) is a practice that helps you achieve it. If they test implementation details, they will be very difficult to change. I've seen a lot of unit tests that verify pieces of code that provide internal results. Those pieces of code are the result of how a developer organizes the code. If the logic needs to be organized in a different way and moved around, many tests break. When this happens, tests don't protect you anymore and are almost useless. It also gives the team extra work. So it is important to think about what is actually a unit. I've been thinking a lot about this after having to reorganize the code several times and I started to think that the concept of a unit may not just be methods or classes, but maybe it needs to be thought of in terms of features. This might sound weird, and similar to an integration test, but it is not. To my understanding, the book Unit Testing: Principles, Practices, and Patterns confirmed that I'm not crazy, or at least I'm not the only one. Favour simpler and faster tests: Unit over Integration. Considering integration at the application level; integration tests should take care of things that cannot be verified in unit tests, such as integration with frameworks. E2E tests are not needed by default for every feature. They can be important for features that would be life-threatening, PII critical, can make the company lose a lot of money or similar. Conclusion Keeping the system flexible is critical if you need to introduce changes often, as is the case in Agile environments. Otherwise, after some time, it will be harder and harder to incorporate changes. Other practices, such as the ones mentioned in the article, will help you compensate for that for a while, but in the end, their effects will be less significant. Many times, practices that help you keep the code flexible are very easy to apply. There is more evidence every day that supports the fact that quality helps keep a constant pace in development. Also, new ideas appear that could connect the effect of rigid code in the business.
TL; DR: When Should a Team Stop Using Scrum? When is the time to look beyond Scrum? After all, many things—ideas, practices, mantras, etc.—outlive their utility sooner or later; why would Scrum be an exception? Moreover, we are not getting paid to practice Scrum but solve our customers’ problems within the given constraints while contributing to the sustainability of our organization. Scrum is a tool, a helpful practice but neither a religion nor a philosophy. Which brings us back to the original question: Is there a moment when a Scrum team should stop using Scrum? Setting the Context of Using Scrum To Your Benefit When I ask whether there is a moment when a Scrum team should stop using Scrum, I am not referring to a situation in which using Scrum is useless, to begin with. For example, if you look at the Stacey Matrix below, you will notice areas colored in red—Simple and Chaotic: "Simple" does not require elaborate risk-mitigation strategies as best practices typically work; you do not need a Sprint Planning to prepare a [large hamburger of your choice] menu with fries and a soda. The focus of "Chaotic," on the other end of the spectrum, is on creating stability as anarchy lurks around the corner. As we are dealing with novel practices, a short-timed act-sense-respond approach is beneficial, which is not necessarily Scrum’s strong suit, given the importance of Sprints as the central planning instance. Therefore, both areas are unsuited for using Scrum from the start. I am also not referring to situations where your team fails to solve the perceived problem of your customers for technical reasons or because there is no problem to solve in the first place. (As we all know, the ground is littered with numerous start-ups that failed to identify a problem worth solving; I participated in some of those myself.) Finally, I am not referring to the pundits who believe that using Scrum is a disadvantageous decision in any situation and you should not get involved with it at all. For this article, I refer to a Scrum team solving its customers’ problems. A team that gains a good understanding of the problem and solution space over time. I am thinking of a Scrum team that embodies the idea of sound Scrum application, enjoying a good standing in the organization. However, will that team ever face a situation where Scrum will outlive its usefulness? Or will they be scrumming happily ever after for eternity? The Evolution that Leads to Reconsidering Scrum What I have observed in the past is a slow but steady development resulting from the successful work of the Scrum team, moving further to the maturity stage of the product life cycle. What started as an expedition into the unknown—what is worth building in an area where the team initially had little knowledge—turned into a methodical advance, requiring increasingly less risk mitigation as the Scrum team mastered the main challenge. Returning to the Stacy Matrix, the Scrum team moved from "Complex" [1] to "Complicated" [2]. How Can Scrum Teams Notice When They Moved from "Complex" to "Complicated?" Some indicators help Scrum teams understand whether their progress as a team, as well as the product’s increasing maturity, justify inspecting their original decision to use Scrum, for example: Increasing product maturity leads to progress becoming more steady and less volatile; there are fewer disruptions in delivering Increments. There are fewer match points to score, and progress becomes more incremental—focusing on minor improvements—as the “big features” are already available. The Scrum team experiences growing difficulties in creating team-unifying Sprint Goals; there is a growing number of Product Backlog items that cannot be clustered under one topic. Reduced volatility results in an expanding planning horizon. At least, there is a temptation to plan further ahead, which also suits the team’s stakeholder relationship management. (The Scrum team best creates trust with stakeholders by boring yet reliable deliveries.) Stakeholders gain more trust in the team’s capabilities, resulting, for example, in less engagement in Sprint Reviews. (Why breathe down the neck of the Scrum team as a stakeholder when they successfully deliver valuable Increments, allowing you to do your own planning?) Metaphorically speaking, the Scrum team moves from leaping forward to walking steadily. In my experience, no unique threshold signals the completion of moving from "Complex" to "Complicated." On the contrary, noticing this slow and non-obvious process requires dedicated observation from the Scrum Master and all team members. Moreover, it needs psychological safety to challenge what works just fine regularly. As mentioned before: We do not get paid to practice Scrum but solve our customers’ problems within the given constraints while contributing to the sustainability of our organization. Conclusion: When Is It Time to Stop Using Scrum? Choosing Scrum at a certain point does not imply that we will use Scrum for all eternity. There may be a time when we decide to stop using Scrum as it no longer serves the original purpose: figuring out what is worth building while mitigating risk. The moment we notice competition regarding our way of working by a different approach, we ought to inspect and probably adapt our decision to use Scrum if the new way of working promises a better return on investment. (Please note, though, that by referring to "return on investment," I am not merely thinking in financial terms. Other factors are, for example, team health or product quality.) As always, it is a good idea to include all team members early in this process. Have you ever worked with a team that decided to stop using Scrum? If so, please share with us in the comments: What steps they took to come to that conclusion, and how did it work out for them?
Agile workflows have fast become a cornerstone of software development environments globally, so much so that the methods that underpin the framework have spread into many other disciplines. Whether it’s helping a marketing team revamp their core strategy or giving customer relations a boost toward their latest service goal, Agile is here to stay. Where to Begin, Then? With that popularity in mind, it can be intimidating for a team to launch headfirst into adopting a new methodology that will likely upend many, if not all, aspects of their daily workflow. To help you choose the best model for your team, compiled below is an Encyclopedia Agilica, if you will, of the most fundamental methodologies out there today. Some lesser-known frameworks are also introduced, shedding some light on the vast array of ways Agile can and should benefit your organization with functional testing frameworks. Before you know it you’ll be well on your way to becoming an Agile coach! Scrum This is the big one. Anyone dipping their toes in Agile waters will likely have already come across the Scrum methodology. Scrum has worked its way to the top of the methodology charts thanks to its focus on ownership and segmentation of development stages into smaller, more easily-deliverable actions called ‘sprints.’ From here, any task is a sum of manageable components leading the team step by step toward their larger, final goal. Sprints allow for timely adjustments to project goals and a foundation of constant communication between task owners, meaning that project realities remain current and transparent. Things like meeting notes template and core documentation should be readily available to all so that reference replaces repetition. Anything that can help drive forward little victories toward the big win is championed in Scrum and Agile in general! Kanban Kanban, from the Japanese term meaning ‘signboard,’ shares a lot of similarities with Scrum. Like its neighbor, Kanban utilizes the same ‘project breakdown’ approach but uses the visual communication offered by what's known as a ‘Kanban Board’ (pictured below) to keep everyone in the loop on statuses and deliverables within the task dashboard. The Kanban Board is broken down into columns, where various tasks are placed depending on their progress that everyone involved can edit in real time. This ensures more time goes toward completion and forward movement instead of into constant review and ‘this could have been an email’ meetings to suck valuable resources. Further, having that visual representation will help everyone on the team see where tasks have started to flounder or require more attention, allowing for all-hands-on-deck Agile Swarming until the wheels start turning again. Extreme Programming (XP) Another framework that utilizes sprints, Extreme Programming (or XP), offers some of the best buffers against unexpected changes or late-stage customer demands. Within sprints and from the start of the business process development, feedback gathering takes place. It’s this feedback that informs everything. This means the entire team becomes accustomed to a culture of pivoting on real-world client demands and outcomes that would otherwise threaten to derail a project and seriously warp lead time production. Any organization with a client-based focus will understand the tightrope that can exist between external demands and internal resources. Continuously orienting those resources based on external demands as they appear is the single most efficient way to achieve harmony. This is something that XP does organically once integrated into your development culture. As you can guess by the name, XP primarily concerns itself with the software development workflow. However, it still has core principles on offer for other areas of business efficiency, given its client-centric realism. Lean Software Development ‘Lean’ is exactly that. Trimming the fat from the development process is what this method is all about. If something doesn’t add immediate value, or tasks within tasks seem to be piling up, the laser focus of Lean Development steps in. Similarly, Lean places the focus on efficient and harmonious teamwork. With remote and hybrid working adding potential complications to the development landscape of late, Lean’s focus on conflict management and a culture of respect can help meld teams that have found themselves scattered to the winds. If rapid delivery is something you want to be known for, Lean could be the methodology for you. Keeping solid documentation around the development process mapping so that it can be utilized more efficiently, or even scaled, in the future puts Lean at the top of the list for a team focused on quick, surgical turnarounds. In that regard, preparation is key. Having kick-off and operational documentation will get externals and freelancers up to speed quickly. This will make project onboarding an almost automated process that requires no additional staffing resources. Crystal Crystal and its iterations — including Crystal Clear, Crystal Red, and Crystal Yellow — absolutely sound like generations of Pokemon from days gone by. Rest assured, though, choose the right one, and you’ll have no need to catch ‘em all. Where Lean Development focused on efficient, no-nonsense practices, Crystal offers a similar lightweight approach, with much more flexible and non-committal rhetoric. In fact, the Crystal methodologies at their highest level are about the team and self-determination. Crystal believes that there is no one better placed to decide the most effective way a team should work than the team itself. Cultural consensus or even a prevailing leadership style can define a working environment. And hey, if it works, let it continue to do so! Crystal nourishes that seed and is person-centric enough to put communication, transparency, and accountability at the forefront of development. As such, if you take pride in your established culture and want a way to formalize that without commitment to rigorous methodology, Crystal could be the framework for you. Scaled Agile Framework The Scaled Agile Framework, or SAFe to its friends, is the ‘enterprise edition’ of Agile. Put simply, if your business has hit a growth spurt that threatens to become unruly or disparate, SAFe provides a means by which Agile practices can grow with you. It will also help you keep that growth manageable and productive. The customer, and their needs, remain very much at the heart of SAFe, but it provides a playbook for roles and responsibilities within an organization to allow that to happen. Think of it like an Agile security blanket around your business! Due to its nature as an accompaniment to business growth, there is a certain importance placed on leadership within SAFe. ‘Lean’ leadership, specifically, in that those in charge should embody the cultural values they have decided are in the best interests of a team and create an environment in which those values are embraced. By now, you should be seeing a lot of crossover in the methodologies; both in core values and basic principles. However, there are a few instances where the melding is a little more explicit. This brings us to… The Hybrids: Scrumban It’s a testament to the success and relative simplicity of Agile and its various iterations that the second generation of methodologies has emerged: the hybrids. They offer the best of two complementary worlds by taking key elements from their parent frameworks. Indeed, with an array of operational disciplines outside of software development going Agile, it makes sense we’re starting to see the inclusion of more ‘tweaked’ models. Scrumban, a combination of Scrum and Kanban (would you have guessed?), utilizes the sprint structure of Scrum with the added bonus of the visual project representation of Kanban. The core tenets of both methods combine here in a way that Lean would be proud of. Indeed, a successful Sprint review accompanied by visual confirmation of progress is a great way to keep all parties motivated and rally around the next steps. The Hybrids: Scrum/XP Scrum has also made easy bedfellows with Extreme Programming. The key benefit to XP is its feedback inclusiveness and client-centricity in the software development lifecycle. Where Scrum can traditionally be seen as the Project Manager’s method, XP rests firmly with the Devs. Hybridizing these two, however, bridges a gap that needn’t exist in DevOps. Better still when their powers combine with renewed focus, Scrum/XP keeps the client and their ever-changing needs at the heart of everything. As it should be. Scrum is a foundational means by which all collaboration members can rally around the project's current state. When real-time feedback is provided at every opportunity, there can be no conflict as to what the next steps should be. It’s quite literally laid out in black and white by the client. That way, you can kiss goodbye to any interoffice ego battles! Why Choose? Finding an Agile methodology that’s right for your organization might seem like a daunting task to the uninitiated. However, while the list above isn’t exhaustive, it does go a long way to showcasing the flexibility and scalability of this family we call Agile. Regardless of your needs, your business culture or ambition, employing the right Agile methodology will help you retain your core values and make collaboration easier than ever; regardless of what comes your way!
There is no doubt that Scrum is one of the most important tools in the search for business agility for teams in any context, and in tackling challenges of varying complexity. As explained by Forbes, business agility enables organizations to thrive in a world of rapid and unpredictable change, helping them to adapt their business management models and internal processes to make them more efficient. All of this without compromising quality, and being truly able to maintain their competitive advantage. Several times I’ve had conversations with people who work with Scrum and Agile methodologies who claim they don’t have testers and don’t run into any problems. On the other hand, I have seen testers within these schemes who often feel excluded from the development team. Other testers who have not yet worked in Agile teams question whether there is even room for testers in Scrum. It’s often stated that everyone in a Scrum team should be able to perform different tasks and that all are accountable for quality. But, there are some things that a tester can handle better than others. For example, writing good acceptance criteria requires a tester’s skill set, as one must keep in mind and worry about certain characteristics such as quality, testability, maintainability, and so on. These are all things that the tester is responsible for obsessing over. Therefore, when you need to write acceptance criteria, you’ll be better off delegating it to someone trained in testing over someone that’s not.Software developers and software testers have two very important, yet distinct roles that don’t always work well when conflated. Developers and the software development industry at large can agree that once you have the developers you need on your team, it’s important to find the right tester with a high level of QA expertise to complement them. So, can there be testers in Scrum? It’s not just that they can be there. When it comes to quality software, testers should always be involved. “The objective of the Scrum Master is to help teams grow and evolve in their organization. So that they can incorporate work methodologies that make it easier for them to solve all kinds of challenges autonomously,” explained Gabriel Ledesma, leadership coach at Abstracta and co-founder of the Agile community in Uruguay. “The development of agile transformations is evolutionary,” he emphasized. In this vein, The Scrum Guide is clear: “Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.” In other words, Scrum can be used in different contexts and by a variety of professionals to find solutions to complex problems. “We follow the growing use of Scrum within an ever-growing complex world. We are humbled to see Scrum being adopted in many domains holding essentially complex work, beyond software product development where Scrum has its roots,” outlines the Scrum Guide. “As Scrum’s use spreads, developers, researchers, analysts, scientists, and other specialists do the work. We use the word 'developers' in Scrum not to exclude, but to simplify. If you get value from Scrum, consider yourself included," it continues. Scrum does not recognize roles or sub-teams, but there may be members with specialized skills and an area in which they focus. That is, there may be testers (with a tester’s skillset) that focus on quality tasks. However, the responsibility for quality is on the whole team. From my professional experience, having worked with all sorts of development teams, including Scrum, I believe the “tester role” is truly relevant.A critical aspect of Scrum and Agile methodologies is that it is fundamental to have T-shaped skills, meaning that it is not only necessary to have the testing mindset and capabilities, but also to have some skill in the specialties of the people you work with — for instance, business, development, operations, and so on. In such a way, you can contribute more, making the team self-sufficient and promoting its excellence. Inside of our teams, we testers have to help shift testing left, allowing developers to test earlier, frequently, and more easily, with CI/CD support, and then they can do pair testing, or the devs can test each other’s code. Anyway, developers still have a developer mindset, which is great for development, but not for testing. In the words of Melissa Eaden, “Anybody can do testing, but only a tester can do good testing.” Speaking of Agile testing, here is a little reminder of the Testing Manifesto published by Growing Agile, which we love so much that we have it hanging on the walls in our Abstracta headquarters! What do you think… is there room for testers in Scrum? Please let me know in the comments below.
Agile, which started off as a better and more practical method of software development proposed by a group of developers, is now transforming the way in which organizations are run. Agile is now adopted by banks, manufacturers, research & development centers, hospitals, and even airports for execution. When the scale and reach of Agile increased, newer frameworks such as Scaled Agile Framework (SAFe), Large Scale Scrum, Nexus, and so on gained popularity. Enterprise agility and business agility is radically changing the way in which organizations are structured. The very premise of Agile is that organizations are complex adaptive systems and not merely a group of departments that can function in a sequential manner. The COVID-19 pandemic accelerated the widespread adoption of Agile when organizations realized that it is a matter of survival and sustenance to innovate newer methods to be flexible and adaptable to the ever-changing needs of the customers. Agile does exactly that! Uncovering Agile Insights When Agile is implemented at scale in organizations, there could be variations in the depth and rigor of implementation. Organizations use several modes of assessment to measure the maturity of being agile an indicator of true agility. The factors in these assessments are usually related to systems, practices, tools, people, and culture. Organizations use key performance indicators (KPIs) to measure agile attributes at team, program, and business levels. Many of these measures are kept very simple in construct and design, to ensure that it does not overcomplicate the inherent simplicity of agile. For instance, burn-down charts indicate the progress of work completion. Velocity is a team measure, which shows the amount of work that the team has done in an iteration. While these are pretty useful to visualize the product increment execution, there could be underlying patterns, trends, and insights in an agile implementation that could be understood to sustain and continually improve agile at a business level. To uncover these insights, organizations need to employ more sophisticated data analytics techniques and tools, as the volume and variety of this data will be quite diverse. An example could be to understand the quality of user stories. Almost all agile practitioners agree that a user story must be simple and clear. Some use attributes such as Independent, Negotiable, Valuable, Estimable, Small, and Testable (abbreviated as INVEST) to ensure the quality of user stories. With a text analytics tool in natural language processing, we can uncover whether the user stories written by the team are of good quality and whether it follows the INVEST pattern. Likewise, to know whether the product team will be able to release a product increment successfully on time, we could use a predictive analytics algorithm to determine the success rate of releases. Practical Use Cases Here are five use cases of applying data science in Agile to visualize and uncover insights. 1. Determining Release Readiness Using Decision Trees Like Random Forest "Are we ready to release?" is one question that may be crucial for any Agile team to answer. While the frameworks such as Scaled Agile advocate a release on demand approach, it is not always easy to know if the releases done on demand of the customer will meet their expectation. Studies have shown that, while agile projects are three times more likely to succeed than waterfall projects, nearly 47% of agile projects are challenged, and 11% fail on release to customers [Standish Group Chaos Report, 2021]. To overcome this, the readiness of release can be predicted using a combination of factors. The success of release will depend upon factors such as code quality, burn rate of stories, test coverage, defect fix efficiency, and effectively managing product owner goals. These factors can be modeled using the Random Forest algorithm (or any similar Decision Tree technique) by defining thresholds at each level to determine if the team should release or not. The probability of success associated with a release can also be determined using the same method, post which it is up to the business leaders to determine whether to go ahead with the release for a given probability. 2. Estimating Flow Predictability Using Predictive Analytics Predictability and agility in combination are sought by many organizations to deliver products and services. While agile methods ask for empowered teams to self-organize around value, it is sometimes challenging to predict the outcome the team will deliver in future releases. This is due to the inherent nature of Agile, which places importance on embracing change and complexity rather than unnecessarily (or artificially) sticking to an irrelevant plan. Business leaders, however, may need to know the product output with a timeline associated with it to plan for cash inflows and market launches, and even to answer shareholders. This predictability of business value can be computed by applying predictive analytic techniques in data science. The features delivered across iterations can be used to model the rate using time-series techniques to predict the next release. Yet another option is to model the factors leading to delivery outcomes. Both these approaches will provide a reasonable view to business owners to take important decisions to estimate delivery outcomes. 3. Analyzing the Quality of User Stories Using Text Analytics User stories are perhaps one of the most important artifacts in agile implementation. If the quality of user stories is not good, it might have an impact on multiple aspects including design, code, and goodness of test cases. Also, if the user stories are not clear enough, it will confuse the developers, designers, testers, and even customers, and hinder the development team from producing high-quality products and services. Measuring the quality of user stories is not that easy since it is not quantitative. Here is where advanced analytics techniques like text analytics can be of aid. A natural language processing algorithm can scan through the user stories in the agile tool and identify the clarity, coverage, and consistency of user stories. This will help in better estimation also as poorly written user stories can be rewritten to make them more consistent with an ideal reference. 4. Managing Technical Debt Using Database and Code Analysis Technical debt, if not managed in a timely manner, is something that will haunt the product team for a long time. Simply put, it is the price that you are willing to pay to meet the urgent demands of the customer. In a study done by McKinsey [Reclaiming Tech Equity, 2020], CIOs reported that around 20% of the budget for new product development is utilized to resolve issues related to technical debt. This translates to millions of dollars for organizations. Accumulating this debt over a long time will certainly have an impact on the stability and maintainability of the product. Analysis of databases and code to decide when to do refactoring can maintain technical debt within acceptable limits. Testing Employee Engagement and Motivation Using Behavioral Analytics One of the big reasons for organizations to adopt agile methods is its emphasis on people practices. Agile promises a highly motivated and empowered workforce. This is vital to bring in the needed innovation to products and to retain happy employees in the long run. Employee satisfaction is measured using various metrics such as Indices, Employee Engagement Score, Employee NPS, and so on. Most of these metrics are lagging indicators, which will indicate the post facto result of employee satisfaction after the measurement period. It would be beneficial for organizations and human resources function if they can know signals of satisfaction or dissatisfaction on an ongoing basis, which can be course-corrected. This is where behavioral analytics tools such as A/B testing can help to determine if employees are excited or not about changes and policies that are introduced in an agile way of working. As per the Drive theory proposed by Daniel Pink, the employee has to be in a state of flow and have intrinsic motivation to deliver the best results. This effect can be studied through analytical methods. Conclusion Data science has advanced over the last few years to deal with very sophisticated events, and it now powers many of the artificial intelligence applications that we see around us. However, the application of data science in product development — especially in an agile environment — is still minimal. If organizations can use the power of analytics to reveal hidden insights and patterns of an Agile implementation, it can bring tremendous value to teams, organizations, and ultimately customers. This is a point-of-view article, and the views and opinions expressed are personal.
I like reading books about corporate dysfunction when they come in the shape of a compelling (fictional) narrative. Business writers know how storytelling can spice up dry theory and support their argument. Patrick Lencioni’s The Five Dysfunctions of a Team and Gene Kim’s Unicorn and Phoenix projects are good examples. It works for popular science too. In Snakes in Suits, psychologist Robert Hare, a renowned authority on psychopathy, explains for a lay readership the manifestations and biological foundations of this dark human design flaw. He interweaves the science with a chilling fictional narrative of a parasitic young suit slithering his way up the corporate ladder. So, when a coworker told me the other day about an especially glib colleague who lied, cheated, charmed, and flunked his way to job security, I immediately thought: psycho! In software, any rule or recommendation, whether it’s the Law of Demeter, SOLID principles, or the Agile Manifesto is the distillation of years of experience, spirited discussion, and plenty of compromises. Observing how teams work has led us to certain recommendations that boil the specific down to the generic. Stories are a wonderful aid to explain and justify such rules because they can show how the rules were arrived at in the first place. They supply the back story that reconnects the specific back to the generic. You need these to know and respect the justifications behind a principle. It’s not enough to learn a rule by heart if you want to apply it well. Concise lists of opinionated statements make for pithy posters, but the necessary back story is missing from the text. Demeter’s Law Is Nothing Like Newton’s Some bits of the software developer’s rulebook make it into laws – well, that’s what we call them in the case of the Law of Demeter. This is doubtful at best since they’re hardly laws of nature. They are recommendations. Laws are our best efforts to describe how some part of the natural world works, and these belong to the realm of science. If the definition of natural law doesn’t fit observations, it must be amended or rejected. Rules, on the other hand, express how we want humans to behave in certain cases. Rules and laws are derived from careful observation, but rules allow for exceptions and leeway. Laws don’t. Demeter’s law is different from Newton’s in that it needs your judgment to decide when it shouldn’t apply. There’s a good reason why Donald Knuth didn’t call his highly mathematical magnum opus the science of computer programming. Still, rules about software development practices should be rooted in proper science. Any established Agile way of working (whether the original manifesto or the new Agile 2) is still an agreement between fallible humans, with all their likes and dislikes. Therefore, their rules must have a sound scientific justification, drawing from research on psychology and sociology that shows how individuals and groups actually function rather than how they should according to your biased preference. There’s no better way to expose the fallibility of our presumed failsafe recipes than by reading stories of disasters, especially when they are not fictional. The Mythical Man-Month and Dreaming in Code are humbling accounts of teams who played by the book and failed badly. The best minds in the field and their dedication to solid craftsmanship can’t save a project when reality gets the better of their ambition. The educational benefit of stories has a neurological explanation. We’re terrible at remembering random data. Any amateur musician knows that the words of a song are much easier to memorize than its chord scheme, even though it’s a fraction of the informational content – another reminder not to make simplistic comparisons between computers and the human brain. To make something stick, stories are the most natural and effective way to process and store data. The Famous Ruling of the Diluted Milk On the topic of effective memorization, allow me a little segue into the realm of ‘the’ law. As a fresh Eng. Lit. graduate planning his next move in life I took some courses in Dutch criminal law, a lifetime ago. As a student, you are supposed to know many seminal supreme court rulings, on top of all the other stuff you’re supposed to memorize. This is not as tedious as you may suspect. It's easy to presume that a judge can simply go ‘by the book’ once the facts of a case are established. Surely the legislature has expressed their intent in a sufficiently generic fashion to apply to many hypothetical circumstances and is precise enough to leave no room for differences of interpretation? The court need only rule whether the facts of the case apply to the words of the law text. It’s not always that clear cut. Sometimes the prosecutor or defendant challenges the supreme court to pass a verdict on how the law itself should be interpreted. There was the famous case (1916) of a milkman who was fined for diluting his milk (a common scam). Since it was his unwitting clerk who had sold the product, the boss (though clearly in the wrong) thought he could be let off on a technicality. He argued that the law did not demand that criminal intent be proven for minor misdemeanors (which the clerk clearly did not have) and that therefore the clerk was also guilty, merely for being the distributor of the impure product. This argument was rejected, as you may expect. But trivial though the case seems, it forced the judiciary to rethink the very notion of guilt. You can never be punished without a reasonable degree of culpability. Every law student knows the ruling of the diluted milk, the Melk en Water Arrest. I hope the relevance to this article is obvious. After 25 years I still remember several of these crucial court cases. They make the abstraction concrete. They tie together in a single story both the specific law texts, the legal concepts underpinning them, the practice of passing law, and the facts as they happened. Stories illustrate the need for compromise which is so easily forgotten. Do self-governing teams produce the best work? Well, I have stories in support and stories to the contrary. So do you, most likely. Whenever you find yourself newly in love with a tool X, language Y or pundit Z, bring yourself back to earth with a simple web search on ‘Why X/Y/Z sucks’. No Worries, We’re Only Going to the Moon and Back I’ll leave you with a story about courage, the first value of Scrum. Have you ever fixed a crucial bug prior to deployment? How did it make you feel? Not too confident, I bet. Go watch the amazing Netflix documentary Apollo 11 for some perspective. Billions of dollars were poured into the biggest and most hazardous engineering feat of all time. The possibilities for mishap that would mean certain death for the brave astronauts were too many to contemplate. Already kitted up and on their way to the launch platform, the engineers who were running final tests on the Saturn V rocket had discovered a malfunctioning fuel valve and were frantically tightening some bolts (12 minutes into the film). Not to worry, they were only going to the moon and back with the whole world watching.
Sprint Goals as the Key to Efficient Decision-Making A business is made of decisions, and what drives great decision-making is indeed the gateway to a flourishing venture. Though companies have overlooked the value brought in by the Sprint Goals, this blog here is all about giving a brief account of Sprint Goals and how we achieve success using them. Sprint Goal holds the capacity to either sustain or hinder your Sprint. Being one of the crucial components, Sprint Goal helps organizations to more successfully pivot, prioritize, and line up their tasks. With the presence of Scrum goals, it is easy for teams and stakeholders to finish the tasks that they are committed to. How? Well, the present times have a lot to offer in terms of raw data about the products and solutions. Defining this data and analyzing which one is more valuable than the other is a tough task. But, with the help of Sprint Goals, prioritization as per data’s importance is possible, which also provides for decision decentralization leading to a quick process. If you are thinking of a substitute…there isn’t any. Product teams that proceed further to the product backlog without setting the scrum goal usually have to counter challenges during Scrum implementation. How to Write Sprint Goals After comprehending the value inculcated by the sprint goals, it becomes essential to make sure they are created in the most effective way possible. Here, I am providing you with a few tips and tricks that would help you write the sprint goals that would further assist you in vision clarification, work alignment, and priorities focus. The 5 Principles to Keep in Mind: It's been said before, but it needs mentioning. Sprint goals, like all good goals, adhere to the following tips: Specific: Determine precisely what you want to accomplish, along with a realistic idea of achievements at the finish. Rather than simply stating you would like to "enhance the performance of the website," specify how and what you would like to enhance it. "Enhance on-page conversions by 15%," for instance. Quantifiable: How will you monitor processes and effectiveness? What criteria will you employ to specify completion? Not only does this assists you in determining after you've achieved your objectives, but it also sets up objective milestones, so you don't rely on your achievement from the viewpoint of one individual. Workable: Your sprint goal should really be challenging but attainable. Ensure your objectives are attainable given the available resources and time. Do not even try to cram all of the product backlog items into a single sprint. If the primary objective is too large, it may be necessary to divide it into short-term goals for distinct sprints. Relevance: How can the sprint goal relate to your corporate goals? Make absolutely sure your objectives are pertinent to your core objective and illustrate the benefit you're attempting to accomplish for your company or clients. Arrange a delivery deadline and strategize and prioritize the sprint backlog consequently. Goals with a concrete plan are simpler to achieve and guarantee that each individual is functioning at the same pace and on the same page. Check That the Sprint Goal Includes a Relevant "Why” Sprint goals highlight the sprint's intent and guide and line up your successive sprint backlog. However, if that objective is too broad or lacks a powerful linkage to the job you're performing and the quality you would like to produce, it's time to start over. Your sprint goal could perhaps explain why the work is important and link it to the significantly bigger team and organizational quest. In other instances, how will this sprint affect the company or the patrons? If your team is unable to grasp the sight of your sprint goal, or if the primary objective does not feel important or impactful, it can result in a lack of emphasis, decreased motivation, and incongruence. Establish sprint goals that spell out exactly why the sprint is crucial and how the backlog of tasks communicate and collaborate together to add value to hold your team engaged, effective, and thrilled about the job they're performing. Be Open to New Experiences The primary objective of agility is for goals to alter and for transformation to actually boost goal setting. Utilize your sprint goals as a reference point for decision-making as opposed to a straight jacket tying your team to a specific set of duties. When new data becomes available, the client does need change, or unforeseen situations spring up, correspond to your sprint goals to determine how and where to proceed, and be agile to allow for optimized synchronization with your primary targets and the significance you're attempting to convey. How to Manage Sprint Goals Handling a sprint backlog can assume to like corralling kittens at points in time. There are a plethora of tasks, obligations, and individuals to keep track of, and it's simple for stuff to get misplaced in the meander. Even if you have a straightforward sprint goal to guide your endeavors, it is beneficial to visually trace out your plans and objectives. Envisioning your backlog and sprint goals allows you and your team to take a moment to reflect and examine how your functions match together just to endorse your objectives. Steps to Achieve Sprint Goals Well before the Sprint Planning Phase, the Product Owner must begin preparing one or even more proposal Sprint Goals. This saves a significant amount of time in your Sprint Planning Stage attempting to achieve agreement on what constitutes an effective Sprint Goal. The proposal Sprint Goal should indeed be shared by the Product Owner during the initial aspect of Sprint Planning, or maybe even sequentially in advance. It is under the gamut of Product Owner to describe why this goal will provide value to customers and exactly how it fits into the long-term aspiration and strategic plan. During Sprint Planning, you can tweak and alter the Sprint Goal as you gain a better understanding of the upcoming Sprint, along with what you'll work on and how. It should be noted that the Product Owner should also receive input from the software developers to ensure for the Sprint Goal is something on which all the team members can agree. As the Product Owner, you will double-check the Sprint Goal at the conclusion of the Sprint Planning incident and ensure that the duties in your Sprint Backlog will assist you in achieving it. Ask all team members if they think the group goal is attainable. Then, reassure them that Sprint's success is dictated by the Sprint Goal. You can now add the final Sprint Goal to your task board. For instance, you could place it towards the top of your Scrum board's Sprint Backlog or Ready section. You can attribute it while conducting Daily Scrums to track progress and pinpoint roadblocks to the goal. The Final Verdict An exceptionally crafted Sprint Goal is a useful tool for the duration of your Sprint. Here's the ultimate checklist about just how impactful agile teams achieve their objectives using the Sprint Goals: Provide a route to the Product Owner as to which Product Backlog Items (PBIs) to tweak and prioritize in order to prepare for Sprint Planning. All through Sprint Planning, assist the management team in selecting PBIs for the Sprint Backlog. Interested parties should be informed about Sprint's intent. Throughout this Daily Scrum, monitor progress. Promote collaboration and team emphasis by establishing a shared, specific purpose. If you encounter major obstacles during the Sprint, shift your orientation or strategy. Ascertain what feedback and information to obtain during the Sprint in order to validate achievement in the Sprint Review. During Sprint Retrospectives, gain knowledge from its achievement or failure to enhance your upcoming Sprint. Hence speaking, we can't prepare flawlessly for the uncertain. The Sprint Goal puts the emphasis on a target we desire to acquire and gives us the leeway to make a deal of the work to get there.
If done right, retrospectives can help you inspect past actions, help adapt to future requirements and guide teams towards continuous improvement. However, organizations find it difficult to adopt the right mindset to execute retrospectives effectively. This article will help you understand what retrospectives are and provide valuable tips to make your retrospectives meaningful. This article will cover: What are retrospectives? What isn’t a retrospective? Common mistakes in retrospectives Tips to make retrospectives meaningful Incident activity timeline What Are Retrospectives? A retrospective is a structured process that typically helps you reflect on the events from past activities and set a precedent for future decisions. Retrospectives are often conducted at the end of a project/event or at a regular cadence. The aim is to give teams the opportunity to backtrack and examine their activities and plan future actions that can help achieve the desired results. It should be a blameless process where team members can share their honest feedback about what’s working for the team and what could be improved. The next step is to document the takeaways from these discussions (shortcomings, actionable items, and so on), which can be followed up in the future. An important term related to retrospectives is postmortems. Postmortems are a type of retrospective that deal with operational problems and the response to those problems. What Isn’t a Retrospective? Retrospectives are often wrongly interpreted. Here is what retrospectives are not meant to be: They are not aimed at replacing communication or action taken to fix a team or project issues at the time of occurrence. They should not be used as an excuse to complain about missed opportunities and point fingers at others. Retrospectives are not a lecture to a team about past mistakes. Instead, it is aimed at coaching or guiding a team through the defined period which helps them grow and meet the desired results. Common Mistakes in Retrospectives Not Focusing on the "Hows" Teams often make the mistake of focusing more on ‘what’ happened and ignoring asking the ‘how’ questions. “how” questions help you identify the causes of events. Knowing the cause will help you define preventative actions. A retrospective, therefore, should be treated as a process that reviews the "how" of what happened. Infrequent Postmortems Many teams are stressed with deadlines and that forces them to miss out on regular retrospectives. In some cases, retrospectives are not done at all. This makes retrospectives less effective and you might miss out on important insights in the process. When retrospectives are done in terms of postmortems, it is essential to plan and schedule retrospectives at regular intervals. There can be exceptions (false positives) when you don’t have retrospectives. Hence, there should be a criterion for retrospectives and if an incident merits a retrospective, you should have a retrospective. Oftentimes, many insights unravel once everyone is in the room. It is a habit every team should cultivate. Not Using Data Teams often do not use data to build a shared mental model of what actually happened to the team. It is good to have a shared understanding of what happened in the first place otherwise in pursuit of improvement teams may end up targeting different problems or a different set of data that could potentially hinder growth. Tips to Make Retrospectives Meaningful Neutral Facilitator Facilitators are responsible for the smooth execution of a retrospective meeting. Their job is to ensure everyone has a say in the retrospectives and to make sure all planned events are discussed in the meeting to make it more productive. Having neutral facilitators without a stake in the incident outcome helps, as they will not push the discussion in one direction or the other. This will help in rational decision-making and smooth & blameless retrospectives. Retrospective Exercises Safety checks are an important part of a retrospective. Before a team reflects on their past actions, everyone who is participating in the process should feel comfortable about sharing information. Even if one individual does not feel safe, or is hesitant to share information, it can nullify the purpose of a retrospective. A facilitator should encourage everyone to participate in the process and ensure everyone feels confident to give their input in the discussion. This helps break barriers and can make these conversations insightful. Different members attending a retrospective may come to a retrospective meeting expecting a certain outcome. For individuals, it can be about addressing a certain issue with the existing incident management process. For someone, it could be about a tool being used or a database issue. The process should have time for expectation management and certain criteria should be in place to do this effectively. Based on the needs and processes of an organization, postmortems and retrospectives can be as short as an hour or can even go on for 1-2 days. Safety checks are more suited for longer retrospectives. In some situations, an exercise called Speed Boat can be beneficial. It takes the metaphor of a boat and asks participants to think about the causes of an incident, takes their input and moves the discussion to the next participant. This exercise enables collective intelligence to be brought into play. There are many such exercises that add value to retrospectives and team building. Measuring the effectiveness of retrospectives is important. On completion of a retrospective, one participant may have more takeaways than the other. For example, after a meeting, an incident responder may have more takeaways than a software engineer or vice versa. There should be a process that not only measures how balanced the outcome of a retrospective was but it should also help set processes for future retrospectives where every participant has some takeaways. This ensures the active participation of every member, which can add value to the activity and not force it as a burden on individuals who had no takeaways from it. Healthy Communication Culture Good communication helps a team to perform in unison. Especially when the projects have longer spans, familiarity with team members serves well in achieving consistent results. The team members should feel comfortable giving and receiving feedback. Having regular team-building exercises can help team members to open up and express their ideas, and also help to have a healthy communication culture. Make Retrospectives Blameless Incidents are bound to happen. When these incidents are discussed, it is important to ensure individuals or teams are not considered as points of failure and blamed for the outcome. Traditionally, in postmortems, a key outcome has been to fix responsibility/find the responsible individual or point of failure. This results in people attending retrospectives or postmortems with a negative and defensive mindset. This could result in key information not being discovered or discussed. An idea of a blameless retrospective is more of a corrective measure where members go to a meeting with a positive attitude and the point of failure is associated more with the situation and not with people. Ask the Right Questions It's essential to ask the right questions in a retrospective. One approach is the "Three little pigs retrospective:" What is at risk of breaking? What section needs more work? What section is rock solid and can continue working well? Another approach is the "Process, People, Tools" approach. With this approach following questions should be asked, What operational or incident management process changes would have helped to prevent the incident or resolve it quicker? What behavioral change, decision, or training would have helped in incident prevention or faster resolution? If any tools had helped in a quicker resolution of incidents? Your team should be encouraged to focus not just on the current cycle, but on the broader state of the product/problem. While doing so, you should aim to find answers to the questions mentioned above and then plan the future steps accordingly. Do Not Jump to Solutions Not all retrospectives can help yield solutions to the problem at hand, especially not at the very moment you start discussing it. You can try out different techniques to reach a solution. Some common examples include: 5 whys: An iterative technique to explore the cause-and-effect relationships underlying a particular problem Impact mapping: Helps teams to map the effects of their work on an organization's broader processes and outcomes Fishbone diagrams: These are causal effect diagrams that help in root cause analysis and show other potential causes of a specific event or action There are various solutions/techniques that could help solve problems specific to your team. However, it is important to understand the issue and find different ways to address and analyze these situations. Incident Activity Timeline An Incident Activity Timeline can serve as a real-time chain of incident resolution activity. This timeline is very helpful in understanding how an incident is addressed from detection to resolution. Having a feature that records incident activity can give you valuable insights. Conclusion Incident response teams need to be prepared to handle unplanned incidents, so they can help save time, prevent frustration, and reduce refactoring in the long run. Having effective retrospective processes in place can help teams identify what went wrong in the past and plan for incidents that can arise in the near future.
There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. For example, what if there is no Sprint Goal — Sprint after Sprint? What if the Scrum team is always only working on a random assortment of work items that seem to be the most pressing at the moment of the Sprint Planning? Join me and delve into the importance of the Sprint Goal for meaningful work as a Scrum team in less than two minutes. The Purpose of the Sprint Goal According to the Scrum Guide According to the Scrum Guide, the Sprint Goal serves the following purpose: The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives. The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.” Source: Scrum Guide 2020. The Sprint Goal is many things to the Scrum team: a beacon showing how to create more value for customers and the organization, a rallying cry to collaborate as a team, and a measure to figure out whether the Sprint was successful. Successfully identifying the Sprint Goal is thus a mission-critical step for every Scrum team. The Sprint Goal turns a Sprint into a team endeavor founded on cohesion, collaboration, and self-management. Anything less is merely toiling on an “assembly line,” probably leading to becoming a feature factory. Reasons for Having No Sprint Goal In my experience, there are three main reasons why a Scrum team is not capable of creating a Sprint Goal during the Sprint Planning: Focusing on getting the most pressing work done: The Product Owner proposes a direction that resembles a random assortment of tasks, providing no cohesion: “We need to work on 123, 426, 637, 845, and 343.” (Probably, the Scrum team does not have a Product Goal; it is all about business-as-usual and keeping the ship afloat. On the other hand, maybe, the product is in such bad shape that it is all about fire-fighting. Whatever the reason, these use-cases are less suited for Scrum as product discovery and delivery framework.) Last minute Product Backlog: The Product Owner and the rest of the Scrum team do not invest adequately in Product Backlog creation and refinement. Consequently, they rush to fill the Product Backlog immediately before the Sprint Planning to ensure there is enough work for the upcoming Sprint. (Garbage in, garbage out. This approach points to a fundamental misunderstanding or ignorance regarding the purpose of Scrum: when to use it, and what Scrum’s critical success factors creating value for everyone involved are.) Someone imposes a Sprint Goal: The Scrum team does not collectively decide on the Sprint Goal, but an individual imposes their idea of a Sprint Goal upon the team; for example, an outside stakeholder. (This may be an edge case. However, it is equally defying Scrum’s first principles, as Scrum is a framework based on the pull, not the push. The Scrum team is not an internal agency but a self-managing entity tasked with solving customer problems.) The Consequences: If not identifying a Sprint Goal is the natural way of finishing your Sprint Planning, you probably have never embraced Scrum as a framework in the first place. Or, you have outlived the usefulness of Scrum as a product development framework. In the latter case, 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 aiming to accomplish the Product Goal, composing and ordering the Product Backlog appropriately. The Solution: Go back to the basics of the framework by pursuing the original goal the Sprint Planning: Align the Developers and the Product Owner on what to build next, delivering the highest possible value to customers. First, the Product Owner points to the team’s Product Goal and introduces the business objective of the upcoming Sprint. The Scrum Team then collaboratively creates a Sprint Goal, considering who is available and the target the team shall accomplish. Next, the Developers forecast the work required to achieve the Sprint Goal by picking the right items from the Product Backlog and transferring them to the Sprint Backlog. Also, the Developers need to create a plan on how to accomplish their forecast. While this sounds straightforward, it may take time to get there, starting with creating a Product Goal and subsequently the corresponding Product Backlog as pre-requisites for Sprint Goals. No one said getting Scrum up and running for your team would be simple. Conclusion We do not get paid to practice Scrum but solve our customers’ problems within the given constraints while contributing to the organization’s sustainability. However, if you conclude that Scrum can support your team on that path, embrace Scrum’s first principles and checks & balances. For a Scrum team to be successful, it needs a Sprint Goal. Moreover, creating the Sprint Goal is a collaborative exercise of the complete Scrum team. If you cannot identify unifying goals, maybe Scrum is not for you. Have you encountered Scrum teams that try working without Sprint Goals? Please share your learnings with us in the comments.
Jasper Sprengers
senior developer,
Team Rockstars IT
Alireza Chegini
DevOps Architect / Azure Specialist,
Smartwyre
Dr. Srijith Sreenivasan
Director,
Schneider Electric
Martin Fowler
ABOUT US
ADVERTISE
CONTRIBUTE ON DZONE
LEGAL
CONTACT US
Let's be friends:
DZone.com is powered by
