I have come across many people in life who are asking for an estimate for a job they need done and when I have provided them with the estimate, they turn around and take that as an actual number of hours it will take to do the job.  This is a wrong approach.

Estimates are ...... estimates.  The only way you can get actual’s is to look at the time spend after the job has been done.

Estimates are at best a good guess of the time we need to develop something brand new without all the details known up front.  And by the way, all development is brand new, not matter how many times you have tried developing something similar in the past.  There will always be new outside things influencing how your development is going; even just the fact that you have done this before, changes the way you would do it again.  Building software is not production of gizmos where we know that the machine can spit out 100 gizmos per hour so all we need to do is do the math.

Compare software development and estimating with a simple thing as going to and from work every day.  Even thou you have done this 200 times, you can still not estimate how long it will take you to get to work tomorrow or for that matter three weeks from now.  Weather affects the time is takes; other people in traffic affect the time it takes; your driving style on any particular day affect the time.  "Well" some would argue "I know that on a good day it takes me 30 minutes to get to work so I can apply the +/- X% rule and give you a better estimate."  Really?  So you are telling me that you can apply +/- 10% and tell me that you would get there in 27-33 minutes?  Or how about we make it more accurate and add +/- 50% just to be on the safe side?

So now we are looking at completing the task between 15 and 45 minutes.  What does that give me that the 30 minutes estimate does not?  Nothing I would argue.  All we are doing is fooling ourselves into believing that we can estimate more accurately.

Estimates are estimates and should be used for nothing else that that; our best guess on how much time a task will take.

Just got the acceptance from Scrum Alliance that I have been accepted as a Certified SCRUM Professional.

It is quite a process to go through with a paper yo have to submit where you explain al your experience using SCRUM in real life.

This is too funny .

I have seen numerous examples of Project Managers claiming that they know how to do SCRUM, but this is probably one of the best examples I have seen which provides us with an insight into a traditional Project Managers brain and mindset.

I am not sure why it is that Project Manager have such a hard time giving up control and instead have the team being committed to deliver what they as a team have promised to deliver.

Guys don't you get it? If you do it right, it's a free ride for you and you even get to be the 'hero' that made this all happen.  But "Noooo!  I have to manage the people because I am a Manager".  Correct you are a Manager but remember you are a PROJECT manager, not a PEOPLE manager.  Huge difference.  Stop managing people when you are doing SCRUM.  You have to lead people and mentor them by teaching them how to become self-managed.  SCRUM-whipping and micro-managing people is NOT a discipline in SCRUM.

I have seen several PM's fail miserably trying to combine waterfall with SCRUM. They try to take the parts they like from each approach and create their own way of doing it; with terrible results and a disillusioned team as a result.  Even worse; They give SCRUM a bad reputation.

So get this: either you do SCRUM and you do it 100% or you don't do it at all.  It's that simple.  If you do not understand SCRUM, go get certified, but please stop pretending that you know SCRUM.  There is no shame in admitting that here is an opportunity for you to grow and learn something new.

Ok, enough for now.

Here is the Task Board I referred to in the beginning:

Now what does a Cruise Missile have to do with Project Management / Software development you might ask yourself?

Well they have a lot in common with agile software development if you ask me.

One day Melvin owners decided to send him out on a mission, a very long mission.  Melvin was given a goal that was more than 2,000 km away and was told that there would be no room for failure;  he was to hit his target no matter how.  And that was all Melvin had got to go with.  Melvin was all prepared for his journey, fueled up and excited to be launched from the submarine in which he had been living a quite life up until now.

The hatch on top of Melvin's house opened and "KAPOW", Melvin was launched out of his house.  As soon as Melvin was out of his house and in the water Melvin's engines roared to life with a loud "WROOOOMMMMMMMM".  "WOW", Melvin thought as he broke out of the water, "This is it";  "This is my time";  "This is what I have been waiting for since I was born."

