There are a number of practices that contribute to the effectiveness of agile development and help to distinguish it from traditional waterfall software development. Five commonly-used practices can be applied easily and rapidly to change management projects to help improve their efficiency and effectiveness, especially when the change at hand is software being developed using agile practices.
Sprint. At the heart of agile is the sprint—a time-defined, time-boxed, and iterative meeting during which working software is created. Sprints, also called scrums, are most often two, four, or six weeks in duration. The same practice can be applied to change efforts except that a set of change management work products can be produced which are limited to a portion of the total implementation, for example, addressing a defined segment of the targeted population. A change impact assessment as well as high-level stakeholder and employee engagement, communication, and training plans are produced with just enough information to allow implementation of the plans. Daily Stand-up. At this brief, daily, time-boxed (5-15 minutes) meeting, working teams come together to provide status information to other team members, evaluating the health and progress of the sprint. This daily communication and planning forum occurs at the same time and place; team members stand to emphasize being short and to the point. The same three questions generally answered during software daily stand-ups can be asked at a change management stand-up: User Story. A user story is a brief and concise statement used to describe a requirement from a specific user’s perspective. Stories should be estimable and testable features or units of business value. Generally captured on 3 x 5 cards—forcing brevity and conciseness—the stories use the following format: As a (user role), I would like (statement of need), so that I can (desired benefit). For change management efforts, a sample user story might be: “As a customer service representative, I would like to understand the timing, impact, and benefits of changes to our customers, so that I feel confident telling them what and when to expect, and how it will benefit them.” Burn Down Chart. A burn down chart is a simple, publicly displayed graph that maps work still to be done (vertical axis) versus time remaining to do it (horizontal axis). Burn down charts are used effectively to communicate progress and predict completions so that adjustments can be made to meet expectations. To finish 360 story points within six sprints, the team planned to average 60 points per sprint. The first sprint went well and they completed 90, leaving 270 stories. Things continued to progress well during the second sprint, but during the third sprint, the estimated work remaining actually burned up. This could have been because work was added to the project or because the team changed some estimates of the remaining work. After that, things again went well. (*Chart Source: Mountain Goat Software) The user story point also works for the change management team to measure progress during sprints. Imagine being able to picture each user’s requirement being satisfied as progress is noted! Retrospective. Held at the end of an iteration, a release, or the project, a retrospective is a communication forum during which the team celebrates team successes and examines its processes to determine what succeeded and what could be improved. The retrospective differs from traditional postmortems in two ways: Change management is an important, yet difficult and stressful profession. A more frequent and expected review of what the team will work on during the next iteration may help to relieve stress and guilt about issues that were not handled as well as expected. Some Tips from Experienced Agile Practitioners People who have implemented agile practices articulate similar precautions—do not equate limited documentation with no planning. Planning is still critical—in agile there are planning levels, some of which happen within the team structure. Equally important to remember is that agile practices are executed against a background of collaboration and communication as well as transparency and feedback—collaboration among team members and between teams, and among teams, business owners, and customers. Communication is done, as much as possible, face-to-face and not via email, text, or chat. Transparency in practices and results facilitates open communication, and feedback is expected among and between all parties. Does it sound like we’re talking about ideal change management practices as well as agile practices? Want to Know More? This blog is a brief glance into just a few of the many agile practices that have been used and refined by developers. Of late, there is an increasing number of sources that address agile and change management. I have listed some sources below so that you can do additional reading on agile and look into insights from individuals who have used it in their change management practice.
