Regulating development

An interesting post on the Ken Schwaber blog:

Our  shortcomings were surprising to me. When I rolled out Scrum, I thought that the excellent developers that had been stifled by waterfall processes would emerge, and we would again do great work and build great software. Much to my surprise, many never had those skills or had lost any skills they had. The pressure of “get it all out now, cut quality to do so” had reduced most developers to unskilled, unprofessional, angry drones. The larger the organization, the worse the situation as “mediocrity scaled.” Organizations whose software is only five years old are already crippled by technical debt.

He posits that governance of software developers is imminent – whether the industry elects to self impose these guidelines or the government demands it – and that formal regulation of skills and capabilities is needed.

It reminds me of my real estate days – an industry with a very low barrier to entry, and an extraordinary range of practitioner proficiency.  (Sound like software development to you?  Yeah, to me, too.)  There is a plethora of “certifications” that are intended to provide proof of an agent’s skill.  A Certified Residential Specialist?  How about a Graduate of the REALTOR Institute?  When working with an agent with a set of fancy letters after their name, did the transaction proceed more smoothly?

Not generally, no.  In my experience.  They’re generally pay to play: read the handout, sit in a chair and exist for the required number of hours, pass a simple test, pay the man for the honor of putting the letters after your name for a year.  Clearly, this is not the model to adopt.

This, however, is certainly a problem:

If I were on a team, I wish that I knew the level of the developer that I was bringing on board, instead relying on personal references and “the usual suspects” to avoid getting swamped by unfounded braggarts.

I don’t personally believe a governance board can replace screening candidates for my personal standards for proficiency.  Might it give me some warm fuzzies that the candidate has at least tried to gain a skill?  Possibly.  But in a world where even a college degree is seen as optional, an archaic proof of capacity, what can a governance board provide?

It’s an interesting thought.  Can you regulate development processes across an entire industry?  Can anyone really certify skill, if proficiency is a relative determination?  Things to ponder.

Efficiency and Effectiveness

I went and got myself a certification this week – I am now a Certified Scrum Master, thank you very much.

Overall, the class was interesting. The teacher was engaging and the format was interactive. I enjoyed having time to dive into “true” scrum practices, see them at work, and better understand the reasoning behind the process.

A common complaint about scrum is the volume of meetings – the sprint planning, the daily scrum, the backlog grooming, the review, the retrospective. That’s 5 mandated meetings per sprint!

The teacher made an interesting comment, however, that scrum is an effective solution, but it might not always be the most efficient solution. This, I believe, is very true, at least from the day to day perspective. As a project, using scrum might indeed be more efficient, but as an individual contributor on a daily basis, scrum can seem like a lot of overhead.

Indeed, in some agency environments, and in very small teams, scrum may be too much process – there are many situations where a leaner solution like kanban would be more appropriate.

As a systems engineer, I am typically hyper-focused on efficiency – but that should never come at the price of effectiveness. What may be most efficient on a daily basis might not be most effective in the long run.

Things to consider.