This Blog is On.The.Move

I decided to get my own domain and conquer the world from that base.

You can now find me at

ardonio.com

hope to see you all there!

Music

Since Studio Brussel is having a birthday party these days, I wanted to share some thoughts on music, mainly how my collection got where it is. People that were on some of my kot-parties or copied my music at ICT-Blue.lan parties (don't copy music kidz) know I have a rather wide variety of music on my regular playlist.

As far as I can remember, I've always had some thing with music. If I'm not playing myself than there's some music on (my ipod is an always-on device so to speak). I grew up with MTV, back in the day it was not yet hijacked by hip hoppers,  R&B (Rhythm & Boobs anyone?), ringtone ads, ... . The days where TMF was just rising. The times where Katja Schuurman presented "so 90's", the days where Nirvana, Pearl Jam, Bush and The Smashing Pumpkins were all the rage. I played guitar in a (rock/grunge) band for a while (the infamous "Moldy & the blasting nymphlikes"), I still enjoy playing piano and guitar (hell, I sometimes even take a 30min drive to my parents house just to play). All this to simply say: I love music, it runs in the family, and I couldn't live without.

It all started out with hearing what my brothers had on tape (yes, tape, those were the days). It ranged from early Clouseau over R.E.M. to Nick Cave. The inspirational odd piece of classical opera or French popular chanson were brought in by my parents. The parents also included some "pré historie" of late 60's (Ricky Nelson, Jewel Akens, Edith Piaff, ... ).

It's fair to say my brothers (Ardi and the not-online Zors) shaped my early taste. Add on top of that the Sunday morning ritual called "De Afrekening" on Studio Brussel and it's not too hard to see where I got my rock influence.

In the Dutch series, there was 10 om te zien, leaving me with a notorious collection of "foute muziek" (politically incorrect music, think YMCA on a straight, heavy metal, biker party, but worse). An influence that still shows today in my collection through artists like the Backstreet Boys, Take That, Bart Kaëll, Frans Bauer, various aprés ski hits (Drei Weisse tauben by EAV was an instant classic @ Casa Ardonio). Who cares, I like those songs just as much as the more established, politically correct artists.

Little rebellion I am, I dug into house music around the age of 15 (when I started going out on Saturdays). I filled my head with beats all day long. The more the better, hard and fast beats. Me and my friends were Jumping before it became a hype. Times spent in Discotheek BBC, Kokorico and Lamborghieni (simply called "De koko" and "De Lambo" because we were hip & cool and long names were so against our fastbeats life style) introduced me to a new era in my music evolution. I don't know what pulled me into it, but I think Formula had something to do with it (or at least the cover of the single)

I discovered the bliss of trance music in those hellholes. Heavenly voices, violin arrangements, long notes hanging high in the air on a solid line of slightly varying base and rhythm sections. Some of my all time favorite tracks are still the ones I discovered early on in this journey. Think about (amongst others): Delirium - Silence, Maria Naylor - Angry Skies (terrestrial vox mix), Lost Witness - Song to the siren.

For the sake of completeness, I have to admit I took the occasional wigger sidestep. Filling my collection with homies like 2Pac, P. Diddy, Nas, Eminem but also the lighter "black" music such as Aaliyah, All Saints (that's probably more "foute muziek" anyway)

All those beats started begging for a bit of counterweight and a bit more "substantial" music. Slowly, what I liked about trance started to resemble deephouse. The fact that, around that time, the internetmusic really started to be everywhere probably helped on this part of the journey. I also must pay the necessary respect here to my bro/DJ Ardixiv and the gang of KinkyPeople.

As I indicated earlier, I played piano ever since I was a little kid meaning I got some classical baggage. I still enjoy the sound of a well played piano, even on less classical works like this. Next to everything mentioned above this is a constant parallel path that every now and again pulled some classical music in. My hard drive still features a lot of Mozart (probably my favorite), Chopin, Bach, Vivaldi (what would I do without the wonderful rendition of Sposa Son Disprezzeta by Cecilia Bartoli). I recently started to go and see live opera performances. Not for the acting, simply for the live music. There's something magical about hearing opera music performed life in front of you, regardless of the acting and stage setting. It's something even the best in house audio system can't compete with.

The last part of my influence is down to my love for Italy and the language, fueled somewhat more by The Sopranos (the soundtrack is simply wonderful). One of the most memorable moments (music wise) must be the end of season 3 where uncle Junior performs Core Ngrato supported by just a guitar. Simply magical. It's not just the Sopranos that triggered it (even though they helped refueling). I was an early adopter of Andrea Bocelli, the recent passing of Pavarotti made me (re)discover his works (&friends). To top it off, here's a classic in my "Italian" list, a rendition of Caruso by Lara Fabian.

Since I'm a geek and love devoting myself entirely to videogames, It should be no surprise that I've been influenced by the following music stations:

And off Course:

That's a fairly large amount of variety in music I'd say. It pretty much ranges from heavy metal over a whole lot of mid-stream rock (some vids: Smashing pumpkins, creed, pearl jam, guns & roses, R.E.M., ...) over to the more soulful matters (more vids: Norah Jones, Sade, Erykah Badu,...), a lot of electronical influences (youtube all the way: Moby, Hotel Costes,...) to the big classics (Mozart high above). Recent discoveries include Carla Bruni, Soulshine, Vasco Rossi and Marvin Gaye (in  "The Very Best of Motown" 3cd set).

I know I forgot a lot of music I listen to on a regular basis, if I wanted to really detail what I like on music I wouldn't have time to actually listen to it and figure out what else I like besides what I know.

I also promised myself that, as of today, I would start using last.fm client on my work laptop also and connect my ipod to my pc so what I play can be scrobbled (I hate itunes auto-sync, don't bother telling me about that). If I can now take up the habit of regularly changing the 8Gb on my ipod that should give a reasonable last.fm in due time.

Product Ownership, in reply to Bramus!

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).

Product Ownership (6)

In this post I'd like to elaborate on the last point from the introduction. You can read this post as a standalone, or you can go back to the introduction, part 2, part 3, part 4 or part 5.

Point 5: "No other job"

No other job, that would indicate that you dedicate all your useful time in the office (there's always some overhead). Just think about that idea. Only having to care about one project would allow you to shape up on the knowledge you need, take your time for all the stakeholders, spend enough time dissecting the backlog, have regular talks with the team, provide timelines and other needed documents for project support and follow up amongst the golf players of this world, ... AND you probably still would have some sort of social life left. Doing a good job as a product owner is a full time job, if you don't believe that, try being a good one. So really, I literally mean, not having any other job.

The statement also implies a second thing, because no other job means no other priorities. 
We all know the office is rigged with politics and hidden agendas. I think as a product owner guarding your own neutrality in that jungle is something you should aim for.

Looking at it from a pragmatic side, it might be worth having a product owner governing a few related products. It means a good use of needed knowledge since, amongst similar projects, often similar knowledge is needed and generally the same (or big overlapping) group of stakeholders is involved. The downside is that it might somewhat distort the product owners neutrality.

I'd like to use these last few words as some kind of a closing note on the entire series. A lot of it was written with a perfect world in mind and with the idea that there are little to no personal preferences and/or tradeoffs to be made.
Since we don't live in an ideal world, I think it's important to carry forward the ideas and try to implement these in the best possible way. You may not always get what you ask for, but being creative with what you get is never a bad thing.

Product Ownership (5)

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.

Product Ownership (4)

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:

I prefer  a slight variant to it:

[[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)

Product Ownership (3)

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"