In an organization that is using Agile software development, can managers with no Agile experience or training be effective? Should they have some basic understanding so that they can guide Agile teams in the right direction? Or, does it matter if the team is self-organizing? Can a lack of understanding about Agile software development by managers harm Agile teams? Some of the best Agile projects I have been involved in were ones where the managers spent a lot of time learning Agile best practices and what works for other companies running Agile projects. On projects where this was not the case, we tended to have a lot of issues.

Real-Life Stories

Story 1: Artificial Limits

While on a Scrum team I saw an example of what happens when managers put aside Agile values and principles that they either don’t understand or don’t like. On this specific Scrum team, instead of the team determining what it would take on in a given Sprint, the manager had a rule of each developer only taking on 3 points. This rule had been in place before I joined the team, so one day I asked, “Where does the 3-points-per-developer rule come from?” I was told that it was based on historic data.

But while on this team, I saw that some developers could easily do 6 or even 9 points in a given Sprint. Even faced with that fact, the manager did not want to change the “3-points-per-developer” rule. If you did more than 3 points during a Sprint you were almost seen as rocking the boat.

So, as you might imagine, User Stories that were over 3 points would get split into smaller User Stories that were 3 points or less. The problem is that splitting User Stories this way often meant that at the end of the Sprint, we could only demo partial functionality. This was not even close to being a shippable product (I discuss that specific issue and how it relates to transparency in Chapters 4 and 9).

Thoughts

I think there are many ways to track a team’s productivity in terms of how many points are closed per developer per Sprint. There is nothing wrong with understanding, for example, that each developer on a team can close an average of 5 points in a Sprint. That kind of data is great for Program Managers to understand how a project is trending and to plan capacity. But the real measure, in terms of Agile, for understanding how a team is performing should be its velocity.

The other issue with the situation in Story 1 was a manager being the one to dictate how many points the team could commit to per Sprint. The Sprint commitment should be made by the team, not the manager. Also, by having a flat number of points per developer, the team’s velocity will always be the same. If the expectations from the manager are that the team will always close X points in a Sprint, then what is the motivation for the team to improve its velocity?

So the bottom line is that the members of a Scrum team should be the ones making the Sprint commitment, not someone outside the Scrum team (“chickens” in Scrum). The team has to do the work and knows what its members are capable of, so let them make the commitment. If they make the commitment, they will feel more responsible for meeting the commitment.

Story 2: Merging of Roles

In one organization I was a team lead for a Scrum team. In this particular organization, three roles were blended into one. The team lead was also the technical lead and the Scrum Master. In my case, I played these three roles and also spent about 50% of my time doing development. This is a lot of work for one person, but I had had several years of experience with Agile projects at this point, so that really helped. I had seen many different things that worked and that didn’t work.

However, in other cases I’ve seen that the person playing the Scrum Master role did not have much experience. That is not necessarily a problem, but when you combine being a Scrum Master with the other roles I mentioned, it can be difficult. I saw this first-hand on one Scrum team where the team lead was playing the Scrum Master role but did not have adequate time to spend on being an effective Scrum Master. Being a good Scrum Master is not easy. It takes a lot of time and effort. It takes finding creative solutions to issues. On the team I just, the thought was that being the Scrum Master was something anyone could do and should not be a full-time role. However, that is not what I’ve seen in my experience on several Scrum teams; it can easily be a full-time job.

Thoughts

One thing I’ve seen work well is to have team members take turns being the Scrum Master. There is no set rotation, but I’ve seen rotating the role every Sprint work pretty well. During the time that a person is the Scrum Master, he or she is dedicated 100% to that role. He or she does not commit to points for that Sprint or take on additional work. At the end of the Sprint, the role transitions to the next person. If switching the Scrum Master every Sprint creates too many handoffs or things falling between the cracks, then try rotating the position on a different frequency.

Bring in a CSM to help the team. Have the CSM train others to be a good Scrum Master. Once people are trained, keep one person dedicated to being the Scrum Master for the team. An Agile Coach can help in a similar way.

Story 3: Agile Smells

There are a lot of things that I have begun to see as red flags when working on an Agile project or team. For example, one team lead used to say, “It is time for Scrum.” I used to think to myself, “Scrum is not a specific meeting.” I’ve heard it called “Daily Scrum” or more generally “Daily Stand-up meeting.” Of course, this is a nit-picky thing, but combined with other things it becomes a red flag.

