Business colleagues working in team

A Small External Enterprise Development Team is Cheaper than Your Own

Business colleagues working in team

Time is money in the application development business. We have to get to market sooner so someone else does not gazump us, and pip us at the post. We increase the likelihood of this with every delay. Moreover, the longer your in-house team takes to get you through the swamp, the higher the project cost to you.

Of course, in theory this should not be the case. Why bring in a team from outside, and pay more to support their corporate structure? Even going for a contract micro team ought not to make financial sense, because we have to fund their mark-up and their profit taking. Our common sense tells us that this is crazy. But, hold that thought for a minute. What would you say if a small external enterprise development team was actually cheaper? To achieve that, they would have to work faster too.

The Case Against Having Your Own Internal Enterprise Development Team

Even if you were able to keep your own team fully occupied – which is unlikely in the long term – having your own digital talent pool works out expensive when you factor in the total cost. Your difficulties begin with the hiring process, especially if you do not fully understand the project topic, and have to subcontract the hiring task.

If you decide to attempt this yourself, your learning curve could push out the project completion date. Whichever way you decide to go, you are up for paying advertising, orientation training, technical upskilling, travel expenses, and salaries all of which are going to rob your time. Moreover, a wrong recruitment decision would cost three times the new employee’s annual salary, and there is no sign of that changing.

But that is not all, not all by far. If want your in-house team to keep their work files in the office, then you are going to have to buy them laptops, plus extra screens so they can keep track of what they are doing. Those laptops are going to need desks, and those employees, chairs to sit in. Plus, you are going to need expensive workspace with good security for your team’s base.

If we really wanted to lay it on, we would add software / cloud costs, telephony, internet access, and ongoing technical training to the growing pile. We did a quick scan on PayScale. The median salary of a computer programmer in Ireland is €38,000 per year and that is just the beginning. If you need a program manager for your computer software, their salary will be almost double that at €65,000 annually.

The Case for a Small External Enterprise Development Team

The case for a small externally sourced enterprise development team revolves around the opportunity cost – or loss to put in bluntly – of hiring your own specialist staff for projects. If you own a smaller business with up to 100 people, you are going to have to find work for idle digital fingers, after you roll out your in-house enterprise project. If you do not, you head down the road towards owning a dysfunctional team lacking a core, shared objective to drive them forward.

Compared to this potential extravagance, hiring a small external enterprise development team on an as-needed basis makes far more sense. Using a good service provider as a ‘convenience store’ drives enterprise development costs down through the floor, relative to having your own permanent team. Moreover, the major savings that arise are in your hands and free to deploy as opportunities arise. A successful business is quick and nimble, with cash flow on tap for R & D.

Using Pull Systems to Optimise Work Flows in Call Centres

[vc_row][vc_column][vc_column_text]When call centres emerged towards the end of the 20th century, they deserved their name ‘the sweatshops of the nineties’. A new brand of low-paid workers crammed into tiny cubicles to interact with consumers who were still trying to understand the system. Supervisors followed ‘scientific management’ principles aimed at maximising call-agent activity. When there was sudden surge in incoming calls, systems and customer care fell over.

The flow is nowadays in the opposite direction. Systems borrowed from manufacturing like Kanban, Pull, and Levelling are in place enabling a more customer-oriented approach. In this short article, our focus is on Pull Systems. We discuss what are they, and how they can make modern call centres even better for both sets of stakeholders.

Pull Systems from a Manufacturing Perspective

Manufacturing has traditionally been push-based. Sums are done, demand predicted, raw materials ordered and the machines turned on. Manufacturers send out representatives to obtain orders and push out stock. If the sums turn out wrong inventories rise, and stock holding costs increase. The consumer is on the receiving end again and the accountant is irritable all day long.

Just-in-time thinking has evolved a pull-based approach to manufacturing. This limits inventories to anticipated demand in the time it takes to manufacture more, plus a cushion as a trigger. When the cushion is gone, demand-pull spurs the factory into action. This approach brings us closer to only making what we can sell. The consumer benefits from a lower price and the accountant smiles again.

Are Pull Systems Possible in Dual Call Centres

There are many comments in the public domain regarding the practicality of using lean pull systems to regulate call centre workflow. Critics point to the practical impossibility of limiting the number of incoming callers. They believe a call centre must answer all inbound calls within a target period, or lose its clients to the competition.

In this world-view customers are often the losers. At peak times, operators can seem keen to shrug them off with canned answers. When things are quiet, they languidly explain things to keep their occupancy levels high. But this is not the end of the discussion, because modern call centres do more than just take inbound calls.

Using the Pull System Approach in Dual Call Centres

Most call centre support-desks originally focused are handling technical queries on behalf of a number of clients. When these clients’ customers called in, their staff used operator’s guides to help them answer specific queries. Financial models determined staffing levels and the number of ‘man-hours’ available daily. Using a manufacturing analogy, they used a push-approach to decide the amount of effort they were going to put out, and that is where they planted their standard.

