Category: Work

Years ago I picked a fight with my best friend’s boyfriend because he wasn’t looking and indicating when he changed lanes. “There’s nobody there” he replied. I learned to drive on the LA freeways and I know that in the blink of an eye there can be another car next to yours. You always look. You always indicate. Most of the time you are right, there is nobody there. But that time you are wrong might be the last time.

Fortunately for everybody I am not a driving instructor. I work in software. But the same rules apply. If you are going to pivot, you need to let people know. Don’t assume it doesn’t impact anybody else.

Recently I was working on a re-design that wasn’t going particularly well. There was one area of functionality where we could choose to retain the old design or forge ahead with the new design. There were a lot of edge cases and secondary workflows in this area so different developers had tasks that were impacted by this change.

So I sent out an IM @all to let anybody who wanted to be part of a quick catch up to join us. We ended up with two POs, our QA lead and a few developers getting together to agree on the overall approach so that they could each go forward with their individual tasks. Stick with the old design or continue on with the new one.

Half way through our meeting the Director of Engineering sent us an IM to say that the Vice President had already made that call. The decision had been made to go forward with the new design the week before.

It wasn’t a bad decision. I probably would have made the same decision myself. I think he made the decision assuming we were mostly done when in fact we were only mostly done with the ‘happy path’. Nevertheless, we could deal with the edge cases and secondary workflows and we all agreed the new design was better.

The point is the VP didn’t indicate. He didn’t look to see who would be impacted if he changed lanes. He didn’t update any of the tasks to let the POs and developers know of the decision that had been made. In this case, none of the people working on the tasks knew of the decision that had been made.

It’s not always practical to have everybody in every meeting. Nobody wants endless documentation and discussion but if we are going a different way, everybody needs to know.

This happened early in our Agile transformation.  I’m not saying that it never happens any more but Agile practices are protecting us more now. Agile ceremonies may sometimes seem like overkill but they are actually a good way to indicate your movement to a wider group rather than assuming that you aren’t impacting anybody else.

The team was given a story to estimate in backlog refinement. “Add an error message to the checkout page when details are missing for an order referred from our parent site.” We were given the design and text for this error message. The Product Owner presented it to the team for an estimate.

So why do I have a problem with that?

I’ll explain. One of our challenges is that we have business owners and product managers in another country who like to “save time” by

“doing the stories for us.”

Writing stories for the team doesn’t really save any time. Even worse, it’s in conflict with Agile values and principles. Stories written for a team are just a functional spec written in the form of a story.

But back to my story.

We were presented with this already written story on a shared screen with the Product Manager (in a Product Owner role) driving the computer from another country. (Yeah, I know that’s wrong but we can’t change that). However, the team is sitting with me. So this is what I do. “OK, let’s start at the beginning.” I turn the laptop around and video Skype the Product Manager. “Who are we doing this for?” I ask the team. In a few minutes we come up with the customer, Jenny, a persona we have used before. What does Jenny want? Well she wants to know if something is missing. Why? So she can fix it and continue with her purchase. Good.

Some background. We work for a subsidiary of a parent company with a site that has significantly more traffic than we do. Let’s pretend we sell clothes. On the parent site a customer will select a product, let’s say it’s a t-shirt. They can also pick a colour, a size, a currency for purchase and quantity of items and send those attributes to our site to purchase in our cart. The error message is for those times the customer ends up in our shopping cart missing one or more of those attributes.

I ask the team to give me stories. “What kind of information might be missing?”

We end up with a list of things Jenny might want to fix as well as “unrecoverable error, we have nothing”. We also assume we need a story to re-direct as far down the funnel as we can get so Jenny doesn’t waste her time.

We turn these into stories and prioritise them.

Jenny is on the shopping cart page, which of these missing attributes can be fixed on the shopping cart page? Currency and quantity. That’s a story. So our first story is about missing attributes that can be fixed on the shopping cart and the error messages for that.

OK, so what happens if Jenny lands on the shopping cart page and we don’t know the colour or size? We aren’t sure because that doesn’t happen on our site but we assume the shopping cart is empty because we need to know these attributes in order to put a product in the cart. So she gets an empty shopping cart with an error message. Jenny can’t fix that problem, can she? What can we do with this story so it gives Jenny the outcome she wants.

We know the product code. Story number two: we can take her to the product page with an error message so she knows what she needs to fix. On the product page she can pick size and colour.