Another example was when a manager said “one point is 20 hours” when our team was estimating User Stories for the Product Backlog. I asked “why are we even using points if we are translating them directly to hours anyway?” I was more or less told that “in Agile you have to use points for User Stories.” So we basically did all estimates in points but discussed points in terms of hours. It was a strange exercise to say the least.

In another example, the manager of the team was the one doing the estimations for the User Stories, not the team members. He said he did the t-shirt sizing and would give those estimates back to the business. Then the team would be left doing the work and having to hit the dates based on the manager’s estimates.

Thoughts

I’m not saying that the items mentioned in Story 3 are necessarily wrong, but I am saying that in an organization that proclaims to be Agile, these are red flags. Hearing and seeing things like the items mentioned have taught me to set expectations. They show the amount of experience groups or individuals have with Agile. It shows their understanding of fundamental Agile concepts.

I mention some of these red flags in Chapter 9. As mentioned in that chapter, the main point is that hearing and seeing things like I describe in Story 3 can erode the confidence developers have in leadership.

The point is, when I’ve seen fundamental misunderstandings of Agile values and practices, it always worries me a little. But there is a positive side as well. The positive side is that there is an opportunity to teach people and share Agile experiences. By sharing our knowledge, as long as the organization and management are open to learning, we all grow and learn how Agile can make software development better.

Story 4: Going Through the Motions

One Scrum team that I was on had a very interesting way to conduct the Daily Stand-up meeting. This team was at a very successful electronics company with a lot of really smart engineers. Every morning we would head into the conference room. We would turn on the TV and sit around the conference table, someone would connect her laptop, and then she would open a browser. Then she would open a wiki page which had a few things on it: date, attendees, and notes for each attendee. The manager would typically copy the previous days “status” wiki page and clear out all the sections. This would eat up about the first five minutes of the meeting. Then the manager would proceed to go around the table and ask what each person had done the prior day. The next day we would repeat this process.

Thoughts

In Story 4, there is nothing wrong with what this team was doing. As a matter of fact, it was one of the most casual meetings I had ever seen. The team was doing what worked for them, and that is great. My only issue occurs when a team says it is practicing Scrum but then does things that are contrary to what Scrum prescribes. In this case, the Daily Stand-up meeting was anything but a stand-up meeting, and it did not provide the value that it should. Again, I am not saying the process the team used was bad; it just was not typical for a Scrum team.

Story 5: What Are We Building?

Considering that the output of Agile software development is quality, working software that delivers business value, it is curious when I have seen leadership on Agile projects not grasp that concept. For example, I’m a big fan of the idea of “building software right” and “building the right software.” I don’t recall where I first was introduced to this way of looking at software development, but I believe it was related to BDD. What it basically says is that you can build software the right way (in terms of quality, etc.) but that does not mean it is the right software if it does not behave as expected. You need to do both in order to both provide business value now and create quality software that is maintainable in the future. I tried to discuss this with a manager one time but he didn’t care about this concept. He was simply more interested in getting code pushed through the pipeline.

Thoughts

Although not everyone on Agile projects might have heard of these particular quotes in Story 5, I would think people would be curious about the ideas. If nothing else, developers and anyone involved in an Agile project should understand the importance of building the right software and building it the right way.

Story 6: Things Are Not Always Interchangeable

A fundamental principle of Agile is understanding that what is delivered to the business every Sprint is more important than just delivering User Stories. But on one Scrum team there was a mentality that the amount of points completed in a Sprint was the most important measure. During a Daily Stand-up meeting we were discussing that some of the User Stories we committed to might be in jeopardy and we were told that “as long as we close 20 points this Sprint, it doesn’t matter which User Stories constitute those 20 points.”

To be fair, part of this mentality was due to the fact that this group was doing more Water-Scrum-fall, even though they thought they were doing pure Scrum. But with that aside, I was still surprised that the idea that we build the Sprint Backlog based on what Product Owner sees as the most valuable was lost on some people. In other words, there was a mind-set that all User Stories are equal.

Thoughts

