• Prev
  • Next

How to Transition from Packaged Products to the Cloud

Mike HarrisWith all the talk about the cloud, you’d think most companies, at this point, would be discussing how they can make use of the power and flexibility it offers. And you’d be right – for the most part. According to the International Data Corporation (IDC), the worldwide market for SaaS offerings is on track to grow by around 20 percent per year through 2018 (exceed $100 billion).

Of course, this is no surprise to most you reading this. At least, I’d assume not. Cloud computing allows for faster processing speeds, better network connections, lower delivery and support costs, and improved customer experiences.

Despite this, only eight percent of the revenues of the top 100 software companies come from SaaS models. The reason is largely because of the challenges that face companies as they wish to move their offerings to the cloud, including security concerns.

That’s where the article, “From Box to Cloud,” from McKinsey & Company proves useful. The article offers 6 principles for a successful switch from, well, box to cloud. We’re sharing the principles here, with our thoughts, in hopes that more companies will capitalize on the power of cloud.

  1. Minimum viable products – Cloud almost necessitates “light” versions of software – or minimally viable products. Develop your cloud-based software with the assumption that it will be tested and refined on an ongoing basis. It doesn’t have to be the final version!
  2. Users are key – With cloud, your development team should be engaging with their customers as often as possible, again, on an ongoing basis. Their real-time feedback is important – and something that developers can use to their advantage, by A/B testing features to assess and refine for the future.
  3. Failure will happen – In packaged software, bugs are seen as a major failure. With cloud, bugs are expected – and can (and should) be fixed quickly. Software maintenance should be easier in the cloud, and some developers even simulate failures regularly to make their own adjustments.
  4. Agile! – Look, we know that we talk about Agile all the time, but that’s because we know the value it offers, and if you’re moving to cloud, Agile is a must-have. The cloud functions best in an environment of continuous release, which is a tenant of Agile. DevOps, which brings together IT and R&D, is also useful in the cloud. On the whole, frequent releases can help manage risk and complexity. And, as the article notes, Agile teams can increase their productivity by about 27 percent and improve the timeliness of feature releases by 30 percent!
  5. Developers’ expanded role – Developers should now be given the responsibility of QA and testing – and they should be expected to fix problems as they come across them.
  6. Invest in the latest and greatest – This means people and products. Seek out the top talent for development and invest in the tools and infrastructure that will power a cloud model most effectively.

The move to cloud will certainly not be easy, but it’s worth the time, effort and frustrations that may lie ahead. We’re here to help ease the transition. We’re ready and available to help your team transition to Agile or improve their current Agile implementation, ahead of a cloud-based move. Prepare your organization for the future or risk being left behind!


Mike Harris
DCG President


Written by Michael D. Harris at 05:00

Mckinsey Findings Support Value of Agile - But More is Needed

MikeWe are always on the lookout for industry data to support or refute our views on Agile (see the Trusted Advisor report, "Data to Suggest That Agile Has Had A Positive Impact on Performance"). In this case, it was pleasing to see supportive data in a recent report from McKinsey, “How winning banks refocus their IT budgets for digital.”

One such finding revealed in the article is that “high-capability” banks tend to spend less on day-to-day IT operations; in fact, McKinsey found that, for application development, the capabilities most related to lower spending were:

  • Effective demand management
  • Centralized application-architecture governance
  • Use of Agile software development

The report states that, on average, banks with self-assessed high capabilities in these areas devote only 3.5 percent of the bank’s total expenses to application development, while banks with lower capabilities allocate as much as 8.2 percent of expenses to the area. What’s more, this difference in spending is not attributable to the elimination of discretionary projects. Mckinsey found that banks with high capabilities in areas related to application development, on average, manage to invest 62 percent of their application-development spending on customer-facing applications, compared with only 47 percent for banks with lower capabilities.

It’s an interesting report and I believe that these findings are applicable to other industries.  Of course, the three critical capabilities taken together amount to more than just Scrum.  Do you think that your organization can claim high capabilities in these areas?  What challenges do you see?

Mike Harris
DCG President

Written by Michael D. Harris at 05:00
Categories :

Enhancing the Efficiency and Effectiveness of Application Development

Along with some of our regular readers, I was delighted and slightly surprised to see that an article with the above title (see reference information and link at the bottom of this post) made it to #1 on McKinsey’s list of the most popular articles with readers of its website in the third quarter of 2013.

Of course, there is nothing new in the article (at least we don’t think so at DCG), but the authors draw a bold conclusion from their research into the best productivity metric to use for application development:

“Although all output-based metrics have their pros and cons and can be challenging to implement, we believe the best solution to this problem is to combine use cases (UCs)—a method for gathering requirements for application-development projects—with use-case points (UCPs), an output metric that captures the amount of software functionality delivered.”

Now, here at DCG, we are interested in helping our clients improve their metrics (or even to begin their own metrics practice). Hence, we adopt a pretty broad philosophical approach to where our clients are today on the maturity curve and where they should realistically aim to be in the near future.  Hence,

  • We greatly prefer any well-defined software size metric over no software size metric.
  • We greatly prefer UCPs over lines of code (LOCs). 
  • We marginally prefer UCPs over size metrics that have been designed internally by one organization. 
  • We prefer function points over UCPs.

The main challenge with UCPs is that there is no standard way to count them, so they are quite prone to the implementation in one organization and the discipline the organization applies to consistency of counting.  “Consistency” of sizing is the foundation of any software metrics. If you use a sizing metric that does not come with a history and methodology that reinforces consistency, then it can and will undermine your results and decision making. This becomes an issue when the organization comes to use the productivity metrics by comparing different parts of the organization against each other, and most organizations usually want to benchmark themselves against other organizations.  None of this can be done reliably with UCPs.

McKinsey Sizing Comparison ChartTo give the authors their due, the well–researched chart that they include in a side bar in their article (reproduced above) highlights this problem in the “credibility” line. In producing their recommendation, it seems that they have not given this line of their analysis as much weight as other lines. Indeed, I would argue that the “minimal overhead in calculating” assessment is based on out-of-date information so far as function points are concerned, but, in any case, the effort saved is surely wasted if the results are not credible.

Source: McKinsey & Company, “Enhancing the Efficiency and Effectiveness of Application Development,” Michael Huskins, James Kaplan, Krish Krishnakanthan, August 2013.

Written by Michael D. Harris at 05:00
Categories :

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!