Do we need to be agile?

Every few years there is a lot of fuzz about new and revolutionary methods, techniques or tools that promise vast productivity improvements in software developments. And then this wave dies away, and everybody continues as before. Actually, anybody out there old enough to remember the term CASE as in “CASE tools”? CASE stood for Computer Aided Software Engineering, and of course one thought of a toolsuite when using this term. This was a popular term in the 1980s. The (partial) automation of software engineering was the the glorious goal. All you needed to do thereafter was to buy better computers so that the CASE tools could run faster – true to the Newtonian spirit of industry.

What happened? Well, do you see a “software assembly line” anywhere? I remember a report about the CASE tools that were sold and bought in those years. It stated that close to 50% of the tools purchased, sorry, licenced, were never ever used! They couldn’t get past deployment in the organisation, not even to mention usage in a live project.

BTW, in 1977 Barry Boehm had already published his research showing that tools were not the productivity “wunderwaffe”.

Somehow the industry survived. The software crisis deepened, and provided limitless employment and business opportunities. Software “infected” more and more services and products. Within less than twenty years cars, which initially had a bit of software in some of their parts, turned into “software on wheels.” Other industries experienced something similar. It is like software began to change from an infectious disease to a pandemic.

And look what is in stall for us: the Internet of Things.

Thanks to Cisco for this nice graphics, which visualises the explosion that is about to happen – or is it happening already? Software engineers of the world – five day week and holidays are a thing of the past. There is work to be done! Back to scheduling people for 130% of their time so that they work at least 100%. Or – what will the future bring?

Do we have to be agile? Quite definitely – YES! Wouldn’t more automation through better tools not be a better route? That would increase efficiency, wouldn’t it?

Look at all the different areas and applications in the graphics, think for a moment of the emergent power of the connectivity, and you will come to the conclusion, that it is not efficiency we need. New worlds are to be explored. Intelligence, intuition, experience and flexibility are what is needed – people – good people – teams. Agile behaviour is needed. And still the reliabillity, safety and security concerns must be met. Do you need to be agile? Well, the ecosystem in which you live and work will be. Remember Darwin?

Posted in Agility | Leave a comment

Agile Software Development … Hype or True Benefits?

Is Agile Software Development a hype or does it deliver benefits that are destined to make this approach the main paradigm of development of the future?

Google for agile and you get thousands of results, many of which contain quite a bit of information demonstrating the success of agile behavior on the basis of team-oriented approaches. Even if this were all true, that wouldn’t mean that the new paradigm would be accepted. The insights of Thomas Kuhn [Kuhn, Thomas S. 1970. The Structure of Scientific Revolutions. Univ of Chicago Pr (T) (1970), Edition: 2nd, Paperback, 210 pages.] hold for our domain, too.

That difficulty apart, is it really that simple to deploy “methods” like “Scrum” or “XP” successfully?

Let me be quite up-front about what I think:

  • there are a many Scrum methods as there are book authors
  • there is no method, and there is no process, that can help a team to perform with the grace and effectivnes of agility, if the environment, in which the team is embedded, does not want such behaviour
  • to behave in an agile manner I do not need so-called “agile methods”
  • none of the so-called “agile methods” guarantees the the desired agile behaviour, not even at team level.

Well, I still think one of the key competences to deal with the fast increase of complexity in the systems we construct is to learn how to become more agile (see my post on “agile“). So I am an”agilist”, but with a difference, maybe.

The core of the “agile aproaches” is to take the (nearly ‘ancient’) insights of Barry Boehm and others at heart, and to give human factors the importance they always should have had in knowledge intensive tasks. Software is created by the “other soft-ware“, by human individuals themselves and on the basis of their social relationships. This is why the Agile Manifesto is so important, because it lays down philosophical foundations of how to get an organisation to learn agile behaviour from the roots up. These philosophical foundations do need re-intepretation in the respective context and for the specific team and task. Those who only see “less documentation” in the manifesto have not come anywhere near to the true meaning of the manifesto. This approach here is very similar to the concepts of the Toyota Production System.

