Yosef Falsafi
Posted on Aug 03, 2021
Preventing Team Level Mistakes in Following Agile
In the previous blog, I shared organization level mistakes in implementing Agile. In the following paragraphs, I will focus on tips that help Agile teams prevent common mistakes in following the Scrum methodology, one of the most popular methodologies within the Agile framework. In my experience, I have seen some teams going through the Scrum ceremonies, but follow the same Waterfall approach and call it Agile. Such examples are common enough in the industry that some companies are referred to as “companies that have become agile in name only.” Scrum ceremonies are essential; however, not sufficient to be Agile. Tips below will help teams follow Scrum to the fullest and prevent repeating Waterfall and falsely calling it Agile.
1. Use cross-functional teams and not silos
Agile is based on the collaboration of experts from different areas. The goal of each cross-functional team is to drive collaboration, and each cross-functional team “should contain the full set of experts needed to deliver a great product.”
Some common team dynamics that prevent the formation of cross-functional teams or reduces their effectiveness include:
a) Experts are grouped and collaborate only in their functional teams and there are silos between different functions (e.g. development team, QA team, UX team exists, but there is no dedicated team composed of resources from these areas to collaborate on the project).
b) Teams using tools that prevent collaboration between experts from different functions.
c) Functional managers have conflicting goals. This conflict impacts the cross-functional teams in prioritizing work.
d) Politics and pressure to get promoted or retain one’s job are always in conflict with collaboration.
2. Release something every sprint
Agile and specifically Scrum is a feedback-enabled framework. The purpose of dividing the project into structured time-boxed intervals (sprints) is to deliver something to the end-user/customer at the end of each sprint and use the customer feedback to iterate accordingly. Please note that “customer” in this context could be an external customer or an internal customer within the organization who will use the outcome of the project. Harvard Business Review remarks that the Agile approach to “building software (even internal-use software) should be squarely customer-centric.” This description applies to Agile projects in other industries, as long as Agile is a good fit. However, some teams work on work packages that won’t lead to the release of a presentable feature within each sprint. This approach does not achieve a good enough outcome for the sprint to be presented to the customer. Thus, this approach prevents the team from using customer’s feedback. Using customer feedback and iterating accordingly is one of the main benefits of Scrum. Therefore, not releasing a presentable outcome to the customer at the end of each sprint defeats the purpose of Scrum methodology.
3. Release something that is both developed and tested
Some teams fully develop a complete feature during the sprint; however, they don’t fully test it. This approach has a significant drawback. The lag between development and testing keeps growing over time and this results in a large amount of QA debt. By the time the QA team raises the defects and bugs to the development team, the software developers may have forgotten about the context and details related to the defect. This reduces the efficiency and agility of the team in responding to the defects. Moreover, this keeps distracting the development team concerning the development tasks they are working on.
4. Utilize Retrospective feedback in an optimized manner
In addition to end-user/customer feedback, another benefit of Scrum is to enable teams to continuously provide feedback for themselves and improve. This is done as part of the Retrospective ceremonies which occur toward the end of each sprint. Some teams may treat the Retrospective sessions as an opportunity to blame their peers. This approach conflicts with the purpose of the Retrospective. The point of Retrospective sessions is to discuss what went well for the team and what the team could have done better. Starting a blame game deviates the focus from practices and areas of improvement to individuals. The focus should be a Retrospective on the team, and not on individuals. “Studies by the MIT Center for Collective Intelligence and others show that although the intelligence of individuals affects team performance, the team’s collective intelligence is even more important. It’s also far easier to change. Agile teams use process facilitators to continually improve their collective intelligence.” Hence it is crucially important to avoid blaming peers and it is essential to focus on the team as opposed to individuals. Moreover, some individuals within the team may treat the feedback as a sign of offense. This behavior and defensiveness reduce the team's ability to provide holistic feedback which reduces the usefulness of Retrospectives. When assembling the cross-functional teams, it is essential to ensure all team members are aligned on the purpose of Retrospective, understand peer feedback is not meant to offend any specific person, and defensiveness is a barrier to iterative team self-improvement.
Now What
Thankfully, there are some simple steps you can take to avoid the most common agile mistakes. I
f
you want to make sure that your project is nothing but a
success:
About the Author: Yosef Falsafi is an experienced Scrum Maser and Project Manager. Yosef’s passion is helping companies better manage their journey from
Waterfall to Agile methodology. Equipped with PMP, CSM, Lean Greenbelt as well as an MBA degree, Yosef looks at firms’ project management practices from a holistic angle to optimize diverse organizational elements the project needs in order to create value.