The Scrum 3x3

I've published a new and improved version of this article on LinkedIn. Click here.

I've been developing software professionally for over 20 years, and project methodology has been a perennial problem in the industry. In the mid-90s it seemed like a new methodology was being devised every other week, and none of them seemed to deliver what was promised. I think I came to the implicit conclusion that software project management was an intractable problem.

If you had told me back then that a new methodology would soon come along that would be adopted by perhaps 80% of commercial companies, with many people reporting great success, I would scarcely have believed it. Yet that is exactly what has happened with Scrum.

Let me admit up front that I am a fan of Scrum, and I want to discuss it in future posts. Now, I'm not really interested in the Quest for the One True Scrum, and nor do I want to participate in the Scrum Wars. But I thought I should at least share what I believe Scrum to be.

Essentially, to be doing Scrum you need to have the following 3x3 -

• 3 Roles - Scrum Master, Product Owner, Team Member
• 3 Meetings - Sprint Planning, Daily Scrum, Sprint Review/Retrospectivve
• 3 Artifacts - Product Backlog, Sprint Backlog, Burndown Chart

The whole process is well captured in this image -

And that's it. If you are doing anything less than this, I would suggest that your methodology is "Scrum-like" but not Scrum. If you are doing anything more, good for you.

Why this blog?

I thought it might be helpful to explain the purpose of this blog. I started it for three reasons -

1. I agree with Scott Hanselman that software professionals should have a public blog, a place where they share ideas, opinions and lessons learnt. Software development is difficult, and will be even more so if we don't share our knowledge.
2. I've recently commenced a Master of Business in IT Management, and this will be a place where I can reflect on what I've been learning.
3. I wanted to fill a bit of a gap in the knowledgesphere. There is plenty of information online about software project management, but very little about managing software developers. Indeed, the only other blog I'm aware of in this space is Rands in Repose (and a good read it is, too). Hopefully I can encourage a bit more discussion in this space.

More on Motivation

Click here for a new and improved version of this article.

Have you seen the animated video called Drive: The surprising truth about what motivates us? If not, you should check it out now. The video is a summary of a book by the same name by Daniel H. Pink. His thoroughly researched thesis is that extrinsic motivators (the proverbial carrot and stick) are not effective when applied to jobs requiring intelligence and creativity - jobs like software development. Pink proposes that intrinsic motivators are much more effective in these instances, and he identifies three - autonomy, mastery and purpose.

There was a big "a-ha" moment when I first encountered this idea. Looking back over a long career in software, it is plain to me that the most ineffective managers have been those who relied most strongly on an authoritarian "punishments and rewards" approach. The same experience suggests that Pink's three intrinsic motivators are spot-on with regards to software developers.

I've previously discussed the idea of purpose at work. In future posts I'll examine autonomy and mastery, and how these ideas can be applied to create a great environment for software development.

Key Leadership Tasks

Leadership is a complicated idea, and defies over-simplification. Still, the following four pronged model is as good a description of the strategic leadership task as I have seen -

1. Establishing the organisational Core (mission, vision, values)
2. Aligning organisational structure/culture with the Core
3. Managing power constructively
4. Stewarding renewal

This model was devised by Ken Dovey, from the School of Systems, Management and Leadership at UTS. In future posts I'll reflect on how I see these ideas playing out in software development groups.