The Zen Of Relationships

Relationships, between friends, family, lovers, colleagues or competition have a way of evolving. Most people value frequency and quantity in this evolution, and lament a relationship if it is kept idle for a length of time. Most people also value investments made in their relationships, whether by expectation, attention, love or contract (sometimes all of the above). They would also get angry if their investment into the relationship doesn't pan out the way they thought.

It's not really a stable way of looking at it. The thing you can be sure about, is that

• the longer you're around, the more people you meet who compete for your attention
• the more likely you will pick up stuff to worry about, like a house, career, car, insurance...
• you're going to try to fit more and more relationships in the same 24-hour day

I'm not in favour of dismissing relationships as a matter of fact, simply because of a simple human condition, that you can't do two things at once, and that you have to prioritize.

I'd rather just value relationships at the point in time that they existed, and not worry about "long-distance", or "long time ago". It's not like I'll treat everyone as if I've seen them just yesterday, but I'm sure to treat it with respect.

Fear and Loathing in Hell's Kitchen

Gordon Ramsay's Hell's Kitchen (the US version that is) is a microcosm of human behavior. Every emotion, backstab, ass-kiss, victory, loss is magnified under the scrutiny of the camera, as well as through Ramsay's explosive character. And it's brilliant.

I do see a very worrying trend in Hell's Kitchen, in how the candidates argue, justify and deal with failure, defeat or resistance. If this is a reflection of current western society, I fear for humanity.

It is rare that candidates analyze their weaknesses in any level of detail. Ramsay might kick their asses and confront them with their faults (very harshly I might add), but they rarely do anything with these. Instead they turn attention to the faults of others. There's no introspection.

Corollary to not seeing their own weaknesses, candidates usually compensate weaknesses with a display of effort. Truthfully working hard and perseverance under the most difficult of circumstances are virtues, but the trend now is to cover up the biggest of failures with having "fight". Last time I checked "fight" doesn't compensate for "suck".

Candidates have the notion that they live in a free society, and can opine what they want, when they want. And they should be respected for having an own opinion, having unique thoughts, and independent actions. Unfortunately for them, this doesn't fly in Gordon Ramsay's kitchen. If you fail in his kitchen, he will tell you. If you fail badly, he will tell you. In no uncertain vocabulary. If you fail in the worst, dumbest way, he is under no obligation to encourage, help, be nice to you. In fact, you can expect an ass-whuppin' and you will accept it.

Finally candidates try to win arguments by increasing volume. As if any person can be persuaded because he or she didn't hear you the first time. And the candidate is actually offended that the first time wasn't understood. Madness.

And while all this epic fail makes for brilliant television (and in fact the only reality tv I can stomach), it still makes me sad for humanity and society at large. It's deterioration, it's like seeing a loved one growing more ill every day - and there's nothing you can do about it.

When Agile Isn't Agile

I like working in Agile teams. There's nothing better than spending the best part of your working day, with like-minded people, with the same goals, doing our best work. And in my line of work, projects or business-as-usual, it's quickly becoming a given. Talking to people who don't say they work with Agile methods, is like talking to people who aren't yet on social networks. "You aren't on Twitter/Facebook/Linkedin yet?"

Now of course some of those people have very good reasons not to be on any social networks, just the same as some organizations have very good reasons not to work Agile. It's not these organizations I speak about here. It's the organizations who say they are, when they are not - whether mistaken, misguided, misleading, take your pick. They pick up some of the buzzwords, spin it in a way they understand best, but rarely what organizations actually do in the end is in the spirit of Agile.

And I understand it's not easy to go from a traditional way of working to an Agile one. It's a sea change that requires and advocates changing the way people approach their work. And sometimes to make the change palpable, you make concessions, or you make an interpretation. These interpretations may be shaped in a way that does not fit Agile principles, but still works for your organization - which is fine... as long as you are not deluding yourself.

Principles are dangerous things. People live by them. People die by them. And they become even more dangerous when they are not fully understood.

1. All decisions are final. No Backsies

With Agile hopefully there's a semblance of a belief that during the course of project various factors can affect it. Agile advocates iterations to institutionalize a regular evaluation process in a project - so you won't end up missing your mark somewhere down the line.

Agile does not advocate turning on a dime every single iteration. Iterations allow people the opportunity to reflect on what happened, to take stock in what's going on in the environment, and to take actions accordingly. If this means the backlog gets amended, so be it. If it means the work produced so far is worthless so be it.

But people still get stuck with notions similar to: "we made this decision months ago, we're not going to back out of it now"; "a deal's a deal". Which is kind of restrictive in its own right.

I've seen organizations introduce iterative working processes, with each phase of iterations bookended by toll booths, gates, decision points, go/no-go meetings etc. I'm alright with organizations calling these processes iterative. You do introduce specific moments where a project gets evaluated and if necessary redirected or even stopped. Indeed it roots out the situation where you work for a year and then end up with a piece of garbage, because no one evaluated it along the way. Indeed it allows projects that have no chance of succeeding to be killed off before a significant investment has been made.

There's big pressure to keep passing each toll gate, turning each iteration and each phase into a race to the finish line. Usually because budgets are released by passing one - and missing one means no money. It means that after passing one gate, a number of possible issues are no longer viable to break anymore. The money/investment is sunk. The instrument we're trying to utilize (the iteration), becomes a goal in itself.

I've seen some organizations having the gall to call this process Agile. Which is like saying your local beer league soccer team is playing like FC Barcelona. You're not, you don't have the players, you don't put in the training hours, and you certainly don't win the prizes.

2. Making decisions for you

In traditional settings the boss decides what to do, who does it, when and how. His commands move to his subordinates, who proceed to do the same to their subordinates.

In an Agile setting the decision making process is more distributed. Boss still decides the big picture, but the who, when and how becomes a more organic, more self-organizing process, or so it is hoped.

In practice, decisions do not magically move to the level where they make the most sense for the project as a whole to make. People have agendas, egos, capacities, ambitions, emotions and skills. People have roles and relationships. People have a view of themselves and only themselves, and have a tendency to believe they are more important in the grand scheme of things than they really are. All these factors affect when and how decisions are made, and by whom. Few of the factors completely match with the project as a whole, thus creating conflicts.

A boss' natural tendency is to mediate and rule (usually just rule), if he doesn't trust or empower the project members to resolve conflicts between themselves. Sometimes it becomes even necessary for a boss to do so. In doing so the decision making process becomes at the very least sub-optimal. People who have the responsibility to make certain decisions, can't or won't. The boss ends up spending his time making the decisions for them, forgoing his other responsibilities.
You shouldn't want a general to worry about a soldier's broken shoe laces. On the other hand a soldier should not be handing out orders to move an entire army to a new theater of war, despite what Hollywood shows us.

Should the boss just let things falter? No, but he should create the atmosphere where conflicts are worked out and project members keep in mind the overall project objectives. Conflicts are fact of life, but encouraging people to take the opportunity to deal with them for the good of the project, introducing the means to tackle and even anticipate conflicts, is where Agile shows its strengths.

3. Work break down

When planning iterations, people tend to just list a bunch of requirements, estimate the work needed, and then divide the total by the number of iterations. Then they apply metrics to see if they are behind or ahead of schedule. That's a train wreck waiting to happen.

In general people are terrible at estimating. Some people may be lucky in guessing. Others might pick up on trends, tells, fakes and take informed risks. These people work the race track, the stock market or the poker table. These people do not in general work in a cubicle office, not unless they can help it. And they are more often wrong than right.

In general people are also terrible at communicating and defining exactly what they want; and even worse in understanding what others want. If people were able to, divorce rates would be far lower than they are now. You might be good with words. Great, you are in the minority of the world's population, let alone in the project. You might listen better to people who are charismatic, proficient in presenting themselves and their message. Unfortunately not everyone is Richard Branson.

Combine those deficiencies, and you end up with objectives that people can hardly describe in an accurate way, can hardly estimate with any authority, and which are chopped up in arbitrary chunks that may or may not end up being useful or of business value.

I am a firm believer in iterative working. Collectives of people (groups of project members) do not have the capacity to completely come up with a solution from start to finish with any degree of accuracy. Iterations help people manage big solutions, by breaking these down into smaller chunks that collectives can manage.

The chunks should however be so defined that the collective can complete each individually in one iteration, and each should hold business value in itself (i.e. working code). So don't define your task for one iteration as a plastic water cup without a bottom. Rather admit that making a complete plastic cup doesn't fit in one iteration, and make arrangements to adjust the objective or change the capacity.

An Agile construct like complexity points are there for a reason, they force the product owner to think about the goals in terms of business value, rather than hours and dollar amounts which are arbitrary numbers that are attributed too much meaning. There's also a reason complexity points are estimated by the people who are going to do the job, and not the boss.

4. Money rules

Plenty of clients who use money as an excuse to defer responsibilities. Plenty of contractors that let them.

The ancient creed that the Spiderman franchise is based on, applies here though: with great power (money) comes great responsibility.

Now I know that successful clients have got many different things going on simultaneously, and they have to stretch, plan, prioritize their time accordingly. They have to plan where they are accordingly. None of these can be used as an excuse to not be involved with the people they've hired in the job they've hired them for.

The client has empowered them, good on 'em. But if they legitimately come back with a decision they cannot make, or a clarification they cannot make themselves, the client needs to be there.

A client needs to be involved in an Agile project, and should want to need to be involved. He should setup all the means to do so, from daily stand ups, to documentation, to delegating a representative etc.

In the spirit of things

Most organizations still have a ways to go before actually working in a truly Agile way, if they need to at all really. I respect these organizations that realize this, and find ways to make it work in the meantime.

But if you do just a stand-up meeting, or just iterations or just a burndown chart, and say you are the Agile methods guru, I think you've cut some corners.