Special Delivery!

I’m sure most of you don’t think of software when you hear the word delivery, but as a Software Release Manager its the first thing that comes to mind for me. Throughout this year we’ve tweeted, blogged, and discussed dozens of industries in which digital transformation has impacted the way companies conduct business. However, we’ve barely scratched the surface regarding the manner or process in which these transformations are rolled out. The goal of this blog is to provide a high-level introduction to software delivery and the role it plays throughout digital transformation.

Software Delivery Lifecycle (SDLC) Methodologies

The two major delivery methodologies employed at scaled today are Waterfall & Agile. Waterfall is a classic model which places an emphasis on early planning to minimize variance or change prior to development. Typically, it consists of clearly defined stages that must be completed prior to the next stage beginning, and is most effective for large scale transformation programs that are introducing new technology or have complex integrations.

By looking at the image above you will likely notice similarities in the stages of the SDLC for both Waterfall and Agile. First conceived in 2000 and later formally introduced in 2001, Agile delivery aims to improve upon the classic Waterfall methodology by reducing time-to-market and increasing the frequency in which end-to-end software is delivered. Agile is best implemented in dynamic or rapidly changing environment with tight timelines and a need for rapid prototyping. Although originally introduced for smaller scale endeavors, many industries have adopted Scaled Agile including Amazon, Microsoft , and Spotify.

There are hundreds of stories of failed agile implementations and you may hear a noticeable “groan” in the audience of legacy software environments when its brought up. Typical pitfalls include misinterpretation, lack of a high quality two-way communication between development team and stakeholder/customer, and most notably a failure adapt organizational models to support the change. However, there is evidence that agile frameworks are more successful than traditional delivery methodologies like waterfall.

Enterprise Software & Software as a Service (SaaS)

                Delivery methodology alone will not solve all the challenges organizations face when embarking on digital transformation. Another critical step in the process is determining how your product or software will be leveraged. Consider these two examples in deciphering the difference between enterprise/on-premises software & SaaS:

  1. In 2003 a customer purchases a copy of Grand Theft Auto Vice City at GameStop. The game is installed on the customer’s gaming console via a CD.
  2. In 2013 the same customer purchases a copy of Grand Theft Auto, but this time directly from the PlayStation / Xbox online store. The game is downloaded from the online store to the console and future updates are maintained in the same manner.

This simplistic example of the transition to SaaS has major implications. On the business side, Sony & Microsoft have managed to cut out the 3rd party retailer (GameStop) keeping more revenue in house. Over those 10 years they’ve also created lucrative revenue streams within their own ecosystem by providing consumers with access to add-ons, expansion packs, etc. On the consumer side the acquisition process has been simplified and streamlined, removing the need to even leave your house to obtain the new game. Furthermore concepts such as Xbox Live & PlayStation Plus introduced a recurring revenue stream enabling gamers to play online in exchange for a monthly or annual fee.

My company, PegaSystems, is going through a similar transition from legacy on-premises software to SaaS. Many different challenges present themselves than in the video game example, due to vast differences in use-cases and clients. The original Pega platform was never designed to work in a SaaS model, so when we try to decouple some of the key features/services into micro-services you essentially need to rebuild the whole platform. Additionally, once you’ve created this new platform you still need to migrate your existing clients to it without causing upgrade impacts or negatively effecting the software that they use to run their businesses. Despite these challenges and a host of others, its critical for our organization to shift to SaaS remain competitive, agile, and provide the ability to truly scale.

Conclusion

                I’ve briefly touched on two impactful areas of software delivery, Delivery Methodology & SaaS, and identified the impact they have during a large-scale digital transformation. In my opinion its critical to couple these operational/engineering needs with organization’s HR processes to incentivize change.

Additional Resources:

8 comments

  1. I enjoyed the way you explained the challenges of using agile methods, while highlighting its rewards still outweigh the risks by sharing concrete examples that we can easily relate to. I wonder if there’s technology to eliminate the issues you described with agile methods; a tool that provides a two-way communication between clients and customers and can easily adapt to a variety of business organizational models. I personally do not own a gaming system, but I watched my friends easily download games from the online market place from either PlayStation or Xbox. Similarly, I’ve experienced a little bit of this seamless technology from my employer to upgrade a particular system, but like you said it doesn’t happen enough as it should. Most recently, for example, we can all relate to the failed upgrade/maintenance of EagleApps. Great post.

  2. Working in tech, and more specifically headless app software development and integration, I completely agree with your assessment of a more holistic acceptance of agile frameworks needed to be really successful. My company is smaller and has fully adopted agile scrum frameworks- which all work really well for our company. The difficulty comes, however, when we need to interact with major retailers that are as legacy waterfall as it gets. Teams interacting directly with my company have typically been effective in adopting agile methodologies, but not so much with their tangential departments. The more my company pushes to scale our product within enterprise clients, it’s becoming clearer that these larger enterprise clients need to more fully adopt agile work frameworks in order to keep up with the industry’s inevitable technological evolution.

  3. This reminded me of Adobe’s transition to SaaS. In that case, transitioning to SaaS took almost 5 years. As you mentioned, an agile delivery is best for a rapidly changing environment but takes a long time to implement, which presents a challenge – stuck in a rapidly evolving environment -> need to adopt agile delivery -> but that takes a long time. Also, @mwalters22 makes a good point about the transition to EagleApps. Seems in this transition, leaders matter as they can provide vision and guidance as an organization undergoes meaningful but difficult change.

  4. admittedly, I clicked on this because I thought the topic would be about digital food delivery or something like that. Buttttt turns out this is more important, and i learned something! Also working at Pega, but on the sales side, I see not just our internal efforts that you’re working on to transition us to a SaaS model, but also the challenges our customers face with transitioning from waterfall to agile methodologies in their own development cycles. Many times, legacy companies will start using the agile terminology, but in practice are still using waterfall to try to push out new applications – this is where people, culture, and education come in. Many legacy company leadership doesn’t truly understand the deliniation, and it may take a program like BC’s to help them transition fully.

  5. Great post! I appreciate that you highlighted that companies sometimes think they are doing agile, but really are formatting their waterfalls differently. The company I worked for after college fell into this problem and it was a constant battle of blinding following a plan. This caused projects to fail early because they simply did not think about the end-user before the testing stage.

  6. Solid post! I was going to comment that one of the things holding companies to their legacy systems is that their platform is so outdated and/or a mess that it would actually be easier to start from scratch, but you already mentioned that haha. It’s coming to the point where a lot of companies will just have to bite the bullet and start rebuilding their platform. The longer they wait, the more difficult it will become.

  7. Great post! Conner’s point is spot on and hinges on where we began this class: technology fallacy. Like you mention, it is “critical to couple these operational/engineering needs with organization’s HR processes to incentivize change.” It is a good question as to when to start transitioning to a new platform. As I brought up in my presentation – and professor Kane “retweeted” in real life – the best day to plant a tree was 20 years ago; but the second best day is today!

  8. Great post! I think Pega is making the right move by implementing SaaS offerings. We’re seeing the same type of momentum at Dell where I work whether it be SaaS or other types of as a service offerings. Customers are asking for it more and more and I think in these next 10 years we’ll see a dramatic shift in how companies and consumers consume their technology. Better to be in front of the curve than behind it.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com 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

%d bloggers like this: