I am now a Certified Scrum Professional

clock November 18, 2011 10:07 by author Tommy |

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.



Project Management and SCRUM Task Board

clock November 4, 2011 14:58 by author Tommy |

This is too funny Laughing.

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:



Melvin, the self guided cruise missile

clock October 24, 2011 13:42 by author Tommy |

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.