Freedom For Ideas

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

Posts Tagged ‘Methodologies’

Towards post-industrial IT

Posted by Yannick Martel on October 20, 2009

Modern railways station

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: , , , , | Leave a Comment »

The failure of Agile?

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: , , , | Leave a Comment »

Working on the bottleneck – the right one

Posted by Yannick Martel on June 12, 2009

Are you attentive?

Are you paying attention?

From Lean Management and The Goal, you know where to look for when you wish to improve a complex process: you need to search for bottlenecks in the process flow, and first of all the major bottleneck. Find it and then concentrate all your actions on improving it. Then the process will get better (produce more and/or faster), but you will find have another bottleneck, another limiting factor. Just find it and work on it, and so on.

In IT, Agile has been proposed as a solution to the difficulties in the software product development  process. As Agile concentrates on software design and development, it can really help only if difficulties were indeed in design and development. That’s probably partly true as we effectively see improvements when Agile practices are really applied in development projects.

But then from Lean Management, we know we should look for the next bottleneck in the process. Where to look for it? We get an answer by looking at a typical Agile project: somewhere between three and eight weeks after the beginning, the pressure is no more on the development team but on the product owners. And thus we have found our next (and maybe really first and most important – why not?) bottleneck: the team in charge of knowing what to ask.

To me, it is particularly important to effectively address this bottleneck, first because the bottleneck is stronger: knowing what to code is at least as important as knowing how to code it – and generally coding correctly is easier that knowing what to code. Once the development team is ready and eager to produce value, all concentrated on it, it can gell pretty fast and request to be guided, request to know what to produce – pressure has moved.

But there is another, more subtle, reason: softtware development is more related to product design and development than manufacturing (more related to designing a new model of Prius than manufacturing it). It is a profoundly creative activitiy, requiring communication, trust and confidence. If a strong bottleneck is left in the process and it is not addressed, then you risk mining the efforts which have been done elsewhere and loosing everything you’ve earned. More concretely: if your product definition process is visibly the bottleneck and you don’t address it, the demoralizing effect will destroy whatever gains you’ve done by implementing Agile in your development team and you’ll quickly loose the discipline to go on with Agile practices and continuous improvements – maybe creating a secondary bottleneck again.

Posted in Agile, IT, Methodologies | Tagged: , , , , | 1 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 »

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 »