Punctuality and Respect

The following Dilbert cartoon rings true - click here.

Sadly, I've seen this attitude in many companies, especially a couple of large mutli-nationals I used to work for. Managers were perpetually late to team meetings. As the Dilbert cartoon suggests, this really shows a lack of respect for your subordinates, the message being that their time is not valuable.

As a manager, you should be competent at organising your time. Make the effort to be punctual with your staff - they will appreciate the respect.

Autonomy and Motivation

Daniel Pink has identified autonomy as one of the key intrinsic motivators. That is, if we have a complex, creative task to perform (like software development), we enjoy it more if we are given the freedom to make real decisions. From long experience, I have observed that programmers value autonomy almost above anything else. Programming is fundamentally problem-solving - if you put too many restrictions into the process, you rob it of much of it's joy.

So how do we establish autonomy in the workplace? Kenneth Thomas identifies the following building blocks -

1. Delegated authority - the right to make decisions
2. Trust - confidence in an individual's self-management
3. Security - no fear of punishment for experimentation and honest mistakes
4. A clear purpose - an understanding of what one is trying to accomplish
5. Information - access to relevant facts and sources

These are pretty clear, I think. The opposite approach is known as "micro-management", and it is loathed by programmers. I've known managers who insist on personally inspecting every line of code written by their subordinates. This sort of thing simply destroys motivation.

Does this mean we are left with a free-for-all? Not at all - everyone understands there needs to be boundaries, and these are often captured in standards and practices documents. Ideally these should be negotiated up front, and the relevants parties should "buy in" to whatever boundaries have been established. Then, so long as the boundaries are respected, the programmer ought to have autonomy.

One of the reasons I like Scrum is because it establishes and protects programmer autonomy. In a proper Scrum, the development team must agree to the amount of work to be done in a sprint. Furthermore, once the sprint has started, it is up to the team to implement the functionality as they see fit - neither the Scrum Master nor the Product Owner are permitted to interfere. And teams are highly motivated to complete a piece of work that they voluntarily agreed to - much more so than a schedule that is imposed by fiat.

Granting autonomy is not hard for "Big Picture" people - it is much more difficult, I think, for detail people, who want to know and control every little thing. If you are guilty of micro-management, I'd encourage you to change your course - the impact on motivation will be spectacular.

Seven Roles of a Leader

These are quoted from Kimball Fisher's excellent book, Leading Self-Directed Work Teams -

1. The leader unleashes energy and enthusiasm by creating a vision that others find inspiring and motivating.

2. The results catalyst helps the team improve performance, gets good results without resorting to authoritarian methods, manages people by principle rather than by policy, and uses boundaries rather than directives.

3. The facilitator brings together the necessary tools, information and resources for the team to get the job done, and facilitates group efforts.

4. The barrier buster opens doors and runs interference for the team, challenges the status quo, and breaks down artificial barriers to the teams performance.

5. The business analyst understands the big picture, is able to translate changes in the business environment into opportunities for the organisation, and acts as an advocate for the customer.

6. The coach teachers others and helps them develop their potential, maintains an appropriate authority balance, and ensures accountability in others.

7. The living example serves as a role model for others by "walking the talk" and demonstrating the desired behaviours of team members and leaders.

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.