Archive for the 'management' Category

15
Feb

Retroflection

By Don Ardonio 0 Comments
Categories: agile, management, product owner, scrum and twitter

I’ve been following retroflection for a while now and I promised myself time and again that I would take some time out to write up an answer. But first of all, let me say thanks to Yves for doing this. I may be a rather quiet follower most of the time, but I have enjoyed many of the retroflections so far and hope that by the end someone is clever enough to put all of them, with comments and reactions, in a single something (I smell a possible book release…)

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.

15
Dec

The open source question

By Don Ardonio 9 Comments
Categories: development, leadership, management, software and strategy

I’m tired. Tired of hearing yet another big bozo speech about how we will move to open source and how that will magically reduce our costs and make our software better.
Gentlemen (and those few ladies who end up reading this), behold, a couple of reality checks

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.

14
Aug

Embracing failure

By Don Ardonio 3 Comments
Categories: agile, development, management, software and strategy

The most burning question a business generally has for engineers is “when will it be finished”.  They are looking for a specific date and often a specific plan for how you’ll get there. They would most likely be overjoyed if you could tell them exactly at which point in time you will write which line of code. As engineers we have a love/hate relationship with that question. Somehow there is an understanding of the importance, but we are dealing with so much unknowns that we find it hard to commit. It’s in our nature to look at all possibilities and account for a large number complications, even though they may never occur. And then there’s off course always the “give us a clear requirement” catch-phrase we throw back at the business. (truth to be told, we often don’t do a good job in helping the business find that clear requirement, but that’s a different discussion altogether)

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.

23
Apr

don’t take it personal…

By Don Ardonio 1 Comment
Categories: agile, management, product owner, scrum and software

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.

16
Jan

motivation

By Don Ardonio 0 Comments
Categories: communication, leadership, management and 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…

10
Apr

9 baby’s in 1 woman for a month

By Don Ardonio 0 Comments
Categories: business, management and strategy

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…