devopsy.kinsta.cloud

Tag: consultant

  • The DevOps Devil is in the RFP Details

    The DevOps Devil is in the RFP Details

    The request for proposal (RFP) process in IT outsourcing is, at its best, a challenging, time-consuming process rife with pitfalls for both customers and outsourcing providers. The process is made even more complicated if customers are unable to provide clear and detailed requirements because of haste or inexperience in software development outsourcing.

    In my work matching companies that need to outsource their software development to international partners, I’ve seen this particular challenge, where less mature customers do not offer potential partners enough of the needed detail in the RFP process for determining an accurate estimate. The question remains, What is the best way to navigate a situation like this?

    There are two key considerations at the very start. First, because IT outsourcing can mean several types of services, including help desk, cloud enablement, network monitoring, etc., outsourcing of custom software development is a type of IT outsourcing that has specific best practices for engagement, methodology and process. Second, I recommend dropping the word “vendor” from your lexicon to refer to a company you hire for custom software development; instead, use the term “partner.” In my experience, treating your software outsourcing partner like a vendor inevitably leads to an adversarial relationship that shuts down creativity and innovation. For software development outsourcing to work, it is absolutely critical to maintain good communication between equal partners. A good working relationship cannot be underappreciated as a key element of success.

    From the provider perspective, there is no ethical way to respond to an RFP that lacks details with an accurate time estimate and cost quote. Any proposal offered should be for a discovery phase, where the service provider uncovers the details the customer is unable to provide on its own. The customer can use the deliverable from a discovery phase to have a more realistic discussion with multiple service providers and receive credible proposals. If the prospective customer is unwilling to pay for the discovery phase or provide the required details, then the service provider should turn down the opportunity.

    From the customer perspective, the answer to the question of how to resolve unclear requirements, then, is to require that the contract governing the relationship be for a dedicated agile development team that can start developing software as the highest priority requirements are defined. The team may grow or shrink over time to accommodate changing priorities, and the release plan can be updated every three or four sprints as you learn more about the requirements and what users want.

    The customer should be prepared to commit contractually to providing a dedicated, easily accessible and available product owner to resolve questions and issues quickly. A “local” product owner can also be on the outsourced team to facilitate communication when developing apps with complex software requirements, but he or she should not be considered a replacement for the customer’s product owner.

    The provider, then, should be prepared to provide at a minimum:

    • Team ramp-up time
    • Monthly rates per developer at various levels of seniority
    • Historical retention or attrition rates of team members
    • References to other customers using similar software technologies and/or domain experiences for what is needed for a particular project
    • For customer experienced with agile development, an estimated velocity of story points per sprint

    An additional challenge from the client perspective is to be able to define the IT outsourcing speed that is needed for the task at hand. The recent concept of two-speed IT defines two kinds of IT software development—slow and fast. Each kind can be outsourced, but with different types of service providers.

    Slow IT outsourcing is most typically used for the careful update of legacy software systems that are changed slowly over months and years to maintain the stability of the business. Fast IT outsourcing is most frequently used for product development and digital transformation and requires an agile approach that includes UX design, user testing, development and DevOps. By recognizing the distinction between fast and slow IT outsourcing speed approaches, you’ll be able to select a partner company with the right experience.

    By abiding by a few key parameters, customers and providers alike can make the RFP process a constructive and productive experience. While it’s true that customers always seek the best possible deal in an outsourcing bid, they don’t always offer the information required during the RFP process to help providers meet their needs. An RFP should be viewed as an opportunity to build a relationship, rather than executing a transaction, and a commitment by both customer and provider to trust and transparency will go a long way toward long-term success.

    About the Author / Steve Mezak

    steve.005Steve Mezak is CEO of Accelerance, a Silicon Valley firm that, since 2001, has matched hundreds of U.S. companies needing software development with international, outsourcing partners. Steve has more than 30 years of experience in the IT industry, from writing software code to facilitating and managing software development teams. He’s authored two books, including most recently, “Outsource or Else! How a VP of Software Saved His Company” (June 1, 2016). Contact Steve by email: steve@accelerance.com; or Twitter: @SteveMezak.

  • DevOps as a Service at base2Services

    DevOps as a Service at base2Services

    Given DevOps’ emphasis on close collaboration, what are we to make of the idea of DevOps as a Service? Aaron Walker, cloud and integration principal at base2Services explains.

    base2Services started as a consultancy service specializing in open source software (especially middleware), but also developed software for its clients. Over time, the pendulum swung towards development, but clients also wanted the company to provide hosting services and ongoing delivery management.

    In the late 2000s, “We gravitated towards cloud because it was a natural fit… we could manage infrastructure as if it were software,” says Walker. “We were a big Agile shop, so it made sense to apply those practices to operations.”

    By 2012 base2Services realized it had built significant capabilities in this area, and so abandoned software development to concentrate on infrastructure management with a focus on ‘infrastructure as code,’ and migrating clients’ systems to the cloud and then providing ongoing management.

    “We don’t do anything that doesn’t have a cloud element,” says Walker, who explains that base2Services can help clients take advantage of the cloud even if they are still using a traditional piece of software.

    Because of the company’s history, “the DevOps thing was something we just did,” says Walker.

    base2Services’ goal is to enable its clients to move more quickly, and it does this by carrying out the tasks that a client is not yet ready for, by working to minimise any gap between its own and the client’s teams, and through skills transfer.

    The company focuses on continuous improvement, and on the development of a continuous integration and delivery environment for the client.

    base2Services’ clients come from a broad range of sectors, says Walker, but especially e-commerce as well as traditional enterprises and government departments that are moving into the cloud. The former “get the fact that they need to be in the cloud,” while “we’re bringing traditional IT departments along on the DevOps story.”

    In some cases, base2Services is brought in to challenge an internal IT team. This makes it important to show “we’re here to help and we’re not there to replicate what they already do,” he says.

    This approach has proved successful in helping other IT organizations become more agile so they can focus on serving their colleagues on the business side through much shorter cycles.

    Physical proximity of development and operations staff tends to be a characteristic of DevOps, and that would seem to work against base2Services’ strategy of providing the Ops part as a service.

    Not so — “We’re very hands on,” says Walker. When working remotely, base2Services staff take advantage of ChatOps and also attend customer standups via Skype or similar technologies.

    “It all depends on the customer and its maturity,” he explains. More maturity means more daily interaction; less maturity means base2Services people are more likely to physically attend the customer’s premises on the days they are required during each sprint. “We’re pretty flexible… we’ll work with customers how they want to work.”

    base2Services customers include fashion e-tailers Cotton On and The Iconic, utility service provider Service Stream, and state government agency Emergency Management Victoria (EMV).

    EMV is “a really great story of DevOps working to deliver a platform very quickly,” says Walker, as the new system had to be deployed between bushfire seasons. Multiple partners were involved in the project, with base2Services providing full automation for the environment, plus ongoing management including the deployment of new features and capabilities. “It wouldn’t have been able to happen so quickly under a normal government structure — they would have still been at the requirements specification stage.”

    The challenge with new customers is that they need to understand that DevOps is a process, Walker explains. “I cringe when I see job ads for a DevOps engineer,” he says. “DevOps is not a person or a set of tools, it’s a culture. You have to facilitate the culture and the processes when introducing it to an organisation, and use DevOps as a guiding principle to get people to work effectively together.”

    Sometimes the customer does not have the right internal structures for the successful adoption of DevOps, in which case base2Services assists with the transformation.

    “The biggest problem we find is that while teams naturally self-organize in smaller organizations, enterprises and government departments tend to be quite rigidly structured with defined roles and responsibilities — but by its nature, DevOps has to be cross-functional.” This leads to conflicts, because people become unsure of their place in the team and exactly what they are responsible for.

    The answer is education, combined with gradually introducing the various stakeholders to DevOps at an early stage of the project, he says. “You want them to take shared ownership, and the way to do that is to carve out one piece at a time rather than trying to change the whole organisation at once. This approach builds energy and enthusiasm, which encourages other stakeholders to engage with the process.”

    It is also important to avoid being over-prescriptive: “Pick one aspect — perhaps automation of a certain task — and adopt that as a starting point.” That way, even large and traditionally structured organizations can benefit from DevOps.

    For some people, “it becomes religious… ‘You have to follow all these practices or it’s not DevOps’,” but that is not constructive according to Walker. His advice is to avoid getting stuck in the details, and instead make a start and commit to constant improvement. Seeing through small but meaningful changes will deliver value, he says, because the introduction of DevOps is one of many situations where it does not make sense to try to boil the ocean.