Musings of ls6

Backlog Prioritization Experiment

I took the “silent grouping” technique I’ve known from working with affinity diagrams and tried the same mechanism for backlog prioritization. It worked.

Longer version

First a disclaimer: I’m describing here (yet another) method that uses “group wisdom” to bring order to a set of things to be done. There’s time and place for methods like this as there are times and places for a more structured approach. Neither is a silver bullet and your mileage may will vary :)

Now, down to business…

To start, install trust

The gist:

If you are an agile coach contemplating on taking a particular job or a manager trying to breathe some motivation into your people, take a good and honest look whether the organization fundamentally trusts the employees. If not, you are probably going to waste your time and/or money.

Full story (a bit of a rant):

Some time ago I had a rather spirited conversation with an eminent gentleman in charge of a software company. His company operates in a very particular niche is doing fairly well financially: the business is stable, probably no cash-flow problems, generally no stress—at least in comparison with other companies in the business of writing software for others so we were talking about employee motivation and retention.

Prior to owning his own company this gentleman has a history of work at a renown university and a bunch of large companies of which the McKinsey & Co. serves him as an example of a company culture delivering excellent results. And when we dove into what that meant the discussion got spirited.

The discussion took quite a while and I’m not sure I was able to get my arguments across—I was going for Pink’s mastery, autonomy and purpose triangle—but it certainly left me thinking and made me realize something rather fundamental.

When you go through any literature about “the new way of shaping the company culture” it, roughly, prescribes the same cure: empower the people and give them responsibility, purpose, praise and sense of achievement. What I haven’t seen anywhere explicitly stated is that before any of the above can be done you must simply trust them.

If you and me have ever talked (because I don’t think I’ve ever written that) you might have heard me mentioning something similar: that all the agile ideas are based on an assumption that you have hired the right people. People who actually do want to work for you, are not stupid, terribly lazy or dishonest. But I was wrong, it is not the correct assumption.

The real assumption is whether you trust that your people do want to work for you, are not stupid, terribly lazy or dishonest and whether you treat them in such a way.

This is where your corporate background or reality may hinder your most honest efforts to bring the creativity and motivation out of them.

Many corporations have this very weird split personality disorder and hire “passionate, self-motivated people who help them shaping a better future for the company and the whole world” but only have unscrupulous employees whose every hour in the office must be strictly recorded, every pen and sheet of paper accounted for and every task supervised and approved. How come that a simple act of signing an employment agreement transforms them from the first kind to the latter? And the greatest showstopper is that these organisations often don’t see this discrepancy. They want their employees to be creative because that’s the essence of their jobs yet manage them as Taylor would on a 19th century boring and repetitive production line.

So, if you really want to change your organization take a good and honest look at the trust issue. If it is lacking you are in for a long fight. I believe it can be won but it will not be easy and if you just implement new mechanisms and methodologies without addressing the underlying presumptions (or are they assumptions?) the chance of making a lasting change is, in my opinion, zero.

Prioritizing work

Are you sure you prioritize you work thoroughly? Are you sure you are not missing an important aspect?

Here’s an actual case I’ve heard about very recently:

  • an experienced software team of 4 in a much larger organization
  • must be responsive to requests coming from other 8 teams and develop (internal) tools at the same time
  • evolved from a random way of working through sort-of-Scrum to kind-of-Kanban
    • kept Scrum iterations (3 weeks long) as a heartbeat for reflecting upon it’s own work and reporting to the organization
    • kept Scrum planning sessions and commitment to deliver certain amount of work within the iteration.

I’m a proponent of agile approach over strict adherence to one methodology or the other so I don’t think there is anything wrong with this approach. The team have been developing and improving their way of working over a year and a half and reportedly arrived at a solution that was working fine. They have achieved the right balance between being responsive and having the time to keep working on their own projects—which was the major problem they were addressing throughout their agile journey—and overall it sounded like a success story. The only thing that kept nagging me was why, the hell, they were still having these planning sessions. Their progress on their products (the internal tools) was not tracked by the rest of the organization which seemed to care much more about their responsiveness. In my experience the planning session could be long and sometimes painful and they certainly didn’t need it to keep the responsiveness up, Kanban does not require it… I couldn’t let go of this question and approached the guy after the talk and asked.