Product Ownership (2)

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.

Tripit, it just works

Albert Einstein once said: "Everything should be made as simple as possible, but not simpler." That's exactly what TripIt does.

All TripIt does is aggregate all data that you get from confirmation emails when booking flights, hotels, rental cars, ... . Adds in bits of information scraped from the likes of wikipedia, the weather channel, google maps, ... . It doesn't require a genius to come up with this, parsing some standard generated emails is a piece of cake. Adding in extra info may require a bit more effort, but still isn't rocket science. Nothing all that brilliant at first sight, but here's the catch.

It's dead easy to use, it's fantastically thought through and cleverly crafted to minimize your effort. The lazy web at it's best.

Really, all you do is forward those nasty gibberish confirmation emails. Tripit will figure it out for you. It doesn't require a lengthy, time consuming, sign up procedure. Since you sent them an email, they know your name and your email address. That's enough personal information for one day isn't it?
Once you forwarded your first mail you get a nice return mail (caught by my company spamfilter, but they are aware this happens often, unfortunately). That return email contains a link so you can quickly go check out your travel plan, at that point you'll be prompted by a "real" sign up, which has a nice skip button. So you can easily use it without having to register. Ever!
Further in that return mail is also a username (your email address) and a password, for future log-on purposes.

Finally, to add in some 2.0-ness, you can share and discuss your travel plans with friends (or colleagues) and figure out who out of your network is close to you. I still need to get some friends hooked up on this, so I can start checking this thing out :)

Conclusion. Awesome, it simply does what it needs to do, without making it complicated, time consuming. And since 90% of the population uses the same top airlines, travel agents, car rentals and hotel chains, it's able to parse everything most people will ever need (you can still manually add/change if you really have to). I know the year is still long, but this is already a huge contestant for my personal "tool of the year" award!

Also check out the demo videos. It really is that simple.

Product ownership

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

Ardenskie 3.0

For the third year in a row, a bunch of former fellow students went on a weekend to the Ardennes. Doing all you expect a bunch of geeks to do on a boys-weekend-out. Upon arrival, the big table was taken by a 24 port gigabit switch and laptops, network cables, gizmo's and other electronics. Not that we spent a lot of time there, just every now and again setting a queue to borrow some of the friends material.

Friday night was mainly sponsored by Dr. Oetker and Jupiler. On Saturday we took some time out to sit back, chill and enjoy some of the local beverages. I put my hopes on Captain Morgan (original spiced rum), he didn't disappoint me. It's nice to just sit in the sun, share time with friends and forget all about the daily worries, even if only for a day. We ended up in Durbuy at night, in a near empty restaurant. After getting our food served, we started to understand the near emptyness of it. The food on it's own wasn't bad, but "serve with a smile" seemed an odd concept to the place. Too bad, we did have money to burn if they did some effort.

Sunday, traditionally, ended at Don Antonio for an excellent fresh made pizza.

Memorable facts of this edition:

• Vicious Vince (aka Poofter) calling the sleeping people at 3am to hear their ringtone.
• Bladders, Eraser, Crossmol and myself going shopping and buying all of the Mozarella Discs available at the local Delhaize.
• Bladders having a bit of a jet-lag after 2 weeks Shanghai and so waking up at 7am every day.
• Azzy doesn't like pizza, and still he's our friend :)
• Many more, not all suitable for publication

Many thanks to the usual suspects for making it a great weekend. Poofter, Rubella, Punkie, Azzy, Apolio, Eraser, Bladders, Crossmol.

Why we will not have senior developers anymore

I have the pleasure of working with some people who live and breath software development. Coming from the old days where assembly was new and cool and above all something that made you think about the inner workings of a computer.

Now what makes a software developer senior?

These days it seems like becoming "senior" developer means having a few years of experience under your belt. You can easily have senior guys who never did anything else than php or .NET development. (nothing against php or .NET if used under the right circumstances, don't get me wrong).
To many businesses this would qualify as someone who would be labeled 'senior'.
I think there's a bigger issue here. Those new senior developers don't have that deep understanding that many of the current senior developers have. They never had to be bothered with allocating memory or worrying about limited hardware resources.

The current trend seems to evolve to "if we have an issue with resources or performance, we'll throw some extra hardware at it". I understand Ruby relies heavily on this principle, after all, development time is more expensive than cpu time.  A fact, just like looking good is more important to Paris Hilton than having something useful to say.

I personally doubt this level of seniority somewhat. They might be very good developers, but in their own language. When it comes to high performance apps and scalability, often it requires an intimate understanding of the inner workings of a compiler, down to bit level.

The "old" senior developers know for every line of code they write what bits move around, how that relates to the heap and stack. They intimately understand Pascal and C strings and the (dis)advantages of both, or why certain algorithms are more scalable than others. Simply because they grew up having to care about every bit in that machine.

Our future senior developers...

These days people often don't get down to that level of computing. They have fancy things like objects, garbage collectors, excessive amounts of disk and memory available, ... . And they often start out with a higher language like Java or C# which makes them unaware of all these intriguing little details that make or break large scale applications. I don't blame the persons, those who really want will still find all the information necessary to get that understanding of the machine.

I think we should start reconsidering our school system (for Belgium for sure) and start teaching our computer graduates the basics first before letting them have a go at a high level language which takes away a lot of the machine related problems. In their first years, give them an 8086 or an emulator that lets them run assembly. Make them aware of address registers, stack and heapspace, allow them to fool around with 0 terminated strings and the up and downsides. Make them feel the pain, they will even more so appreciate the higher level languages, but above all, they will learn why some things simply require a lower level language.

This is a call to all deciding people on school boards. Don't try to have a sexy education with fancy new languages, just get a good old hardcore education that teaches what they need to provide the world with senior developers.

2008

Everybody seems very preoccupied by lists around this time of year. So for what it's worth, here's a personal round up.

Last year has been a year of firsts. First business trip across the ocean, first powersuit-mandatory meeting (for an engineer, go figure), first product launch, first feedback after a 1.0 product. All in all, it looked good. On a personal level, I finally moved away from the love and caring home my mother provided me all those years (thanks for that). All in all, it's been a good year (no, not the tires) for my NADD brain. A lot of frequent changes, a lot of fun, a lot of pressure (somehow, I like that) and living on the fast track in general.

When it comes to 2008, I have no device to see the future so I can only hope and wish. Most of what I hope for is very similar to what I had in 2007. 

As Kane would have said it:"He who controls the past commands the future, he who commands the future conquers the past"

Wise words, wise words...

An open message to the team

As 2007 is slowly reaching its final day, it feels like a traditionally good time to reflect.

I'd like to reflect on the team I'm in. We've come a long way this year and we've seen an unfair amount of hard times. Getting a manager for a few weeks, having no official manager for the best part of the year and still winging it, dealing with people that don't share our flexible attitude and openness towards technology, ... I am sure that we all learned valuable lessons and above all, we had a lot of fun.

We are aware of the changes and challenges that are ahead of us, both in the micro sphere of POI and in the company as a whole but I feel confident in taking on these challenges and overcoming the obstacles, knowing that you are on my side.

Thanks.