Blog

By: Mike Pav, VP Engineering, Spanning

This is the third in a series of posts discussing some of our core engineering practices.  In the first, I laid out what our core practices are, and in the second, I talked about releasing early and often.  In this post, I will discuss how we use some Agile practices. You will see that they both support and make possible our “release early and often” approach. I’m not going to talk about estimation specifically in this series (that topic could fill a whole new series).  Instead, I’ll just hand-wave and say that we constantly estimate work effort in terms of our delivery milestones.

From an Agile perspective we do not pay any attention to story points, burndown, velocity or any of those other standard Agile metrics.  It is not that we do not understand them. To the contrary, we have deep experience with formal Agile practices and understand how much value they have brought to software engineering.  But, I consider those Agile metrics as first derivatives of real work rather than a direct measure of real work. Ultimately we focus on the most important thing: how often do we actually ship features to our customers?

Our weekly iteration is not a pure Agile sprint.  We do commit (oops, that implies estimation) to what we will get done, but the objective is to force us – engineers, product owners, everyone – to think about features in terms of demonstrating something more than we did last time, and most importantly, demonstrating it from the customers’ point of view.  We try very hard to avoid building horizontal layers of architecture (persistence, then service, then API, then UI in the last few moments of the release).  Instead, we build vertical slices of a feature and then refactor relentlessly as we learn a little more.  This allows us to commit code to our SCM frequently and to get other engineers consuming that code almost immediately. This is the same way that we approach external releases.  From a feature perspective, we are willing to push ourselves to the point of being uncomfortable with the minimum feature set for a first release.  Over and over we are reminded that all the things that we think are must-have issues for our customers turn out to not really matter when customers vote with their dollars.

We played around with our daily standups in terms of when we held them, what we talked about, how much time we spent on issues, and found that the one thing that significantly improved our standup effectiveness was the actual act of standing up and getting away from our keyboards.  For our team, we don’t wait for the standup to collaborate.  We collaborate all day every day.  Instead, the standup allows us to step back a bit and look at the larger picture of how each person’s work contributes immediately to the whole team moving forward.

The Agile process is a wonderful framework for software engineering, but it’s important to not get so caught up in the process that you stop paying attention to what’s important: releasing features to your customers. At the end of the day, we focus relentlessly on what our customers want and making sure that the work we’re doing is directly tied to real customer feedback.

Stay tuned – in our next post, we’ll discuss how we use hackathons to guide our overall process.

Partners Can Build Profitable Data Protection Businesses Around Google Apps

AUSTIN, TEXAS, May 16, 2013 – Spanning Cloud Apps, Inc., creators of the powerful, enterprise-class data protection solution Spanning Backup for Google Apps, today announced the launch of the Spanning Authorized Resellers Program.  Through the program, partners can now provide their customers the highest-rated, most complete product for protecting Google Apps data, Spanning Backup. The program has been designed to provide value-added resellers (VARs) and system integrators with outstanding margins and recurring revenues, as well as sophisticated marketing and sales support.

Spanning Backup provides backup and recovery of the complete Google Apps suite: Gmail, Drive, Sites, Calendar and Contacts.  The solution features a secure cloud-to-cloud environment for protecting Google Apps data and SSAE 16 Type II audited processes that ensure its integrity.  Spanning also provides constant monitoring of data backup, allowing administrators to correct issues before they become problems.

“We have designed a program that extends the value of reseller services, and brings together the key support pieces for their ongoing success,” said Jeff Erramouspe, chief revenue officer, Spanning. “We’re excited to already be working with leading VARs and system integrators worldwide and look forward to expanding into new relationships.”

“As enterprises encounter obstacles in moving to the cloud, Spanning Backup provides a unique solution that solves the challenges facing our customers in North America, Europe and Asia,” said Doug Shepard, President of the Google Business Unit for Cloud Sherpas, the world’s largest Cloud Services Brokerage and two-time Google Apps Global Partner of the Year.  “We look forward to a successful partnership with Spanning as we integrate their solution into an overall cloud strategy for our clients.”

