Archive for the 'product owner' Category

15
Feb

Retroflection

By Don Ardonio 0 Comments
Categories: agile, management, product owner, scrum and twitter

I’ve been following retroflection for a while now and I promised myself time and again that I would take some time out to write up an answer. But first of all, let me say thanks to Yves for doing this. I may be a rather quiet follower most of the time, but I have enjoyed many of the retroflections so far and hope that by the end someone is clever enough to put all of them, with comments and reactions, in a single something (I smell a possible book release…)

To the point though. Today’s retroflection: “What made you ashamed of yourself today?”

I’m mostly ashamed of how I let the state of our backlog degrade. We’re mid sprint (2 week sprints, this is the start of week 2) and we have an upcoming backlog grooming/planning session on Wednesday. Today is generally the day where I take time to sit down with our product owner and start pushing him on unknowns in the backlog, getting the priorities right, questioning requirements and in general make sure that the engineers have something they can actually work from by Wednesday. Lately however I’ve largely neglected the backlog (not looking for an excuse) and it’s now grown into an unorganized cancer of stories that have little relevance, even less description and it just looks downright ugly.

So I’ll use today’s retroflection as a reminder to myself that backlog maintenance is a daily task for a scrum master and that I shouldn’t let the backlog get to this point again.

23
Apr

don’t take it personal…

By Don Ardonio 1 Comment
Categories: agile, management, product owner, scrum and software

In the scrum world there are various roles. There are team members, a scrum master, a product owner and stakeholders. Each of these have their own specific aspect to deal with and all serve a distinct purpose. Obviously, it’s pretty essential that each of these roles is filled with people…and that’s where it gets tricky.

Often, there is no straightforward mapping between a role and a person. I’ve written my vision on good product ownership earlier on this blog, and even though over time I may have changed some of the accents I still stand by what I wrote back than. Let it be clear I was writing about the role of a product owner… . I think you’ll find it very hard to find a person with the right blend of capabilities. So let’s open up the question: “Should we have not one product owner?”

I’d like to argue that you need at least 2 people doing this. (not necessarily 2 full-times). One person who is more aware of the technical side of things (let’s call him the technical owner) and one person who is better at the business side (business owner). Somehow it is very hard to find a combination of these 2 in 1 person.

Now I can see all of you wonder:”That doesn’t jive very well with the concept of a single wringable neck”. And indeed, it doesn’t at fist sight. The problem with this definition of single wringable neck is that it is founded on the principal of accountability. The product owner (part of “the business” in the strict sense) needs to step up, deal with stakeholders and direct the team. He is accountable, he needs to step up. The fact it is “single” is because that makes sure that this person can’t hide behind others. He and only he is accountable for the project. Now there’s a pretty heavy burden :). I like to believe that part of this movement for accountability of the business is based in the dark and evil times where engineers were making decisions based on their interpretation and afterwards pretty much shot in the head for taking the wrong decision. (it happened to all of us, I’ll explain some other time why engineers shouldn’t make business decisions most of the time)
Either way, the accountability movement explains the single, let’s not get stuck on that. I believe that a team of 2 can be held equally accountable than a team of 1.

Since product ownership is a role and not a person let’s take a look at combining jobs. Earlier (on my old blog) I argued that product owners shouldn’t have another job. This is one of the areas where I have refined my ideas in the meantime. I can see cases where it would be possible that a product owner (technical owner) goes head first in a discussion with the team on architecture or feature design. Even though, strictly speaking, product owners (the role) shouldn’t get involved in dictating implementation detail, having your product owner (technical owner person) guide you might be very beneficial for both team and owner. The owner will better understand the system and the tradeoffs made, the team will probably better understand the requirement and direction that the business wants to take. It really all depends on the skills you have available within the people.

Summarizing

  1. Having 2 product owners is often a compromise born out of necessity for mapping an extensive role to people with the right mix of skills
  2. It doesn’t go well with the “single wringable neck”, but that statement needs to be seen as a child of its time. It’s about accountability of the role, not about the singleness of the person
  3. Making optimal use of the skills of every person can perfectly well lead to a bit of fuzyness and combination of certain roles (or parts of them)

In the end…Agile, much like the pirate code, is not a strict code but more a set of guidelines. In the end we’re dealing with people, not with roles. The roles only help us grasp the concepts. Agile is still about common sense.

15
Apr

Technical Debt

By Don Ardonio 1 Comment
Categories: development, product owner and software

Technical debt is a concept which I never fully realized how accurately it is named. (I have to thank some colleagues for listening and discussing this subject on several occasions)

