Building Unity
Having a team that can work together toward a common goal is important in any software development methodology, but it is arguably more important in Agile software development: because the team makes a commitment every Sprint, because the teams tend to stay together, and because of the importance of communication on an Agile team. Sometimes team members naturally gel and other times it takes time and effort. The unity comes in meeting the team’s Sprint commitment and building working software. This means trusting each person on the team will do his or her part. It means swarming to help each other when someone is blocked. It means doing whatever it takes, as one team, to get the job done.
Real-Life Stories
Story 1: Where Is Everyone?
The best Agile teams I’ve been on are ones where everyone on the team worked together to achieve a common goal. Every Sprint the team did whatever it took to meet the Sprint commitment. Everyone showed up, day after day, even when some of those days were very long. But on one team I saw the opposite. Granted, each team is different and what works on one team might not work on another team. But on this one team things didn’t work all that well. People would completely skip the Daily Stand-up meeting. Some people would completely disappear for days, with no e-mails or any kind of communication. When this became a common occurrence, the cadence of the team really suffered, as you might expect it would. There didn’t seem to be a sense of unity. It felt more like ten team members doing their own thing. Some of this occurred because the team lacked a dedicated Scrum Master, and because the team lead was playing that role and he simply did not have the bandwidth to do both roles 100% of the time.
Thoughts
I’m not saying that there is a “right” or “wrong” way for any team to work together, but unity is important on an Agile team. In the case in Story 1, we had a great manager who was a macro manager and very laid back. That was great, but in this case I think some intervention could have helped the team: finding out why team members were not showing up to meetings, impressing upon team members the importance of the Scrum meetings, and impressing upon them the importance of meeting commitments.
The other thing that I’ve seen help is to have someone dedicated 100% as the Scrum Master. This helps in a few ways: it provides consistency, removes roadblocks, and keeps everyone focused on meeting the Sprint commitment.
Scrum relies heavily on peer pressure. The Daily Stand-up is critical because everyone has to explain what he or she is working on; there is no hiding. You can’t claim a great status every day and then not meet your commitment at the end of the Sprint. A lot of pressure is on team members to deliver their share of the point commitment. If a team member is not meeting her commitment, and it is a constant issue, then the other team members should start complaining (either in Retrospective meetings or by voicing concerns privately to the manager).
One could argue that opposed to Waterfall or RUP, which might have a lot of pressure at the end of the project, Agile has a constant, steady flow of pressure. Instead of being a few months of long hours and stress at the end of a project, it is in two-week bursts. On large projects that last for over six months, this pressure can take its toll. It can lead to things that disrupt the unity (either on a team or across multiple teams).
On one such project I saw how pressure affected people, and how their resulting behavior really killed any sense of unity on the teams. For example, I saw a manager yell at a person in a meeting and storm off. The shock and sense of “what the hell just happened” was palpable in the room. It helped set a negative tone that would last to the end of the project. In another example, one of the analysts on the project yelled at one of the tech leads because something was broken and she wanted it fixed “right now.” The bottom line is, treating people as professionals and with respect should be a given.
Thoughts
There’s not much to say about Story 2. Things get heated sometimes on projects. But regardless of using Agile or not, treating people with respect is always important. Long after the project ends, you still need to work with these people, so keep that in mind before losing your temper. Reputations will live a lot longer than any project.
In Agile, where communication is so critical, creating any kind of friction between the Scrum team and the business can really be harmful.
Story 3: Burning Out a Team
Another real-life example is having to stay up until 2 a.m. on the last day of the Sprint to close 1 extra point. How does this make sense? This happened on multiple occasions on one project. The manager was adamant that we meet our point commitment. While meeting a commitment is important, his reasons were not particularly valid. His main concern was that our team not “look bad” compared to other teams on the project. I’ve talked about comparing teams in Chapter 7, Story 2, and why it is a bad idea. Not surprisingly, the amount of turnover on this team was high. By the end of the project, hardly any of the original team members remained; I think 1 original person was left and something like eight people had quit the team. The effect on the team, in terms of a cadence and unity, was very evident.
Thoughts
So is burning out your team for 1 or 2 points advisable (when the Sprint commitment is, say, 15 points)? In my opinion the answer is a resounding “no.” In the grand scheme of things, the points will balance out. I am not saying that if a team consistently falls short, there should not be a penalty. I’m talking about when a team that typically meets or exceeds its commitment is forced (and I do mean forced) to work crazy hours just to not miss a point or two in a given Sprint.
I think the key is being realistic: missing a Sprint commitment by a point here and there won’t jeopardize a project. Just make it clear to the team members that if they miss a Sprint commitment by 2 points, those 2 points need to be made up before the end of the project. On a sustainment team, this is less of an issue, especially if you are using Kanban. As mentioned in other parts of this book, team members should be allowed to say “OK, we missed the commitment and we will make it up next Sprint.”
Story 4: Give Time to Learn New Things
Another way confidence is eroded on teams is when developers don’t believe their managers really understand the core principles of Agile. As I’ve talked about in other chapters, this is not a requirement if other things are in place, like an Agile Coach, a CSM, or training. This was the case on one such team I was on at a retail company. The organization was transitioning to Agile and several members of the leadership had become CSMs. But when talking about things like CI and cross-functional teams, it seemed that these leaders didn’t really have much knowledge. That is not necessarily a bad thing unless those are the same people who are supposed to be teaching everyone else about Agile.
People are busy, especially managers of development teams. But if they are leading the transition to Agile, it is crucial that they have some basic understanding of what Agile is all about. If they don’t have the time to learn about Agile, that is fine, but at least bring in an Agile Coach or empower your team members to learn Agile. I’ve seen that developers who are new to Agile are eager to learn Agile and try new things, so use that energy and enthusiasm to better your team. Give your team members a few hours a week to read articles on Scrum, get a book on starting to use Scrum, find the experts in the field and start following their blogs, and so on. The members of the team can bring this knowledge back to the team and help train others. As the team learns Agile together, team morale will build and the team will understand why unity is important.
Thoughts
I’m not saying that a manager needs to be an expert at Agile or a CSM to manage Scrum teams. I think it is good, of course, but not required. But if managers are not experienced using Agile, then how can they help guide their teams? How can they help their teams improve and help put teams back on the right path when they start going in the wrong direction? One solution is to have an Agile Coach come in. Another solution is to bring in a few CSMs (if you are following Scrum). Learn from these coaches and CSMs who have experience in the field. Let them help you learn from others’ mistakes.
The other thing I think is important is to encourage learning and trying new things. As a manager, demonstrate to your Agile teams that you are taking the time to improve your knowledge of Agile best practices, and so on. Encourage your team members to read articles and books and then bring that knowledge back to the team.
If you are not going to have an Agile Coach or CSM, then offer training to some of the members on the Agile teams. Again, let them bring that knowledge back to the team. From there you can try different things and should constantly be improving by reflecting on each Sprint. This way you have a good foundation on which to build the success of your Agile team.
One of the best examples of unity I’ve seen occurred while I was on a team where the organization was adopting Agile and the Scrum team was eager to learn Agile. The team I was on consisted of mostly senior developers and only a few had had any exposure to Agile. But the team members were very eager to try Agile. Everyone on the team worked hard to meet each Sprint commitment. We all worked very closely together and would swarm on issues that were blocking anyone on the team.
On this team we also had a concept which seemed pretty unique and was a result of the way teams were structured at this particular organization. Like other organizations I’ve been at, this organization separated developers by skill sets. We had some developers who were web developers and others who were server-side developers. We paired one web developer and one server-side developer to form a “teamlet.” Together a teamlet would work on a User Story. They would create the subtasks, discuss how best to tackle the work, and then work together to get the story completed. These developers counted on one another and that made each not want to let the other developer down. So we had a level of unity at the developer level and then we also had unity on the team level.
Thoughts
The idea of unity across the entire Agile development team is important, but being able to get that at a micro level was something that really worked for that particular team. I find as a developer that focus on collaboration in Agile is one of the most rewarding aspects of using that particular software development methodology. Partnering on User Stories with other developers was very satisfying, and I think it made for a better work environment and better-quality software. This can be accomplished even on teams that don’t group developers by skill sets.
Try having multiple developers work on a User Story together. They can create the sub-tasks and divide the work as they best see fit. Contrast that with having a single developer working on a User Story (regardless of size) and see which works better for your team.
Story 6: All Teams Are Not the Same
While not specific to Agile software development, I think having team members who “gel” is more important for Agile teams than for teams using other types of software development methodologies. One of the best Agile teams I’ve ever worked on was cross-functional. The team members really respected each other, worked really well together, and complemented each other’s skill sets. We each knew the others’ capabilities, we swarmed on issues, and we were as close to self-organizing as I’ve seen. This team was very productive, and not surprisingly, the team manager loved to tout our success. As a new project spun up, I was asked to teach other teams “the way we did it.” I worked with some other teams to show them how our team worked with the business, how we ran our meetings, and how we were able to have a good, sustainable cadence.
Management thought that they could clone the success of this team simply by forming new teams with the same number of web developers, engineers, and so on, and have the new teams follow the same processes. But it was not too long after this project started that it was clear that it was not that easy. These new teams struggled to work together in this new way. What made it worse was the fact that when these teams did not become as productive as the team I was on, management was not happy. Not surprisingly, these teams felt the pressure and quickly became frustrated because they felt they were unfairly being compared to the other team—and they were right.
Thoughts
At the beginning of the project discussed in Story 6, I must admit even I felt that we could mimic the success of the team I was on. I had read about the “hidden hand of management” on Agile teams and knew that you can’t just put any group of people together on an Agile team and expect it to work. It takes time and adjustments (sometimes even of team members) to make a team really good. But after the experience in Story 6, what became clear is that there is a huge difference between learning lessons from other teams vs. reproducing the exact chemistry of a team.
So, the bottom line is to learn lessons from other teams. What have they seen go well? What have been their pain points? But teams don’t need to adopt the same culture. As I’ve discussed in Chapters 7, 8, and 18, comparing team velocities is not a good idea. So don’t set up teams for failure by saying “do things like that other team” and just expect to get the same results.
In comparison to some of the experiences I’ve discussed in other stories, I’ve been on teams where the team really knew how to build on its success. On one team in particular, we had a team rule about celebrating success whenever the team would meet or exceed its commitment. When we did not meet our commitment, we really felt bad. We all felt like we needed to try harder the next time. It made the next Sprint that much sweeter when we did meet our commitment. It was not pressure by management but the desire of the team to do our best. We would have our team celebrations during business hours (e.g., leaving early on a Friday and going out to a restaurant, or the like). This not only made the team work harder but kept morale high and showed the team its members were appreciated.
Thoughts
I have been on projects where we only celebrated at the very end of the project, so the way we celebrated in Story 7 was a nice change, and I could see the difference it made. I’m not saying that you need to celebrate every time the team meets or exceeds its commitment, but the point is to celebrate the team’s success. The show of appreciation can go a long way. Again, it does not have to be all the time, but make sure it is tied to a success.
Build on your success. When something goes well (whether it is some process that made a big difference or some architectural issue the team overcame, etc.), build upon that success. Take the energy from that success and use it to motivate the team.
The aforementioned items are not specific to the Agile software development methodology. But I think they are more important when using Agile because the team is always delivering and there is no real “end,” as you might have on a traditional project.