Today's "state-of-the-art" software development processes are based on an iterative or spiral model of development. That is not, however, the "state of the practice." Many organizations understand the value of early risk mitigation, customer driven development, and other benefits of the iterative development paradigm. But they doubt their organization's capacity and ability to adopt these best practices because of cultural and operational roadblocks.
This article presents the cultural challenges you might encounter on your journey to adopting iterative development and suggests how to address those challenges. A future article will address the operational issues (such as financial planning, resource issues, and technical operations) that hinder iterative development. In this article, we discuss the following topics:
- A brief overview of iterative development
- An overview of the cultural challenges to adopting an iterative approach
- Best Practices from organizational change experts and how those practices apply to developing iteratively
- Lessons from the field on overcoming the challenges of adopting iterative development
What is Iterative Development and why is it so important?
Iterative or Spiral development has been around for decades, but Barry Boehm's article, "Spiral Model of Software Development and Enhancement,"1 was in the vanguard of introducing this practice into modern software development. This work explained how to develop systems in small increments, prioritized according to risk, as opposed to using the more traditional sequential, single-pass, waterfall model.
Iterative development is a software development paradigm that stresses the importance of executable software as proof of progress. In the waterfall method, you produce reams of documentation that are passed from requirements analysts, to designers, to developers, to testers all in a serial fashion. By contract, in iterative development, the system is developed by actually implementing portions of the application, growing its functionality over time. Each iteration includes a mix of analysis, design, construction, and testing. The increment of the iteration, that is, the functionality that the team focuses on in the iteration, is determined by assessing the riskiest aspects of the architecture, architectural coverage, and business value. That increment is designed, coded, and tested within the timebox of the iteration. Each iteration verifies the system architecture, adherence to requirements and stakeholder needs, and the software quality.
The iterative development approach emphasizes real project progress by producing demonstrable results. It gives end users and stakeholders visibility into the real progress, not the perceived and subjective view of progress. This is possible because a working version of the system is available for inspection in each iteration. This is an important concept: By practicing iterative development, software teams stay focused on results.
What are the challenges to organizations that are adopting iterative development?
The iterative paradigm has been demonstrated as a superior method for developing software predictably. However, according to the November/December 2003 IEEE Software Magazine2 only about 30% of software development projects use an iterative approach. This statistic leads us to ask, "If iterative development is so great, why aren't more organizations using it?" The answer is fourfold: 1) Many organizations have been developing software with a waterfall for a long time; 2) we tend to believe myths about making organizational change; 3) we overestimate our capacity for change; and 4) we underestimate resistance to change. Common myths have impeded adoption of iterative development and led organizations to either decide by decree or default to adhere to the status quo.
This section discusses some of the myths surrounding cultural change and provides some responses to those myths.
Myth: We can declare to our organizations that we are standardizing on an iterative process and our teams will happily adapt.
Reality: Such a declaration can be quite threatening, and is likely to be met with at least some resistance. There are a number of reasons why teams and individuals resist change. For instance:
- Fear of lost power and influence. While the change may be good for the organization, individuals may believe that they personally will suffer. Change can mean loss, which instills fear and anxiety. Fear of change is a powerful resistance factor.
- People are satisfied with the status quo. Members of your team may have a compulsion to cling to our past successes,3 or they may not even recognize that there is room for improvement. This attitude is often expressed as "Hey, we've been doing it this way for years, why change now."
- The Fallacy of the Exception.4 No matter how well established a best practice is, or how much it is trumpeted and benchmarked, people will resist by expressing the belief that "That won't work here." In other words, despite evidence to the contrary, they feel that they are the exception to the rule.
- The Law of Unintended Consequences. You may hear this expressed as "We don't know what else might happen as a side effect of making this change."
We must recognize that undertaking any type of organizational change, including iterative development, is difficult and often results in resistance. Iterative development is not just an internal process that only the "techies" need to understand. It is a transformational approach to planning and collaboration and therefore has tremendous impact across business teams. Consequently, you must treat the introduction of iterative development as a project or program and give it the appropriate support.
All these human issues are very real inhibitors to change. Later, I will address the specific cultural aspects that affect resistance to change.
Myth: A silver bullet will solve all our problems.
Reality: This myth persists within our approaches to improving software capability. Some organizations shun process and instead rely on heroics and the sheer talent of their development teams. Other teams embrace process too enthusiastically and attempt to ensure success by overwhelming the team with mountains of process. Still others look for the cure-all software tool that will solve their problems. We know, however, that one single solution does not fix anything. Real, lasting success must embrace all these elements in parallel -- balanced for the organization and the project.
Myth: Everything's fine. We do not need to make global improvements.
Reality: With a nod to the "fallacy of the exception" rule we mentioned earlier, some leaders believe that they can achieve breakthrough results simply by making improvements in key process areas. A few years ago, a consumer products company wanted to improve its distribution system. Each division had diverse product lines, and each had its own trucks to distribute products to regional distribution centers. Some cost savings could have been achieved by improving the logistics of loading trucks and shipping packages within each division. But a global change proved to be a much more effective solution. The company moved to a centralized distribution mechanism that served all divisions, and thus was better positioned to optimize loading, routing, and warehousing. This resulted in fewer trucks, fewer trips to retail distribution centers, and ultimately, lower costs and higher profits.5
Similarly, some groups try to improve their software development capabilities by reorganizing their teams, in the spirit of the proverbial rearranging of the deck chairs on the sinking ship. A recent meeting with the Chief Technology Officer of a Fortune 50 company reminded me of this fallacy. "If we just improve the processes for gathering requirements, if we just do better at designing our applications, if we just do a better job of testing, we will ultimately improve the quality of our software and the predictability of its delivery." In other words, the CTO felt that by focusing on the internal processes for each area of the development lifecycle, the organization could achieve higher levels of product quality. These improvements probably could help the organization in an incremental way, but the approach misses the opportunities for breakthrough improvements in effectiveness.
Most application development problems persist because different parts of the organization are optimizing their efforts at the expense of the overall goal; having better requirements is of little value if the processes for development and testing are holding up the organization. You can certainly gain incremental improvements by adopting use case driven development or by using visual models. Jeffrey K. Liker suggests in his new book, The Toyota Way, that this thinking is associated with traditional process improvement, focusing on local efficiencies. You may see significant local improvement, but little impact on the overall result. Liker notes, "This is especially true because in most processes there are relatively few value-added steps, so improving those value-added steps will not amount to much."6 To achieve transformational results requires a cross-functional, iterative approach rather than local or siloed process improvements. Using our previous distribution example metaphorically, all our software departments need to get rid of their "trucks."
These common myths are symptoms of deeply ingrained attitudes and behaviors in organizational cultures. A report published by The Software Engineering Institute (SEI) suggested, Ã¢â¬Åorganizations have experienced difficulties with spiral developmentÃ¢â¬âdue to over-relaxed controls, underestimated risks, existing sequential development policies, inflexible financing mechanisms, ingrained cultures, and confusion about what spiral development is and how to apply it."
The next section of this article explores the cultural aspects that hinder iterative development; a forthcoming article will address the operational issues.
Organizational culture is the collection of values, beliefs, and operating behaviors shared by individuals within an organization. Adopting the iterative approach to development often requires a change of culture. In this section, I will discuss a framework for understanding organizational culture and some important attributes of culture that support an iterative paradigm.
A framework for assessing organizational culture
A useful framework to assess an organization's behavior and culture is The Competing Values Framework, described by Kim Cameron and Robert Quinn. It is a widely used approach to understanding the fundamental values that exist in an organization. If an organization's members predominantly adhere to one dominant value, then that dimension largely defines the operating culture.
A useful framework to assess an organization's behavior and culture is The Competing Values Framework, described by Kim Cameron and Robert Quinn. It is a widely used approach to understanding the fundamental values that exist in an organization. If an organization's members predominantly adhere to one dominant value, then that dimension largely defines the operating culture. Understanding how the people in the organization view their group can help us anticipate challenges, structure our adoption approach to tackle these challenges, and even serve as an input to the way we tailor our software development process. Table 1 describes each of the four cultural values.
Table 1: The Competing Values Framework, developed by Kim Cameron and Robert Quinn
Understanding how individuals view the culture gives you insight into the type of organization you are dealing with and therefore what behavior needs to change as you adopt iterative development. For instance, if your organization focuses on results and ignores how to achieve those results, it's likely that the group will suffer from low trust and consequently low morale. As we discuss in the next section, this lack of trust directs the group toward rigorously detailed contracts and specifications. This early focus on detail leads to a rigidity that is antithetical to an iterative or adaptive approach. People will probably fear making decisions on their own and will therefore default to group consensus, which usually reinforces the status quo. This reaction has the effect of sabotaging success when problems crop up (as they always do) -- no one wants to risk group censure by raising issues the group does not want to deal with. In a later section, we describe one way to assess your organization's culture, and how the results can help you plan a migration to iterative development.
Cultural impediments to adoption
Now, let's examine the cultural issues that act as impediments to the adoption of the iterative approach. Figure 1 shows a map of these issues.
Figure 1: Cultural issues that act as impediments to the adoption of the iterative approach
Working in a high or low trust organization
Whether your organization has an internal development team, or outsources development projects to a third party, it is common for the relationship between the business team and the development team to be adversarial. The two groups often develop an "Us versus Them" attitude towards working together.
A lack of trust often leads to a culture that is obsessed with documenting everything. The groups tend to overcompensate by creating contracts and specifications prior to designing, developing, and integrating code. The reality is that these "contracts" never produce the desired result; they simply define the battlefield on which opponents will square off as soon as things go wrong. When you have the proof to say that "the project failed because we didn't have the right requirements," your victory is hollow, and no one, least of all your customers, actually wins.
Do not misunderstand. I'm not suggesting that documentation and signoff are unnecessary -- they are a fact of life in the world of business. "High Trust" does not mean that everyone has to gather around, joins hands and sings "Kum Ba Ya." However, when detailed software requirements are embedded in contracts, odds are your team has trust issues. The important point is to find a balance between trusting the other guy and documenting high-level agreements.
We should focus on ensuring that we have good, working relationships and communication so that we don't end up in trouble in the first place. If key leaders both model and encourage curiosity and creative thinking, and if they focus on a shared vision, you can create an organization where open and honest communication can flourish. We'll discuss this point more in a later section.
Seeking reality or hiding from it
In too many organizations, the culture does not encourage its members to seek and confront risks, uncover unpleasant facts, or ask the tough questions. In fact, when they do deliver bad news there is a tendency to "shoot the messenger." To illustrate how not confronting brutal facts affects organizations, Jim Collins, in his book Good to Great, tells of an interview with Admiral Jim Stockdale, the highest ranking officer held by the North Vietnamese during the US/Vietnam War. Collins boils down the lessons of facing reality to this statement: "You must never confuse faith that you will prevail in the end -- which you can never afford to lose -- with the discipline to confront the most brutal facts of your current reality, whatever they might be."
Collins calls this lesson the Stockdale Paradox and says that the acceptance of this paradox is a recurring characteristic in the companies that have become great. This lesson is applicable to the world of software development. Many development projects begin with unrealistic -- overly optimistic -- schedules, scope, and budget. Rather than deal with reality, we deal with hope. This tendancy feeds into a low trust environment, spelling disaster for the organization.
There are countless business stories where a failure to confront brutal facts has resulted in lost market dominance, bankruptcy, and other reversals of fortune. The failure often starts at the top and meanders its way down into software development projects. So what happens when this failure to acknowledge reality manifests itself in software projects?
Lofty goals often inspire business teams, while they often demoralize engineering teams. The business team is "shooting for the moon" while the engineering team focuses more on the apparent lack of attention to the brutal facts.
Encouraging or discouraging curiosity
As a project progresses, no one wants to question whether the project will actually meet its objectives. Team members are conditioned to ignore risks that could be perceived as derailing the project. This complacency, or at least wishful thinking, is potentially damaging to project success. A healthy degree of paranoia is a good thing. As Walker Royce of IBM Rational says, "No one is picking up rocks and looking for the ugly, squiggly things underneath." Developing and embracing the habit of proactively searching for risks is essential for adopting an iterative approach.
Why are we reluctant to ask questions and why do we stick our heads in the sand? Some of the first projects that I was involved with suffered from this problem. We allowed ourselves to become too optimistic. We didn't ask questions such as Ã¢â¬ÅHow do you know that we will have no problems integrating with that legacy system? Or what happens if we have to build that component rather than buy it?" It can be tempting to lull yourself into a false sense of security by not asking the tough questions. Just because you haven't stepped on a landmine yet doesn't mean the field isn't littered with them.
A former organizational behavior professor of mine at Georgia State University, Dr. Louis St. Peter, says, "We frequently stop being inquisitive as we get older because we learn it is good to be intelligent, and being intelligent is interpreted as already knowing the correct answers (instead of asking good questions)." The authors of BusinessThink7 concur, suggesting that curiosity is an essential element of finding the right solution to a problem. Unfortunately, it is fairly common for members of a development team to simply accept that the solution they are asked to develop is indeed necessary. Rather than engaging the client (internal or external) to understand the problem being tackled, we simply "do as we're told," and go build the system.
Developers all too often learn not to ask questions when they are punished for asking exactly those questions that they should be asking. They also might not ask questions because they fear being perceived as ignorant or lacking necessary expertise. We have all been in meetings trying to follow an incomprehensible presentation. We look around the room and we see nods and general agreement. What we don't realize is that much of the body language is a cover -- no one else understands the presentation either. It takes courage to raise your hand and ask for clarification.
People may also avoid asking questions because doing so may cause conflict. Conflict can be either good or bad depending on the type of conflict and the tact with which it is engaged. The right kind of conflict can lead to better decision making. There are two types of conflict to discuss here:
C-type conflict, or "cognitive conflict," focuses on problems and issues related to differences of opinion. With c-type conflict, team members disagree because their different experiences and expertise lead them to different views of the problem and possible solutions. However, c-type conflict is also characterized by a willingness to examine, compare, and reconcile those differences to produce the best possible solution.
A-type conflict, or "affective conflict," refers to the emotional reactions that can occur when disagreements become personal rather than professional. A-type conflict often results in hostility, anger, resentment, distrust, cynicism, and apathy. So, unlike c-type conflict, a-type conflict undermines team effectiveness by preventing teams from engaging in the kinds of activities, such as c-type conflict, that are critical to team.8
Regardless of the reasons that people in your organization don't ask questions, this behavior has to change for iterative development to be successful. The culture must foster C-type conflict and allow for anyone to ask the hard questions and to get honest, reasoned answers.
Execution vs. the allure of activity
Of course, the goal of software development is to produce working software. Your process -- the way you create the software -- affects the quality of the final product. So your process is a means of producing a product of high quality, rather than the focus of your effort. In this section, we discuss execution and the hindrances we encounter in the workplace.
Larry Bossidy and Ram Charan, in their book Execution, explain that execution is the art of getting things done,9 which places a higher premium on results-oriented action than dialogue or paper promises. As any personal productivity specialist will tell you, it is easy to trick yourself into thinking that you are being productive; activity has a misleading allure. It makes you believe that staying busy generates results. How do we judge the effectiveness of our politicians? By the fact that they propose a lot of legislation, produce a lot of ideas, and negotiate a lot of language? Or do they actually pass legislation that has a meaningful impact on their constituents' quality of life? If we judge by the latter criterion, then we are focusing on results, not on "procedural progress".
Organizations and projects can fall into the same trap of confusing activity with achievement. In the context of software projects, the lack of execution manifests itself through excessive meetings, exorbitant quantities of documentation, and other low-value activities that are the by products of an activity mindset.
What factors prevent organizations from being oriented to achieve? Sometimes, people fear action because they fear being held accountable for failures that might result. This risk aversion can embed itself in the culture, resulting in stagnation for the entire organization. In a more general sense, people fear the unknown. Consequently, individuals and organizations take comfort in knowing all the answers and risks from the start. They stick to routines, even when there is a strong possibility that things could improve. No matter how bad things are, they can always be worse. Our project plans reflect this. We build detailed plans early on because they give us a sense of security, even though we know that those early plans will quickly become obsolete.
Iterative development is challenging because it acknowledges that we cannot know everything up front and it requires us to plan to adjust for the unknown. Yet, in a culture that discourages questions and encourages "results at any cost," it's hard to imagine that iterative development can be successful. In an environment that fosters office politics, that instills fear if you speak up, or that encourages complacency, a low-trust culture emerges. These features can lead to a culture where reality is hidden from key stakeholders. And it becomes difficult to mitigate risks. This type of environment is not very conducive to introducing risk-driven, iterative development.
Creating change: How to affect the culture
Pointing out the challenges is much easier than describing what to do about them. Fortunately, there are dozens of books and gurus who have distilled lessons from thousands of cases.
Bossidy and Charan10 suggest that when executives realize their organization needs to change, they often try to change the "hardware." They spend their time rethinking strategic plans, organizational structures, roles and responsibilities, high-level processes -- in other words, the "hardware" of the organization. But just as the hardware of a computer is useless without the right software, an organization's hardware (its strategy and structure) is meaningless without the Ã¢â¬Åsoftware," which is the hearts and minds of its people. You must address their beliefs, their concerns, and their issues if change is to happen.
Understanding the culture
Culture is a difficult concept to pin down. We can examine organizational structures and process documentation to determine where change is possible and desirable. But the first step is to understand the culture as it exists today and how the team believes it needs to change.
Surveying the team
In their book, Diagnosing and Changing Organizational Culture, Cameron and Quinn present a series of questions called the Organizational Culture Assessment Instrument (OCAI).11 This short questionnaire, which usually takes about five to ten minutes to complete, is answered by members of the organization to assess their perspective of the current and desired culture.
Figure 2 shows a portion of an OCAI questionnaire recently completed by a large government agency conducting a software capabilities assessment.
Figure 2: A portion of an Organizational Culture Assessment Instrument (OCAI) conducted by IBM Rational
The OCAI assessment instrument includes the following sections:
- Dominant Characteristics. What is most important in our culture? For instance, is building really cool solutions more important than predictable results?
- Organizational Leadership. How do you characterize the leadership style? Are our managers no-nonsense aggressive competitors or are they more concerned with driving out inefficiencies?
- Management of Employees. How are employees treated -- like cogs in a wheel or as valuable assets to be nurtured and grown?
- Organizational Glue. What holds the organization together?
- Strategic Emphases. What do we value? High trust? winning?
- Criteria for Success. How do we measure our success? Market share? teamwork? innovation?
Each member of the team distributes 100 points across four descriptive statements in each section, assigning more points to the statement that best describes the organization.
How is this assessment useful?
Understanding how key team members view the organization is interesting, but does it help us adopt iterative development? Yes. By analyzing the cultural profiles, we gain specific insights into how changes might be made in a given organization. Looking at a graphical profile yields a quick method of understanding the data. For each of the answer groups, a Culture Profile is developed and then an average is calculated.
Let's look at general insights that can be drawn from analyzing these profiles.
Analyzing the gap. How far of a divide is there between perceptions of the culture today versus where members of the group believe it should be? (In Figure 2, this gap is represented by the Now and Desired columns.) Is our current culture overly structured in a "command and control" style? Do we need to be more innovative to meet the demands of our clients? The gap tells us how much work we need to do.
Looking for incongruence. Analyzing what an organization says is important versus what actions the organization takes aids in spotting latent cynicism. For example, what happens if management states that our most important value is its people, but our leadership style and management of employees emphasizes rigid adherence to documented procedures and rules at the expense of common sense? Introducing a change into an organization whose members are jaded from the Ã¢â¬Åmanagement quick fix of the month" is difficult; discrepancies in the culture profile can help spot these problem areas.
Varying opinions. It's not unusual to discover differing perceptions of the culture across different individuals and teams. However, if there are striking differences between different groups of the organization, or if no clear pattern exists, this can be a sign of underlying problems. For instance, suppose you notice that management believes the dominant cultural value is the Human Relations (refer to Table 1, Collaborate) culture where the organization feels like a family, but employees believe that the dominant value is delivering results (Compete). In this case, management may be unplugged from reality, and top-down efforts to change process will be met with resistance.
Now specifically how does understanding the culture help us plan the adoption of iterative development? There are no easy answers. To date, theories are based more on anecdotal and qualitative evidence rather than empirical data. However, as we begin to understand the Competing Values Framework, we can make some logical assumptions about cultural attributes in relation to iterative software development and its adoption. Table 2 shows the likely positive and negative conditions at work within each of the four culture types described earlier.
Table 2: The positive and negative conditions likely to be at work within each of the four culture types
Changing the thinking
In the style of the classic "chicken or egg first" question, one might ask: "Which should come first, culture change or the adoption of iterative development?" As Bossidy and Chraran so aptly put it, "We don't think ourselves into a new way of acting; we act ourselves into a new way of thinking." This is also the opinion of Harvard change guru, John Kotter:
"Culture is not something you manipulate easily. Attempts to grab it and twist it into a new shape never work because you can't grab it. Culture changes only after you have successfully altered people's actions, after the new behavior produces some group benefit for a period of time, and after people see the connection between the new actions and performance improvement."12
While you must acknowledge the cultural and operational issues we've discussed, and have a plan for dealing with them, the key to changing attitudes is to produce demonstrable results. In other words, you cannot hold cheerleading sessions and coax people into these new behaviors.
For many of the reasons suggested by Bossidy, Charan, and Kotter, IBM Rational Software advocates adoption through execution when deploying iterative development and the IBM Rational Unified Process. Kurt Bittner's and Saif Islam's recent Rational Edge article, "Adoption through execution: Project-level mentoring to improve software capability,"13 explains the concept in detail; basically, adopting iterative development requires a "learning by doing" approach. The goal is to demonstrate to a software development organization how a change in the way its team members collaborate can yield more predictable results. Successful demonstration of an iterative approach provides the proof necessary to change attitudes about what is possible. And this proof comes in the form of actual, working software -- even if it's in its early stages, and only partly functional.
Telling stories: Old way and new way
Once we have the results of a cultural assessment, we must then figure out how to change the culture. In a presentation I recently attended, IBM Rational process guru Per Kroll suggested we must change the way we think about our roles in software development by looking at the "old way" versus the "new way" of thinking. Black and Gregersen's book, Leading Strategic Change, echoes this concept by suggesting that to make changes in the organizational culture, you must alter the "mind maps" of the individual.14 In the spirit of changing the hearts and minds of our team, promoting new thought patterns within the culture of our organization can go a long way toward developing a climate more hospitable to iterative development. Table 3 presents some examples you can use to challenge your team.
Table 3: As teams make the transition to iterative development, project leaders and executives can challenge them to think differently about roles and responsibilities.
Characteristics of a hospitable iterative culture
Is there an ideal cultural profile for iterative development? This question will only be answered definitively after more research; however, it is safe to assert that a balanced culture is important. Regardless of the exact cultural profile, there are ways to combat dysfunctional cultural elements. The following list describes the features of the culture and environment that our organization needs to build if we hope to adopt iterative development:
- High trust. Customers, stakeholders, and the software team all believe they are working toward the same objective.
- Open and collaborative. Risks are openly discussed in a realistic manner. We value coaching and building a facilitating leaders.
- Passion for problem solving. The team actively looks for root causes and engages in creative problem solving. We don't just build or deploy a solution because somebody said to; we truly understand the correlation between the solution and the problem.
- Curiosity is encouraged. Question everything, understand the assumptions.
- Customer results driven. What matters is that customers receive the results they need, not just what was documented as a requirement.
- Team members are empowered and accountable. Project teams are given the authority to make things happen as opposed to having their hands tied by dozens of oversight committees, functional management teams, and process cops.
- Organizational politics are spurned. The overriding value is that we share goals tied to delivering value to our customer. We care far less about who gets credit or who will be promoted after the successful completion of the project.
- Execution oriented. A preference for getting things accomplished -- not simply stepping through a sequence of activities -- is evident.
Many attempted adoptions of iterative development fail because the advocates do not adequately prepare to face the cultural issues that characterize the organization. You can overcome these challenges to iterative development by actively assessing, then understanding, the culture prior to the transition. Adopting process change through execution is critical to making the changes real and apparent to the key stakeholder. Changing hearts and minds is best done by changing behavior -- by implementing real projects with the help of experienced practitioners of iterative development. Culture change does not come from platitudes and slogans, but from creating new success stories that become the norm.
1Boehm, B. W., "A Spiral Model of Software Development and Enhancement," in Computer magazine, May 1988, Vol. 21, Issue 5, pp. 61-72
2Michael Cusumano, Alan MacCormack, Chris F. Kemerer, Bill Crandall, "Software Development Worldwide: The State of the Practice", IEEE Software, November/December Volume 20. No 6, p p. 28-34
3Gordon MacKenzie, Orbiting the Giant Hairball, Viking, 1996
4Joseph H. Boyett, Jimmie T. Boyett, The Guru Guide, Wiley, 2000
5Murray Cantor, from his presentation at the IBM Rational Software Developer and User Conference 2004
6Jeffrey Liker, The Toyota Way: 14 Management Principles From the World's Greatest Manufacturer, McGraw-Hill, 2003
7Dave Marcum, Steve Smith, Mahan Khalsa, businessThink: Rules for Getting It Right -- Now and No Matter What! Franklin Covey Co., 2002
8Dr. Louis St. Peter
9Larry Bossidy and Ram Charan, Execution, Crown Publishing, 2002
11Kim S. Cameron, Robert E. Quinn, Diagnosing and Changing Organizational Culture:Based on the Competing Values Framework, Addison-Wesley, 1999
12John P. Kotter, Leading Change, Harvard Business Press, 1996.
13June 2004: http://www-106.ibm.com/developerworks/rational/library/4866.htm
14J. Steward Black and Hal B. Gregersen, Leading Strategic Change- Breaking Through the Brain Barrier, Financial Times Prentice Hall, 2002.
15Adapted from Per Kroll
The thoughts and writings of Kurt Bittner, Murray Cantor, Saif Islam, Walker Royce, and Dr. Louis St. Peter, were instrumental in helping to formulate the key messages of this article. Thanks to the many other colleagues, friends, and clients who have reviewed and given feedback on the content of this article.
- Philippe Kruchten and Per Kroll, The Rational Unified Process Made Easy. Addison Wesley, 2003.
- Steffan Bergström and Lotta Råberg, Adopting the Rational Unfied Process. Addison Wesley, 2004.
- Barry Boehm and Richard Turner, Balancing Agility and Discipline
- Jim Collins, Good to Great. Harper Collins, 2001.
- Larry Bossidy and Ram Charan, Execution, Crown Publishing, 2002.
- Kim S. Cameron, Robert E. Quinn, Diagnosing and Changing Organizational Culture: Based on the Competing Values Framework, Addison-Wesley, 1999
- Stephen P. Robbins, Essentials of Organizational Behavior, Prentice Hall Publishing, 2003.
- Lee G. Bolman and Terrence E. Deal, Reframing Organizations-Artistry, Choice, and Leadership, Josey-Bass Publishing, 2003.
- J. Steward Black and Hal B. Gregersen, Leading Strategic Change- Breaking Through the Brain Barrier, Financial Times Prentice Hall, 2002.
- Dave Marcum, Steve Smith, and Mahan Khalsa, BusinessThink- Rules for Getting It Right- Now and No Matter What!, John Wiley and Sons, 2002.
- John P. Kotter, Leading Change, Harvard Business Press, 1996.
- Joseph H. Boyett and Jimmie T. Boyett, The Guru Guide, John Wiley and Sons, 1998.
- Jeffrey K. Liker, The Toyota Way, McGraw Hill, 2004.
- Philippe Kruchten, "From Waterfall to Iterative Development: A Challenging Transition for Project Managers." The Rational Edge, December 2000.
- Philippe Kruchten, "Going over the Waterfall with the RUP". The Rational Edge, September 2001.
- Carol Lavin Bernick, "When Your Culture Needs a Makeover." Havard Business Review, June 2001.
- W. J. Hansen, J. T. Foreman, D. J. Carney, E. C. Forrester, C. P. Graettinger, W. C. Peterson, and P. R. Place, "Spiral Development- Building the Culture", A Report on the CSE-SEI Workshop, February, 2000
- Joe Marasco, "On Politics in Technical Organizations", The Rational Edge, October 2001
- Kurt Bittner, Saif Islam, "Adoption through execution: Project-level mentoring to improve software capability", The Rational Edge, June 2004
- Craig Larman and Victor R. Bacili, "Iterative and Incremental Development: A Brief History", IEEE Computer, June 2003
- Ian Spence, "Principles of Process Improvement", The Rational Edge, January 2002
- Michael Cusumano, Alan MacCormack, Chris F. Kemerer, Bill Crandall, "Software Development Worldwide: The State of the Practice", IEEE Software Magazine, November-December 2003
- Barry Boehm, "A Spiral Model of Software Development and Enhancement," Proc. Int'l Workshop Software Process and Software Environments, ACM Press