Please login or join to subscribe to this thread
This comes to mind immediately:
- Rate of success in change processes within the company;
- Successful pilot with people that are open minded to the idea;
- Change the perceptions of risks.
Nicely stated Bouko.
I am a proponent of agile methodologies, but I believe adoption follows the basics of organizational change. I would suggest the keys are:
I think the most important prerequisite is a clear understanding of why you are looking at Agile. I am just off of managing a 13.5 month project in which we adopted some Agile elements. I think we generally adopted the right elements for the right reasons, and these were things that the team identified as successful in the post-project analysis.
Don't assume that "going Agile" is somehow going to magically make it easier to deliver on schedule - it will not. Make sure that developers understand that Agile does not mean less accountability for estimating and scheduling.
One other key thing: Make sure business owners, sponsors, stakeholders are clear that scheduling and estimating will be done in a wholly different manner.
RallyDev.com has a series of 4 1-hour webinars on Agile, the first being pitfalls of moving from traditional to agile sdlc. They are available off this site. If you can't find them, let me know at email@example.com and I'll send the gantthead newsletter they were in.
I was asked to be the agent of change for the adoption of an agile methodology in a waterfall environment at Symcor, a financial sector organization. One of the tricks/prerequisites was identifying the personality traits/skills/ethics of the trailing 10% of the 10/80/10 bell curve. Once I understood the "bottom" end, I had a major component of the scope required to create the behavioural change. A bridging tool was required in the form of an SDLC showing up as a Microsoft Project template. That template bridged waterfall with agile. The way I did it was simple: Create custom columns that corresponded to the waterfall as well as agile. This replaces/augments the conventional summary level headings that show up as rows. Additonal custom columns allowed them to identify their business unit, the way they want to identify themselves. By seeing themselves show up for the first time, in a standard PMO template, they were attracted to the template that by its nature would transition them from waterfall to agile. By training and walking the PMs through how to make the transition, and at the same time making them feel really good about Microsoft Project, they had the "excuse" to move over. As a bonus, I introduced PgMP concepts built into the MSP template, so they were more inclined to try the new template as they saw an advantage with the new designation.
Please login or join to reply