In part two of my series on software craftsmanship I take a look at how Peter McBreen, in his book entitled Software Craftsmanship (McBreen, 2001), sets up software craftsmanship in opposition to software engineering. Actually he does say that "Software craftsmanship is not the opposite of software engineering or computer science. Rather, craftsmanship is a different tradition that happily coexists" (p. xvi). But the rest of the book undermines any claimed coexistence.
Continue reading
Management on the Ground
You have to keep your feet on the ground when others want to put you on a pedestal. After a while on a pedestal, you stop hearing the truth. It’s filtered by the henchmen, and they read you so well, they know what you want to hear. You end up as the queen bee in the hive, with no relationship with the worker bees.
Bill Burns, CEO of Roche Pharmaceuticals
quoted in Goffee & Jones (2006), p. 43
One of my project managers recently mentioned that, despite being a programme manager, my own management style is quite "hands-on". In the sense of being on the ground with my team rather than in the technical sense although the two often come together. This approach has held me in good stead over the years.
Others, like Bill Burns quoted above, have realised dangers of being distant from the people doing the work and the corresponding benefits of being on the ground. I thought I’d take a quick look at some of these previous advocates of being on the ground:
- Military Commanders on the ground
- Management by Walking Around (MBWA)
- Toyota, Lean and Genchi Genbutsu
I’ll wrap up by having a quick look at the Agile practices that help me be on the ground.
Continue reading
Is Software Craftsmanship some code-obsessed mishmash of martial arts and carpentry?
Software Craftsmanship is some code-obsessed mishmash of martial arts and carpentry or plumbing
Ade Oshineye: Software Craftsmanship – More than just a manifesto
"Software Craftsmanship" is one of the big catch phrases in the software development community at the moment. There is an Manifesto for Software Craftsmanship, a few books (Hoover & Oshineye, 2009; Hunt & Thomas, 1999; Martin, 2008; McBreen, 2001), conferences and seminars, and lots of blog posts.
But what does software craftsmanship actually mean?
Continue reading
Agile: I Prefer Hype to Ignorance
The good news is that Agile has crossed the chasm (Moore, 1991). On the down side there has been, and is, a lot of hype and hyperbole around Agile, Lean, Scrum, XP and Kanban, etc, etc. In particular, and despite the Agile Manifesto, the meaning of the term "Agile" has become very diffuse. So much so that there are many people, like a colleague of mine and one time Agile fan, who now says "I don’t talk about ‘Agile’ any more; it doesn’t mean anything".
I find the hype annoying, and Agile’s loss of meaning exasperating, but I also think it an inevitable part of progress.
Continue reading
Side Bets and Sweeties in Organisational Change
People don’t resist organizational change! – People resist being changed!
My current programme is using new, bespoke software to drive organisational change. So I need people to change what they’re doing. A lot of people. As a first step I need them to adopt our new software. So I am always looking for ways to push the software roll out. In an earlier post I described one approach we use for encouraging adoption: Foot in the Door Technique. In this post I look at two other methods – which we call "Side bets" and "Sweeties".
Continue reading
Reinforcing Success in Products and Projects
A fundamental military axiom is to reinforce success.
Reinforcing success is a strategic concept used in many areas of decision making and management. Originally a military doctrine, the term is also used in theories related to parenting, business and other fields. It is essentially a selection criterion, or a prioritizing principle. A course of action is selected from various options on the basis of previous results of similar actions. The basic idea is: if it works, keep doing it; if it doesn’t, don’t invest more in something that’s failing.
Wikipedia: Reinforcing Success
I believe businesses should apply this principle to projects, products and product features. So not surprisingly I apply this as a guiding principle in my own work as an agile programme manager.
Continue reading
Requirements: State the Problem not the Solution
We all do it. Even those of us, like myself, who should know better do it occasionally. But it is wrong. Or if "wrong" is too strong a word, then it is at least misguided.
What is it? It is the habit of stating a solution when we should be explaining the problem. This habit isn’t confined to a specific role; I’ve seen all members of the team do this … users, product managers, project managers, business analysts, technical architects, developers, user experience designers, testers, and management stakeholders.
Continue reading
Case Study: Motivating a team using Agile practices
A while ago I did some consultancy with an Israeli company that was kicking off a large, complicated and challenging project. They wanted advice on how to motivate the team so I looked in my toolkit – both Agile and general management – and suggested a few things.
It is worth emphasising that the company’s sole concern in this case, and the reason for my engagement, was "motivation" and not Agile per se.
Continue reading
Two Types of Post Implementation Review
Recently people at work have been asking my advice on how to run post implementation reviews of major programmes so I thought I’d write up my thoughts. I believe there are two types of post implementation review and I recommend doing both. The first type happens in Project Closure and the second happens after the project has finished, i.e. Post Project.
Continue reading
Managers v Leaders: Are Managers Plodders and Leaders Cool?
I consider myself a good manager and a passable leader. This should be okay but there is a certain anti-manager trend in the business world that is particularly prevalent in the Agile community. For example it has been common for Agilists to say "We don’t need no stinking managers " (Esther Derby: Rethinking Managers Relationship with Agile Teams).
It seems that leaders are somehow more cool than managers. Conventional wisdom says "Managers do things right; Leaders do the right things" (Buckingham & Coffman, 2001). And Jim Highsmith (2009), one of the Agile gurus, makes it clear that Leader = Agile and Manager = Non-Agile. Ouch.
Agile leaders lead teams, non-agile ones manage tasks.
Highsmith (2009) cited by Scrum Expert
All of which makes self-labelling as a "manager", particularly an "Agile manager", rather risky. But before I go off to find a job as a leader, for which I’m possibly under qualified, I thought I’d take a look at the differences between leaders and managers and assess whether common wisdom is, after all, very wise at all. To do that I’ll outline what a couple of other people say about managers and leaders and how that marries up with my own view.
Continue reading