How does an organization that is adopting Agile show that it is serious about adopting Agile values and principles? How does management avoid sending the wrong signals to teams—signals that are confusing and contradict what people have learned about Agile on their own or at other companies? Sending the wrong signals can lead to a lot of confusion and can create poor morale among teams. Poor morale can then lead to poor-quality software and spending more time on things like technical debt. This is the opposite of building projects around motivated individuals and giving them what they need to be successful.

Real-Life Stories

Story 1: Complete Breakdown in Trust

While working on a large project that had adopted BDD, I personally experienced how sending the wrong signals can lead to a complete breakdown in trust.

On this project we had requirements that said that every feature needed automated functional tests. This sounded great in theory, but unfortunately team members lacked the discipline to maintain the automated tests. At one point, when tests started to fail often and it became clear that we needed dedicated developers to maintain the tests, management chose to stop running the automated tests. This led to many automated tests becoming outdated very quickly. It also led to an increase in introduced defects, which in turn led to low confidence in the software we were delivering. This ultimately led to more and more manual testing. It also engendered a feeling among teams that they had wasted so much time on tests that were now rotting on the vine. The other feeling that started to spread among Agile teams was a lack of trust in management’s dedication to delivering quality software.

Thoughts

In Story 1, this was a real turning point in terms of team morale. There was already some mistrust of management and how the project was being run, but the decision to lower our standards really created a bad atmosphere that would last until the end of the project.

A different approach may have been to take the following into consideration: first, set realistic goals upfront and base them on past experience. Don’t base these goals on some other company’s standards. Setting the bar high is one thing, but given your team’s skill sets and past performance, be realistic in your quality gates.

Second, perhaps start small and build on success. In other words, set realistic quality gates and then ramp up a little over time to raise the bar. For example, make it a rule that code coverage can never go down once it hits a new level. So, if the project says you need to have 80% code coverage, set that as your floor. As you add more tests and the coverage goes up to, let’s say, 85%, set that as the new floor and don’t allow developers to lower the floor.

Finally, as mentioned in Chapter 4, building a solid foundation is critical to the success of your Agile teams. Don’t set your teams up for failure. Telling teams that they need to write automated functional tests without having the appropriate infrastructure and support will only lead to failure for the teams. Instead, invest in the needed infrastructure and support so that they scale as more tests are added.

Instead of completely stopping the automated testing, management could have formed a team whose sole focus was to create and maintain the automated tests.

This is just one idea. The point is to find solutions that do not undermine your Agile team’s ability to deliver quality software.

I’m a big believer in automated tests (unit, functional, and integration) and think that for any company or organization to be successful, it needs to be willing to invest in testing. The ROI (return on investment) can be huge: catching defects early in CI, less manual testing, speed to market, and so on.

Story 2: Please Don’t Compare Scrum Teams

While training to become a CSM, I had learned that Scrum teams should not be compared. Each team has its own velocity, its own way of estimating User Stories, and its own idea of what a point represents. But I saw the exact opposite on one Agile project.

On this specific project managers thought that one way to get the teams to perform better would be to compare teams’ velocities. By all accounts, that is a truly terrible idea, regardless of what is taught in Scrum Master certification. The comparing of velocities led to a lot of terrible things on this specific project. It led to teams inflating their point values just to say they closed more points than other teams. I recall looking at a User Story from one team that was 8 points and thought to myself, “This would be equivalent to a 3-point story on my team.” It led to teams cramming through code that was not ready. It led to bitter feelings between teams; I heard things like “the X team thinks they are so much better, but they really suck.”

I remember saying to my manager at one point, “Comparing points across teams means nothing. It doesn’t tell the whole story. A team’s health and velocity should be the real measure of success.” He was not very happy with that comment. Soon other developers started saying “points don’t matter.” There was no convincing some managers and the team comparisons continued. But by the end of the project most developers could care less about being compared to other teams and knew it meant nothing.

Thoughts

At the end of the day there was a huge misunderstanding, I believe, on the part of management when it came to thinking that comparing teams would create some kind of healthy competition. It had so many unforeseen consequences. Having a slide that shows how many points each team closed each Sprint created less team unity, not more. The teams on that particular project were in many geographic areas, so it also led to an “us vs. them” mentality.

