Transparency
The importance of transparency in Agile software development cannot be overstated. In some organizations it is not easy to be transparent and open. There is a lot of pressure to say what the business wants to hear. But I believe, in the long run, that a lack of transparency hurts an Agile team, the project, and the company. Having seen first-hand organizations that claim they want “openness” but then don’t listen or, worse, punish those who are open, I can say that true transparency is not easy. But it is critical to the success of Agile software development and worth the effort.
Real-Life Stories
I was fortunate enough to work on an amazing project at a major entertainment company. The project would allow users to have highly customized vacations. It was truly going to be a game changer in this specific industry. Soon after joining this team, I attended my first Sprint Planning meeting. During the meeting I noticed something odd. The team’s true velocity was, let’s say, 30 points, but they would only commit to around 20 points. They would then find a few more stories and put them in the next Sprint. These additional stories were “a stretch goal.” But they knew their velocity was much higher than what they were committing to. This seemed very wrong to me. It was a total lack of transparency and honesty.
Not surprisingly, the team would typically finish the stories in the current Sprint and then work on a few more stories from the next Sprint that they had put aside. For the most part, this was a management decision because management did not trust the team to meet their velocity in a consistent fashion. This led to a lack of transparency with the business, and normal tools like burn-down charts could not be trusted. Also, it did not make the team feel very good because team members knew they were not being honest with the business.
Thoughts
Use the velocity of the team to measure how much work can be done in a given Sprint. Then, based on capacity, commit to what you know your team can complete during that Sprint.
Be honest about the team’s velocity and don’t give into political games about trying “to look good” on some presentation slide. This type of misrepresentation does not benefit anyone in the long run.
Use burn-down charts to be honest about how the team is performing in a given Sprint. A burn-down chart tells the true story of how the team is performing. Some teams also use a burn-up chart for this purpose. If you cliff dive at the end of the Sprint, that’s not the greatest, but at least you are being honest with the Product Owner in terms of what happened. If you are not going to make the Sprint commitment, at least that will be more obvious during the Sprint (i.e., the burn-down will show that the team is not closing enough points each day and is at risk of either cliff diving or not meeting the commitment). The point is that the team is being completely transparent.
Using the raw data and not hiding anything from the business frees an Agile team. Kent Beck has an excellent quote in one of his presentations about what he calls “schedule chicken.” He tells a story about people around the table during a typical project meeting and the project manager who is walking around and asking each team how things are going. Everyone wants to put on a good face and say “umm, yeah we are on schedule,” even when he is not. Now each person has to sit there and know that he might be caught it a lie later. It is better to just be honest and say “well, we are about two Sprints behind.” Done. Now there is nothing to hide and you can move on and deal with the reality of the situation you are faced with.
Let the quality of the team’s work speak for itself. Have a consistent velocity, deliver software without defects, deliver business value, and adapt to what the business needs.
I was on a large multiyear project with dozens of Scrum teams. There was a lot of pressure on the teams to use BDD. Unfortunately, many of the teams were new to BDD and the infrastructure needed to scale automated functional tests was not in place. We had dashboards displayed on large flat-screen TVs in various development areas. It showed the automated functional test results for each team, which were aligned with functional verticals. These tests were run as part of the CI pipeline. These information radiators were supposed to alert teams to broken builds.
Over time, some teams, with their manager’s knowledge, started to game the system. They would put “skip” meta tags in the tests when the tests would fail. Then they showed as green on the dashboard monitors around the development area. But this was completely misleading and produced a false sense of confidence in the quality of the application. Over time, it became a bit of joke among developers. Upper management was just glad to see green builds in CI. Worse yet, as I talked about in Chapter 7, the automated functional tests were eventually completely turned off.
Thoughts
One of the Agile principles is delivering quality software early and often that provides value to the business. But in order to know that you are building quality software and to have a high level of confidence in your software, you need to be open about the amount of testing that is being done. It is crucial, for the sake of building trust with the business, to be open about the quality of the software you are building. If not, the business will eventually find out anyway due to high defect counts and poor user experiences, and ultimately it will hurt the name of the company.
Story 3: Caving into Pressure
The question of pressure on team members in a cross-functional team was something I had been curious about since the first Agile project I had been on. During my first few Agile projects, I did not see pressure play a big part and did not see it lead to developers lowering their standards. Nor did I see pressure get to other team members, like the QA member of the team, to the point where they lowered their standards. Each person on the team pushed back whenever there was pressure to get them to accept software that was below our standards.
Then, on one project, I saw the pressure of meeting Sprint commitments completely erode the professionalism of some team members. It happened at the end of the Sprint, when the pressure on the QA engineer to close stories was very high. In this case, the team collected points when the story was passed by our QA engineer, not after the Product Owner accepted the features during the demo meeting. Often when the QA engineer would find a defect, there would be pressure to call it a “tech debt item” or say something like “we will fix that in the next Sprint.” This also happened to the Product Owner. The Product Owner had the ultimate signoff on a User Story and also felt pressure to ignore certain things for the benefit of the team. There was a mentality of “the team worked really hard, so we can ignore this defect for now.” I often questioned this mentality and pushed for a zero-defect policy, but I was over-ruled. Worse, on this particular project, there was a measure of success that said if we did not have severity 1 or 2 defects, then the project could go live. So what happened? Defects slowly but surely went from severity 2 to a 3 or 4.
The pressure on teams was high to portray the right picture, and people’s standards and professionalism started to slip. There was a total lack of transparency to the business in terms of what was being delivered and the quality of the application.
Thoughts
When on a cross-functional team there can be a lot of pressure to close stories so the team can meet its Sprint commitment. But it is critical to the success of the team, the project, and the spirit of being transparent to be open about what the team is delivering. Each person on the team is a professional, and if he or she were in an environment that had clear boundaries between disciplines, I believe he or she would be less susceptible to caving in to peer pressure. Yes, even professionals on an Agile team can feel peer pressure.
So, what can be done to prevent this? I think one important thing is to have clear “Steps to Doneness.” In your “Steps to Doneness,” state that the User Story can only be closed if, for example, it has no defects (even visual). Of course, these rules are up to your team and there is no right answer. Clearly state that the team values openness and what the standards are for closing a story/feature. Then people can point to these team rules and standards. Of course, this is only as valuable as the team that adheres to rules. Team members need to support each other and hold each other to the highest standards.
At the end of the day we all have bosses, so it is crucial that management respect and support the values of the team. With these values in place, and knowing they are supported by their manager, team members can feel good about not compromising. They can feel good knowing that they are being completely open with their business partners. In my opinion, this is a much better way to work and removes a lot of stress.