Monday, 22 August 2016 07:55

Just Because You Can Doesn't Mean You Should

Written by

Continuous delivery is the ability of an organization to deliver new or modified capabilities to customers as soon as those changes have been constructed and fully tested.

Such practices exist in many technology-as-a-core-competency companies such as Amazon where changes get deployed to production every twelve seconds.

Related Article: The Importance of Continuous Project Tracking

This capability sounds very attractive, doesn't it?

Imagine all the challenges which could be eliminated if your organization evolved from infrequent releases:

  • Missed market opportunities resulting from pre-emptive launches from competitors
  • Reduced return on investment for delayed capabilities which are no longer considered innovative
  • Encouraging stakeholder complacency as they grow unused to change and a higher likelihood of change resistance when changes are eventually released
  • Wasted administrative effort spent in planning and managing large release deployments
  • Reduced employee engagement or satisfaction resulting from the lack of reinforcement which occurs when stakeholders are quickly and actively using the deliverables produced by the team

Few would consider this to be an easy transformation as it goes beyond introducing some new practices or tools to requiring significant structural and behavior changes across the organization.

Here are just a few of the challenges your company will face if your leadership chooses to accept this mission:

  • Moving from project-focused, short-lived teams to capability or value-stream aligned, long-lived teams. No one denies the performing power of a group of professionals who have worked together for many months or even years but for organizations which have enjoyed the productivity illusion of multitasking team members across multiple simultaneous projects, having to "cut their coat according to their cloth" is a bitter pill to swallow.
  • A shift from individual to team-based performance evaluations and recognition. Formal recognition and annual performance evaluation programs usually focus on the individual, and this can encourage team members to act in their own interests instead of the best interests of the team. The shift to continuous delivery forces a company to move from encouraging specialized silo skill sets to generalizing specialists who play well in whole teams.
  • Technology limitations such as lower or higher environments which can't be provisioned quickly or have to be shared with other teams, lack of tooling to support continuous delivery or application footprints which don't lend themselves to incremental updates. Continuous delivery works very well for applications which were designed for cloud environments, but legacy applications tend to have well-established release schedules which can be very difficult to modify.
  • Internal or external governance requirements which prolong transition efforts. These could include the need for independent verification and validation after internal quality control efforts have completed or formal reviews with audit or regulatory bodies.
  • Operational teams which are ill-equipped to accept frequent change. Applications might need to be instrumented to be self-maintaining, and delivery teams would ideally ensure that production support collateral is released in line with functionality. This is a big leap for organizations which are used to having extended warranty periods after releases to give operational teams a chance to play catch up.
  • Changes to traditional budgeting approaches. While the temporary nature of projects can provide finance teams with a sense of security about funding decisions, continuous delivery requires leadership teams to allocate available funding to capabilities or value streams. This shift is still capable of aligning with fiscal annual budgeting cycles but will change the engagement model from one of project submission to value stream justification.

These blockers are par for the course when it comes to scaling agile within traditional organizations but let's say you could wave a magic wand and resolve of them.

Continuous delivery will still not make sense for all of your organization's capabilities as stakeholder context and expectations will influence timing on how quickly a given change should be made.

Think about the mobile applications you've downloaded and installed on your smartphone or tablet. By acknowledging their end user agreements, you've authorized the companies which developed them to update them whenever they feel like. This is a normal expectation for these platforms.

But think about the home pages for critical websites such as those of your bank, insurance or healthcare providers. If those were updated every few hours, imagine how challenging it would be to have to relearn how to complete the simplest activities. Even if the changes were aimed at improving usability, very few users have the appetite or capacity to absorb frequent changes without negative impacts.

One merely has to look at the inadvertent Darwin awards won and other unintended consequences of Google Glass, auto-driving cars or Pokemon GO to recognize that the pace of technology evolution far exceeds our ability to appropriately absorb it.

Effective change management eats continuous delivery for breakfast and just because you can deliver frequently doesn't mean you should!

Read 7505 times
Kiron Bondale

Kiron D. Bondale, PMP, PMI-RMP has worked for over thirteen years in the project management domain with a focus on technology and change management. He has setup and managed Project Management Offices (PMO) and has provided PPM consulting services to clients across multiple industries.

For more of Kiron’s views on project & change management, please visit his blog or contact him directly at kiron_bondale @ yahoo.ca.

© ProjectTimes.com 2017

macgregor logo white web