The recent changes in the Internet economy have resulted in the movement toward new software development methodologies that focus more on creativity and collaboration and less on strict process and rules. To find out more about this innovative approach, I talked with Jim Highsmith, director of Cutter Consortium’s e-Project Management Advisory Service, author of Adaptive Software Development: A Collaborative Approach to Managing Complex Systems(Dorset House, 1999), and a leading advocate of these “light methodologies.”
In the first part of my conversation with Highsmith, we discussed the basics of the light methodology movement. In this installment, we’ll review some of the team aspects of this approach and discuss how consultants and programmers can adapt to this new way of thinking.
Cutter Consortium defines light methodologies as “thin-process, thick-skilled, action-oriented project management and software delivery.” These approaches are replacing the heavy methodologies of the past because they:
- Focus on customer value.
- Create a culture of innovation and rapid delivery.
- Appeal to talented people (focus on skill).
- Facilitate collaboration, knowledge sharing, and decision-making.
- Decrease time, cost, and defect levels significantly.
Freedman: There’s a component of these light methods that is focused on team collaboration. What’s that about?
Highsmith: We sometimes perceive computer folks as geeks who want to go off in the corner. But in reality, we geeks want to be with other geeks and have a community, and I think the light methodologies really speak to that. I would include the whole open source movement as an example of this.
[Editor’s note: Open source refers to making the source code of a program freely available to the entire software development community via the Internet. The rationale behind the “freely shared” concept is that a broader group of programmers will ultimately produce a better product, with developers from around the world distributing their results to others.]
It’s the kind of community that technical people want to build—and they’re not really willing to, for instance, do a bunch of documentation for which they see no value. I’ve been in situations recently where I had project managers and methodology people and developers in a room, and they were talking about the need for some very specific kinds of documentation. I would turn to the programmers and say, “These people have just said that you need these kinds of documentation so you can do maintenance more easily. How much of this documentation do you actually use?” The programmers’ answers were either “Never” or “Virtually never.” All the managers looked at them incredulously and asked, “You don’t ever look at the documentation?” and the programmers said, “No, we look at the code.”
Freedman: Do you see the migration to these light methodologies as a competitive issue, in the sense that a lot of consulting organizations use the robustness and detail-orientation of their methodologies as selling tools, and customers have been trained to look for that highly structured methodology when they’re selecting consultants?
Highsmith: The speedup in competition is working its way back from the dot coms to the IT organizations, and it hasn’t made it all the way back to all of the IT organizations yet. I’m working with three large systems-integration firms—one each from the U.S., India, and Japan. From two years ago to this year, their business has changed from 80 percent legacy to 80 percent e-business, and they understand that their CMM approach isn’t going to work on these types of applications.
[Editor’s note: CMM Level 4 is the widely accepted Software Capabilities Maturity Model, a framework for software engineering developed by the Software Engineering Institute at Carnegie Mellon University, which it defines as“a model for judging the maturity of the software processes of an organization and for identifying the key practices that are required to increase the maturity of these processes.”]
Freedman: Not only that, but [CMM] can actually be a handicap.
Highsmith: It can be a handicap, and [these companies] want to get out in front of the curve, so they’re saying, “For our legacy stuff, we’ll continue to use our CMM methodologies. However, we want to put in place these agile, light methodologies for stuff we take on in the future. They see that as a competitive move for the future. To migrate to light methods, they have to ask themselves, “How do we manage projects differently, how do we measure them differently (because the management and the measurement are very different), how do we deliver differently, and how do we sell this to our clients?
Freedman: The more sophisticated clients are in their understanding of CMM and structured methodologies, the more difficult it may become to sell these new approaches to them.
Highsmith: In one of these groups I talked to… the sales guy was actually the most enthusiastic. He said, “We’re running up against clients who are sophisticated enough to understand that the old ways aren’t working, and they want a new model, and we want a new model.”
[The light method] is best for higher risk projects, and therefore, you tend to need more skilled people, and in particular, more skilled project managers. You don’t want to run one of these light methodology projects with beginning project managers.
Heavy skills, light process
Freedman: This is where the concept of “heavy skills, light process” comes into play, because the experienced project manager can almost instinctively assess the project and the client, and make decisions about which pieces of the methodology are pertinent.
Highsmith: Right, and a lot of this comes from the scientific realm. Things like creativity and innovation emerge from the interaction. By putting a bunch of creative people together, these things occur at what scientists call “the edge of chaos.” You’ve got to maintain that critical edge, and if you have too much process, it weighs that down, and you lose the creativity. On the other side, if you’re too ad hoc, you’ve got everyone running around cleaning up messes and you lose the creativity that way.
Freedman: So, as the pendulum swings from overbearing structure to the edge of chaos, is there a risk that this light methodology movement could be misunderstood as swinging the pendulum too far towards chaos?
Highsmith: Actually, I think these light methods are the swing to the middle. The Rapid Application Development stuff was the swing the other way. RAD of the early ‘90s was a complete divergence from the heavy information-engineering theories of the early ‘80s; then in the ‘90s we got away from the mainframe into client server, and I think that was really the move to ad hoc. The light methods combine the essence of the software engineering disciplines with the iteration and the speed of RAD, and because of that, we’ve created a robust methodology that really scales up.
Freedman: For our readers who work within the more structured methodologies, how does this change the approach on a day-to-day level? What stays and what goes away?
Highsmith: The life cycle itself is more feature-driven and more focused on short cycles, and not so driven by tasks. If I know something has to be delivered in four weeks and I know the features that go into that, I’m not as likely to have a detailed task list. I’m more likely to [focus on] the objective. It’s more oriented to discipline on the back end and exploration on the front end. It’s much lighter in terms of documentation. Some people already use some of these, like Joint Application Development sessions, but we also specify things like customer focus groups on the back end so that we actually demonstrate what we’ve done in each development cycle.
Innovation and creativity
Freedman: In our rapidly changing business and technical environment, we’re uncovering things that are going to significantly enhance our deliverables, so that’s an advantage of these methods.
Highsmith: One of the metrics I keep track of is the disposition of all the change requests, and I report back on that. Clients are not used to software development organizations being responsive to them, so when we say, “We delivered 230 of the 280 changes you requested,” it shows responsiveness. Most customers are very happy about that.
Freedman: Will these new approaches take over the world in the next few years?
Highsmith: I think they’ll have a very significant impact, because they go beyond software development and project management. They’re about how organizations are managed. It reflects the kind of organizations that people want to work in and the kind of development teams that people want to work in. This is not a movement that’s going away unless the Internet and e-commerce go away.
Freedman: How do consultants and developers get mentally ready to make this migration?
Highsmith: Without innovation we have no e-business. These light methodologies really speak to the idea of innovation and creativity, and we have to have that. It’s too hard to do these e-business things without innovative groups and organizations. These approaches create the kinds of communities that people want to work in. To me, it really boils down to innovation and community.
Freedman is e-technology practice leader for the Kansas City office of Influence LLC, the Midwest’s leading e-business professional services firm. He has 19 years of experience as an IT consultant, both as an employee of large corporate organizations such as Citicorp and Dun & Bradstreet, and as a principal consultant for Cap Gemini America and ENTEX Consulting Services. Freedman is author of The IT Consultant: A Commensense Framework for Managing the Client Relationship—currently ranked number two on Fatbrain’s bestseller list for consulting titles—and two upcoming works: The e-Consultant and Building the IT Consulting Practice, both scheduled for publication in 2001.
As a supplement to his “Consultant Master Class” column, Rick Freedman periodically interviews a leading executive, practice manager, or consultant from the top IT professional service firms. If you have a question for Rick, e-mail us.