Freedom For Ideas

Sharing ideas, concepts and thoughts, mainly about Information Technology – and consulting

Rowing, steering or shouting?

Posted by Yannick Martel on February 11, 2009

On the shore, ready and willing to go!

On the shore, ready and willing to go!

Recently we had a discussion with an interesting man at a major company. This man wanted a team set up to develop tools for new services. He wanted to go with Agile, and we suggested some critical resources for a team (coach, teach lead…) alongside with some developers. This man was worried he would get too many steersmen, and not enough rowers. We finally convinced him that our people would also provide muscle for his ideas, and we then set up his team.

Then, later, I gave some thought to his worries: yes, you need muscle, rowers, for his dreams to come true, and for sure you need a steersman with strong hands. On the other hand, we frequently see many people around IT projects, which he might have called steersmen, but indeed the boats are not controlled so well, and these persons are not steering. So what are they doing? They are only sitting on the shore, shouting advices…

It is much more comfortable on the shore: the ground is stable, it’s less humid, you don’t risk falling into the river. But the race is won by people in the boat. Of course it’s some help to be supported from the shore. But if your best people are not on the boat, rowing or steering, you’ve got a problem.

It was always the case in the navies of the age of sail: captains and admirals had to go with their teams, in their ships. The majority of victims were not from actual combat, but from just sailing on the sea: from weather, the waves, scurvy… Captains and admirals had to suffer them as well. They had to go, because the means of communication and the distance required them to be close physically to be able to command. Of course, they needed good people in the offices, at the Admiralty, but they also needed strong captains in the ships.

Now, that is the same with our projects: we need strong people rowing and steering, because whatever you do the distance is too large with the people who are just shouting from the shore – not physically, but mentally.


Posted in Agile, Management | Tagged: , , , , | Leave a Comment »

The Wave

Posted by Yannick Martel on February 3, 2009


After going straight in a direction with my previous post, I came across The Wave. I was fascinated by the experience it described, got a copy from the local library and finished reading it in parallel with a busy weekend. The Wave is a novel based on an experiment performed by an history teacher, when he wanted to teach about the rise of the Nazi movement in Germany and the atrocities which came from the movement.

At first, the teacher used his authority and charisma to channel students into the experiment, discipline them into a more efficient group. Then discipline, peer pressure and the positive feeling of being part of a group took over as driving forces, making the group still stronger and more disciplined, more together. The teacher himself was then no more leading the movement – he was being lead and driven by it. Independent thinking was then felt as a threat to the movement – and thus to be condemned. Any objection was to be rejected.

I take many lessons from this story (as far as the book is true to the original experiment). One of them is that fascist monstrosities can be awakened any time, any place if we forget about the past. Another one is the power of the group as providing:

  • a sense of community, of being well together;
  • efficiency for some activities;
  • a relatively egalitarian environment, or at least leveling the traditional hierarchies of performance or popularity.

These are relatively positive characteristics, which makes group-imposed tyrannies the more dangerous. A group can be a wonderful environment, but it can also turn to be de-humanizing: a human being lost in a certain group with certain values can become a machine, losing critical mind and independence.

I appreciate that in all human systems, discipline and authority must be balanced by some regulation mechanism, especially when they are self-imposed by the group where they can be stronger and more cruel than when imposed from the outside. In the case of the experiment, the regulatory mechanism was the outside world, parents, other teachers, the principal, the history teacher’s wife, and himself. This mechanism played its role before it was too late.

How is that relevant to this blog? One reason amongst many: I have still more reasons to appreciate the value of thinking outside of the boundaries of the system, any system, thinking on it, thinking about it, understanding its mechanisms and meaning, while not being bounded by it. An illustration of the pattern is the retrospective practice used in Agile methodologies to look back, improve and make the team a better team. Here – hopefully – members of the group can reflect on it, criticize it and work together on improving it. Thus we avoid declaring as absolute what is only relative.

But, in itself, this experiment does not provide a proof against my thesis that discipline and authority can be good. It certainly provides a nice boundary to this declaration.

Posted in Books, Management, Methodologies | Leave a Comment »

An anarchist with an acquired taste for discipline

Posted by Yannick Martel on February 1, 2009

Discipline, discipline?
I hate to disclose it: at the core I am an anarchist, with an acquired taste for discipline and authority… At some point, I tended to avoid authority and discipline, not seeing its necessity. Indeed, I am mostly self-disciplined, and not wishing to get discipline from the outside, I was avoiding pressing it on others.

