Can a Project Be Beautiful?

September 7, 2014

What would make a project beautiful? What sort of aesthetic would we seek? Would would make a beautiful plan? What would make a beautiful backlog? What would make a beautiful team? What would make a beautiful delivery?

I imagine it might be different for everyone…

The Plan

For me, a beautiful plan would be something that covers a wall of a team or war room. It would have requirements, wireframes, architectures, acceptance criteria, impediments.

mess

 

 

 

 

 

It would tell a graphic story of the evolution of the project over time. It would be a graphic history in multiple dimensions, worthy of Edward Tufte. But it would not be perfect. It would reflect rough edges, rapid sketching, mistakes, blind alleys, rough annotations everywhere.

istock_000019366898small

 

 

 

 

 

 

 

 

It would also reflect the growth and improvement of the team. Items from retrospectives would be incorporated into the timeline. There would be different ways that the team measured their own performance. It would be a glorious mess!

OLYMPUS DIGITAL CAMERA

 

 

 

 

 

 

 

The Backlog

A beautiful backlog would be on it’s own wall. It would reflect dialog with the customer, questions from the team, user profiles and scenarios.

tumblr_ly5c4tDfnr1qfg8uu

 

 

 

 

 

 

 

 

 

It would be shaped like an inverted pyramid, with rich detail at the top, tapering down to sparse sets of one line ideas and proposals below. It would have color (LOTS of color) and use different shapes to indicate stories, epics, features, etc.

writing-on-wall

 

 

 

 

 

 

 

The Team

A beautiful team is tight. The team works physically closely together, eliminating all barriers, focusing on collaborative activity over solo activity. They work together, they eat together, they respect each other. They share roles and responsibilities promiscuously.

teamroom

 

 

 

 

 

 

 

 

 

They pair, they mob, they swarm!

8666.pp-Team-Room_4C3230AF

 

 

 

 

 

 

 

 

 

 The Delivery

A beautiful delivery is smooth and effortless: friction free. It happens on demand – with the ease of a thought. Work flows through to production almost inevitably. It’s a downhill slide, not a grind uphill.

Free-Mattress-Delivery-Farmington-Hills

 

 

 

 

 

 

 

 

 

 

 

What does a beautiful project look like to you?


On Product Ownership

November 1, 2011

Recently I’ve been dealing with disengaged product owners. You know the type: they don’t show up for the stand-ups, when they come to the standup meeting they don’t bring any stories and instead simply review whatever the team has brought to them – and then leave early because they have more important things to do. When they show up for the demo, they obviously don’t recognize the stories and simply give tacit approval to the work that the team has done. And the scrum master marks the work as accepted. The only time they express any opinion about the project is if it is late. Otherwise they are off in other meetings for projects that seem more attractive to them.

Call me a jerk, but these are the product owners that I least like to deal with. I almost prefer an actively hostile product owner – at least then I know that they care! Instead these ghost product managers do nothing to engage the passions and the commitment of the team. Soon I find that the team is coming to me and saying, “We don’t see much value in the work we are doing…” This is a very bad sign for a team. When you hear this from a team you can rest assured that you have a product owner who at best is distracted or at worst just doesn’t care.

Of course part of the problem is that I just haven’t worked with that many really good product owners. I think they are a rare breed. However, I saw something the other day that gave me pause. I was watching a coordination meeting for a big program that was getting started. The meeting was being run by a talented facilitator and there was a very charismatic product manager who was conveying a very obvious air of “being in charge”. You could tell that he had an ego the size of Texas. He was comfortable with public speaking, he used terms that were dramatic and conveyed a sense of purpose and commitment. He also conveyed the sense that he was confident an knew what he was talking about. People would defer to his knowledge of the business domain. He was brash, arrogant, had a full head of hair, and I almost instantly despised him. I know that type of guy all too well. He was just like me – with hair. What a jerk!

I saw him again a couple of months later and he was still selling the hell out of his program. I remembered thinking to myself, “Does this guy ever quit?” There he was in front of the team. He was basically reaffirming the value of the product that they were all trying to deliver. He was still selling the heck out of it! At the time I’m afraid I must confess I did not recognize the value of what he was trying to do. It all seemed a bit too “high school cheerleader” to me. So instead I settled for quietly loathing his presence.

So lo and behold, there I am a month or so later working on my own program. And I don’t happen to have a product owner who is charismatic, energetic, or at least has a face. No, instead I’m working with some guy I’ve only met once who lives on the east coast and who has not shown up for a planning meeting in recent living memory. The project is stumbling along, like many of them sometimes manage to do. Schedules are slipping, impediments are being worked around rather than being resolved, and we all pray for the day when we get to work on another project. And then it hits me.