All this excitement plus the cold water, made Melvin a little dizzy, but he shook of the initial excitement and got to work.  First thing Melvin did was to orient himself using his GPS and build-in map.  Or rather he tried to, only to realize that the map was useless out here flying over the ocean.  Oh well, Melvin thought, I have plenty of time and I know the barring of my goal, so I will just fly a while in the direction of the goal and see how it goes.  And so he did.  Melvin set the course as good as he could, given the circumstances.

After flying for 15 minutes, Melvin started to see land ahead.  "Swell", he thought to himself, "now I can adjust my course".  Melvin looked at his map again and tried to recognize where abouts he was now, but he was still a bit to far away to see enough details with his eye.  "But wait, there is a mountain range out there, and I see a mountain range on the map."  Using his logic and his on-board computer, Melvin quickly calculated where he was suppose to be, compared that to his current location, and then adjusted a little bit to the right.  "Nice" Melvin thought to himself, "Now that I have adjusted my course, I have a better chance of hitting my goal." and so he continued for another 5 minutes.  Now Melvin was flying over land and had a much better picture of where he was.  Using his eye, the build-in map, and his goal, Melvin started to check his position again.  All this while he had to focus on the flying as well.  Melvin liked the excitement of low flying, but it was also challenging with all the towers, mountains and other obstacles he had to navigate around.  It was important that he was not discovered, so Melvin could not fly in a direct line toward his goal, but he had to follow the natural landscape with valley's and old dried out riverbeds to stay below the radars.  This meant that Melvin now had to adjust his course on a more regular basis.  Actually he was now adjusting his course constantly, while still trying to keep his end goal in mind.

The close Melvin got to his goal, the more often he had to adjust, but he still felt that he was doing all-right.  Then all of the sudden, Melvin heard a voice telling him that his goal had changed a bit and he was provided with the new goal.  "Oh well" Melvin thought to himself, "it is a good thing that I did not plan out my entire trip when I was launched, because I have had to adjust my path at least 5 times up till now.  If I had calculated my entire trip in details, I would have wasted a lot of time on calculations that would not add any value anymore."  So Melvin adjusted his goal according to the instructions, did another minor adjustment to his flight-path and carried on.  After another 5 minutes the voice came back: "Sorry Melvin, but your goal have moved again, so you have to adjust your plans again."  "Not a problem" Melvin thought, and adjusted a bit to the left.

Now Melvin was getting really close to his goal and to make sure that he would not miss, he started making more frequently, yet minor, adjustments to his flight-path.  Actually, Melvin was adjusting every minute now.  He was getting more and more excited because he knew he was in a good position and only had another 5 minutes to fly.  "I better validate my goal is still the same" Melvin and called up the commander in charge.  The commander confirmed the goal was still the same and with that knowledge Melvin now prepared himself for the final approach, arming himself and switching over to his vision for the final approach.  Melvin locked on to the goal, which was 5 km. away and made small adjustments constantly.  It was quite stressful for Melvin, as he had some side-wind to adjust for and the goal was still moving around.  Never the less, Melvin was now so close, that he only needed one final adjustment and braised himself.  BOOMMMMMMMMM!! was the last Melvin heard when he reached his goal dead center.  Maybe slightly off to the right, maybe one inch or two, but nothing that really mattered.  The commander at home in the submarine was very very pleased with Melvin's results and accepted the delivery without problems.  Later that night, the team celebrated the success of Project Melvin.

My point with this story, inspired by a presentation done by John Cleese (yes the Monty Python one) during a conference in Copenhagen some 10 years ago, is that if Melvin had not had the capacity to adjust his path during the project, then the odds of him hitting the goal would have been very close to zero, but by having the goal in focus all the time and adjusting his path, Melvin was a big success.  This is what we have to do as well when we build software for our clients.  Their goal's change as time passes and if we do not adjust our path during the project, then we will not reach the goal.  Allowing a project team to adjust and work on the most critical items first, without spending time on the lower priority items, we allow for our client to adjust his goals as time passes without jeopardizing the project, and we avoid having the team "wasting" time on items that might never be pat of the end solution.  This is what agile development is all about; making room for constant adjustments during the project.