For those not ‘in the know’…technical debt refers to dirty pieces of code/db design/UI clutter/… that build up over the time of a project. They can be due to changing requirements, time pressure, developer oversights, … . Essentially it’s the stuff you don’t want but somehow hardly ever get round to really cleaning up, as they don’t necessarily generate bugs or functional problems. And rest assured, every piece of software (of a significant size) has it. As all developers know, there is no such thing as perfect code so there’s always an area to refactor, improve or otherwise clean out.

Back to the name though…Technical debt really is a debt. Extremely comparable to monetary debt. In a typical situation monetary debt comes from you buying something that costs more than you can afford at that time. So what you do is: you get an instance to give you what you want and you work out a plan to repay them. That plan entails a couple of things. It looks at what you can afford to pay them based on your current paycheck, it looks at the length of time it will take before you are without debt again and they will charge you an extra fee on top of the amount you borrow for their service. But above all, based on these conditions they will set a limit to the amount of debt you can accumulate.

Oddly enough, technical debt isn’t all that different. You create that same amount of debt when building software, for reasons I mentioned before. However the big difference is that there is no governing body that puts a limit on the debt you can accumulate. It doesn’t take a rocket scientist to figure out this is indeed a baaaaad situation. If you keep on building your debt it means that maintenance becomes harder (i.e. you *pay* more for doing a small change than in a clean codebase), new features become “just another hack” in the software, there are exception routines everywhere and this spiral keeps spinning down. Eventually this will drag down your development velocity and ultimately will grind your project to a halt.

This is where, for me, good product ownership (/project management) comes in. The product owner can help here in several ways…

  1. Understand how technical debt gets created (i.e. understand the implications of selecting a specific implementation)
  2. Allow developers time to gradually work away that debt. This also means standing up to the business and actively refusing new features* (just like you wouldn’t buy that Porsche if you know that you can’t pay off your house anymore if you did)

*actively refusing is obviously more than saying no. It means working out a plan on where features can fit in and/or look at the scope. The essence is really to work away technical debt as part of the entire planning routine.

25
Mar

Product Ownership, in reply to Bramus!

By Don Ardonio 5 Comments
Categories: product owner and scrum

My pal Bramus! (mind the exclamation mark) was so nice to post a long comment on the series. Instead of replying on the comment, I decided it deserved a full post. (I’ve snipped the comment, the original can be read here).

Define a set of features/tweaks for the next release and go for it.
Hereby I keep a list of urgent/less urgent/nice to have which indicate the priority (the so called backlog).

This sounds more like a release plan to me, in which you define a feature set (number of groups of stories) that will be delivered. Generally these will take some time, and you will divide your time in sprints. Part of the power of sprints is that they allow a certain pace and rhythm (each sprint takes the same amount of time), making your process and release dates predictable to a certain degree. (you’re never sure since you’re estimating).

However I implement these in a kind of a waterfall method (define, implement, test, fix bugs, final). Don’t know if I get the full picture here, but to me a sprint seems like a mini-waterfall to me.

Part of scrum is based on reducing the time between development of code and the testing of it (hence test driven development) and making sure you have something ’shippable’ at the end of every sprint. So you could indeed look at it as a mini waterfall (there are points where it doesn’t hold true, mainly in design phases and the command&control style inherent in waterfall systems)

You wrote “In order to do all this, there is no way the product owner will get away with having a high level overview of what the product is supposed to be”. Shouldn’t that be without?

I admit, it’s not the most wonderful sentence I’ve ever used. What I intended is that he won’t get away with JUST having the high level overview. He needs more, deeper understanding. He won’t get away without any overview also, but that’s a different matter altogether :)

Adding more developers, will increase the price, leaving less money for the development itself (as you indicate).
Yet, when adding more resources, the product won’t necessarily improve the product (once read: “nine women can’t deliver a baby in on month”).

I know that one, but there is an essential difference. Women are people (yes, they really are, I’m not just saying that because of wijvenweek). If delivering a baby would only require thought (=cpu power) it would probably be possible to deliver a baby in one month with nine women. (probably little over a month due to the overhead generated by nine women). Never thought I’d say that one day :)

Yeah, I’m a bit confused on the placement of scope & resources in the variant (IM me :D)

Will do. Or we’ll catch up sometime at one of the local bars.

the final goal must never be kept out of sight.

Couldn’t agree more.

And to the questions you asked: no and yes. Two obvious answers imo as ones decisions are highly impacted by knowing what’s possible and what’s not (cfr. “A good enough technical background”)

Had an interesting discussion about this with someone arguing that a project manager (slight difference to product owner) doesn’t need technical baggage. To a certain degree I can follow this logic. However, if you think scrum is widely used on software development projects, I still would like to see the first project manager on a software project who hasn’t got a technical background and does a really good job. On more operational projects, I agree you can get away with less of a technical background, but that’s somewhat outside the scope of the series.