Since these early 1990 days, advanced telephony on the internet has empowered call centres to provide additional remote services in any country with these networks. They have added sales and marketing to their business models, and increased their revenue through commissions. They have control over activity levels in this part of their business. They have the power to decide how many calls they are going to make, and within reason when they are going to make them.

This dichotomy of being passive regarding incoming traffic on the one hand, and having active control over outgoing calls on the other, opens up the possibility of a partly pull-based lean approach to call centre operation. In this model, a switching mechanism moves dual trained operators between call centre duties and marketing activities, as required by the volume of call centre traffic, thus making a pull system viable in dual call centres.[/vc_column_text][/vc_column][/vc_row]

How DevOps Oils the Value Chain

DevOps – a clipped compound of development and operations – is a way of working whereby software developers are in a team with project beneficiaries. A client centred approach extends the project plan to include the life cycle of the product or service, for which the software is developed.

We can then no longer speak of a software project for say Joe’s Accounting App. The software has no intrinsic value of its own. It follows that the software engineers are building an accounting app product. This is a small, crucially important distinction, because they are no longer in a silo with different business interests.

To take the analogy further, the developers are no longer contractors possibly trying to stretch out the process. They are members of Joe’s accounting company, and they are just as keen to get to market fast as Joe is to start earning income. DevOps uses this synergy to achieve the overarching business goal.

A Brief Introduction to OpsDev

You can skip this section if you already read this article. If not then you need to know that DevOps is a culture, not a working method. The three ‘members’ are the software developers, the beneficiaries, and a quality control mechanism. The developers break their task into smaller chunks instead of releasing the code to quality control as a single batch. As a result, the review process happens contiguously along these simplified lines.

CodeQCTest
CodeQCTest
CodeQCTest
CodeQCTest
Colour KeyDevelopersQuality ControlBeneficiary

 

This is a marked improvement over the previously cumbersome method below.

Write the CodeTest the CodeUse the Code
Evaluate, Schedule for Next Review

 

Working quickly and releasing smaller amounts of code means the OpsDev team learns quickly from mistakes, and should come to product release ahead of any competitor using the older, more linear method. The shared method of working releases huge resources in terms of user experience and in-line QC practices. Instead of being in a silo working on its own, development finds it has a richer brief and more support from being ‘on the same side of the organization’.

The Key Role that Application Program Interfaces Play

Application Program Interfaces, or API’s for short, are building blocks for software applications. Using proprietary software-bridges speeds this process up. A good example would be the PayPal applications that we find on so many websites today. API’s are not just for commercial sites, and they can reduce costs and improve efficiency considerably.

The following diagram courtesy of TIBCO illustrates how second-party applications integrate with PayPal architecture via an API façade.

Working quickly and releasing smaller amounts of code means the OpsDev team learns quickly from mistakes, and should come to product release ahead of any competitor using the older, more linear method. The shared method of working releases huge resources in terms of user experience and in-line QC practices. Instead of being in a silo working on its own, development finds it has a richer brief and more support from being ‘on the same side of the organization’.

imgd2.jpg

 

The DevOps Revolution Continues …

We close with some important insights from an interview with Jim Stoneham. He was general manager of the Yahoo Communities business unit, at the time Flickr became a part. “Flickr was a codebase,” Jim recalls, “that evolved to operate at high scale over 7 years – and continuing to scale while adding and refining features was no small challenge. During this transition, it was a huge advantage that there was such an integrated dev and ops team”

The ‘maturity model’ as engineers refer to DevOps status currently, enables developers to learn faster, and deploy upgrades ahead of their competitors. This means the client reaches and exceeds break-even sooner. DevOps lubricates the value chain so companies add value to a product faster. One reason it worked so well with Flickr, was the immense trust between Dev and Ops, and that is a lesson we should learn.

“We transformed from a team of employees to a team of owners. When you move at that speed, and are looking at the numbers and the results daily, your investment level radically changes. This just can’t happen in teams that release quarterly, and it’s difficult even with monthly cycles.” (Jim Stoneham)

Why DevOps Matters: Things You Need to Know

DevOps creates an agile relationship between system development and operating departments, so the two collaborate in providing results that are technically effective, and work well for customers and users. This is an improvement over the traditional model where development delivers a complete design – and then spends weeks and even months afterwards, fixing client side problems that should never have occurred.
Writing for Tech Radar Nigel Wilson explains why it is important to roll out innovation quickly to leverage advantage. This implies the need for a flexible organisation capable of thinking on its feet and forming matrix-based project teams to ensure that development is reliable and cost effective.
Skirmishes in Boardrooms
This cooperative approach runs counter to traditional silo thinking, where Operations does not understand Development, while Development treats the former as problem children. This is a natural outcome of team-centred psychology. It is also the reason why different functions pull up drawbridges at the entrance to their silos. This situation needs managing before it corrodes organization effectiveness. DevOps aims to cut through this spider web of conflict and produce faster results.

The Seeds of Collaboration
Social and personal relationships work best when the strengths of each party compensate the deficiencies of the other. In the case of development and operations, development lacks full understanding of the daily practicalities operating staff face. Conversely, operations lacks – and should lack knowledge of the nuances of digital automation, for the very reason it is not their business.
DevOps straddles the gap between these silos by building bridges towards a co-operative way of thinking, in which matrix-teams work together to define a problem, translate it into needs and spec the system to resolve these. It is more a culture than a method. Behavioural change naturally leads to contiguous delivery and ongoing deployment. Needless to say only the very best need apply for the roles of client representative, functional tester and developer lead.

Is DevOps Worth the Pain of Change?
Breaking down silos encroaches on individual managers’ turf. We should only automate to improve quality and save money. These savings often distil into organizational change. The matrix team may find itself in the middle of a catfight. Despite the pain associated with change resistance, DevOps more than pays its way in terms of benefits gained. We close by considering what these advantages are.

An Agile Matrix Structure – Technical innovation is happening at a blistering rate. The IT industry can no longer afford to churn out inferior designs that take longer to fix than to create. We cannot afford to allow office politics to stand in the way of progress. Silos and team builds are custodians of routine and that does not sit well with development.

An Integrated Organization – DevOps not only delivers operational systems faster through contiguous testing. It also creates an environment whereby cross-border teams work together towards achieving a shared objective. When development understands the challenges that operations faces – and operations understands the technical limiters – a new perspective emerges of ‘we are in this together’.

The Final Word – With understanding of human dynamics pocketed, a DevOps project may be easier to commission than you first think. The traditional way of doing development – and the waterfall delivery at the end is akin to a two-phase production line, in which liaison is the weakest link and loss of quality inevitable.

DevOps avoids this risk by having parties work side-by-side. We need them both to produce the desired results. This is least until robotics takes over and there is no longer a human element in play.

How DevOps Could Change Your Business

Henry Ford turned the U.S. auto industry on its head when he introduced the idea of prefabricating components at remote sites, and then putting them together on a production line. Despite many industries following suit, software lagged behind until 2008, when Andrew Clay Shafer and Patrick Debois told the Agile Conference there was a better way to develop code:
– Write the Code
– Test the Code
– Use the Code
– Evaluate, Schedule for Next Review

The term ‘DevOps’ is short for Development and Operations. It first appeared in Belgium, where developers refined Shafer and Depois’ ideas. Since then, DevOps became a counter movement against the belief that software development is a linear process and has largely overwhelmed it.

DevOps – A Better Way
DevOps emerged at an exciting time in the IT industry, with new technology benefiting from a faster internet. However, the 2008 world recession was also beginning to bite. Developers scampered to lower their human resource costs and get to market sooner.
The DevOps method enabled them to colloborate across organizational boundaries and work together to write, quality assure and performance test each piece of code produced in parallel.
DevOps’ greater time-efficiency got them to market sooner and helped them steal a march on the competition.

There are many advantages to DevOps when we work in this collaborative way. Cooperation improves relationships between developers, quality assurers and end users. This helps ensure a better understanding of the other drivers and a more time-effective product.

Summary of DevOps Objectives
DevOps spans the entire delivery pipeline, and increases the frequency with which progress is reviewed, and updates are deployed. The benefits of this include:
• Faster time to market and implementation

• Lower failure rate of new releases

• Shortened lead time for bug fixes and updates

The Psycho-Social Implications of DevOps
DevOps drills through organization borders and traditional work roles. Participants must welcome change and take on board new skills. Its interdepartmental approach requires closer collaboration across structural boundaries and greater focus on overarching business goals.

Outsourcing the detail to freelancers on the Internet adds a further layer of opportunity. Cultures and time zones vary, requiring advanced project management skills. Although cloud-based project management software provides adequate tools, it needs an astute mind to build teams that are never going to meet.

The DevOps movement is thus primarily a culture changer, where parties to a project accept the good intentions of their collaborators, while perhaps tactfully proposing alternatives. There is more to accepting a culture than using a new tool. We have to blend different ways of thinking together. We conclude by discussing three different methods to achieve this.

Three Ways to Deploy DevOps in your Organization
If you foresee regular DevOps-based projects, consider running your entire organization through an awareness program to redirect thinking. This will help non-participants understand why DevOps members may be ‘off limits’ when they are occupied with project work. Outsourcing tasks to contracting freelancers can mitigate this effect.

There are three implementation models associated with DevOps although these are not mutually exclusive.

• Use systems thinking. Adopt DevOps as company culture and apply it to every change regardless of whether the process is digital, or not

• Drive the process via increased understanding and feedback from key receivers. Allow this to auto-generate participative DevOps projects

• Adopt a continuous improvement culture. DevOps is not only for mega upgrades. Feedback between role players is paramount for success everywhere we go.

You can use the DevOps concept everywhere you go and whenever you need a bridge to better understanding of new ideas. We diminish DevOps when we restrict its usefulness to the vital role it plays in software development. The philosophy behind it belongs in every business.