Evidence shows that agile development done well can positively affect your ROI. But if these methods are so great, why doesn’t every team adopt them? Look to management for the answer.
Evidence shows that agile development done well can positively affect your ROI. But if these methods are so great, why doesn’t every team adopt them? Look to management for the answer.
Again and again, empirical evidence has shown that agile software development, when done well, shows a tremendous return on investment [1]. But, if agile methods have such positive effects, then why doesn’t everyone use them? Why are so many software projects around the world still failing?
The report State of Agile Development Survey 2009 by VersionOne lists “management opposed to change,” “loss of management control,” “lack of engineering discipline,” “team opposed to change,” and “quality of engineering talent” as the main concerns about adoption of agile, together with many organizations’ “needs” for planning, predictability, and documentation.
Hold on. Let’s review those concerns again. We’re talking about various managerial controls, organizational change management, and engineering talent. Forgive me if I’m wrong, but aren’t they all management responsibilities? Doesn’t this simply mean that managers around the world are the biggest obstacle to agile software development?
As a manager, this conclusion doesn’t make me happy.
As a writer, it does.
I believe that agile software development has overlooked the importance of (line) management. If managers don’t know what to do and what to expect in an agile organization, how are they supposed to feel involved in a transition to agile software development? What is the message of agile here? If it’s just “We don’t need managers,” then it’s no wonder agile transitions are obstructed all over the world.
So, to have organizations enjoy the benefits of agile transitions, they have to know the answer to an important question: What is the future of the manager in an agile world?
My first name, Jurgen, is not common in my country (The Netherlands). But, somehow, I have worked with several instances of the names Jurgen, Jurjen, and Jörgen throughout my career. This has led to a lot of confusion. When names are similar, people tend to ignore all other distinctions. If Ella Fitzgerald had been named Jurgen, I’m sure my colleagues would have asked me to sing for them.
I see the same problem with people who are called “managers.”
In 2005, a number of people who specialized in managerial work (project managers, line managers, and others) got together and fashioned The Declaration of Interdependence (DOI) (see figure 1). In its first incarnation, the declaration was primarily intended for project management. Later, people realized they could interpret its principles more broadly and applied them to “management in general.” However, the declaration is oriented primarily toward managing software projects, not managing teams of people. This is underlined by the fact that the authors of the DOI also founded the Agile Project Leadership Network.
 |
Figure 1: The Declaration of Interdependence |
Unfortunately, project management and functional (or line) management are often mixed up. Excellent books by leading experts, including Agile Management for Software Engineering by David Anderson, Managing Agile Projects by Sanjiv Augustine, and Agile Project Management by Jim Highsmith, discuss both project management and line management issues. And, a similar situation is found in many forums, blogs, and magazines. I wish it were different, because project management and line management are not the same. It’s like confusing software developers with system administrators. They might be sharing the same ideas, the same jokes, the same haircuts, and the same clothes (figuratively speaking), but they should not be treated as the same people. (I’m serious. Just try and ask any software developer to fix your computer. Or, better, don’t!)
By not clearly distinguishing line management from project management, we’re making it hard for both line managers and project managers to understand their roles in an agile organization. Fortunately, I have not been the only one to realize this. Several books came before mine, including Behind Closed Doors by Johanna Rothman and Esther Derby and Leading Lean Software Development by Mary and Tom Poppendieck, in which responsibilities of line managers in software development organizations are better outlined.
Therefore, I always strive to separate line management from project management. My personal goal is to help line managers (including development managers and team leaders) understand their role in their organizations, because, if we want to remove obstacles to agile adoption, we really need to educate line managers.
And, for those of you who thought I was DJ Jurgen ... sorry.
This article is adapted from the book Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo, published by Addison-Wesley in Mike Cohn’s Signature Series.
References
Rico, F., David et.al. The Business Value of Agile Software Methods. New York: McGraw-Hill, 2009.
