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.

1. Open source is not free
Contrary to popular belief, open source comes at a cost. Unlike commercial packages (full software, or libraries) the cost here is not tied to the initial cost of acquisition (either as a license fee with or without a support contract). The true cost of open source hides at a deeper level. The place where it still costs money is a cost of integration. Even though the idea of open source is that there are a whole slew of people working on it and that the community will be the best support group ever, the reality is that a lot of open source projects are actively maintained by only a handful of people per project. Which generally means that you (the developer who needs to integrate it) will spend a lot of time reverse engineering the code.
The second point where there is a form of (rather indirect) cost attached is in the area of strategy and maintenance. Since this code is created and maintained on a voluntary basis it doesn’t really carry any form of guarantee that it will be maintained and/or evolve, and if it does evolve in a direction that might not be what you wish/expect, there is no sales/account/technical staff to help you out in the migration or to voice your concerns to.

2 The licensing aspect
There is a vast number of licenses out there, making the distinction between all of them is beside the point here. Suffice to say that, in general, there are a number of common themes.
Not everything can be used for commercial purposes, some might require that you submit any modification back to the community under the same license, some allow you to use it as if it were closed source, … . Best to have your legal people look at the license if you are unfamiliar with the matter. Just a point of attention…

In conclusion, yes I believe open source code can make your software better but there is an amount of sanity checking that needs to be done (just as we do with closed source). The questions to be asked are not just a matter of financial or legal cover-your-ass but also of strategy (do I like where this thing is heading?, do I want this vital piece of my software to be open source?). There is no one-size-fits-all answer to these questions, so let us please answer them and do the due diligence.

“The ScrumMaster is NOT responsible for the transition from traditional methods of working to Scrum or the implementation of Scrum”

That to me immediately disqualified the opportunity. It shows a clear lack of understanding the role of the scrum master.

The scrum master is first and foremost a facilitator of the scrum process. He is the person who helps set the stage, builds the teams and acts as a coach to both the team and product owner.

#Fail!

To many engineers the request for a date seems unreasonable and shows a clear lack of understanding and appreciation for engineering from the business side. However, if you look at where those people come from it’s not so hard to understand.
When you have to plan a production-type operation you are dealing with a known process. You know every step of the way, probably in great detail. So it’s rather easy to plan. If you know that turning a screw takes 2 seconds, it’s a no-brainer to see that in one minute you can turn 30 screws. It’s very predictable and controlled. And the more detail you get in your planning, generally the more control you’ll have.

Unfortunately, all that is not so much true for engineering. Crafting software is a creative process. It’s about figuring stuff out. Stuff ranging from a vague requirement to the logic that goes into an algorithm. It’s dealing with unclarity and vagueness. Software is often more of a trial and error thing. And the unknown is feared by many as it means letting go of that tight control they had for decades.
The key to engineering is not fearing but embracing failure, and often to try and fail as soon as possible. Many innovations have come after numerous iterations of failure and software is no exception to that rule. Engineers need room to experiment, and you can’t plan for that. You can’t plan (in the typical production way): “let’s fail five times and get it right the sixth”.

All that doesn’t mean that engineers shouldn’t do planning but there’s a different angle to it. Engineers might not readily admit it, but generally if you give them a problem they can make a reasonable estimate. It won’t be accurate per se, but they will have a gut feeling for what it will take. They understand their job and even though they can’t predict every possible failure they encounter they generally can outline an approach in their head and take a shot at telling where the painpoints will be. The key here is that in the end they are still only estimates. They are not the exact science to what traditional managers are used to, only an indication of magnitude of work.
Sometimes though, that simply isn’t possible. The problem might be to vague, the problem space not enough understood, … . In that case I am a huge fan of timeboxing. Reserve a specific set of time to do some preliminary analysis, come up with questions, possibilities, … and present that back to the original requester.

As I said many times before, the job of a good project manager is twofold. First there is the making of a plan, which accounts for both the operational tasks and the more freeform creativity needed for engineers. Second, and more important, is dealing with changes in that plan.

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.

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.

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…

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

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…

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