The Reality:

 

• You are in charge of software development in your organization.
• You have a product development roadmap with hard milestones and critical deadlines that must be met – or else.
• The “or else” is because the software applications you need built are strategic and vital to your business’ ability to move forward as a company and succeed.
• You know from past experience that using Agile as your software development process will allow you to achieve maximum production “velocity” – meaning, you can deliver working software faster to market, faster than the competition, faster to revenue.
• However, to properly implement a high-velocity Agile team you desperately need people – talented, skilled, experienced people to get the work done.

 

The Problem:

 

• The people you need are not readily available, and it’s taking months to fill key open positions.
• Recruiting delays translate directly into missed milestones and deadlines.
• Of the qualified resources who are available, they come at premium salary rates – in most cases over six-figures, and in some cases with non-trivial relocation expenses required.
• At those labor rates, having additional budget to also hire necessary QA/QC people is becoming less and less realistic – as is the case for UI/UX resources.

 

The Result:

 

• You have a partially staffed and overworked team getting further and further behind.
• Your budget is on fumes.
• Key positions are still unable to be filled.
• Milestones and deadlines are being missed, again.
• Existing developers on staff are being pulled away from core new development and being swallowed up with resolving Level-2 and Level-3 service issues (i.e. bug fixes).
• The business is in trouble – release dates get slipped, unhappy customers, morale problems.
• Your CEO is looking for someone to blame and is demanding a credible story to tell the board and investors about how all of this is going to get fixed.

 

Any of that sound familiar?

 

Sadly, this far too common a tale these days in the wonderful world of software development.  But what can you do?

 

Thankfully, there is an answer to that question – a genuinely viable solution to the problem.

 

The solution is to first start by recognizing the futility of trying to build from scratch that which you can readily buy, at a lower cost, with faster velocity to full productivity, that delivers a much higher level of software quality.

 

Sound too good to be true?

 

It’s not.  It’s just a matter of embracing the new reality of how software is predominantly built these days.  For example, are you building a SaaS system?  If so, do you host it yourself, or is it hosted with Amazon (AWS) or Microsoft (Azure) or some other Cloud infrastructure provider?  Because if you do, then you’ve already demonstrated the value in letting a 3^rd-party do something you no longer have to do yourself, and very likely at a much lower cost.

 

Granted, in the old days, you would have likely hosted such an application in your own private data center.  But things have changed.  It takes a lot of justification these days to maintain your own data center in the world of the Cloud.

 

Think about it: If you desire to get a new car, do you go out and get all the parts and build one from scratch?  Or, instead, do you find one you like from a car dealer and simply buy or lease it and immediately start driving it?  The answer is obvious.

 

What isn’t so obvious is that for many software development managers, it’s often difficult to realize that there is more than one way to create the software they are tasked to get built: and that one way isn’t to do it all 100% in-house.

 

Admittedly, in the past, you may have led many very successful software development teams, and built lots of great systems and applications.  But those were the days when top-quality resources weren’t so hard to come by, and weren’t so expensive.  That is what’s different.  If you could readily get all the people you need, at a reasonable price you can afford, then doing it all yourself might still make perfect sense.  But that simply isn’t reality you are currently experiencing first-hand.

 

The good news is that complete Agile teams of any size, or individual team members available to augment existing partially staffed teams, are a little more than a phone call away.  For just as Infrastructure as a Service (IaaS), Platforms as a Service (PaaS), and, of course, Software as a Service (SaaS) are now a readily available commodity services, so is Agile software development.

 

Yes, Agile as a Service (AaaS) exists.

 

With AaaS you define what you need to be done, and what resources are required to get it done.  The AaaS service rapidly staffs all of those resources for you in 30 days or less.  Next, your new AaaS Team Lead, or the most senior AaaS team member if your team lead is already onboard in-house, comes to your location and embeds with your team for a few weeks, or possibly even a month or two.

 

In that embedded time period, through direct onsite immersion learning, your AaaS resource does much more than traditional knowledge transfer.  He/she also assimilates the culture of your organization.  They grasp the vision of your company and the unique perspective of your product roadmap.  What’s more, as a fresh pair of objective eyes with years of experience, this team member can also proactively and creatively contribute ideas to help make the end result that much stronger.

 