As personal as I feel about it, it is indeed a cultural trait of our time: paternal values of authority and discipline have been out of fashion for the last 40 years. The result is families where parents don’t so easily find their place. In the corporate world, managers want responsibilities, but don’t dare to use authority or to ask for discipline in their teams. This can result in indecision, hypocrisy, manipulation, or at the reverse to tyranny.

With my children getting older, and myself trying to be a better father for them, I have felt the necessity for pressing for discipline. Self-discipline is essential, but not sufficient and not always present. In periods of change or growth, parents have to use authority to establish discipline, and create the conditions for development of self-discipline.

In the corporate world, managers have to orient, channel and create the conditions for the right level of discipline – hopefully coaching their teams to self-discipline. Discipline goes along with consistency of effort, and both are required for getting results. That’s work, a lot of work. Hopefully, managers are getting better when they practice it, if they accept the challenge at every instant to balance between anarchy and tyranny.

As for myself, I am reading the Leader’s Handbook and hope to get better at getting results with my team. We’ll see. Maybe I’ll read that this post is irrelevant as based on the “old” “train-wreck” style of management – I am ready to be surprised!

Posted in Management | 1 Comment »

Why the Church as a model?

Posted by Yannick Martel on December 9, 2008

The Church in the village

The Church in the village

From my previous post on the Church as an organizational model worth studying (here), I hope that you agree at least a bit that some of the organizational qualities of the Church are desirable as well for modern corporations. Now the question is: why is that so? Let’s look first at the qualities which the army brought to the first “modern” corporate entities.

The army as a model brings a strong command and control organization. It is designed for hierarchical control, with limited space for horizontal sharing (interestingly modern armies in the XXst century have learned some new ways to cooperate – maybe some matter for another post). This was good for a train company in a simpler time, when it was important to manage traffic with some fluidity and adequate security, in a mostly predictable and stable environment.

What about the Church? It was set up as an organization to propagate faith with limited resources, on a global space, with capacity to teach to a wide audience. The Church also needed (and still needs) to adapt the message and learning, to geographical and historical contexts (over space and time, language and culture), while keeping the cohesiveness and truthfulness.

A large part of today’s core of knowledge has been built over time via exchanges and cooperation between bishops (representing their local people), theologists (experts) and innovators. In essence, the Church has functioned as a learning and self-learning organization.

To me, a modern corporation also has a central core business to manage and develop. It must adapt to complex and different contexts, while staying coherent and cohesive. It must also learn about products, clients, technologies and its own purpose, while redefining the way it address it addresses the contradictions and tensions along its path. No wonder the organisational model of the Church can bring something to the business world of the XXIst century!

Posted in Agile, Management, Methodologies | Leave a Comment »

Something new on Mashups and SOA

Posted by Yannick Martel on December 3, 2008

Before / After Services

At least something new about SOA! Many articles and discussions on SOA only address the technical or implementation aspects of SOA. We then wonder SOA is only a technology for IT departments to worry about, or whether it really concerns IT users. I have frequently been frustrated by some of the debates about SOA: much ado about nothing… Of course technology has evolved, but, more or less, service-oriented architectures have been possible for a long time, and have not been invented with Web Services. Limiting the debate on SOA with reorganizing existing IT applications around services restricts the debate to technicians – with only incremental improvements to bring to users. So why should they pay for major changes? An incremental improvement can justify only a progressive introduction, always guided by business requirements or a quest for optimizations.

Mashups Corporations brings something new with inviting directly the corporation’s strategy into the discussion. Organized as a novel (in the tradition of The Goal), its introduces us into a “brick and mortar” corporation, which is ultimately lead to evolving its IT under pressure from some Marketing product manager attracted by the new possibilities of Internet and Web 2.0.

This corporation’s IT is at the beginning of the book organized traditionally as a cost center, an expensive black box, tolerated as necessary for the company, secured and closed. In the shadow of this official IT, a “pirate” IT (the Shadow IT) survives, developed by employees avid to put new technologies in the service of their innovative ideas. Change arrives when the Shadow IT opens up to the outside (quite inadvertently at first) and allows third parties (client, prescriptors…) to interact with it. To cope with the new flow of transactions and revenue then generated, the official IT must open up (just a bit) to the Shadow IT. Then we begin to see the real, bottom-line certified justification for services and a service architecture. From a central fortress, opened only via GUIs, with a few Shadow IT autonomous cells, we switch to a central core, which provides access to internal and external applications via well-defined interaction points – services. This is the justification for SOA, as opposed to morphing an existing stable architecture into a service-oriented one, with limited business value.

This transformation creates new problems for the IT department, as well as provides a new positioning: from a cost center, attached to the CFO, the IT department becomes an innovation facilitator, supporting fundamental and industrial processes as well as new ideas – for people who can experiment, try, fail and succeed, develop new revenue streams, whether they are part of the company or not. IT must change its culture and its mission at the service of the rest of the company. Shadow ITs becomes authorized and officially supported.

