The below is an extract of an article Ivar wrote for Cutter IT Journal, Jan 2002. Any text omitted (marked with “…”) is related to other techniques popular at the time of writing, such as RUP, UML, which were there to exemplify the key message.
Agility has become today’s buzzword when describing a modern software process. Everyone is agile. An agile team is a nimble team able to appropriately respond to changes. Change is what software development is very much about. Changes in the software being built, changes to the team members, changes because of new technology, changes of all kinds that may have an impact on the product the team builds or the project that creates the product. Support for changes should be built into everything we do in software, something we embrace because it is the heart and soul of software. An agile team recognizes that software is developed by individuals working in teams and that the skills of these people and their ability to collaborate are critical to the success of the project.
…
As the title of this article suggests, I am a strong believer in an agile process. No one can afford to develop software by slavishly following a predefined process. Instead, the project should follow a process that helps the team to achieve its goal. The key is that you continually adjust the process as you go by reflecting on what you’re learning, what works, and what doesn’t. In this article, I will discuss some other properties of a good process that go beyond what is commonly thought of as “agility.”
A PROCESS SHOULD EMPOWER YOU TO FOCUS ON CREATIVITY
I believe that software development is the most creative process that we humans have ever invented. I also believe that processes or tools can never replace true creativity. However, not everything we do when developing software is creative.
In every project, a large portion of the work done by developers is not genuinely creative — it is tedious, routine work that we should try to automate. The problem is that the creative and the routine work are interspersed in micro-steps, each such step only lasting from maybe tens of seconds to tens of minutes. Since these two kinds of works are interleaved, the developers may still have the feeling of being engaged in creative work, but fundamentally they are not.
Some of you would probably argue that, in fact, you don’t do the unnecessary work. You focus on solving the business problem and ignore much of the other work that does not deliver business value. This is, of course, partly true.
However, even in projects where the focus is on code, people have different approaches to good coding standards. What most people thought was good code some years ago is considered bad code today. Thus people spend time arguing these things. With a strong, good leader, these problems may be smaller. However, most teams won’t have such a leader.
Aside from process issues, we also spend considerable time on many other small, technical issues. For instance, if you want to apply a pattern, there are many small steps you have to go through before you have instantiated the pattern. These small steps could, with proper tooling, be reduced to almost a single step.
I don’t think anyone would argue with the fact that some portion of the work developers do is non-creative. I have discussed how large the portion is with colleagues from several camps, and based on my own experience and these discussions, I believe it is as large as 80%. That number assumes a light programming environment. There is no significant difference if you develop with or without reuse of existing components. Reuse should reduce the total work, but it doesn’t significantly reduce the non-creative portion of the work. I have only seen one very old scientific study on this subject and would welcome one based on current practices and tools.
To make software development truly agile, we need to attack and reduce this 80% of the work effort. I don’t think we can eliminate it entirely, but we may be able to get from 20/80 (20% creative content and 80% non-creative) to 80/20. The way to attack it is to understand in depth, not just on the surface, what is not genuinely creative. Then, once we understand it, we can eliminate it by training, mentoring, and proper software tools. Developers will be able to communicate and collaborate creatively, supported by new or improved tools to verify that they are consistent, complete, and correct.
If developers can rely on such tools to eliminate much of their not genuinely creative work, they will be in a much better position to maximize the time they spend on developing business solutions. This use of tools will also increase the quality of the developers’ lives. They will be able to spend more time doing the creative work they enjoy and less time on the routine or repetitive work they dread. This would enable the agility we all are looking for. It would empower people to do the maximum amount of creative work.
A GOOD PROCESS ALLOWS YOU TO LEARN AS YOU GO — WITHOUT SLOWING DOWN THE PROJECT
Developing software has never been as hard as it is today. You need to have a knowledge base that is larger than ever before. You need to know about operating systems, database management systems, programming languages and environments, system software, middleware, patterns, object-oriented design, component-based development, and distributed systems. You also need to know a software process, a modeling language, and all kinds of tools. And if you succeed in learning something, you can be sure it will soon change. Change is the famous constant in software!
There is simply no way you will be able to learn all this before you start working on a project. You have to learn a little before, but most of it you will need to learn as you go.
The way we learn is very different from individual to individual. Some learn different things better than others. We learn at different speeds, and in different ways. Some people learn better by reading, and others by listening.
Who will teach us? Teachers give classes and mentors participate in projects with the role of being available to help the team while going. As we know, not everyone is a good teacher or a good mentor, and even fewer can be both. Good teachers and good mentors are very valuable but not easy to find.
Since we are all different, we should ideally be allowed to learn in our own way as we go — from teachers, from mentors, or from reading. Traditional education has consisted of attending some basic classes, possibly reading a textbook, and then learning by watching or being instructed by a more experienced person.
Just taking some classes on different subjects — for instance, in using a programming environment, in a methodology, in testing — is a poor start. Software development is much more than that. Going away to different classes that are not correlated with a bigger picture — such as a software process — is not efficient.
Learning from a more experienced person is very effective, particularly if that person is a mentor. However, it is hard to get good mentors — competent individuals with unusual personal skills. There is always the risk that a good mentor may be given other project responsibilities or that time pressure may force him or her to leave the mentor role. Moreover, someone taking on the role of mentor may veer into inventing his or her own process, which certainly will slow down the project.
Thus having a mentor on site (maybe only part-time) is a good investment, but we need to reduce the risks I just mentioned. What should we do?
In 1986, I had a dream. I wanted to create a knowledge base, not just a book, for everyone that could play a role in a modern software project: component-based, object-oriented, use case-driven … you name it. Whereas a book may be a nice introduction, it cannot possibly provide depth in all areas. I also wanted this knowledge to grow as we learned more, to change as we better understand how to develop software — to enable us to throw away what was bad and incorporate new, good experiences. Moreover, the knowledge base should be able to adapt itself to new technologies as they became available. Since then, technology has exploded — the Internet, J2EE, .NET, new middleware, and much more. Later versions of the knowledge base should accommodate such innovations.
In other words, what I had in mind was to derive knowledge equivalent to 15-20 books dealing with relevant subjects like requirements, architecture, design and implementation, user experience design, business engineering, testing, software reuse, configuration management, and project management. For ease of use, this information would be written in a common style with consistent terminology. Of course, no single individual would read all of these book equivalents right off the bat. Rather, he or she would get an overview of the whole approach in order to understand how to go from a business problem to a deployed system. The individual developer would have the base on which to grow when he or she went into a project that had already started.
…
These agents are programmed to trigger for different events. They recognize patterns and anti-patterns; they suggest resolutions. They assist the developer dynamically in using the knowledge base. They suggest the next micro-activities to be performed, many of which follow from the context of the work being done and do not require anything creative by the developer. The developer is empowered to “think” and not be bothered by all the small pieces of work that today constitute what we usually call “the hard work.”
The process will be very agile. It will be perceived as a very light process, but it is based on very rigorous tools. Obviously, you learn as you go. It can easily adapt to different roles that people play, and it can scale up as needed.
Does this “next big thing” sound like science fiction? Maybe, but I don’t think it is far ahead ….
Let me conclude by saying that … we expect much more of a process than just agility. We want it to empower you to solve your business problems and to satisfy your users. We want your systems not only to work 24/7, but to grow gracefully as the world changes. To get there, you need … tools, not the least of which will be the “next big thing”, intelligent agents.