4squareviews

I am going through the material in Chapter 6 of the Agile Practice Guide, which focuses on organizational support of an agile project.

Here are the changes particularly associated with agile projects, and why they have to be considered in any change management approach.

• Accelerated delivery–Agile is an approach that focuses on delivering project outputs early and often to the customer (the “incremental” part of agile) and giving feedback from the customer back to the team on a regular basis (the “iterative” part of agile).   On the organizational side, it is important to discover and deliver the features of the product to the customer.   But as the pace of delivery increases, it is important on the customer’s side to be able to accept the delivery and validate that it aligns with the project objectives, or point out where it doesn’t align in as clear a manner as possible.
• Learning curve–when an organization is just beginning to use agile approaches, there is a high degree of change when learning to accept the culture of agile.  Agile will require more frequent hand-offs between teams, departments, and even vendors.   Change management techniques can help address the hurdles of transitioning to agile approaches.

So it is not just a learning curve to learn the culture of agile, but an acceleration of already existing communications.

The problem in many organizations is that agile is seen as something that replaces traditional project management.   A better way to see this is that it transcends and includes a lot of the traditional structures in the organization, and can end up transforming them.   An example is with the “lessons learned” process, which in traditional project management was typically done at the end of a project (at least according to the 5th Edition of the PMBOK Guide).   When agile came along, this lessons learned process was still done, but not at the end of the project, but rather at the end of each iteration.   Any lessons learned were applied directly to the project at hand, and not at some hypothetical project in the future that may or may not take place.   This accelerated improvement not only made the project better, but those “best practices” that developed during the project could be used by the organization as a whole or even by other project teams.

This is an example of how agile did not replace a structure from traditional project management, but instead it transcended and included it (by having it incorporated into each iteration).   It proved so useful that in the 6th Edition of the PMBOK Guide, it is no longer a part of the “Close Project or Phase” process in the Closing process group, but is a separate process that it done during the Executing process group, as process 4.4 Manage Project Knowledge.

So with this more positive way to thinking about agile approaches, what are some of the characteristics of organizations that make supporting agile principles easier?   And conversely, what are some of the characteristics that may be roadblocks to achieving agile principles?   This will be the subject of the next post.

Filed under: Uncategorized |