High Performing Agile Teams
One of the most rewarding aspects of consulting is being able to share collective experiences with my clients. By collective experiences I’m referring to all of them, both great and not so great. Creating and nurturing high performing agile teams has been an educational process for me over the years with a mixture of outcomes. Reflecting over all of them, I’ll do my best to share what I believe have been the largest factors to getting velocity numbers up and consistent. In addition I reached out to my colleague Margy Dessypris Thomas-a well respected agile coach at Anthem-to compare notes. I’ll intersperse her thoughts throughout this article.
Team Composition
An ideal team is one that has all the skill sets necessary to do the work. Simple right? Not really. Depending on how many people with specific skill sets there are, as the team learns to deliver faster you’ll soon start to see barriers emerge (think engine “governor”). Teams composed of generalized skill sets (e.g., the “Full Stack” Developer) tend to perform better over time and will experience fewer bottlenecks. With the rate of change today in the technology field, finding generalists is becoming more and more challenging.
While it’s important to have all the skill sets within a team, it’s equally important to have the right number of people with those skill sets. Putting a team together for an engagement is a combination of skill sets and overall experience level, budgetary concerns, scope and schedule. In other words, it’s not as easy as it could/should be.
Margy, what do you think about team composition?
“Ideal teams — perfect is the enemy of good. Can an ideal team exist? Maybe if they all have a learning mindset?
The Full stack development team means that they may have started as individuals with specific skill sets, but they took time to partner and share knowledge. They learned how to swarm on their work. And the T-shaped skill sets transformed into M-shaped skill sets. Putting together a team from scratch is hard, and they need more than just three sprints to become high performing. In three sprints they can start to move past a forming stage. Within some further time and evolution, they can usually move into the storming phase, and will deal with their pain points and slowdowns directly. With the full support of management/leadership, once a team works past their issues, the norming stage is apparent. Teams are likely to spend more significant time in this phase, but eventually, once they have tackled some big issues, and with management’s continued support, they can achieve a performant phase.”
Margy touches on another one of those points I’ve forgotten about over time. In all cases where my teams have achieved high performing status, we had the undying support of Leadership. My time at Virginia DMV saw full support from Angelisa Jennings as well as our program manager Jen Peters (RIP). If the team’s completion percentage was below 100 for a sprint, neither Angelisa nor Jen brought the hammer down. Rather, they asked the questions, What’s your plan to course correct” and “How can we help”.
Sprint Zero
Sprint 0 is a team’s most important sprint and quite often it is not perceived to have as much importance as it does. In the Forming phase of a team (remember Forming, Storming, Norming and Performing?) the “Definition of Done” (DOD) becomes a rallying point. It creates the mindset for a newly formed team in terms of what good looks like. Every story the team will work on needs to meet DOD.
Definition of Done
On one of the better teams I’ve worked with, our DOD included passing Unit Tests, Automation Tests and we measured cyclomatic complexity to improve the maintainability of our code over time.
By defining DOD, not only did we describe the quality goal we expected on every story, we also defined our tasks. For automation tests to pass, we needed the actual automation tests. For unit tests to pass, they needed to be written.
Margy, is there anything else you’d add here?
“…the DOR becomes another key policy to accept work. — These are team norms that help them move along to a performant stage.”
DOD is important for a team to understand when a story is complete. On the intake side, Definition of Ready (DOR) becomes important as well. High performing teams learn over time what good looks like, both when evaluating work for a completed user story and for evaluating a story for intake into a sprint. DOD is important for a team to understand when a story is complete. On the intake side, Definition of Ready (DOR) becomes important as well. High performing teams learn, over time, what good looks like, both when evaluating work for a completed user story, and for evaluating a story for intake into a sprint. Margy adds in that both DOR and DOD are artifacts that fall under the category of Team Norms.
Team Norms are often overlooked however, they shouldn’t be. For a team to achieve Norming phase, they need a way to determine when they have moved past Storming. Having an objective measure is best in this case and this is where documented Team Norms come into play. Arguably, the Storming phase for a team is more or less a refinement of Team Norms. For example, a team with a high quality bar might state that 100% code coverage is required for DOD (hopefully, we all know that 100% code coverage is a challenging undertaking). While storming, team members may, during Retrospectives, start arguing that 100% code coverage is unrealistic. Eventually, the team “normalizes” on 60% code coverage focusing on 100% code coverage for critical code sections.
Capacity Planning V Story Points
Many organizations continue to use hours to estimate work in a sprint. On the surface, it makes sense. If I have 2 engineers on a project and they estimate their tasks on stories such that they have allocated 8 hours per day per person over a 2 week period then I have defined the scope for the sprint as well as the amount of work both engineers can accomplish. Unfortunately, what I’ve also done is I’ve micromanaged my developers. For them to plan in this manner, they would have to commit to each story’s tasks. Each story could therefore be broken down into a set of tasks (back to DOD).
Write the code — 4 hours (Both engineers, 2 hrs each)
Unit tests — 2 hours (Back end engineer)
Automation tests — 4 hours (Quality engineer)
Code Review-30 minutes (Team)
Deploy to X — 15 minutes (Team)
If we use task based time estimation as a means by which to plan capacity for a team, planning devolves into building a project plan for each sprint with WBS (Work Breakdown Structures). If we were to use this approach, someone would need to dust off their Microsoft Project app and put each story in, with their team members.
Another way we may use hours is to sum up the total hours available across all team members and have the team members estimate the total hours needed to complete a story. This works just fine if your team is composed of generalists or equal numbers of specialists. As previously mentioned, it’s very challenging to find the former these days and the latter may be too costly. At the end of the day, the team shouldn’t be committing to hours. They need to be committed to completing stories. As a colleague of mine once told me, “Have the team commit to stories. It doesn’t matter how many hours it takes to finish them”. Interestingly, this concept ties in very nicely with predictable costing. You can read more about this model here.
When teams use story points to estimate, the entire team needs to agree to story size. Something that’s relatively easy to build but really hard to test may have the same story size as something that’s hard to build and easy to test. Story points are closely tied to team members as well. A story that’s sized as a 3 for one team may be a 1 or an 8 for another team. For PMOs this means that we can’t report up and say that Team A has more throughput than Team B because they commit to and deliver a higher number of story points.
Margy, is there anything you’d add here?
“Every team needs to manage their capacity. How they choose to do it is up to them. Organizations struggle with the hours v points discussion.
Points should be a relative show of complexity and effort and each team has to learn what the points mean for them. When we want to compare teams, because that’s what management is apt to do, we do so in a normalized fashion by looking at percent, not the raw point values. We want to help the teams get to a place where they hover around a 100% predictability. The velocity over time for a team can increase as they move through storming to norming to performing phases, and we’ll see the velocity increase over time. But still, the predictability of the team has to be stable, so by looking at the delivered/committed points — we get a percentage — and we want to see that approach 100% and stay close to 100%. It’s okay to have an occasional dip because teams will have new challenges and lessons to learn, but their ability to recover shows how well they function and how quickly they learn from the failures.
For the forming team, I use a 6 hour per day calculation. There’s research that shows we don’t produce 8 hours of work within in a sprint. It’s not feasible to expect that. Conversation has to take place to understand what needs to be done, to coordinate the work, to share and learn together. Hours are appropriate for the task level planning that comes along with stories. Stories are pointed. Hours are summarized based on the planned tasks. And it’s okay to add tasks we didn’t expect along the way.”
In 2001, Ken Schwaber and Mike Beedle wrote what is often referred to as the seminal Scrum book entitled “Agile Software Development with Scrum”. I lost this book a while back and amazingly, I found it available on Amazon and immediately secured my second copy of it. 20 years ago (that’s a long time in our engineering discipline!) someone already figured out that we don’t produce 8 hours of work a day (in an 8 hour day). We are likely to produce, at most, 6 hours of “work”. As Margy points out, teams need time to collaborate. When I walk into a team room and I hear passionate discussion (often more than one passionate conversation is happening), I get excited. To me, this implies that the team is coordinating, solving problems and in some cases just taking a moment to de-stress.
Shorten the 4 Phases
All teams go through forming, storming, norming and performing. One way to shorten the time needed for a new team to go through the 4 phases is to build teams based on organizations that foster supportive cultures. If you’re an organization looking for vendors who can help you get work done, make sure their culture is part of their pitch deck. Further, make sure it aligns well to fostering collaboration and high trust. Explore your own culture as well. Does it create an atmosphere where everyone feels included and feels free to voice their opinion? Do your people frequently participate in passionate discussions around how best to solve problems? If the answer is No to either of these questions then you may find it very challenging to create high performing teams.
Guidance
- Coach continuously to overcome the 5 Dysfunctions
- Respect Agile Ceremonies
- Define Definition of Done and all Team Norms during Sprint 0
- Use story points to estimate work
- If you don’t see teamwork, have the entire team work on 1 story at a time (swarm)
- Use retrospectives meaningfully
- Fail fast
- Borrow from Extreme Programming (XP)
#1 should be something I don’t have to mention however it’s necessary given the cultures of some of the organizations I’ve encountered over the years. The cornerstone of a high performing team is founded on trust. Without trust, a team doesn’t have the solid foundation necessary to foster honest collaboration. Without either, you’ll never get your team out of the Forming phase. I encourage you to spend the money and buy the book. You may, like myself, need to read that last few pages at least 3 times to really “get it”.
#2 creates a consistent routine. Context switching remains the bane of most engineers’ existence. Creating a consistent routine and sticking to it allows team members to mentally plan for switching from head’s down work.
Margy, do you have any thoughts to add?
…make sure they are crisp, meaningful, productive, and engaging for all team members. Do not skip a ceremony.
Lyssa Adkins-a well known and respected agile coach-carried a little bell with her. She took “crisp” to heart and timed everything. During planning poker, a team would be given 1 minute to lay their first story point card down. An additional minute per team member was used to voice their reasoning behind their point selection. A final amount of time was attributed to agreeing on a story size. Anyone attempting to go over their time limit got “the bell” (maybe she should have hosted some recent presidential debates).
#3 as previously mentioned, serves as the quality bar every team member needs to meet when they are working on stories. My favorite question I was asked by a former colleague when I had quality issues was “So is this story Done or is it DONE Done?” I can’t stress how important Team Norms are. They are the measuring stick used to see if a team has achieved “Norming”.
#4 may be a shift for many organizations that estimate hours and it is invaluable to foster team commitment. Individuals don’t commit to stories. Teams commit to stories. Trust that your team will deliver a story if they commit to it. Chances are, they’ll work past the “fab 40” a bunch of times until they dial their velocity in.
#5 above sounds counter-productive right? It’s not. Intentionally having the team work on one story at a time fosters collaboration, allows the team to self organize and shortens the time necessary for the team to get through the 4 phases. It should be noted that every team has to go through the 4 phases. If a team composition changes, the team has to go through those phases again. Why? Because we’re still animals and thus, we have to learn to work as a pack (or tribe). We have to learn how to overcome the desire to have alphas and instead have team members. Margy refers to this as swarming. This is about helping teams learn to swarm on stories.
I typically keep this one in my back pocket for occasions where I observe that team members are functioning in silos. For team compositions where there are a higher number of junior engineers, this is a good practice to use. For most undergraduate programs, group projects are graded on completion, not how well the team worked together. Junior engineers need to practice working as a team.
Margy, any additional thoughts here you’d like to share?
“Encourage time for swarming — this is a key aspect of XP and paired programming. Without giving time to the team to learn how to do this well, the collaboration and the quality will not serve the team later as they become more and more productive.”
#6 is of equal importance. Retrospectives are the team’s opportunity to celebrate what went right and to course correct for what didn’t go so well. If a team committed to 25 story points and only delivered 19, it’s an opportunity to reflect and determine an action plan to avoid under-delivering next sprint. If they committed to 25 and delivered 50 then it’s an opportunity to learn why. I’ve seen teams reflect and state that they oversized stories and others found better ways to do their work. Watch out for team feedback such as “we have great collaboration”. This is a warning sign that your team members don’t feel comfortable giving you meaningful feedback. If you do see this, explore it with the team. Ask the team to give examples of how they had great collaboration.
#7 is a mindset and it has to be supported top down. If we treat each failure as a disaster, we’ll eventually shut down the creative aspect of software craftsmanship. Team members need to be able to experiment and need the support to innovate. As an example, while working at Virginia DMV, we used roughly 250 BizTalk Rules Engine rules. These rules, when applied, raised the priority of incoming messages and the validated the messages for completeness. If incomplete, the messages needed to be manually validated. If complete, the messages are automatically moved into the complete phase. We struggled for months with the rules and for a year they weren’t completed. Why? Because they were a pain to test. The team decided to spend some time writing a test harness to be able to test each rule individually. Through trial and error, we finally arrived at a suitable test harness that allowed us to thoroughly test the rules and to automate their testing. So, rather than treating failure as a disaster, treat it as a learning experience.
#8 is a blog post unto itself but I’ll highlight some of the things I’ve seen especially useful for high performing teams. Breaking a build is one of those fail fast things that happens quite a bit. Broken builds shut down the whole team so it only makes sense to allow the whole team to help fix the build. Have the team stop working and focus on getting the build green again. Use pair programming as a learning and development tool and to help with teaching swarming. A team where all of its team members can perform all the tasks will, over time, surpass high performing teams of specialists.
Understand as well that teams take time to become high performing. Empower them, allow them to self organize, coach them and cheer for them and they will reward you with high quality output and consistent throughput.
