Archive for the ‘SCRUM’ Category

We are struggling in a profession with no definitive answer about what it is, but lets be honest. Most of us does to much. Lets go back to basic and do what we are best at. 

A product manager should steer the product. Have a vision. Somehow know where the market is going, or even better where it needs to go. prioritize, interact with customers, look at competition, write requirements, think about marketing and make sure Sales and Delivery have something really good to sell and deliver. (I might have missed some things also).



Is that not enough?


So why do we insist on adding so much else to it?

A product manager is not a product owner. Product owner is the developer role. Its day to day interaction with the development team, go down that road and any time to actually meet customers dwindle. So let the Product Owner be the day o day expert who gets our vision, and then sort out the details when needed. We trust them and they make sure our vision is brought to life.

A product manager is not a designer. We know what we want, why we want it and have a good idea on the road there. But most of us are not experts in user experience (we are probably good at spotting a good or a bad one). The User Experience experts will listen to us, interact with us and come with proposals and different versions for us to comment upon and react to.


A product manager is not the tester. We know enough about QA to keep those experts in high regard. They know what they are doing. When we do the same we test that we got what we wanted, we don’t test all different use cases in detail and setup tricky data to see if the analytics is working 1000% time of the run tests. QA are experts on that.

A product manager is not the documentation and user guide expert. Far from it, we today strive to get systems that don’t need much of that. But when we do need it we know enough about it to hand the actual writing and sorting and layouting to experts.


So lets make sure we have experts around us. People who are as committed to their expertise as we are to ours. That way we can really shine in what we are good at. 


Read Full Post »

But is that so bad? Or is it good? I dont know. I just know that I want to have control of the whole chain from idea to delivery. And off course I don’t, but when I loose control of some details I don’t trust that they are done right.


Does that make me a control freak? Or just a freak? Or someone who thinks he is best at everything so better do it myself? You judge.


I am now back to running teams in the dual role of product manager and product owner. The 2 roles we have debated now for a couple of years and that are overlapping. One way of ending that debate is to just combine them in the same person, Who cares where the line is drawn then?


Anyway. I will now be running 2 sprint teams, 2 teams I have worked with before and that I love and respect. But with 6 months of team absence I have come to some conclusions.


  1. I will require to not be first instance for approval of design and stuff. Come to me when designers have approved them, when you are sure they follow the guidelines. Unless you have a totally new idea.
  2. Stories are either DONE or NOT. Its binary, nothing in between. 0 or 1. May sound hard, but good for all in the long run, It makes it really easy to know what will happen, no speculation. Are they DONE, tested, and pass the PO test with acceptance critera, then they are approved. Fail just one bit, and they are Not passed.


These 2 items are my intentions this time.


Read Full Post »

One thing that always cause issues and grief is the boundaries of responsibilities and handovers. Who is responsible for what, and what is the hand over from product management to product owner are just two examples.
And wow, it has been more than 2 months since last post, vacation and summer it is:-)

As we live in an agile world the development team and the product owner work with user stories, but can that also be done between the product owner and the product manager (if you are lucky enough to have both). I dont think so.