I need to sell this baby. Well, somebody does anyway. It’s probably more suited to the product owner’s role, but in their absence somebody’s got to do it. Otherwise this project will just quietly fade into obscurity. Perhaps it should be put out of it’s misery. If you can’t get the product owner to care, then maybe the best thing to do is to let it die. But there is another school of thought here. Leadership on projects is not always clear. By that I mean that sometimes the product manager is a strong leader, sometimes the project manager is a strong leader, and yes, sometimes that giant dork, the development manager is a strong leader too. Sometimes, but not always. In fact the chemistry has been a little different on nearly every team that I have ever worked on. The fact is that the leadership may be hard to find, it may lie in different, even unexpected places – but it must be there somewhere.

One thing to keep in mind is that your leadership needs are going to vary based on the size of the group you working with. If the project you are working on is a nice little single team project with just a couple of iterations to it, then you probably don’t require much in the way of overt and active leadership. In that case it’s probably enough for the team to be well functioning and trusting each other. The commitment is small enough that it doesn’t require any particular skill of vision or any additional requests for re-commitment. The value of these small projects is often small enough that everybody usually feels that they are easily achievable and they don’t require much additional motivation to achieve.

Then there is the more complicated project, really more of a small program. These projects might have two or three different phases, milestones or releases to them. They generally take longer than your typical individual project and they require more commitment on the part of the organization and the team. The added risk and uncertainty, simply due to that introduced by the increased scope and the concomitant unknowns make these projects more worrisome to all involved. We’re not talking major fear, uncertainty and doubt here, but we are talking about the kind of program where, with just a few things going wrong, the mood can swiftly change from, “We think we can do this” to “We’re all going to die!” These are the types of projects that require someone, an engaged product owner – someone who will consistently paint a clear picture of the overall goal and help the team understand and appreciate the value that they are delivering to the customer and the organization. It may not take all that much, and you may even find that you can get away without it, but like I said, it’s much more likely in these situations that you will find that life goes a lot smoother with someone who is willing to actively rally the troops.

Finally, there is the genuinely large program – to me this is any program that has 3 or more teams, each of whom has multiple overlapping milestones that they need to hit in order to deliver the program successfully. Often times these teams are also distributed/dispersed teams as well. These are the programs where you need one hell of a good salesman. You need someone who is good at bringing people together and helping them feel like they share a common goal. Someone who is good at working with large groups of people – this can’t be the kind of person who will shy away from a room filled with 50 people. They need to be fairly energetic and be able to tell a compelling story. And they need to know the business really, really freakin’ well. They have to have some sort of very real respect within the group. For the really big programs, you probably need more than one person like this. Or maybe not. When I have worked with the multiple leader scenario I have also see a lot of infighting, which can be death for any project, large or small.

These are just some observations and speculations. They aren’t based on any kind of empirical data. To a certain degree they are based on observations of things that I have seen missing in myself as I work with teams. They are also what I often need from a product owner. Teams really need leadership as much as anything else from the product owner. However, leadership is one of those intangible skills that is very difficult to impart in some sort of training class. Certainly it is not the kind of thing that you will find in any sort of product owner certification course. The point is, I think teams need it from the product owner, some more than others, but they all need it.

Of course I suck at things unless I find some sort of way to formalize it into a set of things that I find easy to remember. So how would I formalize what I am asking for here? First I would bring back a much stronger emphasis on the project kick off meeting. This is the first opportunity to sell the project/program to the team and it is very important that you do it well. Second, I would put together regular status updates with the group, perhaps along the lines of key milestones that would serve to bring the group together and reinforce that original commitment to the project. Finally, I will treat impediments very aggressively and review them with the product owner and make sure that not only are they aware of them, but that they are taking an active role in resolving them as well. The team needs to see that the product owner is just as committed to removing project impediments as anyone else – perhaps more so.


Watch Out for the Horns!

May 8, 2011

I saw my first bullfight today in Madrid. It was an impressive spectacle with all of the pomp and circumstance, blood and cheers that I had expected. Much of the work done by the matadors and toreadors was a game of distraction. Watch my bright red cape! Seeing the matador dancing inches from the horns of the bull reminded me of a few projects I’ve been on where it seemed my job had been to distract the bull too.

Now don’t get me wrong, you’ll never see me in those Spanish tight pants the matadors wear (pause now, while the world breathes a collective sigh of relief). Nevertheless, there have been a few different metaphorical project bulls to face:

  1. Product Owners
  2. Architects
  3. Other Project Managers/scrum masters

