I want you to do more!

I have been in the industry for over 15 years now. I have worked in many different environments. There were approaches that you could have called "waterfall", and there were approaches that you could have called "agile". And there were approaches that were somewhere in between (using a linear spectrum).

One thing that has stayed the same during all this time: A customer asking for more. "I want you to do more." And what they mean is: "I want you to increase productivity." (And for the records: A customer could equally be an internal stakeholder, e.g. a product manager.)

The interesting question is, though, how do you measure productivity? The trouble is, if you don't know how your customer measures productivity then how can you improve it? I have approximately 20 or 30 books on metrics in software engineering. Many of them contain attempts to measure the productivity of a software engineer. I am not aware of any metric that really works. If you know of such a metric: Please, I am begging you! Tell me!

An exercise: Let's assume you count lines of code (LOC).... Ok, ok, I got it. We want maintainable code so less is probably better.

Let's try "number of screens". This is more difficult. Do you want to have as much information on one screen as possible? Maybe the screens are used by professionals every day 200 or 300 days a year. In that case, again, less is more!

Let's try "number of stories". Ok, that's an easy one, isn't it? A few years ago a manager asked me how we could motivate the team to deliver more stories (For the less familiar: story = a small piece of work). I thought for a moment and then I said: "Just tell them!" Then he thought for a bit and understood that people would just make the stories smaller and smaller and so we would - on paper - see improvements all the time. In other words "inflation".

Let's try "Defined Scope": I have this statement of work that also includes "The Scope". Let's assume it contains the requirement that on one screen you need a table. For that table you want to reorder the rows because the sequence matters (think of prioritization items for instance). One way to implement that could be that each row gets a unique identifier (or you can select it), and then there are two buttons with "Up" and "Down". Functionality complete! - Well, hang on, wait a second. This is - at least for web applications - what we had about 10 years ago. Today, we need AJAX, and hence at the very least you want the rows to be draggable with the mouse. - Whatever you answer to this is - whether or not the fancy version is in scope or not - the difference between these two versions is about 1:10 in terms of effort.

So where does this take us? It's about scope. And it is about making sure you have the right scope in place. So wouldn't it make sense to precisely define the scope? Absolutely! Have you tried it to define scope in a "waterproof" way? If you were successful please let me know!

Yet another approach is: Just mandate more work to complete. Well, if you don't have family how can you possibly imagine that there are people out there who have family and who do care about their family? How do you know what it feels like if you have to call your partner that you won't be home for dinner? That you won't be home for the weekend? What if your kids start asking who you are? How would you feel? If you are a human being, you know exactly what I'm talking about.

I think all of this is not very constructive. Try to better specify scope is definitely a good thing. Assuming that the scope is completely defined at the beginning of a project - regardless of effort - is in my view a ridiculous assumption. As the project progresses you will discover new items. All IT project, all software projects are so complex that we have to assume that there will be new scope discovered. Do we know how much ahead of time? No we don't. We can try to "guess" as best as possible but there is no guarantee that we will be correct.

So it basically boils down to ensure that all stakeholders are involved, that they always get a sufficient and complete picture of where the project is going. If the remaining capacity is not sufficient for the remaining scope then this needs to be addressed as early as possible, so change management has to kick in.

Creating a blame culture and start finger pointing when coming under pressure won't help make any issue go away. A unilateral mandate or a dictatorial approach will destroy all teams. Requesting respect for one's role and at the same time ignoring a different persons role is destructive and ignorant. It reminds me of the days of the cold war. The Soviet approach was: What mine is is mine, and now let's negotiate about yours. We all know that this approach didn't survive.

Increasing and continuously improving communication and collaboration is the required forward looking approach. Contributing and constructively participating in a proper cross-functional team is where good solutions are created. (And whether or not you use an agile approach doesn't matter at all!)