A few weeks ago, we started a new Meetup group in Berlin called »Coach Me If You Can«. As agile coaches working in a digital agency we felt like there is something missing in the Berlin meetup scene, and saw a need for a new platform on which experienced agile coaches and scrum practitioners can share their situations and discuss common issues. Although most ideas and improvements came out in the conversations during the meetup, this article reflects my view on these issues and how I see our results. I hope you agree or even better: challenge my personal biases.

The attendees of »Coach Me If You Can« set the agenda and we gather a backlog of topics. The group selected “Feedback Culture” and “Constant Change in Scope or Priority” as the most interesting. We then split up into groups and talked about individual cases. Here is my summary from the Constant-Change-group:

First of all, change is very welcome in agile projects. However, sometimes constant change can be a symptom of problems in the process.

Case 1: Badly written stories

The protagonists of the first case were a small, distributed team that worked with Scrum. They faced one main challenge: the scope changed after every single sprint. After some inquiry by our group, we found out that stakeholders generally did not change their mind during their reviews, but were actually expecting different results.

We quickly formulated a hypothesis:

Low quality stories allow for a wide range of outcomes. An unexpected outcome forces stakeholders to refine what they actually wanted after a sprint. To the team this feels as if the stakeholder is indecisive and is constantly changing the scope.

Here are the tips our team has come up with:

1. Get the Developers in touch with their definition of “ready”. If they see uncertainty in the stories, let them reject the story. At Turbine Kreuzberg, we actually require two Devs to approve a story before it is considered ready for a sprint.

2. Check where your PO is spending their time. Physically. Where is their desk?

If the information is not making its way from stakeholder to the developers, find out where it dilutes. Should they spend more time with stakeholders to understand the business or should they spend more time with the developers to explain and unravel uncertainty? Think outside the box (box = office, in this case). It would be totally fine to move the PO around in the office. Even send her or him to the stakeholders office if need be. Everything makes more sense than wasting another sprint of the team.

3. Check whether your PO has access to the right people. They might be forced to deal with what I call “glorified messengers”. Which is a person without decision making powers that answers every question with “I’ll need to get back to you on that one.” Some stakeholders can be reluctant to invest time and attention during a project unless they see something not going their way. These are clear give-aways that your team is working in a non-agile environment. The third case deals with a similar scenario.

Case 2: No time for an MVP

In another case we were told about a hardware team also using Scrum. Even though the team produced meaningful increments, frustration rose due to changing scope. Again, our group brought more details to the surface. Stakeholders jumped from idea to idea before projects could reach an MVP-like maturity. Factor in the specifics with hardware: you need to order material, actually wait for shipping or sometimes deal with subcontractors!

We identified two angles on approaching this challenge:

1. Have longer Sprints. It’s not a shame to have a four week sprint. Agile welcomes change — but it should come from new information and not from a gut feeling of a stakeholder. Changing the plan before you can test your MVP* feels like you didn’t need the last increment in the first place. So if your team needs four weeks to put something testable together, take four weeks.

*{I can already hear the screams. “In our field we cannot test!”, “It is different because we are building for our clients!” and so on. I personally dislike those statements because they are so easy to postulate without even trying to get new information. One might argue, for example, that giving the client a working increment and thus “testing” if you have met their expectations is a valid replacement. Urging the client to place some of their users in the review was also helpful in our experience.}

2. Use release plans. How often I have shuddered when someone said “We are agile — we don’t need to plan anything!” We plan a lot, we just don’t stick to the plan blindly! Planning might not be on the cover of the book but it is a vital part of agility.

Planning more than a Sprint and laying out a release plan as a road map for your product is perfectly fine. Just make sure everyone involved knows the plan is a prediction subject to changes and not a dictate.

Case 3: PO as the puppet of the CEO

Next please! Here we have a more or less typical Scrum team. People know what they are doing and the team delivers working increments. Everything is peachy except for the PO, who basically functions as a mouthpiece for the CEO. The CEO feels like the producer for the band “Backlog and the High-Priorities” and whistles a different tune every other week. The product owner does not own the product and puts ideas from higher places directly on top of the backlog. A participant asked why this was such a big problem. As the head of the company, the CEO surely knows best what the next step should be and as long as she doesn’t change the sprint backlog, it is ok for her to steer the team directly.

{If this sounds reasonable to you, don’t read on! Instead lean back and take a minute to think about it.}

In my mind there is a more precise question:

What information is not available to the CEO that is necessary to prioritize a backlog?

What should be on top of the backlog: the easy answer is the item that adds the most value to the product. I say easy because it is tempting to treat the word value as a black box without clarifying what it means.

{I like to use the following example for clarification: If you run a restaurant and you have asked a consultant how to improve your business, she gives you two observations.

1. The menus feel cheap and are inconsistent with the pricing of the dishes. A better design might increase customer spending and satisfaction.
2. There is no hotel in the area of your restaurant. Turning the building above the restaurant into a hotel might bring an additional revenue stream.

Which one would you do first? The easy and quick win or the long and costly endeavor?}

You get the point — it is not only about the gains, it is also about the efforts. The two are coming from the stakeholders and the development team respectively. The PO is giving these individual pieces of information meaning by putting them in relation to each other. The more complex answer to our initial question thus is: the item with the most favorable ratio of value and effort should be on top of the backlog. If the CEO does not gather information about the necessary effort first, she should not place anything on top of the backlog. In return, the PO should re-prioritize the backlog after all new items have been estimated by the Dev Team. There may be even more constraints that make the top items irrelevant, that is why in the sprint planning the team can forgo important items, this can be the case for example when a story depends on another and cannot be started before the other one is done.

A lot more was said about these topics and some topics haven’t been touched in this article. Nonetheless, I hope it could summarize some of the insights and I’m looking forward to your additions and comments.