I was listening to one of Scott Hanselman's podcasts this morning and Scott made a comment about people thinking that agile methodologies were and excuse for sloppy project management (NOTE: Scott wasn't of this opinion, he just stated that some other people thought this).

I am fully bought into SCRUM, and whilst we don't implement if fully at work (we have our own handcrafted way of doing it that really works well for us) I think it brings great benefits.
One of the real stumbling blocks with people adopting SCRUM / Agile is getting over the mind set that they can determine the delivery dates and that they can force the development team into delivering everything they want by that date. I truly do not believe that it is possible to fix both scope (requirements) and timescale (delivery dates) in a software project, even having done lots of design up front. I have written before on the perils of this approach...

Giving up all control of dates is something that takes quite a psychological leap of getting used to, but when you are there, you see all the benefits. Let me give you an example...

Think of The Beatles.
Their 'products' were (obviously) their songs, they were all passionate about what they were doing (providing great music to the masses) and they did it really well - everyone loved their product.
When Lennon and McCartney (and Harrison) sat down to write a song, if they'd had a limited time then the quality would have suffered. They were not limited in time and they produced great things.

That is one of the things you have to accept in agile - crafting great software products is an skill and an art, for the developers sometimes their creative juices flow in abundance, sometimes they don't.
To meet strict timescales, something has to give, and that something is scope (or quality, but you don't really want that do you ??...)

So, this is something I learned on the Certified ScrumMaster course by Danube Technologies.

It really clarified for me that any sense of control over software deadlines is, pretty much, only a 'perceived' sense of control.

Yes, we can strongarm, use peer pressure or rigid authority to make developers work longer hours, but then they spent more time idling during the day. Someone, somewhere has written a great article on it (Note, after spending an hour looking at Joel On Software thinking the link I wanted was there: Link it here when found)

Anyway, the graph - let me explain....

A development team has a normal work rate (given all things are equal, interruptions, bug fix workload, training , yadda yadda...) in this case the work rate is 30 'units' in a 15 day period (the red line). Supposing we 'force' them to up their productivity to 40 units in a 15 day period (dotted green line). They will work at their normal rate initially and then soon recognise that this will not meet the deadline - at that point they 'speed up' (this is the change in the solid green line at the 7 day point).

What you have actually done (most likely) is generated a 'technical debt' - because the way the developers 'sped up' (wrote more code) was by sacrificing some other aspect of the development (quality, test coverage, peer reviews etc).

So you have a 'technical debt' that needs to be made up during the next period. Even if we go back to the normal rate of work we are not going to get 30 units done in the 15 days, oh no, first we have to make up the debt, then start on the 30 units - which will likely need 'speeding up' to meet deadline.

What is worse though, is that now you have set the expectation that the team can deliver 40 units in the 15 day period, so your next schedule had 40 units factored in, and the next, and the next until ..... well, it's like spending more on your credit card every month than you are paying off, at some point you can go no further .

The moral of all of this ?    Who knows... get a card with a long 0% balance transfer rate ??

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..