What is the recipe for attracting and retaining customers in the XXIst century? Let’s allow third parties to develop new applications which process transactions by interacting with the core applications of the company. Once these third parties, prescriptors, clients, communities, are hooked onto your systems, they are attached to you. They find a competitive value in the interaction with your IT, which your competitors does not bring them – yet. The merit of Mashups Corporations resides in this perspective of SOA related to Web 2.0, justified by new capabilities to innovate and open. The technical information brought by Mashups Corporations (in appendices) is pretty standard, bringing nothing new as compared to mainstream SOAP-SOA – no debate on resource vs RPS styles, nor alternatives to Model Driven approaches. But that’s not the core of the book, nor of the debate.

Posted in Books, IT, Management, SOA | 1 Comment »

A 2000 years old new model!

Posted by Yannick Martel on November 6, 2008


I recently came to read this fascinating article by Poppendieck.LLC, where the roots of the organisation of our modern corporate entities and teams are traced back to a train accident in 1841. The Western Railroad company conducted an investigation on the accident, and concluded it had to find a new model for its business to be able to manage safely its growth and the geographic dispersion – elements which were historically quite absent from the old workshop and small factories.

Two notable organisational models existed at the time: the army and the church. They choose the army. This founded the tradition of hierarchical organisations and the culture of delegating to individuals pieces of the job at hand. One individual is responsible for each piece, and delegates downwards to other individuals in charge of smaller and smaller pieces. When there is a problem, the fault is on the individual (or individuals) in charge of the faulty element – and we only have to blame him and ultimately change him to solve the problem.

Today this hierarchical model and the culture of (blame) delegation which goes with it show their limitations with the complex problems we face, such as cooperating to manage and evolve complex IT infrastructures. In many places we try to infuse a new culture of collective responsibility and to foster self-managed teams – along with other Agile practices.

What would modern corporations look like if they had got inspiration from the church during the post train-wreck reorganisation? This is quite difficult to say now! Interestingly though some of the practices which at OCTO we try to propagate parallel some elements of my personal experience of the Catholic Church of today.

Let’s take collective responsibility. The Agile mouvement holds that the best products are made by self-managed teams practicing collective responsibility. In the same way, the Church teaches that everybody is hurt when one fails: just as the Christ suffers from the sins of every one of us, every one of us suffers from the sins of any of us. Thus everyone of us can mention to a brother his fault. If the brother doesn’t hear me, then I have to grab a few other brothers and come again to talk to him. As in Agile, if I see a problem, then I own it – even if I don’t actually know how to solve it. Christians have been traditionnally very active socially, for instance in charity organisations which often have emerged without the need for central leadership or coordinated and structured action from “management”. The local Church as well works if not always smoothly at least reasonably well thanks to individual initiatives and much goodwill.

Talking about organisation, from an outsider’s perspective, the Church has a complex organisation, but we have indeed two levels of hierarchy: fidels and bishops. The bishops are guiding the fidels in their area – that’s it. Even the Pope is only the bishop of Roma. He has higher authority because he is the successor of Saint Peter, but that’s a very different authority from a boss at GlobalCorp Inc. He is officially referred as the “servant to the servants”, his role being to help and guide the other bishops, who are to help and guide the people of God. To me, it looks very much like the inverted pyramid of the Toyota Way: the managers’ role is to help workers who are everyday on the gemba, the floor of the factory. They are to provide longer-term guidance and help with their experience – to serve, not to request obedience. It is also similar to the role of managers in self-directed Agile development teams: helping, not interfering or directing work.

After all the Catholic Church has stood the test of time, being in existence for nearly 2000 years, going through difficulties, periods of decays, rebirths, schisms, but still existing and bringing a message to humanity. We probably could learn a few things from this collective experience.

Posted in Agile, Management, Methodologies | Tagged: , , | 3 Comments »

Training the next generation of consultants

Posted by Yannick Martel on October 27, 2008

The next generation!

The next generation!

At OCTO Technologies, we have to accomodate two necessities: finding clients and opportunities to express ourselves on one hand, having adequate and experienced people to execute the missions we are requested to perform on the other hand. Fortunately, in 2008 our main limiting factor has been hiring people we were confident we could train into OCTO consultants. Thus we have taken measures, including hiring promising juniors we could train over time – for good effect in the long run.

