Developer

Create an adaptive development methodology

Adaptive software development presents a number of challenges for IT managers. James Highsmith's book--Adaptive Software Development: A Collaborative Approach to Managing Complex Systems--looks at solutions.


Each day, you’re wallowing in the code or in the next cube helping your staff with their code. You’re trying to juggle several roles: programmer, project manager, mentor, and visionary. Every once in a while, afraid you’ll stumble in at least one of your roles, you turn to the published experts for help. You find some really great ideas. When you try to put them into practice, however, you discover that the theory that matches your experience as a programmer doesn’t exactly map to your corporate culture when your manager’s hat is on. What do you do?

You try to change your culture—that’s what you do. One guide to this most difficult challenge is James Highsmith’s book, Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. The book won the Jolt Award in 2000 and can serve you well in creating a method for software development that fits your culture.

We’ll focus in this article on some of the things Highsmith has to say regarding collaboration and complexity. Getting a firm grasp on these two key areas of your work life can help you build a development methodology of your own that really works.

Part 1
This is the second article in a series reviewing the challenges of implementing current software development methodologies. You can read part 1 here.

You’re no stranger to complexity as a programmer, but it really becomes difficult when you try as a manager to coordinate multiple staff whose tasks are interdependent. Traditionally, you might think a nice project management tool would help balance dependencies and resource overloading. But experience teaches that the best plans are only a snapshot of your understanding at a single point in time. They are not often a good predictor of how the project should proceed weeks after the plan has been published and new understanding is available. Highsmith has several important observations about these management issues:
  • Approach software development as an adaptive process, rather than one of optimization.
  • View your team as a living organism and not as interchangeable components in a software factory assembly line.
  • Seek to balance cooperation and competition among your team members to produce creative collaboration.
  • Recognize that team success depends on you as a leader being able to "hold anxiety" and live with the necessary tension between uncertainty and paradox that produces the creative energy needed to adapt your plan as the project unfolds.

Whoa! This sounds good, but how do you make it happen? Let’s take a closer look at each of Highsmith’s points.

Optimize or adapt: Normally, when you have a plan—especially one you really believe in because you worked so hard on it—you don’t want to give it up, and so you think, “If I just tweak it a little bit, things will work out.” This doesn’t always work out with development when requirements change or are poorly understood in the beginning of a project. Sometimes, it’s better to throw out the plan and start over. This can be one way of adapting to change; perhaps not the best way, but still valid. Just remember this: If you work your plan and obtain what you plan—rather than what you really need—is this better than starting over? Adaptive methods recognize that learning occurs at all phases of a project and, thus, any plan must be adjusted (not merely optimized) to account for new knowledge.

Factory workers or unique individuals: Of course, each member of your staff is unique. Sometimes this is good, even if you’d prefer a little less "uniqueness" in some programmers. But automatons they are not. Learn to play to the strengths of your personnel and tailor work to suit their skills and intellect. Don’t divide the number of project tasks by the available resources and let the assignments be parceled out as if one programmer is as good as another. Living organisms have dynamics and enjoy beneficial interactions between their constituent parts, and so should your team. Like a living organism, a team whose parts are functioning in the roles best suited to their abilities will produce the best results.

Cooperation and competition: Balancing cooperation and competition can be tough, but you should take advantage of the fact that human nature drives a person to want to be the best. The goal is team success. But I believe that a win is possible for the team—as well as a win for team members—if you know your people’s response to stress and challenge. Gone are the days when one cowboy programmer can build all the products for the enterprise. Cooperation can be achieved when you build a methodology that allows collaboration between high-strung programmers to benefit each team member. Make collaboration a structured part of your day with the team, not just something you turn to when designs and plans begin to fall apart.

Holding anxiety: This is the hardest principle of all to grasp as a manager and the most common reason we often seek to return to the "command-and-control" school of management. One of Highsmith’s favorite sources in his book is the new science of complexity theory. One of its leaders, Stuart Kauffman, says:

I suspect that the fate of all complex adapting systems in the biosphere—from single cells to economies—is to evolve to a natural state between order and chaos, a grand compromise between structure and surprise. (Highsmith, p. 37)

Surprise is not what you want as a software development manager, but it’s often what you get. Holding anxiety means at least the following, according to my experience as a manager of programmers:
  • You don’t know what you don’t know, and only time and diligent effort will uncover the missing pieces of your development puzzle.
  • You as the manager can’t know every single detail of a project. You have to trust others to be accountable and deliver what you expect (assuming you’re clear in imparting your expectations and frequently inspect their progress).
  • Structure is necessary to produce success, but you can’t be so married to your methodology that you aren’t willing to change when you see things aren’t going well enough to achieve your goals.

In practical terms, "holding anxiety" means keeping interim builds of software granular and frequent. This will help you focus on the scope of each interim build and adapt the development as the results of unit testing provide feedback. In psychological terms, it means you aren’t going to always feel comfortable about your progress, but you will be able to measure it more frequently. In other words, you should know soon how you’re doing and make course corrections as needed. Don’t let planning put you in a prison; rather, allow it to frame your activity so you can break out when you need to.

Highsmith's advice on using adaptive methods during development, treating team members as individuals, balancing their needs for competition and cooperation, and "holding anxiety" is only a fraction of the information in his book. I recommend Adaptive Software Development as a valuable read to help managers deal with the complexities of leading development projects.

Editor's Picks