Yes, guilty of that one, I’m a freelancer too after hours. And yes, that affects my day job one way or another (both in a positive and negative manner).
However, the interpretation of job can be expanded as in “no other big projects to handle” as one cannot focus the full 100% on the project otherwise

That was indeed what I had in mind when saying job. This being said, in an ideal world the fact that you freelance after hours shouldn’t have any impact since it’s after hours. Product Ownership is a full time day job, it’s because people (golf players) are not taking it seriously that they are putting it next to someone’s day to day job. This ends up in that person doing 2 jobs and generally resulting in a poor job on the product ownership side (it is perceived a side job after all). If one wants to do it right, it takes more time than what is available in a normal week resulting in less free/personal time, and in that case it starts negatively affecting the freelance business (and vice versa).

14
Mar

Product Ownership (5)

By Don Ardonio 0 Comments
Categories: agile, product owner and scrum

Continuing the series on product ownership, here’s links to the previous parts: Introduction, part 2, part 3, part 4.

Point 4: A "business sense" and a vision

When I was first thinking about the qualities and how they fit together I had a bit of a hard time placing this one. I felt they are essential, but couldn’t really nail down how or why that would be.  Not just the combination of business sense and vision, but also how a product owner should use these.
The more I was thinking and organizing my ideas, I started to see that they are actually closely related and rely on some of the other qualities I put forward earlier. It brought up some interesting discussions and ideas, which I’ve tried to capture in this post.

Since business sense is a pretty subjective and vague description, I’ll clarify what I mean by that. To me, business sense is all about making good decisions. And in order to make a good decision one would need to understand the tradeoffs, the iron triangle, such concepts as risk vs. value. All these need to be balanced in order to make a good decision imho. So you could sum it up as "the art of making a good decision at the right time". Some of this can be picked up through study and/or experience. What is harder to pick up is "seeing an opportunity", this is where a vision comes in.

A vision could be defined as a long term strategy or goal. Often, it’s not realized overnight but in small incremental steps. Other terms that could indicate a vision is "the Plan" (with capital P), "the big picture",…. Since a vision is some thing like trying to see the future, it means that some assumptions and question marks will be present.

Keeping the above definitions in mind, it’s fairly obvious to see that good business sense is essential for a product owner to make the right decision at the right time. Or at least, to make the right decision with the information known to him at that point. Which to me also makes the decision to gather more information and not make a final decision (given that there is enough time to do so) an equally good decision to "yes" or "no".
A product owner with a well developed business sense should be able to prioritize and make clear decisions about the backlog. This is supported by good communication and negotiation skills, which allow him to convince stakeholders and to get an open dialog so it works, as much as possible, for everybody.

On the vision part, the product owner should be the one guarding the vision, that does not mean he has to be the only one creating it.

I’d like you to think about 2 questions before reading along (and feel free to disagree with my answers below).

  • Can a vision be defended without a deep understanding of the problem?
  • Does the amount of understanding the problem have an impact on refining or adjusting the vision?

I’m inclined to say no to the first and yes to the second. And here’s why.

If the vision needs to be defended, chances are pretty high that there will be an argument on the assumptions and question marks or, in general, on the more vague parts of the vision. In a good vision, those vague parts have been filled in somewhat with a belief, an assumption that is based on knowledge in some way, shape or form. Knowledge, typically drawn from the problem domain. It could be a predicted market change, a new technology that’s upcoming, a desired feature that would give competitive advantage, … . And in order to defend that, you better know what you’re talking about.
On the second question, my answer is yes for a rather similar line of thoughts as the previous. If you end an argument with a need to adjust the vision, typically you’ll be adjusting/refining the vague parts. If you half understand the problem, how will you refine or adjust the solution?

As a final thought, here’s how I see business sense and vision working together. If the vision is your end goal, the business sense makes sure you follow the right path to reach it, with small steps at a time.

12
Mar

Product Ownership (4)

By Don Ardonio 0 Comments
Categories: agile, product owner and scrum

This post is part of a series on my view on essential qualities for a good product owner in scrum. If you just bumped into this post, here are the previous articles: the introduction, part 2 and part 3.

Point 3: "Great communication and negotiation skills"

Let’s first of all pull up one of my favorite pictures about project management.

The traditional representation looks like this:

BQTS

I prefer  a slight variant to it:

BQTSR

