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.
I started taking selfies at the hairdresser because there is not much else to do and I am just sitting there staring at myself in the mirror. So, here it is, selfies at the hairdresser:
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.
At Agile Coach Camp somebody asked me if Project Managers are angry about agile. Well, yes, actually we are.
Bear with me for a minute. As a Project Manager, I delivered a huge number of projects over many years. By and large my projects were delivered on time, on budget and to an agreed scope. That, to a Project Manager, is success. Now the goalposts have moved. In fact, this game is so different, we don’t even have goalposts. In an Agile organization, our focus is on the value we are delivering. I love it. That makes so much sense to me. I will adapt.
But I was angry. Here’s why:
“There are no Project Managers in Agile.”
The first thing I was angry about when we transitioned to Agile is the leadership in my organization saying “there are no Project Managers in Agile.” As the manager of a team of Project Managers, you can expect that was not a sentiment that we wanted to hear.
The actual truth is that we were transitioning to Scrum and Scrum has three roles, Product Owner, ScrumMaster and the team. There is no role called Project Manager. There is also no role for VP of Engineering, Business Analyst, Lead Developer, QA Manager and Sales Director. You get the idea. Agile is a very different way of thinking about who does what in an organization. It isn’t a game of musical chairs where you better grab a role quickly or you are left without a chair.
There are credentials available for Agile Project Management. I have taken courses on Agile Project Management. I attend lectures and read blogs on Agile Project Management. There are jobs advertised for Agile Project Managers. In spite of that, there are elements of Project Management which directly contradict Agile Principles. I believe that a Project Manager can find a place in Agile. However, to do that, she has to change her mind-set. I have actually evolved to believe that ideally we shouldn’t have people called “Project Managers” when we work in an Agile organisation (some frameworks do include Project Managers and some find they need them outside of teams while they are working towards Agile principles).
A Project Manager can transition to an agile role such as a Product Owner or ScrumMaster. Don’t just take the chairs away. It is important to reassure people that their job is secure even though their role will change.
“Don’t go chasing Waterfall”
I hate the term “waterfall”. Waterfall itself is a straw man term that has only been used to describe the opposite of Agile. All of a sudden I was being told that I did “waterfall” and that waterfall projects are failures. I beg to differ. Waterfall is generally used to describe the hypothetical (or real) worst project ever to compare to a mythical perfect agile project.
I love focusing on specific, measurable outcomes rather than the project itself. I think you will find that we actually had outcomes before – and metrics. We even achieved them. Having had to deliver so many bad ideas, I am thrilled to see so much focus on value. Identifying a key metric and measuring an outcome is a terrific thing.
Nevertheless, delivering a well-defined project on time, on budget and to scope isn’t a bad thing. Particularly when a project has a low level of uncertainty.
Recognize that Project Managers may have a tougher journey than the rest of the team
Project Managers do process, that’s all we do. Others have other roles. If you are a developer, your primary focus is to code. With agile, developers will pick up self-management. But as a Project Manager, management is what you do. A transformation hits Project Managers harder.
We can adapt. However, it’s a big change. I think a lot of people look at moving to Agile and say “oh goodie, we don’t have to listen to those pesky Project Managers harping about the plan any more.” Project Managers look at Agile and say “but what am I going to do?” (There are answers to that but I am moving on.) Remember, it’s “adapt to change over following a plan”. It’s not that there is no plan. We focus on what we want to achieve and adapt if we head in the wrong direction.
It’s not me, it’s you
Project Managers have to change because many of their responsibilities are either done by the team or no longer relevant. However, here’s the bit that you might have missed in the small print. It’s not just the Project Managers who need to change. Team Leads, Managers, Specialist Information Architects and Directors have to change too. There is a risk that once the Project Managers are removed from the command and control roles that they had that others step into their place.
To truly be agile, an organisation needs to transform their structure completely.
We need guidance from leaders
Whether from inside the organization or outside of the organization, Project Managers need leadership. Learning agile is not just the few hours it takes to master the basics. It’s an on-going metamorphosis from one way of acting and thinking to an entirely different way of acting and thinking. This level of change needs support.
It’s not just what we do, it’s who we are
As far as the change to who you are, I can’t compete with how Lyssa Adkins explains it in Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition so I will just say insert “Coaching Agile Teams” here. Go read it.
Please be very careful with your transition. Agile values are very different from what is valued in traditional Project Management. That kind of change takes time. Watch the language that you use. Reassure and support the talented individuals that work with you and make sure they find a role that suits and inspires them. If you just dump Agile into your organization and hope all goes well, your Project Managers will be angry.
I did this on purpose. I knew if I divided my site into these three categories that the one with the most in it would be
I’m forcing myself to think of something other than work…
I’ll get right on that…
When I was a little kid, I put my light blue leotard on and headed to a big warehouse to try gymnastics on Saturday mornings. We learned the basics in a very ordered, organised way. Meanwhile, being a kid, I also did cartwheels in the park with my friends. My friends taught me how to do a one-handed cartwheel. I showed off my one handed cartwheel in gymnastics class and the coach was unimpressed. “Get the two handed ones right first,” he said.
Right now there’s a push to release once a week instead of once every two weeks. That’s a good thing. But we don’t have the two week thing right. Continuous deployment is a good thing. Very mature engineering teams do it successfully. Likewise, Olympians do one handed cartwheels; they are amazing. As crushed as I was by the coach when I was a kid, he was right. We all want to move quickly and try something new but continuous improvement doesn’t mean move forward when you aren’t ready.
We aren’t ready.
We have problems matching our releases to our workflow. We don’t have a way to advise stakeholders what is planned in the next release. We don’t have enough automated testing to ensure that releases will be stable. Our development environments don’t match production. Our Product Owners don’t have a way to explicitly sign off on a task. Our release process is manual and clumsy. None of these things will be improved by releasing every week.
A freestyle one handed cartwheel in the park is a fun thing to try. It’s also risky.
On the one hand (pun intended) sometimes you need to master the basics first. On the other hand, embracing a challenge and breaking the rules is what makes the exciting stuff happen.
Continuous Deployment is the type of sport that would benefit from mastering the first step before moving on to the second.
I kind of gave up on the one handed cartwheels. Eventually gave up on gymnastics too. Never really gave me joy. Not giving up on Continuous Deployment, just don’t want to fall on my head.