Following the immersion period, the AaaS resource joins the rest of the AaaS team to execute the ongoing Agile Sprints.  This team member may also serve as the remote Scrum Master; but even if not, a remote Scrum Master is assigned to work hand-in-hand with your onsite, in-house Product Owner.  Daily standups are conducted between your onsite Product Owner/Scrum Master/Team Lead, as applicable. And at the end of every Sprint is a functional demo.

 

The process works quite well.  And it does so as a fraction of the costs of doing it all yourself.

 

Please note that you only pay for your AaaS team’s monthly fixed rate cost.  There are no billable hours to be tabulated and tracked and endlessly argued over.  In a very practical sense, your AaaS team members are simply your remote dedicated employees.  The difference is, however, you don’t pay these employees any health benefits, taxes, insurance, etc.  You don’t have to provide work space for them, or a computer, or an Internet connection.  All of that comes as part of the very-predictable monthly service rate.

 

Furthermore, if you have an urgent demand for additional resources for specific a window of time, they are easily added quickly, and then easily subtracted when the need is satisfied.  No unpleasant HR issues, no hard feelings.

 

Best of all is the economic model.  AaaS is not limited to finding resources in the US or European markets – which are the most expensive in the world.  To the contrary, resources can be obtained from much lower cost labor markets, in some cases saving as much as 50% over local labor markets.  That means you could potentially get your entire team at half the cost, or get a much larger team than you thought you could afford for the same money.  Yes, that means the QA/QC and UI/UX resources suddenly become much more of a possibility than they are currently.

 

Obvious question: So what’s the difference between AaaS and traditional software development outsourcing that’s been around for decades?

 

Answer: Agile.

 

Traditional software development outsourcing gained a much-deserved bad reputation in many quarters due to a variety of causes – i.e. from language and cultural disconnects, to vast time zone disparities, etc.  But the biggest impediment of all was the traditional Waterfall software development methodology itself.

 

With Waterfall, it’s an all or nothing proposition.  Requirements are gathered, developers code and test, and software is delivered at some distant point in the future, hoping everything is right.  And that was rarely found to be the case.

 

The adverse reaction to outsourced software development over the years was to bring everything back in-house, where managers could keep an eye on development on a daily basis, and seek to avoid all the mistakes and/or miscommunications that could be quickly corrected.  That’s actually very understandable.

 

Thankfully, Agile fixed that.

 

By communicating daily, and demoing working software on a regular basis as part of the development process, both the communications issues and the technical issues are all promptly addressed.

 

The result is that, once more, the value proposition of being able to access more top talent from a global pool, at lower costs, and in most cases, with years of prior Agile experience, means that teams can be assembled and high-quality work engaged very quickly – all very cost-effectively.

 

“But wait a minute!” you think.  “What we are building is so unique and complex that I wouldn’t dare entrust it to any 3^rd-party.”

 

Really?

 

Well, as matter of fact, all those new Agile developers that you are currently trying to hire (and can’t find) for your in-house team are just as ignorant of all your “special secret sauce” as any other human being anywhere on the face of the earth.  All new souls will have just as much of a challenge coming up to speed and being productive as anyone else, regardless of where their desk sits.  By virtue of the Internet, videoconferencing, tools like Slack and Skype, VPN technology for security, etc., everyone that needs to attend a meeting can do so – from anywhere in the world.

 

Sorry, but fears of “Not Invented Here” are no longer a valid excuse for not taking advantage of cost-effective, world-class, global resources.

 

What all this means is that there now exists a good answer for the CEO, the board, and investors.

 

“Boss, we’re going fix all this by implementing Agile as a Service.  We’ll get the exact team we need in 30 days or less, fully staffed, at a substantially lower cost than what we’ve budgeted.  That also means we’ll be able to afford the QC and User Interface people we need.  By doing this we’ll finally be able to get on track and start hitting our milestones.”

 

Isn’t that what you’d like to be able to say?