Adrenalin rush, it’s not just for parachutists anymore

In A Successful Manager But Never A Successful Project? Bruce Benson writes about a rather thought provoking idea: People might actually like being in firefighting mode!

The next time I’m in a situation where I’m having trouble understanding why management is not encouraging improvement, but completely focused on dealing with the craze of the day, I’m going to remember this post. And perhaps arrange some panic theater to keep everybody happy…

Deliver business value, yes. But what should the business value?

Paul McArdle of Global-Roam writes about an interesting article by Roger Martin in the Harvard Business Review (which ca be found here, but requires payment for the full article): ‘The Age of Customer Capitalism’.

The main drive of Agile processes is to deliver business value as effectively as possible. For anyone working in a more complex environment, this automatically raises the question of what business value is, and how it should be prioritised. Things like ROI can be clear, but in my experience is hardly ever used with any kind of rigour. The maximising of profits is very nice, but can not often be linked directly to the particular feature that is being developed.

So why not focus on the customer value? As the articles above state, this is usually a pretty good way to ensure long-term profitability for your company. And though there can always be different points of view on how to serve the customer best, customer satisfaction is certainly a measurable quality!

If you are working on software ‘visible’ to the end-user, it is wise to always consider how that customer is affected by your choices. If you’re prioritising a backlog, keep in mind what features are really needed for your customer, and which are coming from a different source. When implementing some new functionality, imagine how this (rare, they’re always rare!) error condition will appear to the user. Or how much he will be helped by simply ordering this list in that pull-down menu alphabetically, even if that was not explicitly in the spec. The end-user rules.

It’s the people, stupid!

I just came across an old article by Alistair Cockburn, called Characterizing people as non-linear, first-order component in software development that should be required reading for anyone working in software development. The title might be a little off-putting, but the message of the article is simple: It’s the people that make or break a project.

Cockburn first describes his own history in designing methodologies, and running into the same problems again and again:

  • Problem 1. The people on the projects were not interested in learning our system.
  • Problem 2. They were successfully able to ignore us, and were still delivering software, anyway.

He then goes into a meta-study of different projects with different methodologies, and finds that:

  • Almost any methodology can be made to work on some project.
  • Any methodology can manage to fail on some project.
  • Heavy processes can be successful.
  • Light processes are more often successful, and more importantly, the people on those projects credit the success to the lightness of the methodology.

He then describes the well-known model of communication effectiveness, where the highest bandwidth communications (‘Two people at a whiteboard”) is the most effective, and paper the least. He gives nice examples here:

Even walking from the train station together was a more effective design environment than talking over a video link.

This is then turned into practical advice on how to document systems: use video recording of a whiteboard sesssion, preferable annotated to indicate the ‘good bits’. This seemed like a lot of effort to me at first, but it might actually be easier then the normal paper trail, and should be a lot more effective.

Then, there’s some bad news: people are inconsistent! Shocking…

But that means that if you have high-discipline methodologies, for instance depending on religiously keeping documentation up-to-date, you’re setting yourself up to fail. Non of the projects he investigated managed to keep their documentation in perfect order. And even in those that came close, people didn’t trust it to be up-to-date, and always referred back to the code.

It is recommended to, instead of relying on the unlikely consistent and disciplined behavior of people, to instead depend on the success factors of people:

  • people are generally interested in being “good citizens”,
  • people take initiative,
  • people are good at looking around.

In other words: You can’t make your documentation perfect, but people will simply take the initiative to look around and find what they need to know. Either by looking in the code, or by talking to people.

I think this is one of the reasons why I like agile methods. They are very much focused on people, and on creating an environment where people can work together, using high-bandwidth, multi-modal communication, and relying on their inherit strengths, instead of trying to force them to compensate their weaknesses.

Seven habits of highly effective scrum-teams

A colleague of mine, Dion Nicolaas, has written what I think is best described as a manual for Scrum: Seven habits of highly effective scrum-teams. The great thing about this book is that it is incredibly practical, a true implementation guide. The subjects discussed are there in enough detail that anyone using scrum will immediately be able to place them, but are very short and to-the-point, obviously coming directly from practical experience. Of course, working at the same company, I know he’s been very successful implemeting scrum in his team.

NOTE: Due to preparations for publishing, Dion’s text is currently not available on his website. It should return in some form in shops at a later date.

The Declaration of Interdependence

The Declaration of Interdependence is an initiative of the APLN, and codifies some guidelines for lean and agile (project) management. It’s not new, but it does make for a nice companion to the Agile Manifesto with a different way of stating the same principles, with a focus to link them to the business reasons for applying the principles.

Lean? Or Gaunt?

The fear of economic downturn can make companies reluctant to enter into any kind of commitment (don’t worry, this won’t deteriorate into some sort of relationship advice… I think). They don’t want to commit to their employees, by stopping bonuses, canceling pay-raises, ‘no-motions’, and sticking to temporary contracts only.

When seen as a matter of risk-management this can readily be understood: limit expenses, and make sure it won’t be too problematic to get rid of any of your employees, should the necessity arrive. But if we look at these practices from the viewpoint of building a sustainable company other considerations should be taken into account.

How do you build a company? Looking at the current share-price and what is of influence on it, and trying to decrease cost and increase profit margins? Yes, you do need to keep an eye on those. But if you intend your company to last for the longer term, it can be very dangerous to limit your focus to only those short-term goals. Especially the type of modern company that is built on knowledge and innovation should not see their employees as a cost factor, but as capital. You try to reduce costs, but you want to increase capital. Neglecting the needs of that capital, especially in economically uncertain times, can mean that you erode the basis on which your company is built.

Of course, monetary incentives and job-security are not the only ways to build a sustainable relationship with the people working in your company. They are not sufficient. But again, especially in an economic downturn, they are a necessary minimum investment.

So what happens when we forget to pay attention to the relationship between a company and its people? Uncertainty, unrest, reduced productivity (and brain damage, according to Ron Burk), people leaving, knowledge draining. In other words: erosion of capital.

Sometimes people imagine their company will simply be more ‘lean’ if a number of people voluntarily leave. The financial pictures look better with less staff to burden the expenses side of the reporting. But losing weight by letting your muscles atrophy is not generally considered the best method to get to a healthy body. You build the muscle, and use it to burn away the fat (like those cumbersome manual procedures that you should have automated years ago, but never had the time for…).

And then you run, and get far ahead of your competition.

How to get rid of the irritating gnome-keyring prompt at log-in

A useful tutorial to get rid of the irritating password prompt by the gnome keyring at every login. It uses pam to pass-through the password you logged-in with to the keyring. As long as that is the same password is the same one as the one for the keyring, that is, but that is the default.