[[small sidestep, skip if you understand the pictures]]
For those that never seen this picture, here it is explained in an easy way.
Scope = what needs to be done
Budget = money, people, hardware, software, …
Time = days till delivery date
Quality = how good the result is (compared to what the customer asked for)
The triangle is sometimes called the iron triangle (there are a few variations out there). Each side and the surface representing one of the aspects. Since it’s an iron triangle you can’t change one aspect without affecting the others.
What the second version factors in is that scope & quality are closely linked. They actually fight for the same area in the triangle, meaning they mostly behave in a "scope+quality=1" manner. The only way to improve both is generally to play with the sides of the triangle to provide a bigger surface.
The other nice thing about it is that it takes out the resources (=people) from the budget aspect. In most development projects, adding developers is not something that is as easy as adding more hardware or software (which typically falls in the budget area)
[[end sidestep]]

As far as I’m concerned, this is one of the most fundamental pictures to understand. The good news is, it’s not rocket science. The bad news, you’ll always be fighting about at least one aspect of the triangle.
The thing that is not on the triangle though, is equally important. Communication! I consider communication the glue that holds this triangle together. I already expanded on communication in an earlier post. What is said there still holds true (hurray), and the key point in this case would be the feedback. Because feedback means exchanging ideas, ideas generally mean new ways of looking at something and eventually coming up with a solution. In the case of our triangle, that solution might be to make a tradeoff that suits all stakeholders as good as possible. Or put differently, communication is a key aspect of negotiating. And both skills are indispensable to come to an agreement.

Another part of reaching an agreement is striking a good balance between complexity and added functionality, based on the time (and other aspects in the triangle) that are set. This is where the negotiation really kicks in. Every stakeholder feels his feature set is the most important, highest value, first to be developed feature. And probably, in their distinct worlds, that could be very true. However, if stakeholder A is asking a feature that is so complex it would take 2 sprints of the team, that would cut off the minor update for B and that small module for C for at least another 2 sprints. Stakeholder A’s feature may bring some added functionality for B also, but C has no benefit. Where do you go from there? This is where it becomes interesting. How do you balance this? (on a sidenote: yes, I love thinking about balancing stuff also outside game design)
This is where the scrum metrics velocity, business value and storypoints (indicators of complexity as I like to see them) come in handy. They provide you with ammo for your negotiations. How you get out of the situation above? I would probably ask A to split up the 1 story in multiple stories first of all, and see how B could benefit from some of those . Since they are split up, they shouldn’t require 2 sprints and complexity on the individual elements should go down. This would open a time for C’s request to be fitted in.

The last part of this communication is something I already touched in part 2 of the series. There is a need to communicate with a wide variety of people. Ranging from hardcore developers to golf playing VPs. The way something needs to be presented to those groups is without a doubt very different. In an ideal world, you would have a product owner that can easily summarize technical detail into executive summaries and can expand executive thoughts into detailed user stories. Read that last sentence again, it’s key to solving many problems. Speaking the right way to the right person is something I tried to get through on my old blog one time (I’m not entirely happy reading back that post now, but still, the idea in there is key to this last statement)

07
Mar

Product Ownership (3)

By Don Ardonio 0 Comments
Categories: agile, product owner and scrum

In this article I’d like to elaborate on point 2 of my take on good product ownership qualities.
The introduction can be found here, point 1 is here.

Point 2 is: "A good enough technical background"

I know this is a somewhat controversial topic amongst many of the people I spoke to, yet I still think it’s an essential quality.

First of all, how do you define "good enough". A tricky issue and a very subjective matter in my opinion.
Secondly, all of us who have a manager that used to be a technical guru know that he generally misses the deep technical stuff. It’s the reason why most technical managers still like to play with Lego, they make tiny constructions in their office with their pens and paperclips and a lot of them still love to write some piece of software at home. Given all this, I think it’s fair to say that they just miss the "creating" part of software engineering. The technical challenges, coming up with solutions and riding the high waves of new technology and its possibilities. This is one big caveat, and I’ve seen a lot of product owners fail there! (and most people learn it the hard way)

Looking at the natural order of things, it feels normal in the early stages of a project for the development team to drive a lot of the priority settings. They know best what base layer is needed and which components take precedence in order to reach that first thin end to end slice of functionality. They understand what infrastructure needs there are and how low level components (generally those a user will never notice) need to be available before the first features can be built. (sidenote: I am not trying to say they will have a big design up front cycle, but just enough to understand the dependencies). Having a technically trained product owner will help the team out in defending this priority setting to the stakeholders, even though they may not always understand why there is such a need for a "non visible" component or feature.

