Is Agile Suited to Competitive Software Projects more than Support-based Software Projects?

I came across this interesting post on the LinkedIn CSM board today from Victor Penman and felt compelled to provide my 2 cents.

Who actually implements Agile?

Companies whose main product is software are more likely to implement Agile practices than companies where software (including IT) is a support function. This is what I have observed at the 12 companies where I have seen Agile (usually Scrum) either introduced or attempted to be implemented.

I believe this is because companies that sell or license software need products that will compete in the real world where customers have many options. Support software only has to be adequate.

The quality that comes from Agile, including the close interaction with customers, ability to pivot in response to changing market conditions or customer desires, and allowing teams to determine the best way to deliver, provides a needed competitive advantage.

Software developed for internal support does not face these pressures. Its users are unable to turn to a competitor. This allows support managers to continue to operate in the traditional Command and Control mode. If Agile practices are mandated from above, it is more likely that only the trappings of Agile (ceremonies for example) will be implemented.

I will appreciate hearing if others’ observations support or refute mine.

Turns out my 2 cents is actually more like $4.50 so I decided to post my response here (I ran out of room in the LinkedIn response box).

I agree with your premise to an extent but believe that in addition to pressure (rather than calling it competition) a team also requires an environment in which learning from experiments (rather than safety from abject failure) is encouraged. I have 3 experiences in particular that lead me to this conclusion.

In the case of pressure without safety to “fail”, I look back to one product-based business I worked with that was under extreme pressure to perform. Although the team is one of the smartest I’ve worked with, the product company still collapsed as a result of poor product implementations which led to loss of customer confidence. I believe a big component of the failure was due to the focus on architecting perfect implementations from the start rather than delivering solutions early to customers and learning from the interactions.

In the case of no pressure with safety to fail, I’m reminded of one product-based business that I worked with that had attempted to implement a new version of a core product 3 times over the course of 5+ years. I was involved in the 3rd attempt and soon after I left they started on the 4th attempt. This is a company that had made, and continued to make, a lot of money from their existing product and client-base. As a result, there was too much safety to fail so there was no push to experiment or learn from mistakes quickly.

The third project I want to point out was a successful project for an internal system for a large utility. In this particular project, there was immense pressure in the form of limited resources and time. In return, the project team was given a huge amount of safety around failure by the business owners. Although the project was given approx. 5 months of budget in which to complete, the project was re-assessed by a panel of business owners every month. At each monthly meeting, the team would communicate to the business any potential risks to the success of the project and if anything was deemed insurmountable, the panel had the right to pull the plug on the project. “Pulling the plug” on the project would not result in blame being attributed to any group or person, it was just considered a natural decision that had to be made as new information came to light.

The main take away from my 3 examples is that the first two failures were both product companies but both lacked a critical element. The third one was, as you call it, an internal project to develop support software – yet this project has been one of my most successful to date – the business owners were happy as they came within budget and the end-users were so eager to use the system that the beta system went “viral” internally. I attribute the success of this project to both pressure and safety to experiment.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s