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

DevOps: Success Based on Collaboration

Organizations are seeking faster releases, cloud capabilities, reduced time to customer feedback and – most importantly – the ability to more quickly capture market opportunities. As a result, DevOps (a word derived from “development” and “operations”) is going mainstream.

Previously a niche strategy, DevOps is growing in popularity, partly as a way to address the changing priorities of the organization, but also due to the rising popularity of Agile development. DevOps is based on Agile and lean principles, making it easier to implement once an organization has committed to Agile (as many have).

The key to DevOps is collaboration amongst most, if not all, of the organization – the business owners, development, operations and quality assurance. The goal is continuous software delivery. The collaborative aspect of DevOps is important – and it can determine success or failure. Such collaboration typically requires a cultural shift in an organization, something most organizations find challenging – and it doesn’t happen overnight. But once all the people involved in the process are invested, the result is more efficient processes, happier customers and improved profits.

The quickest path to understanding DevOps at a basic level, is with the graphic below.

 DevOps Description

Source: “DevOps: Breaking Barriers to Benefit Bottom Lines,” IEEE Magazine, April 2015

If your organization is considering DevOps, we suggest starting with Agile – whether it’s a first-time implementation or a tune-up to make sure that you’re running Agile as it is meant to be. We can help with that. Regardless, it’s becoming more and more obvious that IT is no longer an isolated entity within an organization; it is increasingly relying on collaboration with other stakeholders. If your team is set apart from the rest of the organization, it’s time to break free and seek out opportunities to work together for the benefit of all involved.

For a more in-depth look at DevOps, read “DevOps: Breaking Barriers to Benefit Bottom Lines,” in the April 2015 edition of IEEE Magazine.


Mike Harris

Written by Michael D. Harris at 05:00

Agile and Risk Management

We're still ruminating over everything we discovered in Seattle last month at the CMMI Global Congress. One thing we are happy to have taken away from the conference is that CMMI adoption seems to be growing - across organizations and across industries. 

We believe this is partly because people are realizing the power of the CMMI model. Why is it powerful? The CMMI is unique in its ability to combine with other methods and techniques, such as lean and Agile, for maximum impact.

A good example of this is in Tom Cagley's presentation from the conference, Agile Risk Management. The presentation discusses how you can combine Agile and CMMI techniques for a more effective software development process and to mitigate risk. You can download the presentation here.

If you have questions or comments, please reach out to Tom via email or Twitter (@TCagley)!

And if you've implemented CMMI in conjunction with other frameworks, we'd love to hear about it - please share in the comments or send us an email! More information about our CMMI services is available here.

Written by Default at 05:00
Categories :

The Scaled Agile Checklist

ChecklistJust because Agile is working well in one part of your organization, doesn't mean that it will work well in another. In fact, even though it's becoming increasingly popular to scale Agile, it's not always the right choice. How do you make that decision for your organization?

We can help. When it comes to scaling Agile, we're proponents of the Scaled Agile Framework® (SAFe™), a proven method for implementing Agile across an organization. But, SAFe won't work if your organization doesn't have a few key things in place.

Download our checklist to see if you have the 10 must-have items for a successful SAFe implementation.

Download Now.

Written by Default at 05:00
Categories :

Adopting the Agile Manifesto for Business Transformation

Alan CameronI’ve been looking at the Agile Manifesto and its “Twelve Principles of Agile Software,” the underpinning of Agile product development, and it struck me that the manifesto and the principles can also be applied to business transformation, where the products are changed business methods.

It’s been reported that effective Agile development works best where the organisation understands the need for effective processes and applies that knowledge throughout the business; so, for me, it follows that there is a need for a recipe that applies Agile principles to business transformation.

So what are the principles that drive an Agile business? I suggest that the Agile Manifesto can only be adopted for business transformation with small changes. Therefore, with due deference to the authors of the original, I have amended the manifesto in a way that can be applied to business transformation, while keeping as much of the original wording as possible.

All the changes I suggest are highlighted below in italics:

We are uncovering better ways of delivering business transformation by doing it and helping others do it. Through this work we have come to value:

           Individuals and interactions over processes and tools

           Working business methods over comprehensive documentation

           Customer collaboration over contract negotiation

           Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The principles can also be suitably amended:

1. Our highest priority is to satisfy the customer through early and continuous delivery of business value.

2. Welcome changing requirements, even late in the transformation journey. Agile processes harness change for the customer's competitive advantage.

3. Deliver working business change frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and change agents* must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a business change team is face-to-face conversation.

7. Working business methods are the primary measure of progress.

8. Agile processes promote sustainable business change. The sponsors, change agents, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to business excellence and best practice enhances agility.

10. Simplicity – the art of maximizing the amount of work not done--is essential.

11. The best business frameworks, requirements, and methods emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

I am convinced that only Agile organisations can make the most of Agile development, and the best way for them to visualise how they will progress is to apply the Agile Manifesto to day-to-day business.


*Change agents are a proxy for the Agile development team and have the same function – but in business terms; that is, they develop and deliver the business change.


Written by Alan Cameron at 05:00
Categories :

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