Spanning is committed to their Google Apps reseller channel; the new program provides resources to ensure that partners receive technical, marketing and sales support.

Key features of the Spanning Authorized Reseller program include:

• An aggressive discount structure with strong margins that gives reseller partners complete control over end-user pricing and a higher average revenue per user (ARPU); potential for increased ARPU by 60-80 percent over selling Google Apps alone
• Lead referral and distribution of new business opportunities
• A simple contracting process to get resellers into the market quickly and efficiently
• Customized marketing programs for specific territories, market segments and business practices, including email marketing, webinars and other co-marketing activities

“We have found Spanning Backup to be an excellent platform for delivering value added services to our clients,” said Rob Morgan, managing director for PIT Group in Wollongong, Australia. “Managing data protection policies isn’t always easy and many of our customers contract with PIT Group to do that for them. The Spanning program gave us the flexibility to bundle our services with Spanning Backup and deliver them both to our clients in one cost-effective package.”

Spanning has partners reselling Spanning Backup around the globe, including in North and South America, Europe, Middle East, Africa, Asia, and Australia/New Zealand.

What Partners Say About Spanning

“I worked with Spanning early in the development of their reseller program.  They were responsive, flexible and built specific items into the program to better accommodate our requirements.  With an already expanding user base using Spanning’s products, I am pleased to represent them in Israel and look forward to a long and fruitful relationship with them.”

-        Amit Dunsky, CEO, high-T, Israel

“At CIMA Solutions Group, we believe that data protection is critical for Google Apps applications.  We’ve seen our customers inadvertently delete data in some cases.  Spanning Backup provides backup and recovery services that work.”

-        Todd R. Brown, VP of sales and business development, Cima Solutions Group, Dallas, TX

“Spanning has created a flexible and easy-to-use reseller program. They offer outstanding margins and top-tier marketing and sales support. Spanning Backup will be a key part of our product offering for a long time to come.”

-        Mike Vanderpool, CEO, Valley Apps, Harrisonburg, VA

Share on Twitter: @spanningbackup launches their targeted reseller channel, available internationally with tools to assist with tech, marketing and sales.

About Spanning Cloud Apps, Inc.

Founded in 2010 and headquartered in Austin, Texas, Spanning was created with a singular purpose – to help companies protect and manage their information in the cloud.  The company provides powerful, reliable, enterprise-class data protection for all Google Apps: Gmail, Drive, Sites, Calendars and Contacts.\

The top-rated backup solution on the Google Apps Marketplace, Spanning Backup is the most reliable and respected cloud-to-cloud backup solution for IT decision-makers.

Join a great team: http://spanning.com/company/jobs/

Save your data from disaster: http://spanning.com/try-it-now/ or Google Apps Marketplace

Get to know us: http://spanning.com/

Follow us on Twitter: @spanningbackup

Eat our favorite food: http://www.chilantrobbq.com

By: Mike Pav, VP Engineering, Spanning

This is the second in a series of posts discussing some of our core engineering practices.  In the first, I laid out what our core practices are, and in this post, I’ll discuss the benefits of shortening our release schedule. Releasing early and often is the most important practice that we follow.  There have been many times where I thought we had a good rhythm going only to see how much better our engineering process was a few months later after increasing our release cadence.

Releasing early and often is the very best way to ensure that we are building things our customers can actually use.  We get quality in our features by using short cycles which force us to continuously explore what is the minimum feature set needed to solve a customer use case.  There is nothing worse (both to Engineering morale and the overall company bottom line) than spending time to build a feature that no one uses. When we release a feature, we get very rapid feedback, which helps influence the next steps that we take.

Additionally, releasing early forces us to think about the implementation in terms of incremental customer exposure so that we build narrow slices of functionality from the customer’s perspective rather than horizontal layers of infrastructure from the engineering perspective.  This has two very solid impacts in terms of quality:

• It forces us to really understand the customer problem from all angles before we start coding, and that deep understanding helps us significantly reduce requirement-level defects, which are the hardest and most expensive to fix.

• It also allows us to watch how our product behaves in production, and when there is an issue, the fix is obvious since very little has changed since our previous production push.