What if we don’t know that product is actually unavailable? We can still go to the product page because we already have a version of that page when products are unavailable.

Maybe we don’t know the product code. Well we could drop Jenny back on the empty shopping cart with an error message. Is that really what we want to do? Our user story says Jenny wants to fix the missing attributes, can she do that? No. So that’s another story.

At this point in our story planning meeting we have a white board filled with post-its under the User Story “As Jenny, I want…” We also have a team that is engaged and thinking.

At this point, the Product Manager says “hold on, I will be right back.” OK. She comes back in a few minutes with a surprise guest, the business owner. I introduce myself and the team. Let’s go back to the top of the board. We go back through what we’ve written, talk it over and ask the Business Owner if she is happy with what we have so far. She is.

Now we move on to the next story: “unrecoverable error, we have nothing”. Where do we take Jenny now? The team had come up with “the Home Page”. The business owner says “we already discussed this, we don’t want people to land on the home page.”

We already discussed this.

I really hate that phrase. My snippy response would be “that’s funny, I have a really good memory. We have only been doing this for about ten minutes and I don’t remember discussing it.” But instead I explain we know we can’t take them to the product page because we don’t know what the product is. If we take them to the shopping cart, it’s empty so that’s just a dead end. So the team thinks in this story we should take them to the home page with an alert Is there a better option? Nope. Home page it is.

I know what has happened. The Product Manager, the Business Owner and perhaps a VP or two have already talked about this. They went straight into solution mode because that’s the fun part. They think the thinking is already done. They have already decided. Invariably when a management group decides on a solution, they don’t know the detail. They don’t have to. They only have to agree on the outcome they want. Where you get into trouble is when the team is handed a specific solution and asked to estimate that. We can do that. But then we don’t know what to do with all the bits they have left out. So we can ask them to document in great detail what they have decided so we can estimate that. We can do that but it’s called waterfall. Let’s not go there.

Back to our agile story mapping and MVP session.

Now everybody on the team has a clear understanding of the stories. We agreed on the stories that are in our MVP and we can estimate those. Actually it didn’t take very long at all.

What do we gain? Engagement, better stories, better estimations, more understanding of what we are doing and why.

What didn’t go well? The Product Owner says it is not up to the Scrum Master to decide what is in scope. Agreed. But it is up to the Scrum Master to protect the team and to make sure agile values and principles are upheld. The Product Owner can choose not to go ahead with any of the stories we have identified. But the team needs to do the story mapping.

The story goes that when one of the original MTV VJs was being interviewed she was trying to get her head around the concept.

“It’s like the radio but it’s on TV.”

That made sense. Except she wanted to know “What do I do while the records are playing?” In retrospect this is funny but we have to remember she was looking at it through the lens she understood. If you have never seen a music video, you don’t know what is going to be on the screen.

This story resonates with me while I grapple with the challenge of evolving from a traditional “command and control” Project Manager into an agile leader. Like the evolution from radio to video, this is a radical shift.

Project Management roles within a team are distributed. Nobody needs to assign tasks because the team takes tasks themselves. A project manager doesn’t need to schedule in scrum because the team takes two weeks (or whatever your agreed time-frame is) into a sprint and that’s what is delivered. The Project Manager no longer needs to worry about what to deliver because the Product Owner determines the desired outcome and the team decides the solution.

So a simplistic answer is “we don’t need Project Managers any more”. Or the more nuanced, “Project Managers schedule outside of the team, dependencies across teams.” A better answer for me is that they evolve into agile leaders. Either way, it is a major shift in thinking and it is reasonable to expect people to be confused and to need some time.

Don’t just blame the team – figure out the impediments and remove them.

Watching Undercover Boss and the CEO was talking about the issues with the bottling company. Bottles labeled incorrectly, mistakes made. This boss made a typical management comment about people not doing a good job. But this is why I watch UB. Then the CEO spent a day in the bottling plant. People running as fast as possible, machines at top capacity can’t meet the demand. The CEO couldn’t hack it. Bottles were broken.

In a typical Control and Command management style the answer is to whip people. “If they can’t do it, get some that will”. In agile, you try to empower the team to solve problems.

One of the things that a WIP does is demonstrate where the bottleneck actually is. It also forces the team to finish one thing before they move on to another.

The idea is that you force a limit to each stage of the process. When you are building software, people tend to work on the new, shiny tasks. If you aren’t careful, you will have ten tasks ready to test and nothing new to develop in your sprint.