Presence in the past does not help today

The previous weeks have been hectic, 7 habits classes, lots of meetings, trips and more meetings. I usually send a couple of days a week in the developer team room, but during this period, I’ve just come and gone.

It’s pretty amazing how fast you lose your touch with reality. Even if I’ve been down and said hi almost every day, I’ve not been a part of the every day hassle and questions and that is evident. I’ve become a chicken in just two weeks.

Scary.

Now, it become so obvious since the time between me leaving and returning to the team was short. But what if this would have been gradual? Or if I’d been gone for half a year? Or perhaps worst; if I’d never been a pig in the project? To be able to see that something is missing, you need to know what you’re missing in the first place.

So, I’m more confident than ever that the product owner IS a part of the team and not just as a happy fellow who drops by and says hi or just hangs around without making a difference to the actual work. A good product owner brings value to the team and the process and to be able to do so I need to be and work in the team room.

Well, you might think that daily meetings does it but I don’t think that this enough. Quite the opposite. If you’re a product owner who just comes for the daily standup, this meeting will probably be about informing you and keeping you updated.

So, what will be my measurement of whether or not I’m a product owner who is part of the project? Well, that is if I on most daily standups can share what I’ve done for that project and that is not only having meetings.

Do you have the perfect process?

Mike Cottmeyer discusses today on his blog the companies working and talking about their process rather than the output of it. I can really relate to this. Too often organizations try building the perfect process without considering the actual outcome. I can truly recommend reading The Goal – A process of Ongoing Improvement.

In this book the focus of the process work is to constantly improve the process to reach the goal of the organization. What do you do? Well, I work as a project manager at the IT department of TUIFly Nordic. But the goal of my work is not to complete IT projects, the goal is to get our customers to have the holidays of their dreams. And my processes should all focus on this goal.

According to The Goal, You don’t talk so much about your current process, instead you improve it and the focus for the improvement is working around the constraints in the process. The idea is that all processes have their constraints. It can be a testing environment which is hard to get access to. It can be a specific developer, who’s work is essential but who works many projects. Yes, you map your process but the rule is to constantly improve the process. Because when you’ve optimized the process with the constraint in mind, new constraints pop up.

It is therefore very interesting when Mike discusses that many scrum teams states that the goal is to have a product owner and how that mindset shifts the focus from What to How. Using the terms of The Goal, this means that you are not optimizing the process from the real goal of the organization, but for the sake of living the Scrum team.

So, what do I think? Well, as I state in one of my comments on his blog, the dedicated sole wringable neck has no self serving value. If you don’t need that, skip that. But if the tasks often filled by product owners in scrum is a constraint in your process of reaching your goals, you should form a role which best handles this constraint. And I do think that one person taking that responsibility is often a good solution. But as Mike states; that’s not a goal in itself, but can be a way to reach the goal.

How some piece of software started a very bad habit

I’ve never been a person who’d been late for meetings. I think I was late once to school and is the kind of person who really makes sure that I’m on time. We’re always first arrivals at parties.

But when I started working for my current employer, I started missing meetings and becoming late at occasions. I even have double booked meetings in my calendar. After having worked for nearly 15 years, one cannot help wondering what started this bad habit.

And it boils down to software which does not help me in the most fundamental way. When I’m invited to a meeting it is crucial to know if I’m already booked. I guess that this is just not me; most people have a problem being at two places at the same time. So, a calendar for professional use should probably warn me directly if I’m invited to a meeting when I’m already booked in my calendar.

Also, if I make a booking, it’s good to know if the participants are available or not during the time in question. And again, this is hopefully not just me but a universal need for everyone.

So, what happened was that I started using the calendar in Lotus Notes, and who ever is responsible for this system does not find this to be a fundamental need: I need to do some clicking before I learn if I’m already booked or if I try to make a booking when people are already busy. And if I accept or suggest a double booking, I’m not prompted or warned. I guess the product owner at Lotus Notes is a super hero with the power to be at several places at the same time, so I guess that is why he haven’t seen this need as a universal, fundamental need for the booking process.

So, what has sneaked into my habits during the months past is that I’m always double booked for meetings. Since I can accept or book meetings without this being flashed in my face, I’ve started to see it as less of a problem. But it is a problem and a bad habit.

