Lessons learned from organizational change initiatives

¶ … Right, What Went Wrong, and Why Introduction

The accelerating pace of product lifecycles, specifically in many high tech and software-dominated industries in conjunction with the increasing number of competitors in specific markets are bringing an high sense of urgency to software development. The three-week project as discussed in the readings recommended for this assignment provide a glimpse into transforming the principles of extreme programming into measurable results on software development projects. The core components of fine scale feedback, continuous process including integration, shared understanding, and programmer welfare all are foundational elements of the concept. When extreme programming is attempted in many organizations the organizations' culture often rebels however as these concepts are different than long-standing processes and perceptions of how time should be managed. From the readings from this assignment however it is clear that extreme programming can significantly change the perception of time itself in organizations, while underscoring the need for greater continuous improvement of applications to customers" requirements while constantly thinking more broadly than just the writing of code to see how the application will integrated into a broader workflow. This is a "forest from the trees" mentality that is essential for time to be perceived differently in companies attempting to use extreme programming to increase the efficiency of their development process.

Lessons Learned: What Went Right

Undertaking a three-week turnaround to a project forces first an entirely new mindset relative to the perception of time and risk in many organizations. This is a very positive aspect of attempting and completing projects with the three-week turnaround as it forces organizations to challenge their perceived limitations around project processes, dependencies and performance. Second, when time gets compressed and the objective of the project is clear, a very high level of collaboration takes place. Everyone on a project is looking to not only get their coding and product tasks done but also to help others. A race mentality can set in and teams begin competing against their old time estimates to get work done. The entire level of intensity goes up across a team and programmers work to get done more in less time as opposed to devoting more and more hours to the project. One of the foundational elements of extreme programming is programmer welfare and sustainable pace, and in the best-managed three-week project teams, collaboration becomes so fluid that everyone celebrates a milestone of every team. In addition, effective leaders in the middle of managing a three-week project needs to develop the mindset that emergencies are opportunities to show the entire team how effective collaboration can be in completing tasks. This is critical as it first takes care of the emergency, and second, binds the team to focus on quick resolution of issues vs. being entirely focused only on their aspect of the project.

In addition to the change in the perception of time and what is accomplishable there is also a change in how teams look at the broader use of the code they are creating. Three-week projects force an integration mindset into development teams and also make it clear that the integration points for the application, whether they are system or process-based, need to be ready for the release of the application within a very short time period. These integration points, in experiences gained on projects, can be as manually intensive as getting other software companies to write small code sets to ensure compatibility, to a broader set of programs that would be considered application integration adapters or connectors. A three-week project makes the integration to outside systems critical and also makes the broader purpose of the application much more a center of focus for the project team.

In summary, changing organizations' perception of time and what can be accomplished within it takes much effort, yet a three-week project that uses extreme programming techniques can do this. What has typically gone right in many of these projects is that given the tighter time constraints political barriers break down and programmers work more effectively with one another and a shared sense of accomplishment begins to pervade the team. In addition, the broader purpose of the development and its integration points become much clearer. Finally the three-week project rules out excuses that were used in the past to either not get work done on time and avoid accountability or not press the norm of a six to nine-month window of development in many organizations.

Lessons Learned: What Went Wrong

Programming can quickly become myopic and too focused on a single set of factors, which often leads to the broader, more critical factors of how the application will integrate with other systems and processes being ignored. In addition, if the emergencies inherent in the project are not addressed and there is not a very strong sense of common objectives being fulfilled, the entire team's morale will suffer. Any political divisions that may have slowed down projects from being completed in the past have also been known to significantly slow down a three-week project schedule as managers battle for their employees' time over the needs of the project itself.