This being said, that cycle can’t go on forever. At a certain point (you’ll feel it when it’s there) this needs to change and the product owner needs to start taking charge of priorities, based on stakeholder requests. Here again, it takes a product owner with a technical understanding to see when a project is ready for this switch (it’s more of a fade than a hard switch anyway). The risk of not having a technically skilled product owner is that the team will keep running circles around him and develop "cool" features (for developers) instead of listening to what the market is asking for. On the other hand, when a product owner is in his mind still too much of a developer, he’ll happily agree to keep working on those cool features and start ignoring stakeholders and market demands. He’ll drift away as part of the development team and that early stage cycle will never be broken.

So, how would one define the "good enough" than?

In my opinion, good enough means something along the lines of:

  • able to understand technical problems and solutions to an extent that an autonomous judgement can be made on the progress of the development team. This generally requires a product owner who did do some development himself.
  • able to grasp the complexity of a proposed feature and its underlying needs
  • able to understand the high level architecture of a system
  • able to place the development team on an equal level to other stakeholders and make a decision based on business demands rather than on "coolness"
05
Mar

Product Ownership (2)

By Don Ardonio 0 Comments
Categories: agile, product owner and scrum

Continuing on my earlier post about Product Ownership, I wanted to dig in a bit more in maybe the most obvious of the items on my list.

"A deep understanding of the problem".

The product owner is the main point of contact for all stakeholders. In most projects these are a set of very different profiles, ranging from high-tech to no-tech and from senior VP of directors to working class heroes. In order for your product owner to communicate well with all those parties he needs to be able to give the executive summary of a project, but also to have detailed discussions about problem areas.

Imagine the following scenario. A simple project (if there is such a thing) to develop a piece of data displaying software to track impact of press releases. Your main 3 stakeholders are a senior marketing executive sponsoring the project, some junior on the marketing force who will be mostly working with the tool but hasn’t got any skills beyond viewing a form in access, and a data analyst who is used to slicing and dicing data with custom scripts and queries.

In order for your product owner to be able to effectively communicate with all these people he needs to be able to give the executive summary, work with the junior in understanding his requirements and translating these into backlog items and, lastly, working with a data guru who thinks in hooking custom scripts and plugs to that output and cares about APIs that should be in there.

These are, in my opinion, 3 completely different approaches to be taken. Perhaps the executive summary could be winged with less understanding of the problem, but that would definitely harm the credibility of the project. Working with the junior may require mostly listening and trying to slot his requirements in a timeframe that would suit him best at any given time. The last one will delve deep into the technical aspects. Some of these requests are better taken up with the developers, but the product owner should at all times be a first point of contact in order to shield the development team from deviating from sprint tasks by outside requests.

In order to do all this, there is no way the product owner will get away with having a high level overview of what the product is supposed to be. He will need to filter out requirements, talk stories through with developers, give regular feedback to his stakeholders and really be just as involved as the development team in order to reach the goals of this sprint.

Since the product owner is equally committed and involved, and will stay involved during the entire project, replacing him is something that would add the same amount of troubles and overhead as replacing anybody in the team. The problem with replacing a product owner is that he is a first point of contact and the "external" interface. Meaning that he doesn’t have a lot of margin to slip up. Any slip up, miscommunication or doubt in understanding the project may (and usually will) result in confusion, angry stakeholders, a mess as to who is the actual product owner. And especially that last part is concerning. One of the most difficult tasks to handle, speaking from experience, is having a lot of channels that are all directly talking to the development team and setting their requirements. The development should focus on development of whatever is needed. It’s not up to them to make decisions about what is a priority to the business. And doing so requires a strong product owner, who understands the problem at large.

19
Feb

Product ownership

By Don Ardonio 1 Comment
Categories: agile, development, product owner, scrum and software

I’ve been catching up on agile development lately, more specific, on the scrum methodology.

After sorting through various books, course material and tons of useful talks to colleagues, peers and agile people (not necessarily claiming they are agile but definitely adopting the concepts). First of all, I wish to thank all of these people for the time they took to educate me. I feel at a point now where I have a grasp on how it works and I’m past the steep hill in the learning curve. A good time to look back.

Starting with a statement: "Having seen the waterfall system in action one to many times, I am sure there is a better way". This, combined with my current employer wanting to adopt scrum, is what drove me down this road. Being on the operational side of the building, I have been experiencing product ownership from up close and here’s what I think are important qualities for becoming a good product owner.

  1. A deep understanding of the problem at hand
  2. A good enough technical background
  3. Great communication and negotiation skills
  4. A "business sense" and a vision
  5. No other job

Unfortunately, many companies (including mine), horribly fail at most (or even all) of the above, especially the last one.

In the coming articles, I’ll be elaborating more on those 5 points (= nice hook to have some more articles on my blog :) )