But the lesson is more important than so. If we just imagine the product owner of Lotus Notes being that super hero who can be at many meetings at the same time, he can either realize that his reality is a bit different from others, why a need that he doesn’t have is really important. But one cannot wonder how often you just disregard a crucial need just because your reality is a bit different from everyone else.

There can only be one product owner – reply on harvesting developer intelligence

I got a very interesting reply on my latest blog post concerning the harvesting of the passion of the developers. Kevin E. Schlabach rightly pointed out that you could misinterpret my suggestion to leave some time for developer’s own initiatives and ideas.

So, just to make it clear; product owners can, if they think that the developers have great ideas, keep this in mind and when scheduling deliveries, leave some slack so if a developer comes up with a great idea, you as a product owner can choose to prioritize this. As Kevin points to, this is not up to the developer to decide. He can come with suggestions just like stakeholders, but just like everyone else, he cannot decide on priorities.

I’ve also been in situations where developers have thought up an idea and just started working on that instead of the stuff that needed to be done. To be frank, I’ve had some serious problems with this and finally had to take very drastic steps to end this, so I know that this is an important and serious problem. Serious, since other stuff isn’t being done, and dangerous since cheating in a team in contagious. It spreads to the other developers.

When you instead harvest the developer’s ideas you place them on the backlog like everything else. But I do like to make the guys happy sometimes and push up something on the priority list if it’s a really good idea and something which is truly valuable to the customer. But as a product owner, I am responsible, and it’s my decision to take.

Thanks, Kevin, for pointing to the risks for misunderstanding of my point of view. Keep the comments coming! I’m agile in point of view.

TFS 2010 for us product owners

I’m currently using a lot of Microsoft Project to keep my distributed stakeholders updated since the scrum dashboard just works for the current sprint and the 2008 web access isn’t very… accessible.  The stakeholders can’t get the overview they need. So, I spend time on separate Microsoft Project files with the long term plans (as described in a previous post) and I keep the product backlog in TFS.

So, I was just thrilled by the images on BHarry’s blog, describing the new features for us non programmers. Finally, I can really invite my stakeholders to keep themselves updated on the level they need.

The dashboard looks awesome! Here are two examples:

For me as a product owner, I of course long for the hierarchical work items:

If I still want to show Gantt charts, I can (if all goes well) use the upgraded Project Integration, since it conserves the hierarchy. This is the main reason I don’t use the integration today.

I’m also very curious about the Sprint planning functions

So, what more can I say: JUST BRING IT ON!

New book in mail today

Having had sort of a touch week with my husband away at TechEd, handling a lot of projects which are in a critical period, trying to be a decent mom and have time to feed and walk the dog, it felt really good when I today found a package in the mail. You know the box in front of the house where they put adds and bills. But now there was a package.

It was Bob Galen’s new book, Scrum Product Ownership – Balancing Value From the Inside Out. I was given the opportunity to read it before the final version, but since this is a book which you want to keep on your desk at work when the problems pop up, I was very happy to receive it today.

Don’t have a copy yet? Get it at Lulu.com:

http://www.lulu.com/content/paperback-book/scrum-product-ownership—-balancing-value-from-the-inside-out/5466386

Downloading Confessions of a serial product owner

Can now be made more easily thanks to Franco Martinig at

http://www.devagile.com/modules/news/article.php?storyid=346!

Product Owner part of the team?

During the previous week, there has been an emotional debate concerning if the product owner is part of the scrum team or if he’s not. These are examples of things that talk for viewing the product owner as part of the team and things that talk against that.

Why view the product owner as part of the team

• Answering questions concerning the stories and requirements are part of the sprint and those tasks should be a part of the work.
• If the product owner does not see himself as part of the team, he will not participate in team activities as daily scrum, etc, and will therefore not be an active part of the daily life. Which result in developers making decisions since the right person is not available to answer the questions.

Why not view the product owner as part of the team

• To be able to make priorities, the product owner must be out with customers and users. He therefore does not have time to be availble on site and in the daily activitites
• If the product owner is there constantly, he will micro manage the developers

I’ve not covered all the arguments in these views, but I think that this catches a bit of the problem: to be able to make the right decisions, the product owner must spend his time outside the team room but to make the decisions come true he must be on site so that the developers don’t make daily decisions which contradicts the objectives.

