Browsing Category



I don’t think this way any more

Disclaimer:  I was going to get rid of some of my early writings but I decided to keep them because I realize they show that I have changed. ”Journey” is over-used but I have to remember that I am learning and others are too.  You may be here.  Or you may be reading what I am writing now and smiling because you know I will move on from there.

Scrum principles may seem like a radical departure from how projects have traditionally been run but ultimately the big picture is pretty much the same. Comparing ‘waterfall’ to ‘agile’ often assumes a pure implementation of both when I find my own practice of Project Management to be much closer on the spectrum to agile without being strictly agile.

Methodologies aside, as a Project Manager, I take the requests of stakeholders, distill them into reasonable tasks, list those tasks in order of priority, estimate how long the project will take, agree on how much we are going to deliver and do what it takes to deliver the project by the deadline. During the project, I answer questions, make decisions about the scope and remove obstacles so the team can deliver. If we can’t meet the deadline, we decrease the scope, increase resources or negotiate a later deadline. As a Project Manager my responsibilities can vary greatly as I do whatever it takes to get the project delivered.

Within a scrum/agile framework, when playing the role of PO, I facilitate user stories from stakeholders, arrange them in order of priority (backlog). The team breaks them down into tasks, estimates the relative scale of each task and agrees on what is included in each sprint. During the project, I answer questions and make decisions about the requirements and remove obstacles. We deliver work that is tested and potentially shippable in completed sprints. As a Product Owner, my role is clearly defined.

Throughout my career I have been a Project Manager, a Program manager, a Producer, a Director and a Consultant. Regardless of which title I have, it is important to me to be involved in the strategy – not just ‘what are we trying to deliver?’ but ‘why are we trying to deliver it?’

PS:  How have I changed? Since I wrote this, my thinking has evolved. I now believe that agile is a radical departure from how projects have traditionally been run.


Why my cat wouldn’t make a good agile leader

Suffering from jet-lag insomnia and thinking about agile, I found myself thinking that my cat is very “command and control.” Equating the fact that I was awake in the middle of the night with the possibility that she would get an extra feed, she started with the loud purring. You would think she would be familiar with the cadence. The sprint ends after about eight hours of sleep. No we are not going to do an emergency release.

Most cats are excellent project managers. They remind and coax and hassle. Would they be good agile leaders? Not so much.

Is she happy to adapt to change?

Depends, she likes to try different places for an afternoon nap. However, a new brand of cat food is generally unacceptable.

Customer collaboration?

I’ll have to give her a free pass on this one since she can’t actually speak and I’m not quite sure who the customer is here.

People over process?

I’m going with no. The process is “feed me now”. Does it matter which person does it? Not really.

“Working software over comprehensive documentation?”

Yep. Well if software = food, absolutely. I haven’t seen her read.

Does she stick to the rules? Not really. We have some large floor to ceiling windows and she often asks me to open them. They are windows, I say, not doors. She doesn’t care, she wants to be let in. So I am going to say she is a good outside of the box agile thinker.

In retrospect, I really shouldn’t judge her.  Agile about is accepting somebody where she is in her journey – even if her journey does tend to be towards the bowl.


Parent Site

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.


What do I do while the records are playing?

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.


WIP, Not Whip

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.