Software Development
Today, everyone wants to be agile, but I want more than agility. We all agree on such principles as iterative development, continuous integration and testing and the like. And we all agree with the four preferences in the Agile Alliance's Agile Manifesto (Software Development, Aug. 2001): Individuals and interactions over process, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. However, we should also want more.
Agile methods primarily rely on tacit (that is, implicit) knowledge achieved ad hoc and undocumented, while the Unified Process (UP) relies on explicit, structured knowledge. This is the real difference that has not come through in the agile versus heavyweight debate.
When we define a process or method as agile, many take that to mean that it is light. Thus, when working on an agile project, you must use tacit knowledge. This may be possible in many cases, but larger organizations are weighed down with people with different tacit knowledge, creating difficulties in working together. Thus, despite agility's benefits, a light process may make a project heavy.
Moreover, we can't teach people much with a tacit knowledge-based method because we have little common knowledge to teach. We can't grow our knowledge base because there's no base to grow, and we can't build tools based on our knowledge because we don't know what knowledge to support.
To work consistently and create good software, people need guidelines in the form of explicit knowledge. But we also know that too much explicit knowledge can weigh down projects because developers must select what to learn, learn it, apply it and update it with new, explicit knowledge as they learn more. Methods (such as the Unified Process; see The Unified Software Development Process by Jacobson, Booch, Rumbaugh, Addison-Wesley, 1999) based on explicit knowledge and delivered in book form have been overwhelming. It's great that IBM Rational has just announced that it will give away as open source 15 percent of RUP as an agile version of UP. Thus, by trimming the UP for agile use, we can bolster it to become an agile process with explicit, structured knowledge. The fact is, it's easy to make an explicit (knowledge-based) process tacit, but it's hard to make a tacit (knowledge-based) process explicit. There are today several variants of an Agile Unified Process.
However, we can go further. If we could, in some magical framework, reduce the work to select, learn, apply and update the UP knowledge, the situation could be different. If we can deliver the knowledge you need, and only that knowledge, exactly when you need it, the size of the process doesn't matter. Whether the process book is 100 pages, 1,000 pages or 100,000 pages will be irrelevant. You will get only what you need, when you need it. And the bigger the book, the more real online mentoring you will receive.
One way to make a process smarter is to codify the explicitly captured knowledge in the form of intelligent agents. In this scenario, every developer has a kind of virtual mentor that can select what he needs to know, teach exactly that, help apply the techniques, and learn from his experience. Recent Penn State studies (http://live.psu.edu/story/12894) on software agents helping humans to react more accurately and quickly revealed that agent-supported human teams performed far better than human-only teams. XP talks about pair programming. With these virtual mentors (or robots), we also talk about virtual pair programmers, pair analysts, pair designers, pair testers, pair project managers and so forth.
I've formulated four principles to define what I call a smarter, knowledge-based agile process that captures tacit knowledge and puts it in a UP framework:
- Explicit knowledge over tacit knowledge. Knowledge should be made explicit and easily accessible and learned.
- Active process over passive process. The process works together with the practitioner actively as peers.
- Team capability over dependency on individuals. Knowledge and workload should be shared by the team.
- Self-organizing teams over extreme (rigid or lax) organization structure. The process should be flexible without losing control.
I can't see how processes that rely primarily on tacit knowledge can compete with a smarter, knowledge-based process. Together, I hope we can make the software world more than just agile: we can make it smart.
Ivar Jacobson is a creator of components and component architecture, use cases, the Unified Modeling Language and the Rational Unified Process. A founder of Jaczone, he is the chairman of Ivar Jacobson International, which has consultant companies in the U.S., U.K., Korea, China and Singapore.
