staging-devopsy.kinsta.cloud

Tag: customer

  • Digital Business: Paving the Way for DevOps’ Second Act

    Digital Business: Paving the Way for DevOps’ Second Act

    DevOps is the buzzword of the moment. It’s at the heart of every strategy—not just CIOs’ IT transformation strategies but also IT vendors’ sales and marketing strategies. The question business unit leaders always ask is, “Is DevOps to improve IT or to boost the business?”

    The disconnect is so big between the concerns of today’s DevOps practitioners and business unit expectations on one side and digital competitive challenges on the other that the question is worth asking. Indeed, the proliferation of tech startups and digital services is making competition tougher and forcing business unit leaders to adopt innovation, velocity and timely revenue as their top competitive advantages, helping them to survive their industry disruption and then boost their digital growth.

    Let’s say it straight: The many DevOps and even cloud migration projects out there aren’t likely to help business units effectively address the digital economy’s challenges. Automating your application deployment processes with infrastructure as code and continuous delivery infrastructure on their own will never make your company an innovation champion or equip it with the fastest time-to-value in the world. That erroneous belief is nurtured within the IT community; it’s the tangible proof that IT still doesn’t understand the business. Period.

    Joe McKendrick, in his fantastic, “The Elusive Mystique of the Digital Enterprise,” and, “Cloud Computing’s Second Act is All Business,” offers insights likely to help business unit leaders remind their CIOs the business reality, “What matters is revenue.” IT innovation for the sake of innovation doesn’t make sense. And Adam Jacob, co-founder and CTO of IT automation company Chef, in a fantastic article, “The Secret of DevOps: It’s Always Been About People, Not Technology,” gives a DevOps vision that’s totally in line with business unit expectations more importantly to more effectively address digital competitive challenges.

    Adam Jacob’s System of Thought: The Foundations of DevOps’ Second Act

    Adam Jacob defines DevOps as:

    Fundamentally being about taking the behaviors and beliefs that draw us together as people, combining them with a deep understanding of our customers’ needs, and using that knowledge to ship better products to our customers.

    He adds:

    Notice that I don’t mention technology, which may be surprising coming from the CTO of a DevOps-focused company.

    He concludes:

    Tools matter. But tools exist in service of the prime directive: building highly functioning, highly effective cross-functional teams, that attack your thorniest business problems as a unit, rather than as lone individuals or silos with competing incentives.

    This perspective of DevOps unveils an authentic business thinking for IT that I turned into a digital business approach:

    adam-jacob-thought-v2

    It’s represented through the above virtuous circle of principles structured around customer:

    Customer is the source of digital wealth: This expresses the proven belief that being customer-focused increases service quality, keeps customers loyal and, in turn, increases his value of the money they spend to buy services. It prevents customer churn caused by changing consumption habits, whereby digital services are increasingly preferred to traditional services.

    People make, create and innovate: This principle translates the proven idea that giving staff skills, resources, authority, opportunity, motivation, and holding them responsible and accountable for outcomes of their actions, will contribute to their qualification and satisfaction and ultimately make them committed to the organization’s wealth. It creates work environments and work styles conducive to innovation.

    Behaviors and beliefs strengthen involvement and commitment: This principle highlights the demonstrated notion that sharing common beliefs, principles and values creates team spirit, which increases cross-functional collaboration and, in turn, accelerates problem-solving and decision-making. It contributes to the business agility.

    Product is the digital wealth driver:  It’s the now-acknowledged idea that to succeed in the rising digital economy, businesses must align their application delivery approach to the new product development (NPD) principles. Applications take value to customers. It helps to keep up with the fast-paced digital business environment.

    Velocity makes the business responsive to market opportunities: It’s the widely adopted notion that time-to-value is the essential revenue driver that will make businesses digitally wealthy. That principle is enabled by the continuous delivery infrastructure which automates—therefore accelerates—the application delivery processes chain.

    This unprecedented vision, dominant on the business side, contrasts with the technocentric approach promoted by the vast majority of IT vendors to increase their sales.

    Being honest to customers is telling them this: Implementing continuous delivery infrastructure is not implementing DevOps. It will never, on its own, make the business digitally competitive.

    I have no doubt that you’re convinced Adam Jacob, Joe McKendrick and even Ernest Mueller, author of “DevOps: It’s Not Chef and Puppet” are definitely right. The question you might be asking now, which may be provocative is, “Okay, that’s good! How do you implement all that?”

    Implementing DevOps’ Second Act Foundations into a Digital Business Capability

    The first step toward implementing DevOps is to admit that a new IT paradigm is needed, Adam articulates it that way:

    Leaders need to realize that implementing DevOps means changing the technology system as well as the cultural system. They must acknowledge that both are intertwined and, to be successful, both systems must evolve to drive velocity.

    It’s not different from the two-dimension IT advocated in my recent book, “Rethink Your IT with DevOps: The Complete Guide to Aligning Your IT to DevOps” and  in my online contents, “Become Digitally Savvy in Just Hours. Boost Your Digital Revenue Now“:

    two-dimension-it

    DevOps implementation is based on four principles that determines successful business transformation:

    Concerns have shifted from technology efficiency to business agility: Forget the outdated idea that IT tools on their own can help your business units succeed. What will make them digitally successful is the combination of technology efficiency and organizational flexibility and agility.

    See IT as a two-dimension asset: To win legitimacy among business units, offer a two-dimension vision of IT including the value stream and the continuous delivery infrastructure. Value stream is where value is created and the continuous delivery infrastructure is what enables business agility.

    The value stream is where the innovation and agility cultures are built: Transform your business organizational structure into an agile value stream through deploying agile practices and methodologies such as Scrum, Kanban and Exteme programming.

    The CD infrastructure is where fast time-to-value is enabled: Automate your applications delivery processes into an accelerated applications delivery chain using automation and continuous delivery tools such as Chef Automation, AWS CodePipeline and Apprenda.

    Summing It Up

    Experienced DevOps Strategists know that DevOps is the means to an end, and not the end itself. DevOps is an enabler to one or a combination of these business competitive advantages: short time-to-value, market responsiveness, innovation culture and many more.

    All the noise surrounding the so-called DevOps tools has to do with technology business—making money through selling IT tools—and absolutely not DevOps.

    DevOps isn’t a tool, it’s an IT approach stressing business competitiveness: shorter time-to-value, market responsiveness and innovation.

    — Philippe Abdoulaye

  • Accelerating DevOps with Service Management (and Vice Versa)

    Accelerating DevOps with Service Management (and Vice Versa)

    One of the great misconceptions of service management is what it means. This also is the reason why so many service management initiatives fail. Consider a call center, for example, with many people answering phones and replying to emails. It’s true that a service desk is one of the functions (and in some organizations, maybe even a cornerstone) of service management. It’s also true that the customer or user is one of the main characters in the story of service management. The very word “service” implies there is a customer at the end of that service.

    However, service management is, at the very core, about designing, delivering and redefining services to the customer base—whether those are internal, external or occasional users of the service. User roles may vary over time and users may become part of the supplier chain, and vice versa. A great example of this is knowledge management, wherein users are typically both consumers and producers of information and, thus, the service.

    When we take this higher-level view of the service management practice, our eyes open to new possibilities. In particular, we can see beyond the service desk. The scope of service management widens to the end-to-end delivery of the services in question, retaining the focus on the customer.

    Finding the Cure: It’s All About the Customer, and Communication

    The happy medium and the much sought-after goal of the harmonization of service management and DevOps can be achieved when stakeholders find common drivers. In both worlds, the respective goals focus on the business, delivering value and doing so quickly.

    The following sections present actionable recommendations that can be implemented incrementally across the entire organization. They offer a bottom-up approach. In conjunction with implementing them, senior management needs to support the culture change that is a vehicle, a catalyst and a byproduct of the improvements. In this way, the full benefits of the changes can be analyzed and achieved.

    Tip 1: Stop playing ping-pong with issues

    We’ve all identified an issue with a system, logged it with IT as a ticket and received updates of the progress while the ticket is handed over from team to team—only to discover weeks later that the development team knew about the bug but had de-prioritized it due to lack of interest.

    Surely, by the time the final bit of information reaches users, they are less than satisfied with the result. What’s more, the organization has wasted everyone’s time, not least the time of network, storage and other team members who had to prove it wasn’t their fault in the first place. Finally, development team members could have prioritized their work correctly if they had known about the customer need in the first place.

    With so many implications in the above scenario, why does this happen? The reason is simple: less than optimum process interfaces and lack of information flow. When you’ve identified the problem, the solution is easy: Include relevant data from the development teams, such as defect information, in your chosen IT service management solution.

    Sometimes, the easiest way is to integrate the defects created in development’s chosen tool set to IT service management’s “problem” records. This way there is no need to change the processes per se, as problem records can be linked to issues (or incidents) easily in the service management tool. The integration simply allows for the information to flow between systems and enables a collaborative approach to issue handling.

    In this scenario, when the development team opens a defect, it creates a problem record in the service management system, which, if feasible, could be displayed automatically to users on a self-service portal. Thus, users can search known errors before logging a ticket, resulting in time savings across the whole organization.

    Tip 2: Communicate bugs and known issues to everyone impacted

    But what happens when a user finds a new issue that has emerged due to a bug that has yet to be discovered by developers and testers? Traditionally, the user might log a ticket, which is then analyzed by the IT service team and forwarded to developers for analysis, coding and testing. That might be last of the ticket the user sees, as the feedback loop often is missing.

    The benefits of forwarding the defect information from the user to developers are realized only when there is a way to easily track the whole life cycle of the issue regardless of where it has been initiated. Instead of batch importing records from one system to another, the most advantageous way is to mirror the record sets in the two systems.

    In this example, the feedback loop between the customer and the service desk to the development team is achieved when synchronizing problems and defects in the two solutions.

    Tip 3: Empower the customer by crowdsourcing bugs and new features

    One key metric that contributes to employee satisfaction and retention is the ability of employees to do their jobs well. To accomplish this, they need resources. When employees have all the resources they need to do their job well, more often they are happy than not.

    We are all dependent on technology; there are few professions that do not require technical resources to perform their jobs. If there is a hiccup in the finance solution, for example, the finance assistant may well be the first to find an issue after a version upgrade. Or, a team-wide brainstorming session may result in some great “if-only-our-analytics-software-could …” ideas of how to improve the efficiency of the team.

    But how best to communicate these issues, and capture the many ideas? Possibly, you might even perform real-time impact analysis on which improvement ideas are important to various business processes, and communicate the urgency of each one to the development organization. The inherent problem in many organizations is that users have only one touchpoint to the “DevOps cycle,” most commonly through the IT service management practice. Meanwhile, the rest of the IT organization may use a number of disparate systems to communicate and assign current work tasks that form a basis of shipping new features and functionalities.

    Again, it may be useful to look at the tools already employed throughout the organization, and understand the existing processes and practices. Understanding team functions is important as well, though many teams are fluid in their roles and tool sets used. Once relevant tools are identified, look for mutually beneficial interfaces between them to ensure that users’ requests for new features are not forgotten but logged and picked up by the development team.

    In this example, you could integrate a tool that supports the back office (such as a defect management tool) and tools that support users (such as requirements management and project management tools). This allows you to effectively crowdsource and track upcoming features and bugs, keeping the whole organization informed.

    Tip 4: Don’t forget suppliers

    Include the entire software supply chain in the equation. After an era of outsourcing, insourcing, and multisourcing, many organizations have a diverse supply and sourcing strategy. One of the main reasons for this is to manage risk and ensure business continuity.

    Thus, the last remark is to ensure that all the above examples work in a multisupplier environment. This typically involves contractual preparation. New frameworks such as service integration and management (SIAM) help identify risk and reward in supplier collaboration. These are useful tools for both IT service management and DevOps practices.

    A great example of supply chain integration is an end user reporting an issue. Once it has been reported, it is then centrally analyzed to find the root cause of the issue and the underlying problem is routed to the correct supplier automatically. By synchronizing the information between supplier and customer, not only is each party kept up to date about current issues, but the pipeline and project customer demand are built by integrating incidents, projects and requirements across the software supply chain.

    One of the core aims of both service management and DevOps initiatives is to respond to customer demand as quickly and effectively as possible. Real-time synchronization between solutions is merely a technical solution, but one that has true potential to elevate the response speed.

    Reflections

    Having examined the above four ways to improve the collaboration of DevOps and service management, there are clear solutions to reforming the partnership to drive quicker customer response and satisfaction. But be forewarned: The four recommendations offered are but advice to improve; an organization’s leadership must truly be committed to a culture change to make change happen.

    About the Author /Tuuli Bell

    tuulibellDr. Tuuli Bell is a Partner Account Manager, EMEA at Tasktop. She is a member of the BCS, the Chartered Institute for IT, and the Institute of Physics. For her, happiness is about discovering opportunities to challenge the status quo and about embracing change, be that organizational change, or professional or personal development. Tuuli’s interests outside work include art, science, and nature. Follow her on Twitter or find her on LinkedIn.

     

  • Learning in the Continuous Customer Economy

    Learning in the Continuous Customer Economy

    We live in a continuous customer economy. Buyers in the 21st century are continuously discovering, adopting and discarding products and services online, telling us—very loudly and unequivocally—that value isn’t perceived in the actual product itself, but rather in our ability to change a product continuously. So, it’s now about the options to change the product, not the product options themselves.

    This utter lack and loss of brand loyalty puts companies at an insane disadvantage. They’re living with a “see you later” digital mindset, where it’s easy for consumers to say goodbye to something they know online for an opportunity with the newest, next best thing.

    Take this to the next logical business level and you see why continuous transformation of your organization is so critical. If you can’t continuously transform the way you deploy your people, processes, skills and resources, so everything is aligned with the consumer’s “see you later” mindset, there’s no way you can keep up with customers, who are continuously discovering, adopting and discarding products at what seems like warp speed.

    Obviously, this means learning and acquiring new knowledge fast.

    The same old knowledge, the knowledge of the past, just doesn’t work in the world of now. But, more profoundly, to continuously transform your organization and meet customers where they are today, you need to learn how to learn.

    Yes, sure, you have to learn from customers and gain an understanding of what they want and need. But every organization does that today. It’s no longer enough to simply grasp that insight and intelligence and run with it. No, you have to continuously improve how you learn from customers in this fluid and fast-changing world.

    Why? Because, at the end of the day, continuously improving how you learn is the only way to continuously transform your organization. And, thus, continuously improving how you learn is the only competitive advantage you have.

    Continuously Improving What—and How—You Ship

    Assume, for a moment, that you’re shipping an update of 1,000 lines of software code each week.

    That’s great.

    You’re likely using continuous delivery.

    But if you can’t continuously improve how you’re learning from customers and continuously improve the teams inside your organization, you can’t ship continuously improved products. So, you need to improve what you ship and how you ship to continuously transform your organization.

    Here’s an example of how this works.

    Let’s say your software development team senses the customer wants an improved red button that’s square instead of round. Okay, development of an improved red button proceeds and is completed in one week. But, at the same time, the team creates an automated test for the red button as well as clear metrics for determining if the red button is actually the problem. Remember, the idea that the button needed changing is a hypothesis until it has been tested with customers.

    So, in addition to shipping the new square button to some customers, the team keeps some subset of customers using the round button. The customer test is then simply whether the click rate of the square and round button differs.

    Let’s imagine that the processes are not currently in place to enable the development team to receive these metrics, as many teams are kept in splendid isolation from the results of their work. Then the establishment of this relationship, perhaps with the web operations team, is also going to be required.

    This is as much a requirement of successful deployment of these features as the features themselves. The focus on the delivery of function, as well as developing internal capability, is a core principle of continuous transformation.

    The Two-Product Principle

    This is the Two-Product Principle.

    Think of the product we ship to the customer as “Product 1.”

    Meanwhile, the internal capabilities we wish to develop—our view of what we need to improve while we build—is “Product 2.”

    To recap two critical points:

    • You always ship twice—you ship an improved product externally and you ship improved capabilities internally.
    • All of our product decisions, what to build and what to deliver, are theory until the customer actually uses the deployed product and we learn from that interaction.

    If you take these two critical points to heart, then your organization will do all it can to shorten the time to deployment and action to shorten the time to gain new learning in the market. This limits the length of the costly business guessing game, the cash-draining theory time.

    Continuously Learning at High Velocity

    The way you can do this is by continuously shipping, continuously delivering, continuously learning how to improve how you learn and deliver—continuously improving your internal capabilities and continuously transforming.

    Unfortunately, many organizations that want to increase velocity go faster without improving their ability to learn at this new speed.

    The implications of this short-sightedness are profound: When you’re leaning and looking backwards, you’re not improving how you learn from your customers in real time and, instead, you’re adding to your risk going forward because you’re so out of step, and out of touch, with what the market wants and needs.

    Every Act of Design is an Act of Feedback

    Too many companies fail to obtain crucial feedback. They throw a ball up in the air and walk away before it actually lands. We see this in software development when an organization releases a new quarterly product or feature and returns four months later; sadly, this approach doesn’t allow for much effectiveness tracking, or much learning, or much improvement.

    Which is why every single action in the continuous transformation process needs to be an act of design. The act of design is an act of feedback. And, in continuous transformation, you’re continuously getting feedback—whether you’re shipping product externally to a customer or you’re making changes inside your organization.

    The bottom line is that you need to continuously test your assumptions about the world, as well as your effectiveness in responding to those assumptions, if you want to keep up with continuously changing customers in the continuous economy of the 21st century.

  • 3 Skills Developers Should Master in 2016

    3 Skills Developers Should Master in 2016

    The era of mobile and web is upon us, which has caused nearly every business decision-maker to ask the question, Is now the time to hire a developer to build our app or website? In 2016, businesses are going to be looking for the best developers to join their team and help scale their business. We’ve already started to see this trend, as a recent Harvey Nash Technology Survey 2016 found that developers are the most sought-after of all technology personnel.

    To stand out from the pack, developers must master the critical skills businesses are looking for. The most valuable developers will be those who can adapt to the changing technology landscape and further hone their craft to help companies scale and solve specific business challenges.

    To stay competitive in today’s market, developers need to invest in these three skills to be relevant in 2016 and beyond.

    Master the Skills to Scale a Product or Service

    Startups increasingly are evolving from early stage concepts to building a growth model to take their business to the next level. To be an asset today, developers need to master and specialize in scaling technologies that are key for businesses looking to expand their customer base and focus on technological innovation.

    There is a demand for developers that have not only a breadth of experience in bringing an organization up to scale but also depth in their technical skill set. Having the ability to work on major systems, support large amounts of traffic and customers and maintain the system for several years are critical competencies that companies will be looking for.

    Also, having a data model or database experience is very important—NoSQL solutions such as Cassandra, CouchDB or Riak, as well as traditional data sources such as MySQL, are in high demand. Middleware languages such as Java and Golang also are an important part of a developer skill set when building services and APIs.

    Understand the Customer Perspective

    When building a technology solution, an engineer must be able to look at the product from a customer’s perspective to understand what problem the product is fixing. While technical skills in developing a product and user experience (UX) are very important, the ability for a developer to understand and create a product that solves a customer challenge far outweighs the focus on building the most elegant software.

    Engineers who are able to demonstrate project management skills and have experience around scaling infrastructure and ensuring the platform is robust will be in high demand. Businesses increasingly are seeing a need to support growing customer bases and traffic with utmost end-user reliability.

    Become a Subject Matter Expert

    There is a gradual shift in the developer community, in which engineers are focusing on specializations and becoming subject matter experts. There is an opportunity for developers to create career highlights by merging their talent and passion with opportunities.

    Developers are encouraged to identify an area they are passionate about and focus on refining those skills. By being able to find these opportunities that build on their passion, these developers can demonstrate they are able to solve a challenging problem for a large number of users—a competitive skill in high demand across the industry.

    The overarching strategy of a successful developer career is to invest in learning how to scale a product or service, understanding the customer perspective and becoming a subject matter expert. Investing in your skills as a developer in 2016 can lead to a longer, more fulfilling career.

    About the Author/Sha Ma

    Sha Ma_SendGridSha Ma is the senior director, Software Engineering at SendGrid. She led development teams at both startups and Fortune 500 companies prior to joining SendGrid. In her current role, she drives strategic planning, development and management of large scale projects. Ma is a graduate of MIT where she earned both her bachelor’s and master’s degrees.