Archive for the 'scrum' Category

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 0 Comments
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 :) )