Agile principles are all about learning as you go and using the new knowledge to redefine the goals of the project. This is perfect for the developers and the immediately involved business representatives. But for a C-level exec it becomes hard.
Let us imagine that you and I are two C-level execs. I’m the CEO (yes, I get to pick first, because I write this before you read it). You can be the CFO and be even harder on keeping track of money than I am. In our management team there is also a CIO and of course some more C*O-people, but to make this story simple it’s just you (CFO) me (CEO) and the CIO that talks.
- I’ve got two interesting projects that would deliver lot of value to the business, says the CIO.
- That’s great, please describe what they are and the benefits, I reply.
- The first one is a trouble ticket management system integrated with the sales system’s backend. We expect that it would reduce the time for support calls by 50% on average by letting the support agents quickly find out if the customer is still covered by warranty or not. The second one is an improved supply chain management software that would reduce the number of spare parts we need to have in stock by 80%.
You (the CFO) gets eager:
- Our spare parts inventory is worth millions, so if you could bring that down by 80% it’s a huge one time profit. You never miss a chance to improved the numbers for the annual report. I continue to fill in:
- Reducing support call time is also a huge improvement. We have a hard time to find staff that are qualified and know enough about our products. Being able to use their time more efficiently would be great. We’ve got two great projects, I continue, that would give about the same level of benefits. Let’s see if we can afford them.
I (the CEO) turn to you (the CFO):
- What’s left of our investment budget?
- About a million.
- Ok, I turn to the CIO, how much do they cost?
As the CEO I am a strong believer of the full funding principle: If a project is launched, it will have the full funding required to finish. If that’s not possible the project won’t be started at all.
As the CEO I need to make a decision about the proposed projects. I have a limited number of alternatives.
Being a great coder is only part of the skills required to be a professional developer. A professional developer is never isolated with the code. All work is done within the context of a project. A professional developer delivers not only high quality code, but also high quality time estimates.
Back in June I wrote about programmers’ time estimates. With more than 100000 views of that post and a lot of interesting comments I want to take a closer look at a common mentality if developers.
Time estimates are impossible. It’s done when it’s done.
That mentality is totally incompatible with being a professional developer. Let’s look at a software project from the perspective of some of the stake holders and see why accurate time estimates are essential for them. It’s not only a matter of some accountant wanting to know the cost for the project. The time estimates are often a key factor when making decisions on what to do and when. Those are decisions that in the end affect the developers.
As a professional developer I definitely have an interest in getting the estimates right, because if they are wrong some bad decisions are going to be made. I think we all know what bad decisions in a software project means: Developers having to work overtime. I don’t like it. Do you?
With authority follows accountability. The other way around is also true. Anyone who’s held accountable has to have authority. Unfortunately it is far too common that developers are held accountable for a project, even though they don’t have any real authority. They typically are responsible for the delivery, but the authority stays on management level and that’s where the accountability belongs.
A bad manager will take all the credits for the success, while any failures are blamed on the developers. A good manager of course does it the other way around, but let’s ignore that for now. This post is about bad managers that do not accept the accountability that comes with authority.
There are two different cases where the developers are held accountable without having authority.
- The developers should really be accountable and have the corresponding authority, but management won’t delegate the authority.
- Management has the authority and they should, but they refuse to accept the accountability that comes with authority.
An experienced project manager I used to work with claimed that he took the programmers’ time estimates, multiplied by pi and converted to the next time magnitude to get the true number. 1 day converts to 3.14 weeks. He had learned the hard way that programmers are bad at estimating times. To get a more precise conversion, I’ve created a translation table for programmers’ time estimations, trying to narrow down where things go wrong.
Yesterday I got hold of a deck of cards, specially made for playing planning poker at sprint planning. I’ve been through many sprint plans before but never actually played planning poker with cards. I’m stunned by the difference it made.
Without the cards, I’ve always been careful that everyone settles their own opinion first, before anyone else tells what they think. I thought that was enough to get the same results as when using actual cards. I was wrong. I was completely wrong. I spoiled an opportunity to build the team spirit, the feeling of doing this together, the collective ownership of the estimates. The most important thing I missed was the possibility to get rid of the feeling of criticism when having a different opinion. The criticism that nags on the team spirit can be replaced with a good collective laugh, empowering the team spirit instead.