A coach colleague of mine has recently initiated me to the power of appreciative inquiry as a tool for shaping teams and helping them get a common goal, and for positively investigating, learning about the best things in the past and the present, and preparing for the future – or still best: preparing the future! For instance, I have used it recently in a meeting with a potential client as a guide for learning more about their past projects. It helped understanding the way they are preparing for their future and finding opportunities for them to avoid living again some problems they had.

I am coming to like very much appreciative inquiry. Of course, its first effect is to make your meeting partners feel good – not so bad! But there is more: I like very much that appreciative inquiry is focused on “discovering, dreaming, designing and delivering”. The very last step, about implementing your dreams with help from your past experiences, is important. Could we say that appreciative inquiry has “a bias for action”?

Beyond this, it is a very powerful way for a consultant to avoid becoming another solution problemer. As consultants, we have many tools to help clients – the more, the better. Still, it is often too tempting to fit your latest trick and tool into the problem your client has – finding the problem for which your trick is a solution. Appreciative inquiry helps you find out what has worked in the past for the people you are interacting with and for yourself – thus helping finding in our collective arsenal which one can be used or transformed or evolved for the future, and shaping new tools from our common experience.

More recently, I began applying appreciative inquiry at home as well, first with my wife, then with my kids – as my coach collague was doing. My younger daughter usually does not say very much about what she is doing at school. “I don’t remember”, she answers to direct questions. So I asked “what has been your most pleasant experience today?” and, hoops, she talked and we learnt many many things she did, and liked, and we got many more details than we were used to.

The day after, when I came back home, she asked me: “Daddy, what is the most pleasant thing you have done today?” I was impressed. I answered my best, and felt better. You see, I am already training the next generation of consultants, but I did not know…

Posted in Consulting | Tagged: | Leave a Comment »

The Vietnam Syndrome

Posted by Yannick Martel on October 5, 2008

This was used in Vietnam to help you get out of hell

She was used in Vietnam to help get you out of hell!

Fighter pilot Ed Rasimus mentions in Palace Cobra that during his second tour in Vietnam in 1966 the US Air Force was a much more efficient organisation than during his first tour in 1972. This was the same war, but as it persisted, methods and practices where developed and implemented to more efficiently and reliably incorporate new arrivals, maintain planes, program missions, route pilots to refueling, direct them to bombing their targets and then get them back. They were able to operate smoothly with larger groups – in one word, they were more industrial. Was it enough to win the war? Not really. Did they achieve their strategic objectives? Not clear. Ed Rasimus even suggests that their very efficiency might be a symptom that the Air Force did not achieve their objectives – they just stayed and did their job, incrementally better, learning and improving, but it did not change the outcome of the war.

Let’s say it again: their very efficiency might have been a sign that they had been doing the same job for too long without any significant result. Of course, it had nothing to do with the guys who were actually in the war. They did better over time and achieved local, tactical success. Ed Rasimus instead condemns the way most of the war was managed, with no real intention of achieving a strong and rapid victory and with very bad understanding of the realities of war by decision-makers.

On reading “Palace Cobra”, I wondered if this could not apply to other situations. If I find a process which is very complex, smooth and well-established, it might mean that it does not really address the root of the problem – else it would have already solved it.

Recently, I found myself interacting with a very large IT organization. There, many years ago, the proliferation of releases, patches and applications lead to a nightmare of side-effects, non compatibilities and nasty disruptions. They decided to set up a mechanism of synchronization, forcing all major releases of applications to go together, with a strong project management organisation for coordinating them and performing qualification in sync. They have been doing it better and better over the years, and now it looks to me like an impressive war machine, very industrial and repeatable. On the other hand, they have made their release process very rigid and increased the time to market of new features and offers.

Is that a case of the “Vietnam Syndrome”? They addressed the problem at hand, which was solving the release nightmare. They kept going on and improving this solution. They kept bombing at the same place – but was it really the right target to bomb? Have they won the war? Maybe not, as they are still doing it. Clearly they have done right in solving their short-term crisis by strongly synchronising releases. Should they have done more than industrialising the approach? I am not sure, maybe address the issue of dependency between applications. Maybe something else. Then they might have won the war, or at least fought it on a strategic scale.

Posted in IT, Methodologies | Tagged: | Leave a Comment »

Adaptable vs Adapted

Posted by Yannick Martel on September 25, 2008

Is it adapted? Would you like to adapt it?

Is it adapted? Would you like to adapt it?

As IT practitioners, we all want to produce solutions adapted to the needs of our clients. And usually we want our solutions to be fully adapted to a bit more than what we understand of the needs of our clients. We want to cover more in case we have missed something. We want to prepare for the future. This is why we make such long analysis, produce documents with complex business rules and go through long and tedious review and validation processes. This is also why we work hard at designing generic, elegant, general solutions. In the interest of the future. And that’s the right way to do, isn’t it?

