23
Apr

don’t take it personal…

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

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.

16
Jan

motivation

After a conversation with one of the suits in the office, I got an email late at night that same day…

To our conversation of this morning…
Kennedy’s challenge was to land a man on the moon and return him safely to earth by the end of the decade…but the first step was to build a rocket powerful enough to escape earth’s atmosphere without blowing up.
I think we’re at the same stage.  Some of our rockets are going to blow up.  Some are just going to fall over.  But if we can start to take major ‘time buckets’ out of our production process, we’ll be getting closer to the stratosphere.

Confident of achieving orbit,

Sometimes knowing that high up in the company problems are understood and the message you were trying to send out hit home is a very rewarding, motivating and inspiring event.

Hope comes in many forms…

14
Jan

The morning routine

I’ve been trying out a new morning routine for a couple of months now. Here’s how it looks.

  1. I wake up around 8:30
  2. I pick up my iPhone and read the mails that were sent overnight by my colleagues from around the world (mainly US)
  3. Mails that require a lengthy answer or research are marked, short answers are sent directly
  4. Get out of bed by 9:00, take a shower, get dressed and walk to work. So by the time I’m at my desk it’s about 9:40

I find that this strategy offers me a few significant advantages over going to the office and start working through my inbox.

First of all, I give my brain a kick start by digesting work related matters straight away forcing myself to get a lot of stuff into memory instead of somewhere latently present in a galaxy far far away. While I’m walking I give myself time to reflect on the information I just received. Those 20 minutes walking are vital since they largely define a plan of action for the day. I draw up a mental list of people I need to speak to, topics I need to digg in, ideas I want to bounce around in a meeting, … . Basically, I’m compiling a to do list on the way to work, knowing I have the latest info available.

Second, and more important, I’m up to speed before I arrive in the office. Our great landscape office is ideal for being harassed every minute of every day, meaning I hardly ever get a quiet 30 minutes stretch to work through some topics (I’d give money for a private office with a door sometimes).

27
Nov

Programming language

I was browsing through some resumes lately and besides the standard templates and paragraphs everybody has, there was one thing that jumped out. In the languages paragraph, one person was claiming to be fluent in the following languages: Dutch, French, English … and … C#. I admit, I was intrigued.

Why would one consider a programming language in the same area as human language? Is it just a trick to make a CV stand out or are these languages essentially the same? How can you find a common denominator to indicate fluency in these languages? Do you read, write and speak C# as well as your native language?

Looking at a definition of language: "a systematic means of communicating by the use of sounds or conventional symbols". Pretty obvious, that does entail both human and programming languages. Still, it somehow doesn’t feel right to think in the same way about human and programming languages.

On human language we often split up our knowledge in 3 areas: reading, writing and speaking. Where reading is the ability to understand text, writing the ability to create text for others to understand and speaking the rapid fire combination of the other 2 abilities.

Maybe if we translate that to programming languages, reading would become the ability to filter out the logic from a piece of code and see the underlying architecture and patterns. Writing could maybe translate to the ability to create code using a base set of functionality from the language, much like most junior developers produce code. Speaking in the end should be what someone more senior does. To know and understand the strength and weakness of a language, the standard interfaces and how/where to use them.

But still, I’d argue to keep them separate on your resume…

25
Aug

Twitter

For those of you who don’t know yet, twitter is a micro blogging platform. Meaning you can post a short message (140 characters) to update people that care enough to follow you of your current ideas, activity, whereabouts or other piece of genius that fits the char limit.

I’ve been on there for some time now and, after a getting started period, must say that it somewhat changed me. I’m not going to make this one of these "10 reasons why I love twitter" type of posts, but let’s just make clear that twitter delivers instant news/headlines in bite size packages.

The people that I follow are carefully selected to keep the signal to noise ratio high. Basically, when they are going wild about something or another, chances are high I will be interested in that subject also. And since it’s only a short blimp of information, I’ll make a snap judgement to invest more time in it or not. The thing is, I got the info at hand (google), and a lot of what’s interesting is pre-filtered through people that deeply care about topics I would otherwise never dig into. So I get a lot of inspiration and topics handed by a variety of people and all I have to do is look at what’s relevant to me. Great, isn’t it :)

There’s 2 evolutions I’m waiting on:

1. Politicians making more active use of twitter. I know some people are trying (Barack Obama, Yves Leterme, Elio Di Rupo, … ) but I’m looking for more activity. Keep us posted on thoughts, ideas, developments in your world, … anything basically. Maybe we’ll catch something that inspires us. Not just during campaign…

2. What I’ll be looking at next is probably a way (yahoo pipes) to filter a bunch of RSS feeds from news sites into a twitter feed. Not because I don’t want to have their RSS feed, but because I want headlines in a centralized place (let’s say, only the soccer news for the Belgian first Division).

27
Jun

The end of an era

Today has been marked in my calendar for a long time. Today is the end of an era. Today is the last day of Bill Gates at Microsoft.

We all have an opinion on Microsoft and their products and strategies. I don’t care what camp you are in, if you’re totally pro or against Microsoft. There is one thing you can’t deny. Bill gates had a vision and shaped the IT industry.

He had a dream of "a computer on every desk and in every home". Looking at where we stand today, I personally think he overachieved. It’s not just a computer on every desk and in every home, it’s gone far beyond that. And if you want it or not, Bill gates and Microsoft have shaped a large part of this, for better and, most likely, also for worse.

I’m not going out on a "all hail" rant for Bill, but respect is definitely due.

07
May

(r)Evolution

I came across this post and immediately felt a very familiar sense. It’s something I had been wondering about for a while.