A user story tells what I want, why I want it and the developers can build something based on it. But it is also often a small subset of features (try to go to the team with a story saying “As a admin I want good drill down ad hoc reporting so that I can produce any reports at any time”. Its just to big. So you break it down into pieces.

As a product manager you want to have the overall view and therefore doing an epic might be an idea. But the list off acceptance criterias will be very long. So we are then back to the question, what is the hand over from product management to product owner.

I prefer to answer the questions:

  1. What am I trying to achieve
  2. Why am I trying to achieve it
  3. What are the hard facts
If I do that the product owner can first present me with epics to make sure they got it, and then do user stories for the team.

I dont really care of all the details, I want to make sure I get my features, they are

  • designed properly
  • a great user experience
  • solves the business pronlem I forumlated

I can do that with epics and also by sign off on the design. I don’t need to put my nose i to each and every detail/user story.

That would make an epic the sign of between product manager and product owner and the user story the signoff between product owner and team.

It will also let the product owner drive the creative process, and just go to the product manager for feedback, present ideas and get signoff.

Read Full Post »

I have earlier argumented that a Product Owner and a Product Manager is not the same thing. I believe that the Product Owner role as defined by the developer community is one role that has some of the Product Management in it, but by no way all of it. Now its time to show that this is true.

I our latest reorganization (they are always latest, never last, believe me) we split the role. I will head back to Product Management territory and hand over my developer teams to dedicated Product Owners. I will work more with customers, analysts, sales and marketing to define what we call the “what and why” and the Product Owners will then work with the developer teams work on the “how” (this is hugely simplified off course). So now its time to split the roles and make the boundaries clear. 

I will get back to that as we get on with it. But for now I intend to spend more time on

  • What should we do, and what should we not do
  • Why should we do it
  • What are my requirements when we do it
  • What innovative options do I have
  • What is must have and what is nice to have

I will then leave to others to answer the questions about

  • What is the detailed design
  • Who does it
  • How is the error messages formulated

Interesting items to pick up when you change roles and responsibilities are:

  • Where does my responsibility end and the Product Owners start?
  • What is the deliverable from me?
  • What does the Product Owner deliver back, and when?

These questions need answers. Previously I did both roles, and before that waterfall. It will he exciting to now try Agile with separated Product Management and Product Ownership .

Stay tuned for updates….

Read Full Post »

Scope creep is a long established phenomenon in software development. Sooner or later we all do it, with various results.

But doing agile you will also meet the “out of scope creep”.

You have epics, broken down to smaller stories, estimated, planned in sprints. Then in mid sprint the time is not enough. Well its easy to fix, just agree to have some feature in the  story declared out of scope. You will deal with it later, and for now you can live without it.

Continue some sprints, reiterate and replan. Finally you will find that the out of scope debt is huge. You are at a point where the accumulated out of scope is more than a sprint.

In order to avoid it you have 2 options

1. Write really good user stories, crystal clear.
2. Dont do the out of scope creep. Fail the sprint.

We all aim for the first, but sometimes we have to settle for the second. Yes its not fun to fail a sprint, but sometimes its the only honest thing to do. And doing it early let you replan in a more honest way. And better yest, to do it early in the game. With an out of scope creep the replan will come late and be bigger than anticipated.

So stay honest, fail a sprint that should fail. Stop being nice, it’s not nice it is just a way of deceiving yourself and the team. (Product management is never about being nice, and product owners are in the same boat).

Read Full Post »

Some of us have teams that are not in our own office. Being in Sweden and working in a European organization that has always been the case for me. But working with SCRUM and teams in India is a lot different than doing Waterfall and team in Norway.

As a Product Owner in SCRUM you are supposed to spend time with the team. Something that has to be done in a number of clever ways when the team is in another time zone, another climate and another continent. You will end up doing a lot of Skype or similar. And the danger is that the communication is a lot of Q&A and not so much creative discussions. These creative discussions are so much harder to do when not face to face.

So when you sit there, write your stories, do the estimation and planning on phone, then spend a lot of time in Q&A with developers and QA over Skype you will end up with holes in your calendar. You might say, well I can do one more team; I don’t spend that much time on this team.

But beware. Filling X hours a week is only one measure. The art of being available is also very important. If you make sure to fill up your week hour quota you will end up in more and more situations where a developer of QA specialist come to you and you will have to answer, sorry can we talk about that tomorrow, for now I have the daily with the other team, then some other meeting and then I have promised time to that developer and after that that QA and then I need to talk to the SCRUM master.

I am not saying you can’t do it. I am saying that it might be harder than you think and that you should be aware of the danger and sometimes just have to do some hard prioritization (but those of you also being Product Managers should at least be used to that).

So what is the advice?

Start by doing one team. If you later find that you might be able to take one more do so, but also make sure you have a daily time for each team. Make sure you have holes in the calendar to be able to solve issues quickly. Don’t book yourself full any day; you have 2 teams that need you. If you end up with a hole and nobody wants you I am sure you have stories to write and/or test or some research to do.

You can do multiple teams; just make sure that you can do that and still be available to the teams. If you think it’s a drawback not being able to just walk over to the developer and look at her screen and discuss a detail, they feel the same. And if a resource is being denied them repeatedly they will start doing without it (you), and then you are not in control anymore and will get surprises on the sprint review.

So holes in the calendar, remember


Read Full Post »

I recently read a blog by Charles Bradley over at Scrum Crazy where he dissected the new version of the SCRUM guide. One item in the new SCRUM guide is funny

Scrum is free and offered in this guide. Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Yes, the high priests of SCRUM close the door for everyone who does not follow all commandments to 100%. Don’t bother to come here if you change anything. The holy truth is the only truth.

Am I the only one who thinks that there is theory and then there is adaptations we have to do to make it work in the real world?

I have been doing SCRUM:ish last year, and it works. We go along and do sprints, we do the reviews, retrospectives, planning and backlog grooming. But we also adapt to changing reality, need to fix things and need to steer away from the everyday obstacles.

I see SCRUM as a theory and a template. And as with all theories and templates I take them and change them to suit my reality.

So come on, lets do SCRUM:ish and be proud of it.

Read Full Post »

Older Posts »

%d bloggers like this: