César touched on hiring and promoting a while back. This came in conjunction with a number of other things that I have heard or lived in the recent past. It is all about the “right” person.

What is the “right” person ? Is she the person that satisfies all your criteria ? Will your criteria become obsolete as the environment evolves ? Or even worse you will discover that you had the wrong criteria ? What if the job you envisioned for the person has changed before they could actually start ? And if the “right” person does not want to work with you, will you settle for a “wrong” one ?

Hiring is all about compromise. The firm needs to make a compromise between diversity of opinions and common values. It needs both to be innovative. Compromise because a job always needs a mix of qualities a fine balance between expertise, character and ethics. There is also an important compromise between immediate results and long term contributions by the new hire. For instance, do you prefer to hire a cheap graduate that you will have to train but you will also get to grow or a seasoned veteran that has done the same thing ten times and will do it again for you ?

Earlier in my career I tended to interview people as a reflection of myself rather than as separate contributors. It turns out no one like me wanted to work with me. As I have aged I now realise that a job definition will always be stereotypical. The person hired to fill it will largely influence its actual shape. And the social group (team, department, company) is the result of the co-evolution of all the persons that compose it. Therefore the “right” person would be right in the situation as it was before you hired her. There is no telling what the situation will be after.

So as a conclusion, if you are deterministic, the person you hire is necessary the right person. For the rest of us there is no such thing as the “right: person. In other words nobody is perfect and right implies a contextual perfection that does not exist. More importantly, looking for the “right” person clouds your judgement as a recruiter. You have to be agile as a recruiter as well.

César over at non linear enterprise is spot on about feedback loops.

That is what so-called reenforcing practices are about. Pairing introduces a very fast feedback loop on code writing. Automated regression tests provide a fast feedback loop on development. Retrospectives are a quick feedback loop on the project.

All this would tend to indicate that Agile is actually a more tightly controlled process than many other development practices. Even more interesting the control is exercised at the time and on the rythm that is most appropriate to the controlled process. Finally most of this control happens without external intervention (which will insecure many managers) which removes the controller single point of failure. It also makes it possible for the process to adapt and self repair.

But beware that feedback loops can also be a factor of instability…

I finally had the revelation, the answer to that puzzling fact that, no matter how much effort and faith a company puts into its transition to Agile methods, it fails. Well it is a bit blunt. Some actually succeed. And others manage to maintain a pretence of success for years.

I have been reading Peopleware recently and found the answer there. I am sure it exists in other places as well. It is not as if it was a hidden treasure of wisdom or a lost manuscript by aristotle. It is the well known fact that change is difficult. So difficult actually that the authors of Peopleware advise to effect only one change at a time ! And here is my realisation. To transition to Agile takes more than a single change. You have to change how people work together collectively, how they work individually, how information flows inside and out of the team and even what type of communication is needed. Any of these changes is challenging by itself. These categories may even hide multiple changes (switching to Test Driven Development and Pair Programming for instance).

Interestingly, this realisation ties perfectly with an open space discussion that happened at the BayAPLN a while back where we discussed the strategies to effect a successful transition to Agile. We came to the conclusion that it was easier (necessary ?) to foster change agents (positive deviants). Another successful approach was to sandbox agile practices. Agile sand boxing is essentially an attempt to transition small isolated (geographically or functionally) groups that are willing to become agile. For obvious reasons, groups that are not sand boxed are likely to be crushed by the rest of the company. The sand boxed group is freer to experiment with practices and to be allowed to progressively install new standards. The rate of possible change is also arguably improved.

So now I think I have linked the reason for failure and the path to success. Or am I missing something ?

I recently got to feel the weight of social conditioning in the enterprise. I was asked to temporary (three weeks to be precise) fill in in a somewhat managerial position. I started with the idea that I have great confidence in my team mates and that therefore I would not need to do much in this interim period aside from fielding a few e-mails and showing up in a few meetings (I was even spared the administrative burden !).

I soon discovered however that I was trapped in the conventional thinking that is continuously hammered into us that people will not do what they should and that, as a result, if you are delegating the work, you should also verify it very thoroughly. Even knowing it is not good (see Peopleware for convincing arguments) I still felt compelled to do it. Worse, I had to refrain myself from over doing it and try to be more supportive than prescriptive !

The awful thing is that it is an attitude I don’t like as a subordinate, it is something that does not happen when the relationship is truly a peer to peer one. I came to realise the reason I was trapped in this attitude is that I felt singled out as the individual responsible for the outcome. It did not feel like a team responsibility but my responsibility.

That is what I would call the management trap. The illusion that things are at stake for you personally rather than the group. It is the social trap that we use everyday to ensure a control structure rather than a collaborative one.

I have been pondering this post for a while now and thought that a visit to the Land of the Rising Sun was an appropriate incentive for me to write.The team I am part of has attempted to work in an Agile manner for the better part of two years with a few ups and mostly downs on that ground. This is however one of the big successes we had in terms of work organization.From the inception the team had QA members for which a test environment needed to be maintained. By itself, deploying a QA environment every couple of days is a sizable task. Even though that task was, over the months, considerably trimmed down, it is disruptive for a developer. More so when QA needs to chase a developer to do the work.As a further disruption, our environment is connected to a number (5 or 6) other systems that occasionally and regularly failed. We therefore needed someone to investigate and resolve (or get someone else to do so) those issues.Finally we had an automated integration test suite running on a fixed schedule. That suite was two long to execute after each check-in as our regular regression test suite does. And the schedule was long enough that the blame was typically difficult to place at first glance. When it was not a false alert due to some other system failing.All those activities quickly prove rather expensive in terms of developers time because, being good citizens, two or three persons would jump on the problem to attempt a quick resolution. Or on the contrary, everyone felt too busy to bother, assuming someone would pick up the flag, wasting precious QA hours. So the obvious solution, as you may have guessed was to designate someone to perform those ungrateful tasks. Two weeks would the term. That person would be called the Ronin.It quickly became apparent that the Ronin plays a release engineering role and so it was assigned the responsibility to maintain and enhance the build system. It also became apparent that in many cases the Ronin was not fully occupied and had room for short, lonely tasks. And he became the teams’ designated bug killer during his term.Maybe Yojimbo would have been a better word.

Miki, over at Leadership Turn, tagged me and asked what I will do with my tax refund. This obviously has nothing to do with my usual topics. Although, strangely enough the next meeting of the Bay APLN has been titled “Taxing Agile”.

Let me start with two notes. First this refund only applies to US tax payers. In most other countries, don’t expect to get any money back. Second, whatever you with your refund, given the poor shape of the US economy, it will be good for the country and quite possibly for the world. Paying down debts and saving are good as it frees some cash for banks to stay in business. Spend and it will help businesses stay afloat.

To link this back to agile subjects, let’s remember that, in a well designed tax scheme, only those who can contribute are taxed. Moreover they are only taxed according to the level they can contribute to but only at a level that encourages them to be able to contribute more. In such a well established tax system contributions grow as well as the well being of contributors. Now I think about it, it really is similar to how companies work. Typical teams try to over tax their members until they have nothing more to give. Agile teams tax their members less to encourage a continuously growing return.

I kind of wonder what a refund means in that case ? Is you were too taxed ? Or that you did not produce as much as anticipated ? I will let my valued readers answer this.

Meanwhile I will answer the original question. As far as I am concerned, it will go into the savings category, most probably under the college fund header.

Alas, as I do not know any american blogger well enough to tag them, I am unable to fulfil the Meme. Oh well… I need to network more !

A while back, right at the time QCon was happening in San Francisco, Linda Rising came to the Bay Area Agile Leadership monthly meeting to give us a talk on pairing and, as it happens, about Bonobos.

As it happens the talk is very entertaining and informative (don’t miss it if you get a chance) about Chimps, Bonobos (one of the lesser known species of hominidae) and as it should about our social behaviours. Linda’s point about was that Chimpanzees are command and control, territorial and aggressive while Bonobos are not and maintain cohesion through the same means as European aristocracies did. And she asserted that agilists are the bonobos of software development. Which is kind of worrying because the Bonobos are an endangered species.

The analogy definitely has merits. And limits. I believe I am an agilist. Maybe I am wrong and only a command and control person who ignores it. Still I am territorial, aggressive and all these bad things that male humans typically are. One of the pieces of analogy was that pairing played a similar role in agile development teams as sexual intercourse do with bonobos, which is maintain social cohesion. It certainly true it has this effect. But, being rather individualistic, I am not pairing for the sake of the group. I am pairing because it makes me better at chat I do first. I do it to test ideas with other intelligent beings (because the computer cannot evaluate it yet) and sometimes, when I am lucky, to plunder someone else’s ideas and integrate them in my own conceptions and theories. That is why I pair. Even better, I find paring is a good way to let a hierarchy of developers emerge. Essentially through a series of duels.

That is where I touched the limits of that very useful analogy. It was truly enlightening to start thinking about how agile development practices may better feel our human needs for social interactions than waterfall style methodologies. It also reminded me of how software developers (as well as humans in general) have a tribal reflex. Agile methodologies in that sense let the tribe emerge while the command and control approach requires management to assemble a tribe. The latter being obviously much more difficult.

I still prefer the Greek/Roman/Barbarian analogy. Still the Bonobos/Chimpanzees one is now a full part of my mental toolbox although I find it preferable to use cross-pollination rather than copulation to define what pairing is.

A few months back, the team I work in was trying to introduce agile methodologies, such as test driven development and pairing. We were all very experienced professionals but none had practiced agile methodologies in a structured manner.

It so happens that some of us were fully convinced of their benefits (and informal practitioners). Others were skeptics. And one was firmly opposed to these practices because he had been very successful doing exactly the opposite and he felt hindered. It is only after he left the team that I realized how valuable this particular member was. Not only because of his expertise but for another very strange reason.

By constantly complaining and criticizing our practices he helped us refine them and remind everyone in the team what they were. The later proved invaluable as we were constantly falling back to our old habits and slowly decaying our advertised practices. His criticism was providing every member of the team with a strong sense of what we wanted our identity to be. The team’s social pressure was very useful to keep everyone in line. More so than any manifesto or charter. I believe this is akin to the kind of effect pairing has on code quality.

When he left, we started abandoning our best practices even faster. Positive reminders did not achieve the same effect. Granted, other changes came in the way of pairing in particular. It also happens that he actually started to see valuable things in our practices which made him a less steadfast contradictor.

So there you have it, maybe it takes a barbarian for greeks to be greeks. But beware that barbarians may in turn become greeks.

The financial world is abuzz with what happened at Société Générale. Many among the professionals are surprised by the size of the loss but not at all by its possibility. Why ?

In the past 10 years the systems security has greatly improved: requirements on password composition, frequent renewal of passwords have done a great deal for that. A bit deeper a lot of things are logged, traced, recorded: phone conversations, e-mails, application use. Even deeper, applications support things like two person checks, roles, permissions to ensure that users are allowed to do only what they are supposed to and get appropriate approvals for this. I would not dare to contend that these protections and safeguards are completely foolproof but for most of the applications I know, hacking them is beyond the reach of a master in finance.

So what gives ? I will give a few examples.

If in a back-office the official procedure is to use cross checks to avoid errors (pairing in agile terms), what really happens most of the time is that operators will exchange their passwords to enable them to do the cross check alone. Why would someone do that ? Because otherwise everybody would have to be here all the time, for very long days, taking no vacations, not being sick.

In a front-office, as noted by some commenters, passwords are on yellow sticky notes inside drawers or underneath keyboards. Why would someone do that when they signed a paper saying they should not ? Because in many applications, other traders cannot act on each other’s trades. Or the procedure to be able to do so is too complex. Or one of them started a trade and it finalizes while he is out getting a cup of coffee. His colleagues naturally cover for him and breach those security checks to accommodate team work.

I will not pile on with users that have permissions they should not, permissions that are not timely maintained when a user changes role, the heavy use of excel for critical things, failures in systems and missing checks.

To simplify, back-offices are the production line and front-offices the sales/engineering force. I have not yet spoken of the risk control part because I have little experience in this area. Believe it or not, risk control has considerably matured and is now very important in many firms. It always hold veto power over the front-office. Unfortunately, without the back-office risk control is half blind (as the SocGen example shows). The sub prime crisis on the other shows that risk models have a hard time keeping-up with financial innovation.

So what is the point in this ?

A lot of ink was devoted to the idea that information systems were tricked to produce unreasonable exposure. The reality is that it is the actual (as opposed to written) processes of the bank that were taken advantage of. The point is that when people cannot work under the rules and procedures they bend them or they give up. Either way problems of this nature will happen. Empowering workers to make appropriate changes to the way they work increases productivity and quality (such as better operations reports in this case). This is the realization at the core of Kaisen in the Toyota production system, this is also the core of Agile methodologies.

This is supposed to be a very flammable article so please light the fire. I attended two talks by Linda Rising one at a Bay Area Agile Leadership meeting, the other at QCon. That added to some other readings fueled the thoughts in that post.

I believe that all humans are naturally driven to perfection. It is the way the human brain works, using pattern and simplifications to accelerate reasoning. When people imagine something it is always perfect. At least initially. Or ideal. It is really unfortunate that many of us realized very early that real things are not perfect. Some may argue that this is the source of the religious fact but I am neither a theologian nor a philosopher.

Working with people, knowing that they are not driving for perfection proves beyond any doubt that they are not motivated and committed. I am not saying it is wrong, I think at some point everybody will stop believing and will try to find something different in which to project their drive.

Now, in many agile talks you hear people saying that one of the founding principles of agility is to abandon the idea that you can make a perfect product in favor of a reasonably good target. This however is only a half truth. It is true that you need to realize that the finished product will be the results of trades off, compromises and misunderstanding because that influences how you are doing things. On the other hand, Kaizen, continuous improvement of the process and the product are all signs of the drive for perfection. The proof ? No one gives the termination condition of these iterations. The termination will always be arbitrary. In other words, it is almost impossible to give a definition of good enough until you see it.

I would further contend that for each item of work, a motivated individual will always do as good as he can. Never good enough.

What are the implications of this for agility ? One is that I think it explains why there is not strong competition among agile team members. To compete you want to do things better than the other team members. If you are trying to do things perfectly you will ask all the help you can. Is this what keeps agile teams motivated or is it a result of the motivation ? I think it is a self-sustaining feedback loop (or something like that). Command and control typically does not achieve that because it is much harder to keep people motivated in that kind of environment which means that sooner rather than later workers will shift their perfectionist mind to other subjects.

I will finish this article with a saying ‘Better is the enemy of good’ which essentially means that you never achieve good if you are aiming for better. I would add that to achieve good you have to aim for perfect.