I described what I consider agile behaviour in the other blog. What is important is that the (development) team, which is the centre of attention in the lime light, can on its own not deliver the performance that is expected. The team needs to be supported by an active network of all those, who together have all the specialist knowledge and prior experience to complete the task at hand. This is also an essential success condition with “traditional” development paradigms. I have never seen a development team that had all the knowledge and experience readily inside the team to develop a complex product, whatever the development paradigm.

Therefore we need to consider two different, but synergetic and interdependent approaches:

1. Team-Orientation: team-orientation can help avoid many of the “mudas” of the top-down control orientation of forward plan based resource allocation. A significant part of the problem stems from the fact that the development team cannot in itself have all the relevant knowledge and experience of the organisation for the task at hand.
2. External Team-Empowerment: the team must be empowered to access all the relevant knowledge and experience resources it requires and operate in a supportive environment.

The so-called “agile methods” focus mainly on supporting point 1. This has to deal with empowerment to, but concerns more directly the team itself. Experience with  effective approaches for point 2 can, for instance, be found in community-based projects, such as in the open source software field. Prof. Heinecke, CEO of BMW Car-IT, spoke about this at the International SPICE Days 2010, and Mike Milinkovich, CEO of the Eclipse Foundation, spoke about building the required supportive environments at the Conference on Software-Competence for the Future in 2011. Trust, respect, and demonstrated competence facilitate the establishment of a meritocracy. This meritocracy serves as the internal reference framework and structures of the respective “communities” in the organisation.

It is this second perspective that will decide if team-based development paradigms can be deployed successfully in an organisation. How can you successfully import these effects, which have formed part of the evolutionary history of open source projects, how can you make them work effectively inside organisations? Well, Bosch has been looking at this for quite a while as part of its internal TOP programme. More about that some other time, hopefully. Thanks to my partner Bonifaz Maag I have quite recently come across an interesting study by IBM, which details such a transplantation of such constructs into a corporate setting and presents some results. [Patrick Howard, Dorit Nevo, and Pat Toole. Small Worlds: The Social Approach to Software Delivery. Executive Report. IBM Global Business Services. IBM Institute for Business Value, 2012.]

The “experiment” was at an IBM scale: three plus years and several thousand participants. The starting point was the need to achieve improvements and innovative capability “jumps” to at least keep pace with the ever increasing dynaxity (ever increasing complexity at ever decreasing intervals). So they asked themselves what the most import factor was, which decided about success or failure of development projects. The answer is not surprising based on the discussion so far:

“The unifying force in all of these projects was the professional, drawing on his or her expertise and relationship network to solve problems and identify solutions.”

Here it is again, the “soft” part of software development. IBM’s short form of the key:

“the better the social interactions, the better the results.”

The experiment started in 2008. Based on the structure of business processes IBM created the communities of experts and committers, which are so very typical for open source projects. This is what IBM calls “small worlds.” Appropriate infrastructures helped linking across organisational and geographical boundaries. Within a community the work of everybody was visible to everybody else. And IBM created a system, which facilitated establishing a trust-based meritocracy inside IBM.

“In a large-scale study of 112 of the 130 globally integrated communities, representing more than 5,000 software engineers delivering on 300-plus projects, we noted significant performance improvements in the complex activity of software engineering and delivery by these project teams. Over the past three years, the cycle time across all major programs, measured in terms of days to deliver a unit of software, was reduced by 30 percent. The quality of code, measured in terms of defects delivered to production for a unit of software, improved by 20 percent.”

This may not sound spectacular, but these are only the “marginal improvements” of existing practices. The real purpose was to tap a creative potential, which would allow higher innovation rates. Unfortunately the study des not give any measures about that – yet. I doubt the would have even referred to it, if this had not been a success. I suppose we’ll have to wait for the next report.

Back to my hypothesis that “external team empowerment” is necessary for development teams to develop their potential. IBM’s dry conclusion

“communities provide the social and knowledge resources needed for teams to perform better”

is certainly what one would have expected. More interesting are the other findings:

“Communities with higher levels of trust among members, and whose members are socially connected to one another, have higher performing teams,”


“communities that have a repository of relevant and well-documented reusable assets also have higher performing teams.”

So, here we return to Barry Boehm. Are we perplexed? [Boehm, Barry, and Richard Turner. Balancing Agility and Discipline: A Guide for the Perplexed. 2004. ed. Addison-Wesley Longman, Amsterdam, 2003.]

