SPaMCAST 768 – Teams, SaaS, Entrepreneurship, A Conversation with Phil Alves

The Software Process and Measurement Cast 768 features our interview with Phil Alves, CEO of DevSquad. Phil and I covered a wide range of topics starting with how he structures teams to perform in dynamic environments and culminating in a discussion of SaaS and entrepreneurship. Software development of any stripe is a team sport; either get it right or suffer the consequences. 

Phil describes himself as a SaaS Aficionado! 

He builds products for bootstrapped founders, fast-growing startups, and big enterprises at DevSquad.

His SaaS company, DevStats, helps product and engineering leaders measure what matters.

Phil also is a podcaster!  The SaaS Origin Stories Podcast uncovers those pivotal moments and decisions that turned SaaS companies into major successes.

Contact Information

DevSquad: 𝒉𝒕𝒕𝒑://𝒅𝒆𝒗𝒔𝒒𝒖𝒂𝒅.𝒄𝒐𝒎/

DevStats: 𝐡𝐭𝐭𝐩𝐬://𝐝𝐞𝐯𝐬𝐭𝐚𝐭𝐬.𝐜𝐨𝐦/

Podcast: 𝒉𝒕𝒕𝒑𝒔://𝒘𝒘𝒘.𝒔𝒂𝒂𝒔𝒐𝒓𝒊𝒈𝒊𝒏𝒔𝒕𝒐𝒓𝒊𝒆𝒔.𝒄𝒐𝒎/𝒔𝒖𝒃𝒔𝒄𝒓𝒊𝒃𝒆 

 

SPaMCAST 724 – Taming SaaS Spend, A Conversation With Indus Khaitan

Play Now!

This week we feature an interview with Indus Khaitan, Founder & CEO at Quolum. A few of the topics covered include: 

• Why do organizations need help in consuming SaaS at scale efficiently?
• How can looking carefully at how you are using SaaS save organizations tons of money? 
• How can organizations refocus on delivering value rather than on overhead?
• What does it take to take a vision and make it a going concern more than once?

 

SPaMCAST 662 – Backing Up SaaS Application, Risk Mitigation, An Interview with Mike Potter

In this week’s podcast, we speak with Mike Potter, CEO of Rewind.  Mike and I talk about the need to backup SaaS applications, remote and hybrid working, and entrepreneurship. This interview opened my eyes to the risks we all face by trusting SaaS application companies to back up our data. Mike also highlights in his answers how humanity in the workplace can help create special results.  

 

Agile Where Agile Fears to Tread: SaaS

The Software Is In The Clouds!

Software as a service (SaaS) is one of the most significant trends of the early 21st Century. SaaS is a scenario in which a person or organization access a piece centrally-hosted software. You use the software as long as you want, you don’t need the infrastructure to host the software and you don’t have to worry about dealing with the code. The organization using SaaS solutions needs to configure the software, manage the data, code and integrate organization-specific solutions outside of the SaaS package and manage internal uses. Significant SaaS solutions rarely are “plug and play”. Even straightforward SaaS solutions, such as Slack, often need administration and support inside the organization. Large SaaS packages, such as Workday, need teams to support, configure and administer the implementation. Some organizations using SaaS solutions to meet their information technology needs find it difficult to leverage agile, however with an agile mindset and a flexible approach agile is extremely useful in a SaaS environment. 

 

Agile Where Agile Fears to Tread

 

 

Fitting agile to fit the picture.

 

In 1516, a few weeks before the modern project management and agile, a Bavarian nobleman enacted the Reinheitsgebot (German Beer Purity Law).  The law defined the ingredients in beer. Water, hops, and barley were one true set of ingredients. There are those inside and outside the agile movement that want to set and enforce similar purity laws. For some, agile is Scrum, Extreme Programming, SAFe, or Kanban. The argument is that you need to pick one but never combine approaches to address your specific culture or scenario. Combining frameworks is a bridge too far. Requiring framework or technique purity is s false requirement is often used to suggest that agile concepts and techniques can’t be applied in certain situations. These are five scenarios are often used as examples where agile is difficult or daren’t go:

1. Mainframe Development and Enhancements,
2. Maintenance,
3. Commercial Off The Shelf Packages (COTS),
4. Software as a Service (SaaS), and
5. Outsourced (Contract) Work.

 

Technical Debt: Transference?

A dark alley…

If someone were to approach you on a dark and stormy night as you stood below an underpowered streetlight and ask if you wanted some “technical debt,” I am sure answer would be an emphatic NO. While there are reasons we would intentionally accept technical debt, any development or support team would be better off if they could avoid being shouldered with it.  One strategy to get rid of it is to transfer the ownership of technical debt onto someone else.  Buying packaged software can do this – COTS (commercial off the shelf software) or SAAS (software as a service) can be used as a strategy to avoid owning technical debt.

When an organization buys a supported package or purchases SAAS, they avoid developing specific software development experience (who wants to code an accounting package if you can buy it), shortening the time needed to move from needs-recognition to using the software and avoiding maintaining a staff to maintain the software. In short, the day-to-day management of technical debt becomes someone else’s problem . . . sort of.  One of the laws of software (or at least should be) is that all software includes accrued technical debt. Some portion of the cost initial and annual support or subscription cost of the software pays for the management and maintenance of the software technical debt.

Most software companies do not explicitly publish measures of technical debt in their software, therefore as a user of the software you are more or less blind to level of the technical debt in the package. Why does it matter?  The level of technical debt can still affect your organization even when you don’t “own” the debt. Technical debt in COTS or SAAS impacts the ease of installation, ease of interfacing with your legacy systems, support costs, the existence of latent defects, and maybe most importantly, function agility.  Function agility represents how quickly new features and functions can be rolled into the software.  The longer it takes to develop and integrate new features, the lower the function agility of a software package. The level of technical debt in a package or in SAAS can only be inferred by observing these areas of performance. Review performance in these areas when you are doing your due diligence, and remember that since technical debt tends to build up, performance generally gets worse before it gets better.  And of course, changing software packages is very similar to trying to switch horses while riding (only done by trained stuntmen in the movies, not in real life). So, try to get it right the first time.

A simple cost analysis for determining whether to shoulder the technical debt or to transfer it elsewhere would use the following criteria (assuming the original build/buy decision has been made).

Costs to internally own the technical debt:

1. Support Staff Costs                            _____
2. Support Staff Overhead                    _____
3. Support Staff Tools                            _____
4. Support Staff Training                      _____

A. Total Costs                                              _____

Costs of someone else owning the technical debt:

1. Support Cost/Subscription Cost   _____
2. Support Staff Costs                            _____
3. Support Staff Overhead                    _____
4. Support Staff Tools                            _____
5. Support Staff Training                      _____

B. Total Costs                                                      _____

Net                   Cost        (A – B)                         _____

This is a relatively simple view of the support costs. You should note that there will more than likely be some residual support staff costs needed to interface the new package with legacy systems or just to act as a help desk to initially triage problems. Intangibles, some of which are affected by technical debt such as function agility, will need to be factored into the decision process.

Transferring the servicing and management of technical debt of software by buying packages or using SAAS can make sense.  In many cases COTS and SAAS can reduce amount organizations spend on support and maintenance, including technical debt.  A cost benefit analysis can easily be done to verify whether this is true.  What is less obvious is whether the software’s owner will manage the level of technical debt well. If technical debt is managed poorly, the ability of the package to keep pace with the necessary functionally may suffer. Caveat emptor: do your due diligence and look before you leap.