The value of adaptability is one of the core concepts in Agile. Adaptability embraces the idea of not being so rigid in terms of delivering functionality that you can’t change midstream. It’s also being able to recognize when things are heading in the wrong direction and adjusting before it is too late. It is about staying flexible, but doing it in a way that does not waste the team’s time.

Real-Life Stories

Story 1: Planning Too Far Ahead

After a few weeks of being on a new Scrum team I noticed that the team had an interesting way of planning work. Basically, on the Monday before the Sprint ended all the team members would disappear for a few hours. I asked my technical lead if I was missing an invite on my calendar. He told me that I was, and then I asked, “OK. What meeting is this on every other Monday?” He explained to me that it was the “Sprint Readiness” meeting. Being a Certified Scrum Master (CSM) and having been on several Agile teams, I was curious about the purpose of this meeting. In the next Sprint Readiness meeting the team met in a room and our SDET (Software Developer in Test) started to go through some of the User Stories from the Product Backlog. When I asked if these were for the next Sprint, he explained that they were for two Sprints in the future. I found this a bit odd, having seen in the past that is hard to predict what the business would need during the next Sprint, never mind during two Sprints in the future. But this was a process that the team had established, and so the team members held the meeting like clockwork. It didn’t matter if all the User Stories we reviewed never even made it into the anticipated Sprint. It’s possible, and in fact it did happen, that User Stories we reviewed never made it into any Sprint. I tried to point out some of the shortcomings of this meeting and possible alternative approaches, but this particular team seemed pretty set in its ways.

Thoughts

The team wasted a lot of time in these meetings and even when the User Stories did make it into the intended Sprint they were not ready. I think the following are some things that could have been tried and would have resulted in a better use of time and added more value:

In general, a Scrum team should not try to predict what the business will want beyond two weeks in the future. Things simply change too often to try to predict beyond the two weeks. That is why the Product Owner should be prioritizing the Product Backlog and then in Sprint Planning should tell the team what he or she wants to be worked on in the next Sprint.

One approach I’ve used that worked well was to have a “pre-Sprint Planning ” meeting. This was held a few days before the Sprint Planning meeting. Typically only the leads (tech lead, BA lead, and QA lead) would attend this meeting, but that was just because of how the team was structured. The idea of the meeting was to look at the stories the Product Owner thought he wanted in the next Sprint. Since it was a few days before the Sprint Planning meeting, this tended to be pretty accurate. We would go through these User Stories and make sure they had everything they needed to be brought into the next Sprint (acceptance criteria, comps, and annotations, etc.). This made the Sprint Planning meeting go a lot quicker.

Regardless of whether you just have a regular Sprint Planning or some sort of a “pre-Sprint planning” meeting, I think it is best run by the Product Owner (or BA proxy). It provides an opportunity for the team to ask questions and make sure team members understand exactly the scope of each User Story.

Story 2: Always Be Improving

One of the things I like about Agile is the idea of constant improvement. Specifically, I like the Retrospective meeting. But I’ve been on teams where this meeting was slowly being phased out. For example, I was on one Scrum team whose members eventually started skipping the Retrospective meeting altogether. Team members felt that the meeting was just not adding any value and the developers would rather be back at their desks. It started with just skipping the Retrospective once or twice, but then it became usual to not have the meeting. Not only should this team not have proclaimed to be a Scrum team, but I think its members were really missing out on an opportunity to improve the team.

Thoughts

In this example, I think it was as much a matter of the team not understanding the value of having the Retrospective as it was laziness on the part of some of the team members.

Whether you are following Scrum or some other flavor of Agile, the concept of stopping at the end of each iteration and seeing what went well and what didn’t is important. If this isn’t happening, the team is missing an opportunity for improvement.

This meeting can be ongoing and doesn’t have to be formal, but I do find that having a meeting time set aside helps to get the team together even when there are a lot of other things going on.

There are many ways to run Retrospective meetings and many ways to decide on the biggest pain points. Typically I’ve seen teams vote on the top three negative items. One thing I don’t always see is follow-up on these negative items. So I’ve created “follow-up items” and I assign them to team members. They are tracked on the task board (either physical or virtual). This keeps the items visible and there is a better chance that they are not forgotten. If they are acted on, then whatever pain points were experienced should go away in the next Sprint. Over time, the velocity of the team will increase as a result of removing these pain points.

Story 3: A Lot of Wasted Planning

While on a Scrum team that was starting a new e-commerce project, I noticed that the team members did something that seemed contrary to what I’ve seen work on other Agile projects. This particular team had estimated the User Stories in the Product Backlog and was getting ready for the first Sprint Planning meeting. The project manager scheduled a “multi-Sprint Planning meeting” for the week before the typical Sprint Planning meeting. I thought to myself, “I wonder what this meeting is going to be all about?” As it turns out, the meeting was just as the invite said; it was to take the User Stories from the Product Backlog and try to plan out all the Sprints for the project. I’ve seen teams do dependency mapping exercises, which makes sense so that you understand the order in which the stories need to be worked. But trying to plan multiple Sprints on a whiteboard did not seem to make much sense. What are the chances that the priority of the User Stories won’t change or that some of the stories won’t get descoped? Well, as it turns out the chances were pretty good.

Thoughts

I’ve worked on some Agile projects where we would map out all remaining Sprints and try to map out what would go in each Sprint. But this would typically happen later in the project and only when the backlog was pretty well groomed and more or less stable. In those cases, it was more to see if all the stories could fit into the remaining Sprints, not to come up with a “plan” for all Sprints. Even then, what was mapped out did not end up matching what actually happened.

I think, in general, a Scrum team should not try to predict what the business will want beyond two weeks in the future. Things simply change too often to try to plan the work for the next two Sprints, never mind the next ten Sprints. Even with two-week Sprints things can change, and the Product Owner comes yelling, “But I need to get this other User Story done during this Sprint.” Most teams manage this by having a rule that the Product Owner can swap things of equal point value and only if the User Story being swapped out is not yet started. This is more a Kanban style, but I think it can be used in Scrum if it is the exception now and then.

I think it is better to make sure the Product Backlog is groomed well. This way you do not waste time going through User Stories that are no longer needed, are lower priority, and so on. If the Product Owner is going through and making sure the Product Backlog is being prioritized and if the team is having the Sprint Planning meeting, then I think that is sufficient. If you want to map out all the Sprints and follow a more or less rigid plan, that is fine, but then don’t call it Agile. Maybe it is more of a Water-Scrum-fall model (as described by Dave West of Forrester Research), which might work better in your organization. Water-Scrum-fall is a term I’ve started seeing more and more as companies have adopted Agile. Basically, it means that a project is being run like a traditional Waterfall project but is also using parts of Scrum. For example, there might be two-week Sprints and the typical Scrum meetings might be conducted, but the delivery of the software follows more of a Waterfall model where it is tested and deployed to Production at the end of the project.