No, Sir, it is not. As Auguste Detoeuf was saying in the 30’s in “Propos d’O.L. Barenton, confiseur”:

Contrairement à une opinion répandue, on fait quelquefois trop grand. Il faut faire juste, mais en ménageant tout pour agrandir le moment venu.
On se borne l’avenir en faisant trop large, aussi bien qu’en faisant trop étroit.

Or, translated in English:

Contrary to widespread belief, we sometimes build too large. We must build just right, while keeping open to enlarge when the time comes.
You can restrict the future by making too large, as well as too narrow.

In fact, when we we build “too large”, we develop mechanisms and answers for questions which have not been asked. When they arise, our solutions have to evolve because the answers we believe were right are not anymore. When other questions are asked, the complexity we have unnecessarily added is an obstacle to providing new, unanticipated answers. Thus by trying to be over-adapted, we prevent our solutions to be adaptable, which is really what our clients needs – really.

We should instead apply Gall’s law:

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

Our job in IT is to build complex systems. We should build a complex system by first building a simple system, satisfying simple needs. Then we can augment and satisfy more sophisticated requirements, while making sure that:

  • the system is still working;
  • the system is still adaptable.

These two points are difficult, and require effort every day, but only then you will be able to help your clients – and keep being able to do so.

This is the paradox: by being adaptable, we can succeed at always being adapted (although it is not guaranteed, and we can still fail). By aiming at being fully adapted today, we are guaranteed to fail at being adaptable, and thus to fail at being adapted tomorrow.

Posted in Agile, IT, Methodologies | Tagged: , , | 1 Comment »

Agile Adoption Patterns, 1, 2, 3

Posted by Yannick Martel on September 16, 2008

A sleeping volcano in Auvergne (France)

This looks like a plateau, but is in fact a volcano. Beware!

Let me confess it: I am not an expert in Agile. I have yet read only the first three chapters of Agile Adoption Patterns, from Amr Elssamadisy, and I already want to share with you how much it has inspired me. Especially in relationship with a specific project we at OCTO Technology are helping to get Agile. I will go on reading the remaining 43 chapters and may later review them here.

Agile is nowadays quite fashionable, and this very success generates its own problems. Amr mentions that the very first teams adopting Agile “methods” obtained 500% improvements in productivity, but that as Agile is becoming more pervasive and adopted by a wider audience we see more teams getting instead only 50% improvements, or failing to obtain any improvement at all. Indeed I now realize that the project I have in mind has probably reached this 50% plateau. Amr’s intention is to help us overcome this difficulty and implement an Agile adoption strategy to go much beyond.

For this, Amr’s gives me two keys. The first key is learning. Learning is the bottleneck in software development, the limiting factor in your effort to develop efficiently useful and dependable software. Learning might be about the functional domain, your user’s preferences, technologies, software development processes, whatever. Thus many of the Agile practices help people examine frequently what they have done and get an opportunity to learn and improve: short cycles, retrospectives, test-driven specifications, etc.

My “plateau” team is not today using some of the most important learning-oriented practises, such as refactoring and retrospective. The emphasis is more on velocity, not on learning. IMHO, this explains the plateau: once you have adopted some basic practices, you don’t improve anymore if you are not willing to experience frequently the slight unease of realizing you could have done better and turn it into the next incremental enhancement.

The second key is personal responsibility. The best Agile teams are self-directed, self-improving and responsible. Collective responsibility can only be based on the individual responsibiliy of team members. Many Agile practices help people in the team evolve towards more individual responsibility. Just as an individual cannot be ordered to be responsible, a team cannot be declared self-directed, but you can help it.

My “plateau” team is not today self-directed. It is composed of individuals moving in a hierarchical environment, which does not encourage personal responsibility. Agile adoption has not been positioned as a change in culture, only as “just another software development methodology”. I think we have not worked enough to empower the team, maybe because we did not fully appreciate the effects of the cultural gap.

The third chapter is about business values. What are your most important goals? What are your reasons for improving your software development process? Amr suggests some candidates, and invite to look for the right motivation for your team. If we know why, we have better chance to improve, and in the right place.

My best idea right now is to talk to the various members of the team and project sponsors, and try to understand what is the motive for getting the team Agile. Time to market? Yes, we would all like to get a release a few months sooner. Cost? Yes, of course, as everybody. But isn’t there any other reason, more specific to their situation? Then, I hope we will be able to get them motivated and empowered to overcome the plateau.

Posted in Agile, Books, IT, Methodologies | Tagged: , , , | 1 Comment »