Agile Product Owner - the New Project Manager Role

Dear Junior

From time to time I hear claims that: "with agile/Scrum, there will be no need for project managers any longer - they will have to find some other job". This seems strange to me, I get what they are getting at, but the analysis is very incomplete.

To start with, a role cannot go and find some other job - role is a job description, not a person. A person can go find "some other job". So, I guess that they mean that all people currently employed as project managers will have to go find themselves something else to do, because "Agile" has come along making them as obsolete as the advent of cars made company stable-hands no longer needed, simply because their skill sets where no longer needed.

Interpreted that way, I can see what they mean. If you have a project manager, who's major part of the workday is to "administer resources" by assigning tasks to programmers and controlling the result - then than those tasks will be absorbed into the Scrum team (using Scrum as an example) and their self-organisation and commitment-driven collaborative work under the lead of a scrum master. And, if the rest of the workday is filled with planning and fiddling with requirements - then those tasks will be absorbed by the engaged, involved product owner (still using scrum as an example). What is left in-between is the clerk accounting tasks like compiling time reports and other stuff - and those things are not considered necessary any longer. Thus, what are left are unemployment, retraining, and disappearance from the scene.

Throughout my years in software development I have met more than a few project managers. Some of them have done a good job and I have gained respect for their skills and efforts, some not. For those, I have not been impressed by, the above analysis hold - I think software development as a whole, and the poor teams they managed specifically, are and would be better off without them. However - the good project managers I have met have made a difference through their skills and efforts - chasing them on the door for having "project manager" on their business card would be a serious mistake.

Where do the skills of these good project managers fit in the "Brand New Agile World of Scrum"?

The naïve answer is often "they become scrum masters". However, when I look at the tasks and skills needed for being a scrum master, and at the skills of the good project managers I have met, I do not see a very good match. Well, "good leader" is a match, but then it stops. The scrum master leads the work in a very tight loop, facilitating the synchronisation of work between programmers, keeps the work focused on the next "smallest step" etc. If I would appoint someone as scrum master, I would not look among the project managers, I would look among the programmers, looking for the informal leader, the one trusted and respected by the rest of the team; perhaps the person already have a title like "lead programmer" or similar. Given complete freedom, I would probably go even one step further: I would let the team itself elect the scrum master, with some mandate period and some mechanism for re-elections.

If not scrum master, then what to do with our excellent project manager? When thinking about where I have really seen them making a difference, there are a few skills that pops into my head. First, they have been leaders with a vision. Even tough they have had some kind of steering board or committee that supposedly has given directions, it is the project manager that has embodied the vision and purpose of the project, and done the job of "walking the floor", being involved and keeping people engaged. Secondly, they have had a really good grasp of requirements and prioritisation thereof. They have understood to the minute detail what the system should do and why, they have been available to answer questions and straighten question-marks when needed. And, thirdly, they have taken responsibility, making decisions when needed - even when putting them self at risk by not waiting for the next steering committee meeting to pose the question, realising some decision is needed right now.

So, where do these skills come best to use in e g Scrum? It should be pretty obvious: they should be product owners!

But, the product owner, should that not be the Manager of Web Sales, or some CXO? For crying out load: NO! No CXO I have met have the time to do a good project owner job. They will not be willing to spend at least an hour a day in the programmers' workspace to answer questions, they will not be at the daily standups, and they will not come to the retrospectives. The former project manager will do all this. And will most probably talk with the Mgr of Web Sales and the CXO, as they are important stakeholders (former members of steering committee), to understand the interests at stake in the system, where after she will make an informed decision, now also having the formal mandate to do what she has always done.

I wish I could give one piece of advice to the excellent project managers I have met. I that case it would be this: do not get fooled to think you should become a team lead or a scrum master; it is a waste of your skills. Your role in the brand new world of agile is the one of a product owner - do what you have been doing so well, now with full empowerment. We all need you there.

Yours

Dan

ps Check out my fellow Swede Anna Forss' essay on "Confessions of a Serial Product Owner". She is an excellent example of a project manager turned product owner. She is also one that shares my interest in the combination of domain driven design and product ownership.

pps Some of the skills for priority of requirements/stories I have seen at good project managers that would make excellent product owners are spending a lot of focus on keeping things upcoming really crisp, and let the rest of the list be a little bit more informal - but never sloppy.

ppps There are many ways to describe a good product owner. One is through the four characteristics engaged, involved, decisive, and empowered.
ppps To give credit where credit is due, the fragments of this idea had been lingering around in the back of my head for some time, but it was not until my friend and colleague John Wilander said it out aloud that I got the push to phrase it properly.

Philosopical Difference between Values, Entities, and Events - a Matter of Existence

Dear Junior

There are numerous ways and rules-of-thumb whether to choose entities or whether to choose value objects when modelling a domain; but I have for long felt that there is a deeper philosophical distinction that I have still not been able to nail down – but now I stand the risk of a try. It is the distinction of their “nature of existence”.

For things that we view as entities, e g people, the set is clearly partitioned between those that do exist and those that don’t. For example, the person I reference as ‘me’ does exist (proof: cognito). On the other hand, the person ‘Dan’s brother-in-law’ does not exist, as none of my sisters is married (at the time of writing, and to my knowledge). Whether the person ‘the father’s father of Dan’ exists is of course a modelling choice – do we only model people alive, or anyone that has been alive? In either case the class ‘people’ is split in two disjoint and exempting subset, those that exist and those don’t.

This is also the reason for entities often come with a repository for finding specific entities (if they exist), and why we have to be prepared for handling entity-does-not-exist conditions. So the question of existence makes a huge difference in the use of entities.

For things that we view as values, e g colours, the question of existence become more academic. Does ‘blue’ exist? Well, there are definitely blue things around us, so we can say that it does exist. Does the colour defined by RGB (112.345, 43.23, 203.447) exist? Well there might be a thing in the world (even in our modelled part of the world) with exactly that colour. On the other hand there might be no thing with exactly that colour. The end point is that, whether there is such a thing or not does not feel relevant to the question of existence of the ‘colour as such’. So, if the mentioned colour exists, it does so rather in Plato’s world-of-ideas, rather in the physical one.

This is also the reason that value objects do not come with repositories. There is simply no usefulness that comes with answering the question ‘does blue exist’. The question of existence makes no difference in the use of values.

What finally set me on track for these thoughts was the use of ‘domain events’ (e g the arrival of a delivery, or a failed authentication) as a modelling tool. I think it is the ‘nature of existence’ that has felt awkward when modelling these as value objects, as that is what I have done. I simply modelled them as value objects because domain events are immutable, and so are value objects – but that is obviously (in hindsight) a line of reasoning en-par with “roses are red, so is father Christmas, ergo father Christmas is a rose". Now I see the faults of my way.

To my defence, I have also acknowledged that events either have-not-happened or have-happened, so there has been repository-like functionality from time to time to account for that distinction. So, they have been value objects with flavours of ‘entitiesm’ to them.

Finally, ‘domain events’ have sprung out of this Hegelian didactic tension. They are immutable as value objects, but they are not value objects as they have a conceptual identity. They have the same ‘nature of existence’ as entities, but they are not entities as they do not evolve their state over time.

Put another way: mutability makes the distinction between entities and domain events; substitutability makes the difference between entities and value objects; and ‘nature of existence’ makes the difference between value objects and domain events.

At least one way of putting it …

Yours

Dan