I started noticing on events and various ad-hoc meets that a lot of the crowd I know is also on twitter, has a (couple of) weblog(s), is all hyped up about latest developments in the e-world, … and all in all are probably a bunch of early adopters.

If I compare that to the business reality I live in, I often find myself far away from those people on the technological front (I don’t work in a internet related business, for those who might wonder). In general, my colleagues represent the ‘average user’. What strikes me most about them (besides the fact they rely on internet exploder) is that they still consider the internet as this ‘out there’ thing that by definition has to be accessed through a browser, either on their desktop or on their mobile. Which to me indicates 2 points that need to change before the masses will be ready for things like twitter.

1. The internet is not a set of web pages. It’s a medium to transport digital content of any kind, that can be stored somewhere in that cloud.

2. Out of realizing point 1 follows that you don’t need (just) a browser to access that content. Which opens a lot of opportunities to work with this concept in innovative ways.

Given that people imho will eventually adopt these 2 things, there are interesting times ahead of us…

20
Apr

Is apple the new fur?

I’ve never been into fanboy-ism (positive or negative). Not on mac, not on most things else. That doesn’t take away the fact that I love to make fun of fanboys. Generally by telling them how good/bad their favorite product is and see them go all wild about my statement.

I recall, when I was young, there was a similar sentiment with fur coats. People owning one would think that the opposition had overly emotional arguments and very little reason or sense. The opposition would bring all sorts of excuses (some very legit and reasonable, others way out there) to make people wearing fur coats look bad.

The entire discussion with apple and its fanboys sometimes feel the same way. The army of fanboys will just react to the slightest notion of the word apple to scream to the world how good it is. On the other side the evil empire will not refrain from highlighting how some parts are actually not suitable.

Which just made me wonder, is apple the new fur? Something you either love, or hate? Are people losing sight of reason on this subject? Or is it just Steve J. having a lot alter egos posting on forums…

10
Apr

9 baby’s in 1 woman for a month

Or at least something containing all those elements. This article is all about the question "Can 9 women deliver a baby in 1 month?". In this post and subsequent comments we already brought up that 9 women can’t deliver a baby in 1 month in a lot of cases. Somewhere I said that they may be able to deliver, if delivering a baby only took cpu power. I still stick to that statement, but want to expand a bit on it.

From an engineering point of view, the statement is ever so true. If 1 server can process 100 jobs every day, than 2 servers generally can process 200 jobs every day. (simplification, I know). So 9 women, 1 month, baby delivered.

From a business point of view, the first thing that comes to mind here is: does the return of adding that extra server really justify the investment. A story that makes it crystal clear.
A production plant for a car has an assembly line installed that produces 500 cars of one model every day and has been producing for the last 100 days. Installation of the assembly line cost 50.000k and took 20 days to install, test and be completely production ready. The lines are specific for one car and can’t be reconfigured. Every car sells for 1k. Recently, due to high demand of that model of car, they would need to produce 750 cars / day to fulfill market demand. The expectation is that this increased demand will last for 300 days, after that demand will drop to 500 again. Or put otherwise: there is a loss of 250k in potential revenue every day (or 75.000k over the 300 day period)

There are 3 options here (for simplicity sake). First one is: build another production line to produce the 250 extra cars / day. Option two is to slightly abuse (overclock, speed up, …) the existing line so it produces 565 cars / day. The last option is simply to ignore the higher demand, and keep producing 500 cars / day with the existing system, and work on a backorder. (and combination of the options are not possible)

Let’s do some maths for option 1. It takes 20 days to set up a new system, meaning you don’t get (20*250) 5.000k in revenue. After that you are able to build 750k cars / day, gaining you 250k extra income every day. In turn meaning that it would take 200 days before you paid for your assembly line and the 250k every day becomes bottom line profit. Summarized: installing the new machine cost you 55.000k (50.000 install + 5.000 in lost revenue) + 220 (20 install + 200 to repay the machine) working days before it makes you 250k/day profit. (to all you economical gurus out there, I know this is technically not entirely correct but I’m trying to get a point across). Since the expectation was that the increased demand would be 300 days you would effectively have profit for 80 days (300-220), it means you’ll get 20.000k (80*250) in bottom line profit and are stuck afterwards with an extra assembly line. Your main line would produce you a profit of (300*500) 150.000k.
Profit and result after 300 days: 170.000k + 1 unused line.

Now consider option 2. Your assembly line cost 50.000k and gets you 500k every day. So you’ll have payed it off after 100 days, in our example this means that your line brings in 500k to your bottom line every day. The speeding up of the line would cause the factory to be closed for 10 days but would get the production speed up to 565 / day. The only cost you’d have is a new software roll out on the robots.Some numbers.
Closing down for 10 days means missed profit of 5.000k (500k *10). However, it leaves you with 290 days (300 days of high demand - 10 for installation) of production at 65k extra profit per day. Or: an additional bottom line profit of 18.850k (65*290), and no unused machinery to take care off when the high demand is over. Your main line would make profit for 145.000k (290*500)
Profit and result after 300 days: 163.850k + nothing extra to maintain

Option 3 is easy on the maths side. You get 150.000k (500k * 300). Your machine was paid off, so all you get is the bottom line of 500 cars / day. 
Profit and result after 300 days: 150.000k + nothing extra to maintain

I would personally favor option 2. Even though there is less immediate gain, you are not stuck with costs associated to having that machinery around (even unused machinery still costs, in the sense that it takes space away for machinery that could be used). Which sounds like a better long term plan.

To go back to the 9 women theory, and the point of this article. Yes, 9 women can deliver a baby in 1 month in certain situations but (big caveat) you’re stuck with 9 women afterwards…