![]() ![]() Because approaches like Scrum and XP accelerate project cycles, developers typically interact with their managers more frequently but for shorter periods. The other team members can quickly assess the value of these activities and will not adopt them if they do not help the overall development effort.Ī surprising number of developers view using agile processes as an attempt to micromanage. In such situations, it is best not to intervene. One programmer, for example, created a formal document type and attempted to coerce his peers into generating the document for hundreds of cases when it was called for in perhaps a dozen. These programmers go beyond “analysis paralysis” and actively seek opportunities to add formalized tasks back into an agile process. We also encountered programmers who measure their contribution to a project by the number of meetings they attend. While introducing Scrum to various project teams, we invariably found programmers who enjoy producing noncode artifacts far more than they are willing to admit. In an agile process, however, these items usually exist only to support the coding activity. In a plan-driven process, developers might treat Unified Modeling Language designs and other noncode items as first-class artifacts. In general, agile processes value code production more than plan-driven processes do. Other developers, however, either resist the change or overzealously jump into the project without enough forethought. Most developers respond to the proposed introduction of an agile process with the appropriate combination of skepticism, enthusiasm, and cautious optimism. Through trial and error, we have discovered several approaches for successfully introducing an agile process to organizations. ![]() A failure to sell the agile process change to any one area can negatively impact the project’s outcome. However, even the simple projects reached across many departments or functional areas. Others were straightforward and involved small, co-located teams. Some of the projects were complex and involved distributed teams. Over the past four years, we have introduced Scrum to seven organizations in four states. Scrum is ideally suited for projects with rapidly changing or highly emergent requirements such as Web projects or product development for new markets. At the end of each sprint, the team delivers a potentially shippable product increment. Development teams meet with the client, or product owner, before each sprint to prioritize the work to be done and select the tasks the team can complete in the upcoming sprint.ĭuring the sprint, the team stays on track by holding brief daily meetings. In Scrum, projects progress in a series of month-long iterations called sprints. 2 The processes most commonly considered agile include Extreme Programming (XP), 1 Lean Development, 3 Crystal, 4 and Scrum. The “Agile Manifesto” establishes a common framework for these processes: Value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Agile processes allow for changing requirements throughout the development cycle and stress collaboration between software developers and customers and early product delivery. Since the publication of Kent Beck’s Extreme Programming Explained, 1 agile processes have grown increasingly popular. In this article I want to discuss introducing an agile process to an organization. ![]()
0 Comments
Leave a Reply. |