Having a presentation slide showing the Sprint point commitment and what the team actually closed is fine. But instead of comparing team’s velocities, show the velocity of each team over the last three Sprints. Show how they are doing as a team, not compared to some other team.

The reason comparing teams did not work on this project, and I suspect would not work in most organizations, is that each team estimated the User Stories in their backlog (which is the way it should be) and a 3-point story for one team might be a 5-point story for another.

I suppose if you are in an organization that wants to compare Agile teams, just don’t get caught up in it, and understand that it is the health of your team that is truly important.

Story 3: Dictating Velocity

One of the things we learn about in Agile is how velocity plays a major role. We use velocity to plan Sprint commitments, to balance life and work, and to gauge how well the team is improving over time. While on a project, I saw the exact opposite—instead of velocity being used to gauge what a team could commit to in a Sprint, program management began to dictate how many points each team must close.

The teams had to meet these commitments, even if it meant working late nights and weekends. It didn’t matter what the velocity of the teams had been up to that point; each team needed to complete X points per Sprint. Teams were treated as failures if they did not meet these mandated Sprint commitments.

This process caused so much distrust and lack of respect for leadership. It really created a terrible work environment that would last until the end of the project.

Thoughts

One thing we know is that working late hours leads to mistakes. No matter how good you are, when you are tired, you will make mistakes. As developers we are not immune to this (we might like to think we are superhuman, but alas we are not). I remember many times working late into the night. The next day or week I’d look at the code and think, “What was I thinking?” The mentality of mandating a Sprint commitment and having people work insane hours led to what I had seen in my own code, but it was multiplied by hundreds of developers.

As you might guess, the quality of the code went downhill fast. It was functionally correct in the sense that it did what it was supposed to, most of the time. But things like code coverage, well-designed code, and so on, suffered. Ultimately, these things made the application hard to maintain. Not surprisingly, after about a year in Production there was talk of doing major rewrites of portions of the application.

As you might imagine, the morale of the developers was not that great after the practice of mandating Sprint commitments began. It is only empirical, but I would say productivity did go down.

Every project has deadlines, and that is not going away. But if you tell teams that you are adopting Scrum and that they can have a better work-life balance by using velocity as a measure, then live up to that promise. Knowing the velocity of each team should in fact allow program managers to know exactly how the project is tracking. Just as we use burn-down charts for an Agile team to show the Product Owner how things are going, we can use project level burn-downs to see how the project is tracking and then it is transparent to executives. With this information there is no reason to not adjust sooner and avoid the “death marches” that many of us are so used to seeing.

Story 4: Avoid Creating Team Hierarchies

While in one organization, I saw some teams say that they were Scrum teams with a flat structure, but in reality that was not the case. The team I was on had a “technical/team lead” role and even though everyone on the team was supposed to be equal, this one person made most of the decisions. Generally speaking, this person’s opinion mattered more than that of other team members. In fact, instead of team members being more self-organized and self-sufficient, they depended heavily on this one person for handing out work.

Thoughts

In Scrum, no person on the team is supposed to have more power than the others. I like the idea of having everyone as equals on the team. Even the Scrum Master does not have more power than others on the Scrum team. But what I saw on this team, and others within this organization, was that the majority of decisions fell to the team lead.

One concept I read about when I was first learning Agile was self-organizing teams: the idea that the team can determine the best way to get things done. But even when a team is highly self-organized, there is still a need for a manager. One of the things a manager can do is to make sure an Agile team is functioning and that is the team has a balance of power. For example, if there is a really strong personality on the team who is convincing everyone to go in her direction all the time, that is not good. In this instance, a manager can perhaps introduce another strong personality on the team to equal things out. Or, the manager can put processes into place that can help to make sure everyone on the team is being heard. Planning Poker when estimating can be one such method.

The main point is to make sure everyone on the team feels he has an equal voice in the decisions that affect the team. When using Planning Poker, for example, if there is a disagreement on how many story points should be assigned to a User Story, each team member can give his reasons for the estimation and the team can come to a consensus.