“Communities as a team’s virtual environment”

is the approach of IBM. IBM has shown how the experiences of Open Source, Toyota Production System, and team-based methods can be transferred successfully to commercial enterprises.

Are there any conclusions we can draw beyond this?

Posted in Agility | Tagged , , , , | Leave a comment


Did you know that the first known use of “agile” was in 1581? That is according to Merriam-Webster. At that time, and until very recently, agile was the property of a person: “marked by ready ability to move with quick easy grace” or “having a quick resourceful and adaptable character”, again according to Merriam-Webster.

Somehow the behaviour was transferred to teams and organisations, and this makes sense, as they are made up of people. Now I have to ask myself, is it still the same meaning of agile? A group of agile people does not necessarily come across as an agile team. It they all moved in different directions without some underlying, perceivable pattern, one would hardly talk of the team being agile.

Ballet is probably a good analogy. There is a script, a play – with meaning – to be acted out. There is a very strict common understanding of allowed movements and expressions, and what quality level needs to be reached. This means that the contribution of each members agile movement to the overall agility – grace – of the ballet performance is monitored. The roles of the members are assigned based on skills, and these are honed in intensive and repeated “drill” under the auspices a coach. Discipline is required, and paired with artistic improvisation where expressiveness – value to the customer, the viewer – can be enhanced.

Want to see an agile team? Go and see Romeo and Juliet. The quality of team members, the rigidity of the discipline, the supportiveness of the environment that develops them, and the sincerity of appreciation by the customers, together determine the quality of the ballet – the agility of the performance.

Does software require less of its development teams and team members?

Posted in Agility | 1 Comment

Can you imagine …

I just came across an interesting quote attributed to Marvin Minsky. A good many years ago he is supposed to have predicted someone in a distant future to say:

Can you imagine that there was a time when library books did not talk to each other?

Wow, isn’t that something for the Internet of Things department?

BTW, can anybody shed light on the  circumstances of that quote? Thanks.

Posted in Reflected | Leave a comment


There is an art of which every man should be a master: the art of reflection. If you are not a thinking man, to what purpose are you a man at all?

William Hart Coleridge

What is real, what is reflected?

A good statement. I shall abide and share what I reflected upon.

Reflection is learning. And this does not have to be purely logical and in the mind. Every artist reflects right-brained. What about intuition?

Posted in Reflected | Leave a comment

Software Competence for the Future – the second

In May of this year the second conference on “Software Competence for the Future took place in Esslingen near Stuttgart. The conference announcement is in German, a and an English summary of the highlights will be available soon.

An overriding theme was the impact of the second type of “software” – the human element – on software as a product. Questions of team orientation, skill development, motivation were discussed whilst trying to reconcile agile behaviour and rigorous discipline.

Posted in Events, Industry, Open Change Events | Tagged , , | Leave a comment

Ready, Set, Change!

This year‘s Open Forum in Stuttgart just ended and I would like to share some thoughts about it with you. First of all it was an amazing gathering of people who believe in something important: change should be embraced and enabled. As always there might be the argument “why change something?” but often the argument should rather be about “how to facilitate and govern change?” The keynotes by high profile figures from German engineering giants showed that this is now entering the corporate world. Among the best car manufacturers and their closest suppliers are using modern techniques – not just on the assembly line – but for managing teams and facilitating innovation in an open environment as well.
But questions remain: What will to do with user and usage data of all those integrated devices? How should privacy be defined in the future? And does this open up opportunity for new forms of democracy? And to get back to automotive: How do the mobility patterns of the future look like? And once again the question of how openness can facilitates and enables change. For many speakers the answer to the last one is crystal clear: open-source software is a major enabling factor. Also they stressed the importance of giving and receiving within a community. This enables their growth to new horizons that had been impossible to reach with proprietary software. Also the managing and governance patterns in the open-source world offer to be a model for commercial software vendors as well.
Apart from the software aspect: openness is a state of mind – an attitude towards people, knowledge, tools, and eventually the whole world. Understanding this and drawing parallels to the open source software movement might help to cope with an increasingly complex and dynamic world – and even enjoy the new blue oceans of possibilities. The Open Forum 2011 was a great event to meet, speak and network with others persons who embrace change in the same way.

Posted in Uncategorized | Leave a comment