Browsing Category

Work

Work

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.

Work

Why a traditional IT project is like an elevator

I have never re-designed an elevator. But the elevators in the building where I work were recently redesigned at the same time that I was working on some website re-designs. It struck me how similar the process was.

The arrow points up; the elevator goes down

Since the upgrade of the three elevators in our building, the indicator triangle above the middle elevator has pointed up when the elevator is about to go down.

The analytics department studying the impact of the button pointing up may determine that the user experience hasn’t been greatly affected. Users, after all, are adaptable. Although a few people may have gone up when they intended to go down, they have adjusted their behavior. Essentially we have all learned that if we push the button to go down and the middle elevator arrives, it will point up but go down. New people may accidentally go the wrong way but they end up going down.

I think anybody in marketing would have no problems explaining that this was in fact a successful upgrade. People just needed some time to adjust to the new, superior interface. Any complaints are just resistance to change.

As a user of the elevator I want to get down five floors as quickly as possible so that I can go home

Experiencing the upgrade of the elevator as a user, I suppose the first thing that strikes me is the lack of consultation with me and – as far as I know – with any of the other users.

Had I been asked, I probably would have said that the elevators provide the core function that I want. They go up and down from one floor to another and I would want to retain that. However, they are prone to stopping in between floors. I think that is a bug that should be addressed since the people stuck in the elevators don’t like it. So if there is going to be an elevator re-design, making it more stable would be what the users would request.

So we got music

Music? Yes, it’s kind of tinny and it kicks in halfway through the journey. Nobody really wanted it and we don’t quite know what to do with it. I don’t know anybody who would have actually asked for the music. But it’s there. We can’t turn it off.

We got the arrow that points up

I did point out to the people working on the elevators that the arrow pointed the wrong way. They didn’t seem too interested. They were just doing what they were told. I suppose it wasn’t in the requirements. Nobody said that the arrows had to point the correct way. Now, the project has been delivered and that will have to go in a future phase. I don’t know if there is a future phase. It has been a few years now.

The doors open really slowly now

You can tell that the elevator has arrived at your floor because it stops. And then for a few seconds you begin to wonder if maybe it’s between floors because nothing is happening. Then just when you are ready to hit the panic button, the doors open slowly.

I don’t know if anybody has any metrics for how quickly the doors opened before the upgrade but they didn’t feel slow. Now they do. We can’t provide any data about the slowness so apparently we will just have to live with it.

So in short

The elevator upgrade is like a lot of traditional projects because:

  • Nobody consulted the users
  • New features were introduced that nobody wanted
  • Critical features that used to work no longer work
  • New issues were introduced that haven’t been fixed
  • The people who sponsored it consider it a great success
  • The work was all done at one time and wasn’t ever revisited.

We’re getting used to it.

Work

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.

Work

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.

Work

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.

Work

Are Project Managers Angry About Agile?

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.

Be Careful

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.