So, how do I think you should solve this? For myself, I solve the problem with sore arms. What? Well, we have three floors and on each floor we have these heavy doors. So, I try to move between the floors as much as I possibly can during the day. I come to the developer’s room every day, to chat, to look on progress and if it’s possible: I try to help out with what ever I can. It can be arranging a meeting with a technical guru from a supplier, it can be testing, fixing with the scrum dashboard or just hang out with the guys. I want the scrum team to view me as part of the crew. A part of the scrum team.

And it’s the same with our users and customers: I try to take part of their every day activities. Just listen in on their discussions, frustration and happiness. And to help out in their daily work when it’s possible. Help out with small tasks, find out what is possible to accomplish, formulate a change request or something like that. To make the business people understand that I’m part of their team as well.

And what a joy it is to transfer experiences between these groups! How rewarding it is for a developer to learn that Robert can work more effective now with the new release. And how rewarding it is for a user to hear that Lisa could fix that problem so easily thanks to that really good formulated change request.

So, my answer to the question is yes and no. You should as a product owner have the mind set that you’re always part of the team. But you work on all the teams.

So, what do I cut? I try to work my own product backlog and try to do what brings the most business value to the product: in this case my work. Which means that what is most often cut is those long off site meetings which are probably very nice but which in reality brings very little value to my actual work. Which is to make sure that we do the right stuff in our projects. This can also mean that I don’t participate in whole meetings. People don’t have a problems if I from the beginning say that I actually don’t have the time but I can be there for 30 minutes or an hour. OK, I probably miss out a lot of nice trips and lunches but what is that really worth. Really?

The decision you didn’t know that you took

If you’re like me, not sitting directly with the developers, you might not think that you have the time to be there physically. Working for an international company, we have that issue to deal with. I wouldn’t call it a problem, it’s a challenge to have a product owner who never sees the developer’s during the actual work. One way to handle the challenge is that we who are available take the time to be physically on site.

You might just sneak into the room on the way from lunch or take that cup of coffee and drink your coffee standing next to a developer. Most of them don’t bite.

Every time you miss the opportunity to go into the developer’s room you should see that as an active decision, which you unknowingly left to a developer who probably wasn’t sure which option was correct. Perhaps it was just a small thingy, so he didn’t bother to call anyone. So he guessed and chances are that he chose the wrong alternative. Or perhaps just a not as good option. If you’d been there, the better option would have been "free" but a later change always cost more.

So, make the choice, take the opportunity when it presents itself and go and spend the perhaps most valuable minutes of your day. How many times do you have the chance to make so many decisions which are carried out at once in just a dew minutes?

Acting product owner or having an active product ownership

The other night, I had a long chat with former colleague and close friend Morten about transparency in software development process. With that we mean that there are no secrets about what users wants and what they need and what is not working. It is one thing that users don’t go directly to individual developers all the time but it’s never a good idea to buffer this information on someone’s desk and that developers are kept in the dark – if they want to see the list they can do so. And the same goes with business people and users: they shouldn’t have to go to that buffer person to learn the current bug situation.

I’ve tried explaining the roles of scrum as roles in a play but reading a simply excellent blog post by Version One, I realize now that this can result in misunderstanding of the responsibility. I’m talking like the product owners who simply act the role like an actor. And as the Version One blogger so correctly puts it:

"In most organizations, the Product Owner is pretty simply acting as a buffer between the team and the business. "

From a lean perspective, a product owner in this case brings no value to the process. If you also have a scrum master who also act the master part of the title, chances are that you now have two buffers and probably non working software. As the blogger at Version One puts it, a working active product owner keep a groomed product backlog which all can take part in. And chances are big that the opposite also applies: the lacking product backlog can often result in non working software. And non working does not have to mean that the software quality is poor, but that the wrong features are built or that the right features don’t meet the user’s actual need.

Applying lean values are important to achieve real excellence in what you do. When I dived into agile I thought that agile software development is connected to lean software development, but I don’t any more. You can use scrum and still have lots of wastes (like buffering product owners and scrum masters) and really poor quality. That is why a lean perspective also should be applied and just not rub eachothers backs and think that we are lean since we use scrum.

But take the time to read the blog post from Version One, me for one love the simple images: going on my wall at work tomorrow!