One of the Agile values is the early and continuous delivery of valuable software—which to me means we not only deliver value but also quality software. So even if you are following Water-Scrum-fall, this should still apply. Forget the misunderstanding of thinking all User Stories are equal and planning to deliver all the features by the end of the project, why would you not work on the most valuable features first? What if, as often happens, the project hits crunch time toward the end and the quality goes out the window? Will the most valuable features now be the worst implemented ones and least tested ones? How can that be a good thing?

So I think whether you are following Scrum or another form of Agile, or Water-Scrum-fall, the Product Owner should be prioritizing what the team works on each Sprint. The work delivered by the team should always be providing value to the business.

Story 7: Cliff Dives

I’ve been on several teams that had a nice burn-down chart Sprint after Sprint. I’ve also been on teams that had “cliff dive” burn-down charts. Based on my experience, I can say it definitely matters. In the cliff dive Sprints, people worked long hours at the end of the Sprint, and on teams with QA members, they would get overwhelmed the last few days of the Sprint. I was on one team, though, that accepted cliff dives as a normal circumstance. On this team we had a rule that each developer does 2 points per Sprint and almost all the estimated stories were 2 points. So basically all the developers would finish their development at the end of the Sprint. This meant our QA engineer would become overloaded the last few days. This was not very fair to the QA engineer. Not surprisingly, the burn-down chart always looked like a cliff dive at the end of the Sprint. This is far from what would be a “nice burn-down chart” in Scrum, where you have a steady burn starting at the beginning at the Sprint and the burn-down line stays close to the trend line.

Thoughts

I think a better way to work is to be delivering stories to be tested throughout the Sprint, every few days—basically, a nice steady stream of work that moves across the task board as the Sprint moves along. You can imagine on day 1 that all the stories are in the “not started” column. Then maybe on day 3 you have some stories in the “not started” column and a few in the “in progress” column. Then in the next few days a few stories end up in the “closed” column and the rest of the “not started” stories make their way across the board throughout the Sprint. The burn-down chart would look like a nice steady burn of points. It means that everyone on the team is busy and there is not a pile of work thrown on the QA people at the end of the Sprint. I’ve seen this work both on Scrum teams and on teams using Kanban. The key is to not say developers can only do X points per Sprint but, rather, to build the Sprint Backlog based on the team’s past velocity and current capacity. As developers finish their stories, they grab the next “not started” story from the Story Backlog. You can then put stories of all sizes in the backlog and you will be delivering stories throughout the Sprint.

Of course, there are always unforeseen blockers that might cause stories to not close until the end of the Sprint. The occasional cliff dive is bound to happen. I am not saying that it will never happen; rather, I’m saying that cliff dives should not be the norm and frequent cliff diving is a red flag. So look at your processes and determine why the cliff dives are happening and find ways to avoid them.

Story 8: Things Always Breaking

While on one team I experienced what happens when there is a lack of understanding about Agile principles, specifically around giving people the environment and support they need to be successful. This was a Scrum team that was in an organization that claimed to be “Agile.” But as a developer who has worked on a lot of teams at several companies, this was probably the first time that I felt very hesitant about making code changes. This is because the environment was very unstable, from both an infrastructure and a support standpoint.

We had a set of REST APIs (application programming interfaces) and there were several issues, like no real versioning, no real integration tests, and a lack of unit-level tests. These things, coupled with the complexity of the code, made adding new functionality a very difficult endeavor. It was difficult in the sense that for every new feature added, we would see about three defects created in existing functionality. The new functionality would work according to the acceptance criteria, but there were side effects on the UI or other services that would not get uncovered until later in the development process.

To make matters worse, all code developed during a Sprint, even though potentially not complete in terms of being fully integration tested, was deployed to the Production environment. There was a notion that this was OK because we were using Feature Toggles or had “if/else” logic in the code. But the evidence was clear: this approach did not work for this particular organization.

Thoughts

The work environment described in Story 8 was incredibly stressful. I don’t mean stressful in the sense of deadlines or constant changes to requirements but because, as a developer, you never felt confident (other than additive changes) that something wasn’t broken somewhere else and you hadn’t realized it. Then, all of a sudden, someone would come over and say “Oh crap! We broke something in Production.” It was a constant firefighting environment.

