Agile frameworks, like Scrum, are generally easy to understand. With many teams where we have taught and coached, there are some common mindset and practice tweaks that make a real difference to productivity. Here's our top 3 easy fixes to boost the level of productivity of your agile implementation.
1. Establish Team Norms - When teams first form as new teams or when the composition of a team changes mid-stream, many teams skip this step of establishing (or re-establishing) Team Norms. Without this critical team discussion, team members have to discover through time, usually too much time, what expectations they have from each other on how to work and interact as a team. This usually leads to passive tolerance of bad team behaviors and formation of cliches (sub-teams) gossiping about the dysfunctions in the other team members. Alternatively, make sure to take a break from delivery and hold a 2-3 hour Team Norms session to air these expectations. The Team Norms session should talk about values that team members hold dearly, expectations on logistics for how the team operates, and a solid airing of how the team wants to deal with conflict. You should expect that these discussions will be challenging. However, on the other side of establishing Team Norms, you will have a team that has clarity on how to work together as a whole team. With that clarity, you will find that the level of team dysfunction will be significantly reduced, and conversely, the productivity of the team will rise and a foundation for continuous improvement in the team is now possible.
2. Measure and drive your "Ready-State" backlog - Agile is not just about the software development and testing. When Agile is really working well, it is about the flow of product ideas moving rapidly to production-ready, customer-consumable product updates. One very common productivity-killer in Agile teams is not having enough well understood, "groomed" backlog when iterations / Sprints start. This lack of "ready-state" backlog leads to teams struggling during planning (i.e., Sprint Planning) to know what they are supposed to build and how to build it. Half-baked planning leads to ineffective iteration execution and often with product that does not meet the customer need, therefore leading to re-work. There are 3 easy steps to inject a new level of discipline into your team to get a solid ready-state backlog. First, establish a clear Definition of Ready - which criteria should backlog items meet in order to be declared "Ready". Second, define a backlog grooming / refinement flow with clarity of roles / responsibilities for moving backlog items from "Grooming" state (i.e., backlog item needs additional refinement) to "Groomed" (i.e., backlog item is teed up for final refinement by the whole team) to "Ready" (i.e., the whole team has declared that the backlog item meets the Definition of Ready). Third, the Backlog / Product Owner should report regularly in daily standups the depth of "ready-state" backlog. The depth should be measured in how many iterations / Sprints worth of backlog are in the Ready state. If the "ready-state well" is getting dry (below one iteration's worth), this should be a signal to the team to jump into re-filling the well and put more energy into grooming additional backlog. With a solid ready-state backlog, teams will find that planning will be more effective and that iteration execution will be clearly aimed at the target established from planning. With clear goals, the team will be wildly more productive towards achieving real customer-valuable delivery.
3. Take retrospectives seriously - Too often, teams take the "check the box" approach to retrospectives. Given retrospectives are a defined part of Agile frameworks like Scrum, teams almost feel forced into holding retrospectives and cannot wait for this meeting to be done and over. The skepticism or boredom with retrospectives are usually associated with one of a few causes - no real action taken from the retros or re-using the same format for retros over and over. For teams that take retrospectives seriously, they are the critical enabler for a Culture of Continuous Improvement. Teams that embody a real Culture of Continuous Improvement have no ceiling on how productive they can become. There are two easy steps to make retrospectives impactful for your team's productivity. First, establish as part of your Team Norms (we talked about this above) a commitment to hold the team accountable for identifying and following through on at least 1 improvement from each retrospective. You can build this accountability into your retros by starting each retrospective with a look back on the improvement commitment made in the last iteration and having a transparent discussion on how the team did on acting on that improvement. Second, if retros are getting stale and boring, spend some time to read Agile Retrospectives (Derby / Larsen), understand the suggested structure for conducting retros and look for new ideas for different activities to "mix it up" at your retros. The structure suggests conducting a Closing to reflect on the retrospective itself - a "retro on the retro". This might seem like overkill, but you will quickly find the approach and activities for retros that really resonate with the team and produce valuable improvements.
These 3 fixes can really get your team to the next level of productivity. So, step back and take a critical view if any "tune ups" could be valuable for your team.
