Certified ScrumMaster Training

So I just spent two days in London on a ‘Certified ScrumMaster’ training course run by Danube Technologies.

The instructor was a Dan Rawsthorne and although he liked to reference things to the military, he covered a great deal of topics and had an incredible wealth of experience – some of the real world example really struck home with me.

 It seems that a common trait is people just not grasping the whole concept of (basically) handing over control to the development team. There were many questions about where the project manager fitted in, who really managed the team etc etc.

It is tough to grasp if you currently have the perception of ‘having control of the process at the moment‘. It suddenly hit home for me as I was traveling into London on the train for the second day and thinking about why this current round of QA release testing was taking so long.

According to the QA guys, the build they had been given originally for this release was pretty poor quality (thankfully sorted out now). I was wondering why and thinking back to when this release was being coded and realized that at the time I was pressuring he developers because we were 100 odd hours behind schedule. We managed to get back on track and I ‘thought’ the reason was because I had beaten/pushed/cajoled/whatever the guys into increasing their work rate.

In reality, what had happened was that I had forced them to deliver early and the way this was done was by sacrificing quality (you cannot change the laws of dynamics – right). The fact was we did not get visibility of that until further down the line in the testing stage.

So, have a think about whether you do actually have control, or are you just exerting force on one particular aspect of the ‘whole’ that is squeezing/reducing another aspect of the same ‘whole’.

When this clicked in my head, it all made sense – the SCRUM methodology became clearer, what needing doing to get it working, why it worked (especially, why it isn’t a bad thing to hand ‘control’ over to the team).

One of the slide deck was about ‘technical debt’ and it really drives this point (sacrificing something for earlier delivery) home – I’ll blog about that later..