Many factors can lead to the type of development environment described in Story 8. In this case, a big part of the stressful environment was a lack of automated functional tests and the fact that we had somewhere around 17 services that comprised the REST API. Very few of the developers knew how all these services integrated. At the time of writing this book, the jury is still out on Micro-Service Architectures (MSAs). After seeing how some organizations approach MSAs, I am now more in the camp of starting with larger applications and splitting them later as needed. But even with MSAs, the key is to have automated tests (unit, functional, and integration tests). Only with a high level of automated tests can you really trust CI and rely less on manual testing.

In Story 8, management knew about this constant firefighting, but it was accepted as the “norm,” and a mentality of “it is what it is” was prevalent. It was unfortunate because things could have been improved by adding more automated tests and with more knowledge sharing across teams. With no management support, and developers always putting out fires, there was no time to really fix the underlying problems.

Story 9: Diminishing Returns

On several teams I’ve had managers talk about “swarming to close points.” What they meant was simply to have more developers work on a single User Story so it could be closed more quickly—which usually made the work go slower because developers had to merge changes, have more meetings, and so on. There really can be too many cooks in the kitchen. I am not saying that having multiple developers work on the same User Story is a bad thing. To the contrary, I think having multiple developers work on one story can make a lot of sense if the work can be divided in a logical way.

Thoughts

When I’ve seen swarming done as in Story 9, it seemed like a misunderstanding of what swarming really means. I believe swarming means that a team works together to get past a specific problem or impediment. So if one person is stuck on something, other members of the team stop and together they swarm on the impediment until the original team member is unblocked. There are several definitions of swarming, so this is just my take on it.

Story 10: Something Is Missing

At one retail company I saw how hard it is to adopt Agile when managers do not understand some of the basic concepts. For instance, the particular application my team worked on had no unit tests and when I raised this as a concern the manager was a bit confused about why that would be an issue. We had a conversation that went something like the following:

• Me: “Are we going to have CI at some point?”
• Technical Manager: “Yes, eventually we would like to get a CI pipeline up and running.”
• Me: “So, I am noticing a lack of unit-level tests in the codebase.”
• Technical Manager: “Really? Why is that an issue?”
• Me: “Well, in order to have Continuous Integration, you need tests that can be run against the codebase when developers check in code to detect when the codebase has been broken.”
• Technical Manager: “Makes sense.”

Thoughts

It was really eye opening to have the conversation shown in Story 10. In this particular case, there were several senior developers on the team, but still unit testing seemed to not be a major concern.

Having unit tests is crucial for CI to be of value. The purpose of integrating your code often is to know that you have not broken anything and you need tests in order to determine that. Unit tests are also critical so that developers can feel safe when refactoring code. CI is such a critical part of Agile and allows teams to delivery early and often. Anyone on an Agile team should have a good grasp of CI, if not CD.

Story 11: Ineffective Demo Meetings

One of the things I like about Scrum is the Demo meeting. This meeting gives the Product Owner a chance to accept the work that the team did during the Sprint. Only when the Product Owner has accepted the work can the team collect the points for the work and close the User Stories. If the Product Owner does not accept some of the work, then those User Stories are revisited in the next Sprint.

But I’ve seen Agile projects where this was not the case. I was on one project where we collected the points and closed the User Stories before the Demo meeting. Worse was the fact that on this particular project we had combined Demo meetings. Each Scrum team only had a few minutes to demonstrate the User Stories they worked on during the Sprint. There was hardly enough time to show the User Stories we had worked on. There was very little time to test all the scenarios and truly allow the Product Owner to ask questions. Teams rushed to demo their User Stories and skimmed over the details.

Thoughts

The way the Demo meetings were run in Story 11 was not fair to the Scrum teams doing the work, and was also not fair to the Product Owner. Adequate time was not given to truly look at what was being delivered in the Sprint. Combining a Demo meeting with several teams, because it was easier to have just a single meeting, had consequences. For one, many people stopped showing up to the Demo meeting because they felt it was not adding any value. Second, many defects were found later when the Product Owner really had a chance to test the new features. Finally, it tended to compare teams in terms of what was done during that Sprint, and in my opinion, it is not a good practice to compare team’s velocities.

A better approach, and one I have seen work well on other projects, is to have smaller Demo meetings with just the team doing the work and the Product Owner. This meeting should be a real conversation about what was built and allow the Product Owner to ask questions. Only when the Product Owner is satisfied can the team collect the points. This is like other areas in life where you only get paid after doing the work.