Software development is not trivial.  It is a highly complex process and yet do we continue to act like it is something we have done many times before.  When we then realize during our post-mortum that we did not deliver what we expected to deliver within the budget we agreed to, we believe that the reason for our lack of success is that the people working in the project are not following the process as we have described it.  This leads us to reviewing the process and tweak it in those areas where we find the process to be unclear or not detailed enough.  After the adjustment we use the new process for the next project, only to realize in the next post-mortum, that once again we need to adjust the process and re-iterate to the team what the process is and that they have to follow it.  We describe in details which steps the team must follow, which phase-gates that must be adhered to and when sign-off is required.

We provide the team with our standard templates that we have created and adjusted using all of our past project experience.  We keep adding more and more details into the documentation to ensure that our clients understand what they will get so that they can sign-off on the documentation.  To have this process makes us feel good and we pride ourselves by having a well defined process that is well documented and should make us more successful.  With client sign-off on key documents, such as Scope-, Requirement-, Design-, Configuration- and Testcase-documents throughout the entire project, we feel secure.  And should the unthinkable happen that the client is not happy with what we deliver, then we can always go back to the documents that they signed off on and prove that we delivered what we promised; it will even hold up in court.  But is that really what we want and how we define our success’s?  By making sure that we can win in court?  Should it not be the happiness of our clients that defines our success’s?  We claim that that is the case, so when the client is not happy and threaten us with lawyers and change of partners, we often go down the path of giving away hours for free and hope that this will make the client happy.  But most clients do not care about getting hours for free.  They would much rather have the software they need when they need it at a reasonable cost.  For clients, the cost of not having the systems in place that will support their business-needs better is often 100-fold more expensive that running a project that is delayed again and again.

In all of the projects I have been part of for more than 15 years, I have never seen a project where the client did not change their mind at least a couple of times during the project on what they wanted and when they want it.  This change in scope and requirements causes delays and extra effort in the project because we now need to adjust all the documentation we have done, get new sign-off and re-start the project again with the new goal defined.  Often we will have to find ways to stay within the original delivery deadline as we agreed with the client on.  This then often leads us to find corners we can cut without compromising the entire project.  So we cut scope; we tell the developers to ‘just make it happen with less time available’;  we decrease the time that we had set aside for QA and still believe that the quality of our product will stay the same as the original plans.  Maybe, and only maybe, are we able to deliver something within the deadline, but how do we make sure that what we deliver is actually what the client needs?  I have seen many many cases where we have over-delivered in one area but totally missed out in other areas that were more important to the client, simply because we only have on focus and that is to follow the project plan;  then when we run out of time, those areas that were important to have delivered have to be dropped from scope.  In many cases it would have been better to delivery ‘thinner’ functionality in some areas, to allow for all areas to have features delivered.

I think most people can recognize the scenario I have described above and most people will agree that not two projects are alike.  So why do we, after 30+ years of experience running software projects, still believe that if only the team would follow the process that we have defined, then we would become successful?  That the process is correct but the execution of the process is wrong?  Why are we still making the same mistakes over and over again without learning from them?  But we do learn do we not?  Is that not the reason why we keep tweaking the process?  Because we become wiser and wiser.  I will risk the blame and claim that we do not learning from our mistakes.  We keep doing the same mistakes over and over again and we blame the wrong things for our failures.  It is time for us to realize that it is the process that is wrong and not the people following the process.  Remember, we are not building the same gizmo over and over again.  We are building net-new functionality every time we get a developer involved.  “Not true” some would say; “we have build the same functionality for several clients, so we must be able to estimate the effort, within 90% probability, that we needed to build it again for this client.”  So my question then is “if we have already built the functionality for several clients, why do we then need both architects and developers to be involved?”  Is it not the case that every time we build functionality, we are in fact building net-new functionality?  Is it not the case that no matter who detailed we describe a feature in our design documents, we still miss the target with what we deliver?