Help, my manager has a vision!
February 19, 2012 at 5:26 pm | Posted in Ramblings, Uncategorized | Leave a commentI started my career about 20 years ago. The first week I got an email from my group leader in which she told us that she had scheduled a meeting with an important topic. This was back in ’91 or ’92 and there were quite a few layoffs due to the crisis and first Gulf war around that time. So a couple of days later when the meeting actually took place and the whole group (that was 3 people!) looked at her in anticipation and a bit of fear. And then she started the meeting with “It is important that we as a group have a mission statement.” I only remember that we looked at each other slightly uncomfortable and thought what the hell is she talking about.
In the following 20 years I have been in this situation many times, so I thought this would be a nice opportunity to write down a simple step-by-step plan to handle such a situation.
Step 1: the Steve Jobs test
This is a very simple test and only takes a couple of seconds. Is your manager a major pain in the butt but at the same time you get a lot of energy when he or she is around? In that case he might actually have a vision which is worth listening to. And even if you don’t listen, if he really is like Steve Jobs his vision will take off anyhow. On the other hand, if your manager is a dull bureaucratic type of person who never had an original idea in his life, it might very well be that he recently has read Steve Jobs biography and mistakenly thinks that he can do that as well.
Step 2: gather the facts
Maybe your manager did read the biography. If not, his silly ideas must have originated somewhere else. There are a couple of possibilities: if you noticed many consultants around the office during the last weeks or months, they might be the source. The other possibility is that there has been an announcement at the company level. You might have noticed an e-mail from the CEO in your mailbox, or maybe even a new company logo. Typically a vision trickles down to the workfloor, where each management layer will take anywhere between a week and a month. This also means that your manager probably doesn’t have a choice: he must have a vision, aligned to the company vision.
Step 3: try to understand the vision
This sounds like a useless step, especially if it is already so obvious to you that your manager isn’t Steve Jobs. However, this only takes a couple of minutes and it is important for the next step. The goal of this step is to find out if by mere coincidence, your boss still has laid out a brilliant vision. Just like the Infinite Improbability Drive this might give tremendous energy to your unit, your department of your organization.
Read the document or presentation. If it is larger than 1 page or 1 slide you can already stop. This is not a vision. Next scan the document for words like ‘better’, ‘cheaper’, ‘faster’, ‘most cost effective’, ‘best in class’, ‘thought leaders’, etc. etc. Real visions don’t include those words.
In the unlikely event that the vision is real (it is motivating and inspiring) you can skip step 4. You are a lucky person with a great manager! Congratulations!
Step 4: handling the situation
You are still reading this because apparently your manager’s vision is as was to be expected: meaningless. Now you have a couple of options to handle this. Let me explain them for you:
Wrong way to react
Telling your boss straight-out that his vision is stupid and a waste of your time is not going to help. Of course his vision is never going to happen but you don’t want to be the person he is going to point to as a scapegoat. It is also not going to help during your yearly performance appraisal.
OKish way
Usually you can quite safely ignore your manager’s vision. Main reason is that there will be a new manager and a new vision anyhow within 1 or 2 years. If you want to have a little bit more fun you can start a lively discussion on the difference between a vision, mission and a strategy, because most likely your manager will have them mixed up. You don’t need a degree in business administration to do this. However, don’t overdo this in large groups because it might make your manager feel stupid.
Right way
However the best way to react is to fully embrace your manager’s vision! First you express your enthusiasm: tell him his vision is very motivational to you. Tell him that he really should share his brilliant ideas with the world for example by writing a white-paper or a blogpost. Make sure that you do this in such a way that he will have to do all the work and won’t be able to delegate it to you. Also make sure that you don’t overdo it: telling him that he should get the peace nobel price for his ideas is probably a bit too much and might raise his suspicion.
After you have shared your enthusiasm you can now weave in your personal agenda. Here is where the results of step 3 come in: if one of the keywords for example is ‘thought leader’ than you can use this to explain that this cool conference in Hawaii on some state-of-the-art technology you want to go to is really helping to support his vision. If you feel self-confident you can also rephrase this as ‘with this practice I can help you to operationalize your vision so that as a group we can really meet our business goals.” Additional benefit: you can refer to all your support during your performance appraisal.
Final words: don’t take me, this blogpost, your manager or yourself too seriously 
Have fun!
Less code matters: don’t repeat yourself
June 27, 2011 at 9:24 am | Posted in C#, GIMP, Programming, Uncategorized | Leave a commentI got quite a few reactions on my previous blog post both positive and negative. The message of the negative comments was mostly that short code shouldn’t be a goal since it tends to result in unmaintainable code. Next some people accused me of writing ‘clever code’ like using lambda functions which they reasoned are not going to be understood by those who will maintain my code. Despite of the tone of some of these comments, they are all very interesting and surely hold some value. At least they gave me a couple of new ideas for future blogs.
In this post I’ll show how I removed another 4 lines from the GIMP# AverageBlur plug-in. The following lines of code have been bothering me for a long time but I never took the time for fixing them:
using System;
namespace Gimp.AverageBlur
{
class AverageBlur : Plugin
{
static void Main(string[] args)
{
new AverageBlur(args);
}
AverageBlur(string[] args) : base(args, "AverageBlur")
{
}
// Remaining code omitted
}
There are 2 things I didn’t like about this code:
- The Main function creates an object which is apparently unused. The reason is that in the constructor all kind of magic happens, include a call to gimp_main which starts the actual GIMP plug-in. This is hard to understand: constructors should be straightforward. Just create the object and make sure it is in a defined state. Nothing more than that.
- Every GIMP# plug-in is derived from the Plugin class but still seems to need it’s own constructor. The only reason for this is that I have to parse a couple of parameters like the arguments (args) and the package name that is used for translation. However this package name is always the same as the plug-in name.
While it is easy to get rid of the first disadvantage by introducing an explicit function call with the object as parameter, that would still leave me with a constructor for every plug-in I write. However, that was my first attempt to clean up this code:
using System;
namespace Gimp.AverageBlur
{
class AverageBlur : Plugin
{
static void Main(string[] args)
{
// Do all magic stuff in GimpMain instead of in constructor
GimpMain(new AverageBlur(args));
}
AverageBlur(string[] args) : base(args, "AverageBlur")
{
}
// Remaining code omitted
}
Now if I just remove the parameters from the constructor and pass them to GimpMain I can use the default constructor so I don’t have to define it anymore:
using System;
namespace Gimp.AverageBlur
{
class AverageBlur : Plugin
{
static void Main(string[] args)
{
// Do all magic stuff in GimpMain instead of in the constructor
GimpMain(new AverageBlur(), args, "AverageBlur");
}
// Remaining code omitted
}
We just removed 4 lines of code while at the same time improving readability. We are left with one single line that calls GimpMain where all the magic happens. Still this line looks a bit like boilerplate code since it will be exactly the same for every plug-in. The final code I used looks like:
using System;
namespace Gimp.AverageBlur
{
class AverageBlur : Plugin
{
static void Main(string[] args)
{
// Do all magic stuff in GimpMain instead of in the constructor
GimpMain<AverageBlur>(args);
}
// Remaining code omitted
}
The Plugin base class instantiates the object as follows:
abstract public class Plugin
{
protected static void GimpMain(string[] args) where T : Plugin, new()
{
var plugin = new T();
Catalog.Init(typeof(T).Name, Gimp.LocaleDirectory);
// Remaining code omitted
}
}
I introduced a generic method. The type parameter T has the constraints that it should be derived from the Plugin class and that it should have a default constructor. In line 5 an object of this type is created. Line 6 now gets the class name (typeof(T).Name) which I use as catalog name for the locale.
Over time the size history for the AverageBlur plug-in now looks like this:
Current code size is now 54 % of what it once was, down from 60 % in the previous revision.
Some people might wonder if this code isn’t ‘too clever’. Generic methods in C# is not something every programmer might be 100 % comfortable with. In a next blog post I am going to write about clever code and try to quantify this a bit more. Until then, enjoy reading this post and I’m looking forward to any comments and/or improvements!
A simulation to show the importance of backlog prioritization
June 8, 2011 at 6:36 pm | Posted in Agile, Uncategorized | 6 CommentsA successful agile software project depends on a prioritized backlog. You can have a perfectly functioning development team that efficiently finishes one feature after the other, but if these features hold no business value it still is waste.
To show just how important this prioritization is I did a Monte Carlo simulation, using Google Docs spreadsheet. Here are the assumptions I made to create the model:
- the business value of a user story is randomly generated from a uniform distribution between 1 (very low value) and 100 (very high value).
- the effort to implement this user story is generated by drawing from a standard set of Scrum poker cards with the values 0, 1/2, 1, 2, 3, 5, 8, 13, 20 and 40 (100 and ? are omitted). The drawing was done first selecting an index based on a normal distribution with average 5 and standard deviation 1. This (zero-based) index is used to select a card from the range of poker cards. For example index 5 corresponds with the fifth card which happens to be 5 as well. Index 6 corresponds with the value 8, etc.
- the assumption was made that there is no correlation between the business value and the effort needed to implement the corresponding story.
- the whole backlog can be delivered in 10 sprints.
- during the first 4 sprints the velocity is increasing in a ration 1, 2, 3, 5. This means that the development team is 5 times as fast in the forth sprint compared to the first. After that the velocity stays constant at a value of 5.
With these assumptions I calculated the delivered business value (as a percentage of the business value of the whole backlog) using 4 different prioritization algorithms:
- no prioritization. The development team picks up the stories in the (random) order from the top of the backlog.
- prioritization using the business value of the stories. Stories with high business value are built first.
- prioritization using the needed effort to build a story. Stories with low effort are built first.
- prioritization build on the ratio between business value and effort. Stories with a high ratio (high business value, low cost) are built first.
The results can be seen in the following graph:
As you can see from this graph is that not prioritizing your backlog will deliver business value quite late. Since there is no correlation between business value this will be a straight line after the first 3 iterations in which we have a low velocity.
The other extreme is the prioritized backlog using the business value / effort ratio. This is the red line. Here you can see that after 5 iterations you already have delivered 80 % of the business value. For the backlog without prioritization this takes more than 8 iterations!
What looks a bit surprising initially is the difference between the prioritization on business value (the yellow line) and prioritization based on effort (the green line). This is introduced by the fact that in our simulation we have created a bias towards more expensive user stories: the number of user stories with effort lower than 5 is equal to the number of user stories with an effort higher than 5, but remember that the Scrum poker card values are not symmetric: 0, 1/2, 1, 2, 3 versus 8, 13, 20 and 40. That is the reason that in this simulation it is better to prioritize on effort instead of business value.
There is one more interesting aspect to investigate. What is the impact of the standard deviation that we use to draw from our poker cards? I repeated the simulation using the business value / effort ratio for the prioritization and different values for the standard deviation. The result:
The results are easy to explain: when using a higher value for the standard deviation you will get more extremes (either 0 or 40) for the effort to implement a user story. This means that there will be more user stories which require little effort and deliver good business value. These can be build first.
Bottom line: make sure your product owner works hard on a prioritized backlog. Let him quantify the business value of his user stories. As you can see from this simulation half of the effort (and cost) needed to complete the whole project might already be sufficient to fullfil his business needs. This is a huge money saver!
Quantifiable New Year’s resolution
January 2, 2010 at 12:47 pm | Posted in Uncategorized | 2 CommentsThis blog entry is about my New Year’s resolution. It’s personal, quantifiable and kind of random. But I just happen to like numbers and targets. So here it is in no particular order:
- 400 LinkedIn contacts. I’m at 370 right now, so that shouldn’t be too difficult
- I want to read 50 books. About one book per week. You can see my books on LibraryThing.
- Three publications on subjects like Agile project management, software metrics, etc. This could be a tough one. The only publication I did last year was with Jeff Sutherland on Fully Distributed Scrum. You can still find it here.
- I want to run 80 times my usual track of 10 km. Also a tough one. It’s easy to run this distance but I will need to find/invest some time here.
- Make 2 GIMP# releases
- Learn 2 new programming languages. At the moment Clojure and Objective-C are on my list, but that might still change. Suggestions are welcome!
- 150 followers on Twitter. You can find me as @mauritsrijk. At the moment 65 people seem to be more or less interested on what I’m doing all day long.
- And finally I want to push the number of average readers on my blog from about 50 currently to 100 a day. Updating my blog now and then certainly seems to help
Happy 2010 everyone!
A new job!
April 6, 2007 at 6:54 am | Posted in Uncategorized | 4 CommentsThis week I signed my contract. I’m going to move from TASS Software Professionals to the Xebia Group starting July 1st.
Blog at WordPress.com. | Theme: Pool by Borja Fernandez.
Entries and comments feeds.