In short, we get quality in terms of our implementation because we have fewer code changes in each release and we get faster feedback on those releases.

Now, the term “release” is used at several different levels.  At the top is the obvious push of code to our production servers for our customers to use, but we also do internal releases for reviews. And finally, we consider a commit into our SCM (Source Code Management tool) to be a release in that the commit has gone through a full test/review cycle and is ready for the rest of the team to consume.  Each of these activities has its own cadence, but the general truism for us is that faster is better.

If you’re working with a long release cycle, consider shortening it to see if the quality of what you’re releasing improves. We’ve done it and couldn’t be happier.

Stay tuned – in our next post we’ll discuss how we’ve adapted Agile processes to work best for us.

By: Mike Pav, VP Engineering, Spanning

When we first set out to build Spanning, we all had a lot of experience building software and we just “knew” that if we could do it “our” way that it would work.  There had to be a better way to build and deliver software, and we were sure that we carried that knowledge.

Now that we are more than 2 years into this journey, I’d like to share a little about what is working for us now as far as our engineering process, and what we have learned along the way.

The key points of our approach are focused on transparency, quality early, and rapid release cycles.  Ultimately, we want to reliably and repeatedly deliver products that delight our customers.  A few points I’ll talk about over the next few posts include:

• Releasing early and often.

• We are Agile influenced, but not dogmatic:

  • We work in weekly iterations

  • We commit on Monday to what we will demo on Friday

  • We do daily standups

  • We work from a single backlog

  • We build teams around features

• Testing is part of the development process, not a secondary effort.  We do not have  a dedicated QA team.

• We run hackathons that push both our technology and our process to see what we should adopt and what we can get by without.

• We use just enough process to stay grounded and have a stable foundation for future growth.

This is just a quick overview of how we work.  It is different enough from other teams that I’ve been a part of that I thought is was worth sharing. I will take you deeper into our engineering process through a series of future posts.  For now, I will caution that these techniques work for Spanning, but they certainly might not apply to everyone. But if you’re frustrated with your engineering process, they might be worth trying.

Stay tuned – in our next post, we’ll discuss how we release early and often.

By: Andrea Bridges-Smith, Content Marketing Manager, Spanning

In a previous post, we discussed why a student might need their data backed up now that more assignments are being completed and submitted via the cloud. If a student works hard on an assignment only to have it lost due to a technical glitch, do they deserve the bad grade that would normally result from not turning something in? Fortunately, backup can render this a moot point. And if students need to have their data backed up (and I think most students who’ve ever lost an assignment online would welcome it), then whose responsibility is it to provide the backup?

Ideally, students would take care of this themselves. Students aren’t generally known for their heavy focus on preparing for future catastrophes though (kindergartners almost never purchase life insurance), and besides, searching for a proper backup solution is probably over most of their heads.

Parents then? Increased parental involvement in their child’s education is always a good thing, and parents should advocate to have their children’s data backed up so that they can focus on getting good grades instead of hunting for things that they may have accidentally deleted. But not every parent is a seasoned IT professional capable of properly evaluating a backup solution. And many of them are running late for soccer practice.

So it falls to the schools then? Well, most schools now have technology systems in place that they require the students to work with. And since they’re providing the framework for the data to live in, it only makes sense that they make sure the data is safe. You see, data loss isn’t just a problem for the students and their GPAs. It’s a problem for teachers, who have to figure out what the plan is when a student comes to them upset about losing something they worked really hard on. It’s a problem for the IT departments who are then going to get the requests from teachers wondering how to get a student’s work back so they don’t have to give a bad grade to a good kid for something that’s maybe not all their fault. It’s a problem for administrators who may have to step in and get involved with these cases and it’s a problem for the parents who may get called in for a conference. It’s a pain in the neck for everyone, and it’s perfectly avoidable with a little bit of backup.

Backing up student work often isn’t on the radar for most schools, and with the long and constantly growing list of needs in education, it’s easy to see why. But now that education is taking place more often in the cloud, schools who are taking advantage of the cloud in the classroom need to know the risks of using it and safeguard against them, not just for their sake but for the sake of their students.