The growth of the cloud computing industry continues to amaze. According to the gurus, we are still looking at annual global growth rates between 18% and 25%. Every new generation of people entering the world's workplaces right now uses the cloud and sees it as obvious, familiar, natural and safe. Cloud computing seems more of a long-term spike, than a mere trend.
It can cost almost nothing for a business to get started with cloud computing. Attractively- priced, feature-rich Starter Packages abound, yet they offer state of the art technologies that could, within a matter of days, expand to provide global capabilities. No wonder they are in demand.
In some ways, the cloud computing Starter Package shows how the cloud industry has grown from being ultra-specialist to mass-market – all in a few short years.
Cloud computing offers so many opportunities, services, features and benefits that specialist consultants are usually required to help organizations navigate the choices and make sound business decisions. Too much complexity and the need for specialist expertise is not good. It slows down business decision-making. It can lead to over-caution and hesitancy. These things do not promote a positive corporate culture. They are also not good for business efficiency and effectiveness.
Despite cloud computing Starter Packages costing from next-to-nothing, costs can still be a problem. With the price of many offerings starting as free trials at zero cost and progressing up to just a few dollars a month, the number of people within an organization, even within teams, able to trial, buy and upgrade services is exploding. The range of individually-priced services and pricing options is now so vast that navigating, evaluating and managing them has become a new challenge for the accountants.
The whole discipline of managing costs now needs to be upgraded as a skill within the IT department and incorporated more as an ongoing function within development teams. Tremendous opportunities, indeed, but with challenges which need addressing.
Finance and IT As Best Buddies?
Cloud computing was always, perhaps, a purely financial decision. And so the functions of financial management, planning, estimating, costing, accounting and cost-control are moving from finance department into the IT department. More financially-savvy people are working more closely, on a day-to-day basis, with development teams than ever before.
So maybe we should have a more structured way of helping the two work better together? Maybe IT methodologies need to be adapted to include more reference to finance.
The Agile Manifesto, published in 2001 proposed that the "highest priority is to satisfy the customer" but did not mention finance, budgets or efficiency. It did make the crucial point that business people and developers "must work together daily" throughout a project.
This was an inspired insight. Note "daily". It was an incredibly important step and the one that is perhaps the biggest single idea for any new methodology for the cloud computing era. We need to grab hold of that idea. And we think it should also explicitly include finance people, not just business people.
Cloud computing opens up the possibility of an entirely revenue-based IT budget. If infrastructure can be kicked-in and scaled up as demand and revenue grows, maybe the same financial methodology which drives those decisions can be applied to development resource?
Why does IT still labor under the pressure to prove its value? No one in an e-commerce firm ever asks the value of IT. Because it is innate. IT makes revenue. In e-commerce firms, IT tends to be closer to the financials, which matter to the business.
Was Agile Too Soft?
When the original Scrum idea was floated in 1986 the authors discussed how to control projects using "subtle control" and the surprising phrase "control by love". They did not cite financial or economic control as part of what was needed to control projects. Of the seven ways in which control should be exercised, according to the authors, including listening and tolerating mistakes, not one mentioned cash or budget.
The authors of Scrum almost seemed to deny the importance of financial or commercial control. They noted some significant built-in limitations with Scrum but they didn't acknowledge these as critical failures. They saw that the Scrum approach required "extraordinary effort" resulting in "monthly overtime of 100 hours" at peak times and a mere "60 hours during the rest of the project".
In their enthusiasm for collaboration and autonomy, and subtle rather than overt control, it appears that the authors just pushed many financial concerns like "extraordinary effort" and 25 hours overtime each week, to one side. Surely these were major problems, not footnotes?
The Event-Driven Approach Embraces Finance
Imagine a small dev team on a new project. They need development skills, a goal, a web browser and a credit card to get started. They would go straight to a cloud starter package, sign in and pay up to start development.
One of the very first things that they do is make some financial decisions and then a financial transaction.
The same people who develop the service, make the initial financial decisions. For them, the development methodology already has finance built in. It is innate.
It appears to contrast with the majority of Agile methodologies and their focus on teams and control by love. You can see how teams comfortable with this approach will also be comfortable with the Event-Driven Software Development methodology approach from one of China's great e-commerce companies, Secoo.
It's very different. The EDSD methodology leads with the idea that the first aspect of an EDSD project is event objectives, such as sales. It then asks if profit, growth, new user registration or brand recognition should also be clearly defined as event objectives.
Without any hesitation, EDSD piles right in with the bluntest possible language to financial outcomes, business outcomes and value creation. Money and finance. The perfect language for the cloud computing era.
According to the Scrum Alliance, almost half of organizations who have adopted Scrum cite the need to align with the strategic and financial goals of the company as a whole. We already see alignment with finance and business goals with the EDSD methodology.
Adapting Agile
Maybe we need some more serious new adaptions of Agile to make it more financially savvy.
One thing to look at in these future methodologies is the opportunity to agree a single, simple, universal measure which can be applied to any project within an organization to show its value. Idealistic, yes, but not impossible.
Such a measure allows senior management to compare the outcomes of a new building, a new hire, closing a plant or building a new software system, buying IT infrastructure or relocating a development team. This is the language of Internal Rate of Return, Return on Investment and Net Present Value, a set of practical and widely-understood universal measures.
With cloud computing starter packages, you can buy and provision servers within minutes of needing them. This gets accountants excited. In certain situations, the cloud services can even provision computing instances themselves as the load requires. This gets the accountants even more excited. They can see very clearly how IT costs can be linked directly to revenue, or transactions, or other direct measures of customer activity.
And then comes the obvious next question from the accountants: if we can link hardware and infrastructure expense to business outcomes, could we link all IT expenses to business outcomes? Maybe not at first at a micro level, but on a longer term basis, such as quarterly.
In other words, let us analyze key IT metrics such as storage, network traffic, payment transactions, page visits and app logins over the last quarter and compare to predictions we made for those metrics. Now predict ahead to the next quarter and set a development budget as a function of the cloud spend for that quarter, assess the product backlogs or portfolio priorities and draw a line under anything that we can't afford to do in the next quarter.
So, might the accountants think. The organizations practicing Zero Based Budgeting are well down the track with these questions. Are we ready to cope with this conversation?
IT always needs to find better ways to prove its value to the business, and the rise of the cloud computing Starter Package has been one of many prompts for us to look again at a more financially-driven development methodology. Maybe as a shorthand, we should use a phrase like "Financial Agile", "Scrum-F" or "Cloud Scrum" to develop the ideas around a more business-like methodology for the cloud computing era.
We need to talk about this stuff as a more everyday part of our software methodologies. If we don't press ahead and create Scrum-F, Financial Agile or Cloud Scrum methodologies, then the accountants might just do it for us.
