When I was working my way towards becoming a CMMI SCAMPI B&C Team Leader, I took a couple of courses with the SEI.  It was an interesting bunch of people that attended those sessions - largely the haute process crowd from the Raytheons and Lockheed Martins of the world, swapping war stories about their drives to attain CMMI Maturity Level 5.  As for myself, I was barely paying attention during my Intro to CMMI training when they covered anything above capability level 1.  I figured I'd never need to know this stuff - it was never going to come up.

My fellow candidate SCAMPI B&C Team Leaders thought it adorable when I told them my experience with the CMMI and appraisals had all been at capability level 1.  Whereas they likened themselves experts in high maturity, I told them I liked to think of myself as a bit of an expert in the low maturity organization.  When they laughed at that, I asked them how big their market was - I'm pretty sure mine is enormous :)

Eventually I got my authorization and started leading appraisals.  At the end of each one we would have a final briefing with the sponsor.  The intent of this meeting was to give the sponsor the opportunity to ask questions about the appraisal findings in a private setting.  In every single one of these briefings, the sponsor would ask us "what should we work on first?".  As appraisal team lead, I'd have to answer that question - and in the early going, I'd always say something weasely like "estimate the value and cost of each one and then build a plan that delivers the most value while keeping cost to where it won't prove a distraction from your day job".  I think I can do better that that now.

At the time, my own organization was fairly small - as we grew and I saw the kinds of problems we encountered in our own nascent processes, I realized the real turning point for us had come when we started with Scrum.  What Scrum did for us in the early going was give us:

• An effective planning model.
• A way to get our stakeholders to trust us (because we were now meeting our commitments most of the time).
• An on-going focus on improving ourselves and a way to get those improvements prioritized and implemented.

That first bit was key though - Scrum taught us to plan better and that one improvement led to everything else we were ultimately able to accomplish.

After this experience, I had a much better answer for people in low maturity organizations looking for guidance in taking their first steps down the process improvement path:

Get better at planning.

If you can plan well, you can do anything else.

I once knew a senior manager who, when asked about a well-respected person who had just left their organization, commented that he didn't know why they'd left but that attrition was a necessary part of personnel management.  As an outlook on attrition, that's just plain wrong.  Rationalizations like these equate whatever successes the organization has had with the methods in place - so if those successes have been had in an environment that historically saw a high degree of personnel turn-over, then that must be a part of how those successes were achieved.  But market success does not imply operational excellence.

In evolution, the genotype is the genetic code for an organism while the phenotype is the organism itself.  If we posit the existence of a real Blind Watchmaker, he'd be an entity that throws spaghetti at the wall in terms of genotype but studies the phenotypic outcome (that is whether or not early death prevented the propagation of the genotype for that organism) to determine the value of genotypic traits.  This imagined Blind Watchmaker would then be dependent on death as his only source of information regarding the phenotypic quality of genotypic traits.  Leaving aside forms of Lamarkism, that's a pretty scarce source of information for the poor Watchmaker.  In a development organization however - the local development biome - management has a lot more leverage on the situation.  Equating genotype with the software developer's inherent traits and characteristics, the environment with the operation of the development organization as a whole (its culture, projects, history and so on) and the phenotype with the outcome of a given developer's tenure with the organization, it's clear that a manager can exert a lot more influence over the biome than can the Watchmaker.

But in the end, phenotypic failure is the most important piece of information in both systems - in software development, phenotypic death is termination of a developer's employment with the organization.  Firing and attrition are death - and with some estimates putting the costs of attrition at over $150K per occurrence, it's the wise manager who looks at every occurrence as an opportunity to improve the selection process in hiring or the biome itself.

Why did they leave?  Why did we have to let them go?  How can we use this painfully bought feedback to make the organization better?

So whatever you do, don't take a laissez faire attitude to attrition - if you do, better managers will clean your clock for you.

In this video I present Scrum staying close to the canon as it is described on scrum.org.  All major aspects of Scrum are covered.  This video should be a useful starting point for people wanting to start to understand Scrum and whether or not it will make sense for them in their work.  I hope it proves useful.

Handouts accompanying the video are available here.

Dim lights Embed Embed this video on your site

When I was a little baby developer, colleagues used to worry about getting a ton of product releases on their resumes and, similarly, looked for people with lots of product releases under their belts when hiring.  People spoke in respectful tones of developers with large collections of "Ship-It" awards.  You still hear this kind of talk - for example, people will say things like "at the end of the day, delivering product is all that matters".

But none of it means much, if anything in hiring.