Posted by Yannick Martel on October 20, 2009
After reading Tools for Conviviality from Ivan Illich, it seems to me that the large IT organizations I know are some of the best examples of industrialization gone wild.
Ivan Illitch introduces a maturity model for the industrialization of a product or process. Before the first threshold, the costs of industrializing exceeds the benefits. It is like transportation with the very first steam machines: noisy, filthy, not much good for anything. Then maturity arrived, and usefulness exceeded the costs – when steam power was mature enough to be applicable to helping in the real life. In this way, many products and services were industrialized successfully and transformed the world: medecine, transportation, education, food…
But then the cost of industrialization in terms of energy, human life, environment, excessive complexity, indirect costs can become too high and exceed the benefits, at least considering the overall society – some people or groups can still benefit by concentrating wealth and power. Ivan Illitch defends the case that many services in in developed countries have exceeded this second threshold, the threshold of decreasing marginal usefullness.
In large IT organizations, industrialization has been used as a set of methods for tackling complexity and volume. Up to a certain point, we have seen some success. New, more complex, more ambitious software applications are being developed, improved, and are to a certain extent serving the business. But as a method for improving the efficiency of the business, the industrialization of large IT systems seems to me to have exceeded the second threshold. Every new aspect which is submitted to industrialization and centralization, turned over to experts, adds a cost which is out of proportion with the benefits the company gets from the move. This added cost takes many forms: human life essence, efficiency, resources, indirect cost on users or customers…
What should we do? Turn to industrialization with the same tool which has helped in the beginning: rationality. We have used rationality to industrialize, but are not applying rationality anymore if we consider the tools of industrialization as mandatory, as an ends in themselves. We should realize that it is not rational anymore to go on applying these tools without any discrimination, that we should better add some new tools, the tools of conviviality to be able to develop a post-industrial IT.
Posted in Books, IT, Management | Tagged: Conviviality, Information Technology, IT, Management, Methodologies | Leave a Comment »
Posted by Yannick Martel on September 24, 2009
I know I should be doing some sport. I like running and live close to the forest. I know it would be better for my body and my health and I do not have any reason not go running every Saturday morning. Or do I? I just cannot discipline myself to go. Comes my son, Simon. He wants to perform better at the running competition organized by the schools of the sector. He then suggests that we should go together to run a bit every Saturday morning, that it would be better for my health. And I say “Yes!”, with good chances to stick to it. I have even stopped using the elevator for getting up the six floors to my flat.
Alone, I lack the discipline. The two of us are stronger. Interestingly, Scott Peck does not develop much this topic, but only mentions group therapy exercises without developing much. My point is that the two of us are a team: a group of persons oriented towards the same goal and willing to cooperate towards it. Simon wants to perform at the competition and his dad to be healthy, I want the same, we have found a way to work together to the two objectives. And I think we will stick to it more easily because we will support one another. This can be the same with a husband and wife couple, and this is the same with a team at work, a true team.
Indeed a group of people can be much worse or much better than a single individual. When not performing, it can be lazy, prone to self-indulgence and sustain poor results – bad attitude can be reinforced. On the opposite, a well-oriented team can offer very strong support to its members – each one is helped by the others and by the conscience of the team.
This is the reason why I have a lot of hopes in the power of team to help in making deep changes in firms, such as infusing a new culture of customer orientation or continuous improvement. Peter Scholtes in The Leader’s Handbook mentions that change is a social activity – we can make better changes in groups if we treat it first as social change, as change in relationships. And we can make better changes if we get help from true teams!
Posted in Books, Management, Motivation | Tagged: Books, Management, Responsibility | Leave a Comment »
Posted by Yannick Martel on September 10, 2009
I have recently read the french translation of The road less traveled from Scott Peck. I particularly appreciated his arguments on discipline as the base for any progress, including spiritual growth. I would like here to share some of what I noted in the book, and then some thinking on teams which it lead me to. As it will be a bit longish, I am going to split the post in two or three. So bear with me, we are for today talking about discipline.
Scott Peck presents discipline as necessary for any progress or growth. Discipline is necessary for succeeding in any difficult learning situation, any spiritual evolution or any improvement process. The opposite of discipline is laziness, which leads to stagnation, and allows entropy to take over – and thus regression and return to mediocrity. Discipline here is meant as self-discipline, I believe, the one which is coming from inside, not enforced from the outside.
I see everywhere real life proof of the pertinence of this model. Let us imagine that I have just received an e-mail which makes me angry. I know, intellectually, that I should not answer it immediately, but wait a bit to cool down before doing so, or not answering at all. I can succeed first because I know it, second because I have the discipline to wait for a moment that I know is right – thus deferring my reaction. On the longer term, I can learn about situations in which I can answer immediately and other situations in which I would better defer my reactions – thus being a bit wiser and less subject to my emotions.
Or another example: it is clear to me that producing working software applications is a difficult activity, requiring creativity and inner strength to put it to work, day after day. We find people who are strong enough to put their hearts in working for the progress of the group or company they are in, putting things in perspective and making sure everyday that they do whatever they find the best for this progress. We find other people who are just doing whatever is fun and pleasant at the moment, doing barely enough to avoid trouble, ignoring what they indeed know they should be doing. They just don’t have the discipline to inquire really on what is best to be done today and stick to it. They wait for external guidance and act minimally on it.
A last, more complex example, from some typical mission of OCTO Technology: we can explain to a software developer good practices and convince him. But the practices will actually stick and bring progress only with discipline. One such good practice consists in first creating a new automated test each time a bug is found in an application, and then only to try correcting the defect. Then you make sure that the next time somebody makes a change to the application which provoke to the same bug it will be detected very soon, during unit testing and not in production. We produce arguments, explain rationally how defects found early and much less costly than found later, how it is a good practice to stop and set this test first because you will not do it later. Still a lot of people will not have the discipline to stick to the practice and will just correct again and again the same defects – or transfer them to unfortunate colleagues…
Posted in Books, Management, Motivation | Tagged: Management, Responsibility | 2 Comments »
Posted by Yannick Martel on August 17, 2009
Is this yet another blog post about the failure of agile? No, not really. More about the failure of Agile adoption, that is failing to notably improving the development process and its effectiveness in delivering features.
A major roadblock with Agile adoption is that Agile is more than a new project management methodology. It is a new approach to product development and application management, based on a number of principles and values, many of which related to management, not just project management. Thus an effective adoption requires new management methods, and its adoption can be gravely impaired by attitudes from decision-makers outside of the project if too far from Agile values.
This means that for an effective adoption (you want results, don’t you?) managers need to also change their attitudes and expectations. They need to change how they interact with their teams and what they expect from them, both explicitely and implicitely.
What if they don’t? Agile will just pass as another fad, but might be an occasion for your competition to benefit from huge productivity improvements and gain an edge. And as Edwards Deming mentionned: “It is not necessary to change. Survival is not mandatory.”
Posted in Agile, IT, Management | Tagged: Agile, IT, Management, Methodologies | Leave a Comment »
Posted by Yannick Martel on February 11, 2009
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: Agile, Management, Rowing, Shouting, Steering | Leave a Comment »