Each is deadly in its own way. We all like to think of Product Owners as an integral part of the team. In the consulting world, this is often not the case. The product owner can be someone who is hostile to the team and looks upon them as a fall guy to be beaten whenever expectations aren’t met. It’s dysfunctional as hell, but it happens. In that situation, the role of the Scrum Master can very quickly look like that of a matador – It’s your job to distract the product owner from the team. This way the team gets their work done unmolested.

A similar thing can happen with Architects who try to micromanage the teams development work. Again, your role as Scrum Master is to distract these sorts of people away from the team, “Hey, can you show me your brilliant UML diagram again?”

It can even happen when dealing with other project managers. Scrum Masters can get very good at defending their teams, sometimes even too good. After all, we give them that mandate. Most of the time it works out well, but there have been times when I’ve set off the defensive reflex in a scrum master and found myself saying, “Dear me, where did those sharp, pointy horns come from?”

Like the matadors, sometimes we manage these situations well, and other times not. Eventually we all get lots of practice. It’s a thing of beauty to watch an experienced project manager handle a crowd of rabid stakeholders and walk away unscathed. But you need to be wary – watch out for the horns!


The Project and The River

May 2, 2010

I’ve had this idea bouncing around in my head for a while that I haven’t quite been able to articulate. Let me see if I can use an image to explain it…let’s pretend that your project is a river. It moves, sometimes rapidly, sometimes slowly, working its way downhill toward some sort of goal. Along the way, the river encounters obstructions in it’s path. Some are large obstructions, perhaps a beaver dam, others are relatively small obstructions like a boulder. The river may be slowed by these impediments, but it finds its way around them. Some obstructions it is even able to move out of it’s way – logjams break, trees are undermined and give way.

Our projects, like our metaphorical river, are shaped by the obstacles that they encounter. Our projects have obstacles that they can remove, and others that they can’t – and we have to work around those. If we could visualize our project’s progress over time, we might describe them as a winding river. They bend and twist, they rush and go calm.

What if you were to take away all of the obstructions in our river metaphor and just look at the water by itself? You would see this snaking tube of water that behaves in all sorts of strange ways for no obvious reason. If we follow the path of this watercourse (I visualize it as hovering in the air) we would have many questions: Why does the water suddenly turn into a hectic spray here? Why does it slow down and turn into an enormous slow pool there?

Without seeing the obstacles, you would only be able to speculate what the causes of these phenomenon were. I believe that we treat our development work in the same fashion as this river. We ignore the obstacles and only look at the work (the water). We don’t see the boulders (impediments) that we work around every day. We wonder why the project is moving so slowly, or we marvel at the sudden, unexpected rush that we never saw coming. If only we could see the obstacles before or even as we reached them. That’s what the good teams do.

We and our projects are shaped by the obstacles that we encounter every day. If you want to understand what shapes your projects, you need to understand the risks and impediments that impact it. If you are aware, and able to manage these issues, then you move from reacting to the obstacles to anticipating and mitigating their impact. You are able to change the shape of your project/river. You move from participant to architect.


Inspection

April 10, 2010

I’m reading Ellen MacArthur’s book, “Taking on the World”. She is arguably one of the greatest sailors around. It’s her story of her life leading up to and including her amazing race in the Vendee Globe.

Before she ever got to the Vendee, she spent years working on other people’s boats. She would prep them, repair them, and otherwise set them up for the big races. She had to know the systems of these amazing race machines inside and out.

These were largely solo racers that she was working with. Once they left the harbor and crossed the start line, they were on their own with no outside help for weeks, even months. Preparation for these racers was critical. Any undetected flaws would very likely come back to haunt them somewhere in the middle of the ocean. Not an attractive thought.
She would spend hours, days, weeks reviewing, inspecting these boats for weaknesses. She would be looking for the telltale warning signs of problems, like rust on the connecting terminals, minute cracks in the paint around areas of stress – anything that would indicate a possible problem.

She was engaging in a form of risk management. The inspections she was doing were designed to uncover the risks that might jeopardize not only the race, but perhaps even the sailor’s life. This sort of assessment goes on all the time in the sailing world. When you go to buy a boat, you get a survey. The point of the survey is to uncover risks to the buyer. Have you ever watched a surveyor in action? They use a lot of checklists.

I’ve watched some great sailors prepare for races too. You can see them wandering over a boat, running their hands over every inch, opening lockers and sticking their head in, tugging on lines – looking for risk. I imagine they have a mental checklist that they are using too.

When we are managing our projects, how do we inspect them? We can use checklists. We can ask others for advice (something that Ellen did very well). We can make things visible – the equivalent of sticking our heads into lockers and looking around. There are a variety of things we can to to look for risk. Being a good project manager, like being a good sailor, means being aware of and constantly on the watch for risk.