devopsy.kinsta.cloud

Tag: agile approach

  • Elevating Agile With Financial Discipline

    Elevating Agile With Financial Discipline

    A corporate axiom is changing, shifting from “Big eats small” to “Fast eats slow.” But change doesn’t happen overnight.

    While Agile and lean methods continue to chip away at the status quo, making gains and increasingly moving beyond pockets of teams to the portfolio and then enterprise-wide adoption levels, waterfall approaches to delivery persist.

    Rumors of waterfall’s demise, it seems, have been somewhat exaggerated. A survey conducted by the Scrum Alliance (2017) of Scrum practitioners revealed that 78% of respondents said they used Agile-Scrum practices in parallel with waterfall practices. Mixed waterfall/Agile environments are complex. For many large companies, this is the norm. This is when the cohabitation challenges of agile and traditional workstyles become more glaring.

    Importantly, as IT finance management (ITFM) leaders know, becoming “more agile” doesn’t give you a pass when it comes to financial discipline and oversight. Agile organizations are still responsible for their ROI and saying you’ve adopted lean methods doesn’t automatically make you lean. Or fiscally responsible. Or well-governed. Or profitable.

    ITFM Leaders are Under Pressure

    Technical organizations are in the midst of evolving from being project-centered to product-oriented solution delivery and scaling Agile from the team level up to the portfolio/enterprise. In these evolving, hybrid working environments, faced with larger and more vocal agile communities, ITFM managers are facing increasing process dissonance between traditional and agile methods, wreaking havoc with their reporting, planning, budgeting and oversight.

    In a blended traditional/agile financial portfolio, understanding the true cost of projects, portfolios, value streams and OKRs helps companies make better use of their financial resources to drive profitable outcomes.

    And with interest in the value of IT spreading beyond the CIO to the rest of the C-suite, integrated reporting and decision-making that combine Agile work with traditional IT projects, the ITFM role itself is even more essential.

    Technology Business Management: Accurately Measuring the Cost of IT

    For many ITFM leaders, a focus on the discipline of technology business management (TBM) has improved their ability to better understand IT costs and influence governance and behavior through targeted analysis of real-time reporting (and chargeback) for IT resources. TBM provides a decision-making framework to help leaders understand the true costs involved in the delivery of products and services to customers. That has worked well, particularly in industries where project-centric, traditional waterfall projects are the norm. As it turns out, it works very well for supporting Agile, too.

    As agile gains momentum, finance is where it collides with P&L statements, budget dollars and fiscal quarters. With the seemingly irreconcilable Agile release trains and program increments, story points and cycle times, it can be difficult to see an integrated path forward. Fortunately, for teams that have embraced it, TBM provides a well-tested, proven framework that is easily extended to support enterprise Agile transformation.

    Agile transformation and scaling initiatives occur as teams of teams seek to reap the rewards of end-to-end enterprise agility.

    And, as enterprise agility expands, ITFM leaders will likely encounter process improvement initiatives that are key to an Agile transformation and that directly influence IT finance. Central among them are lean portfolio management (LPM) and value stream management (VSM). Due to their direct influence on ITFM and their intertwined agile characteristics, these two especially deserve early focus. And, while there are certainly more dimensions to enterprise agility, this is a good place to start.

  • Best of 2021 – How to Combine DevOps and Agile

    Best of 2021 – How to Combine DevOps and Agile

    As we close out 2021, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the thirteenth in our series of the Best of 2021.

    In recent years, application development and deployment have become an increasingly critical part of business operations. Because of this, various entities have sought to optimize their product development process.

    This has led to a rise in the popularity of DevOps, which is designed for that purpose. In simple words, the DevOps application during the software development process reduces the number of steps necessary to bring software to market. These faster releases and streamlined processes mean swift user feedback.

    DevOps implementation focuses also on the software scalability, how well it could be deployed and also its monitoring and maintenance after the future releases However, there is also a downside to traditional DevOps benefits. The system does not include the kind of continuous testing and improvement that Agile offers. 

    This has led to Agile practices being overwhelmingly focused on what you might define as the development aspects of software delivery. Though, there is less focus on operational aspects.

    Hence, both practices are quite critical to be implemented in the SDLC of any product. 

    Separating Agile and DevOps approaches to software development leads to the building of the product but its deployment, work automation, as well as infrastructure management fail as it’s “somebody else’s problem” when the Agile team is looking at it. Moreover, “operability” disappears into the background.

    The solution is combining Agile sprints with the integrated teamwork offered by DevOps. By doing so, you can optimize incrementally the development lifecycle and maintenance of your product both. It helps to correct an imbalance but has little influence over the practices that happen during the continuous development phase.

    What is Accomplished by DevOps and Agile Integration?

    The integration of DevOps and Agile helps in the following areas:

    • Streamlines the release process and improves product offerings.
    • Allows for better collaboration.
    • More value and fewer risks in each release. 
    • Fewer bugs and faster fixes.
    • Increased visibility.
    • Higher user satisfaction rates as the products are more qualitative.

    What to Pay Attention to When Integrating DevOps and Agile

    To simplify the process of implementing DevOps into Agile product development we have gathered the most common pitfalls that might happen during this process and how to avoid them making your process working smoothly.

    Improve Teamwork Flow

    Using the DevOps framework and Agile approach together makes it crucial that team members have a broader understanding of all development aspects. You get DevOps business value and the practicality of Agile together. 

    Team members such as the Product Owner, Scrum Master and the PM, along with operations, infrastructure and sysadmin roles need to consider not only the software development process but also delivery and maintenance. Your teams should be equipped with the knowledge of release, service and change management, environment provisioning, automation and tools, and application deployment. Build-and-run product-centric teams solve the problem of the Agile development-to-operations hand-off.

    Defining the Lifecycle

    Successfully attempting a DevOps implementation plan with an Agile framework means defining the product lifecycle. This increases consistency, reduces cost by minimizing waste and speeds up a time to market. Teams now inherit more of the operational concern within the entire lifecycle. Therefore, it’s ideal if you start to implement some of the DevOps principles right at the beginning of your development process. 

    DevOps Adoption in Sprints

    Agile workflow assumes the software development process divided into sprints, therefore it’s strategic to integrate DevOps management while handling sprints.

    Follow these instructions as you start working the DevOps approach into your Sprints.

    • Invite ops/infrastructure/support personnel to planning sessions.
    • Discuss product functionality and operability features.
    • Include them in the upcoming sprint.
    • Involve the DevOps team in sprint backlog planning and daily meeting, as well as sprint review and scrum and plan alignment.

    The engagement and collaboration of your development team and operations team also keeps the ops team abreast of functionality release timelines. The ops team can then help the dev team in planning the release schedule with greater accuracy and can assist the dev team in shipping the product faster.

    Including QA in Each Phase

    Making the QA part of the entire development lifecycle is another essential factor when integrating DevOps and Agile. Testing assumes a vital position when combining the two. Besides functional testing applied in Agile, DevOps approach requires performance and load testing of the software. Hence, constant testing is equally as important as continuous development.

    Implement Service Backlog Under DevOps

    When implementing DevOps and Agile together, you need to rebuild your service backlogging process. As under DevOps framework, it should include: 

    • Scalability of the software.
    • Deployment capability.
    • Service monitoring.
    • Logging.
    • Setting alerting. 
    • Software testing. 
    • Security and compliance aspects.
    • Operational performance.

    Leveraging the Right Tools

    Using the right tools is the key to successful Agile and DevOps adoption into your software development. Keep in mind that applies to your software development process configuration management tools to create and replicate infrastructure using the Infrastructure as a Code (IaaC) concept needed for DevOps. This helps developers to deploy the application on different types of platforms without any reworking efforts.

    Automation

    Automation of workflow is another part of Agile combining with DevOps. Try to automate all the code scanning processes and avoid any potential vulnerabilities. Build artifacts in a repository, or automate the release out the door. Automate these elements entirely so your end-to-end goalposts are the one possible places where someone has to manually check for issues.

    Documentation 

    While in the Agile approach, teams don’t document their meeting minutes or other communications. Instead, they prefer lo-fi methods such as pen and paper. DevOps, on the other hand, requires entire design documentation and specs to understand a software release.

    Measurement and Analysis

    Well, after building DevOps into Agile project management to keep track of its progress, you need to care about establishing the metrics to measure its effectiveness. This allows for the successful enablement of multiple releases to production faster. As under the Scrum Alliance Organization recommendations, some of these could be:

    • Percentage of release date adherences.
    • Percentage increase in release numbers.
    • Time taken for release to production.
    • Defects attributable to platform/support requirements.
    • Percentage of NFRs met.

    Though you can define other metrics during DevOps implementation to measure that have higher business value.

    Why DevOps and Agile both matter should be obvious now. Though these practices serve to streamline and simplify the product creation and deployment processes, combining Agile and DevOps requires a shift in the organizations. But putting efforts in combining Agile and DevOps management in the right way, you will see how it can improve your development process and deliver results in reliable, scalable and maintainable applications.

    — Slava Vaniukov

  • Bringing 5G-Enabled Digital Services to Life Calls for Cloud-Native Operations

    Bringing 5G-Enabled Digital Services to Life Calls for Cloud-Native Operations

    Spotify, Netflix, IoT connectivity and cloud storage are a few examples of the digital services providing new options for fun and function to consumers and businesses alike, while representing a growing boon for communications service providers (CSPs).

    Gartner predicts by 2020, nearly one quarter (23%) of CSPs’ large enterprise business communication revenues will be driven by digital services—up a staggering 10 percentage points from 13% of revenues in 2017. This gain should come as no shock to developers who favor building in the cloud or using tools such as Microsoft Teams to collaborate, or who stream video from HBO Go or skim stories in Apple News during their commutes. Today’s customers (consumers or businesses) expect value-driven, digitally enabled services that inspire personalized and meaningful experiences with their brands of choice.

    The good news is companies are eager to meet demand: CSPs want to deploy services in the cloud to address the challenges of web-scale companies. In fact, 85% of companies surveyed say launching new digital services is critical to their business strategy.

    What’s the catch? To do it, they’ll need to be agile. Although telecom is not an industry known for its agility, and is often thought of as the opposite, it has been transforming—like many industries—through adopting more agile approaches in business strategy. CSPs are striving to maximize resources and reduce inefficiencies, while at the same time sparking innovation. Nothing has been more of a stimulus for agility than the cloud, especially for the web-scale companies whose services pose the greatest threat to the telco industry.

    A key requirement will be cloud-native applications that improve the agility of network functions. However, being cloud-native involves a lot more than just shoehorning code into a container previously ported from an appliance to a virtual machine.

    Rather, at Oracle, cloud-native means faster development and deployment through DevOps and continuous integration and continuous delivery (CI/CD) pipeline. CSPs can only achieve an agile cloud with an environment enabling developers to innovate true cloud-native solutions if they implement an operational framework that embraces a key set of principles. Specifically, we at Oracle have identified the principles for successful cloud-native operations.

    System Immutability

    Everything, including software and configuration, is code. All changes are made through CI/CD, where they are deployed as immutable artifacts. No manual configurations or customizations are allowed. This makes it easier to implement the principle of least privilege as there is no need to run scripts in the production environment. Also, any changes not coming though the delivery pipeline can be considered malicious.

    Automate Everything

    All aspects of build, test, verification and deployment are automated. This includes activities such as backup, recovery, password/key rotation, etc. Fully automating the DevOps pipeline, including verification and testing, removes much of the potential for human error. This automation also allows changes to be applied to the environment with confidence and provides for rapid repair.

    Disposability

    All services are transient and treated as short-lived. Instead of focusing on never failing, services are designed to go up and down quickly without service interruption. Regular repaving (re-deployment) of the environment ensures failed or failing services are removed and new ones deployed.

    Externalized Configuration

    Configuration (including passwords, credentials, location of backing stores, etc.) is decoupled from the software image, and like software, can be treated as a build artifact in a controlled and versioned manner. Versioned configuration enables development and production parity as an artifact and can eliminate costly operational errors.

    Logs as Event Streams and Constant Telemetry

    Everything needed to debug or diagnose any functional, operational or security issue is found in logs, traces or metrics data. These are treated as a stream of time-ordered events and stored in a centralized collector outside the system, enabling better threat monitoring, forensics and diagnostics through event correlation or analyzing the aggregated and holistic view. Constant telemetry is fundamentally enabled through logs as event streams and, thus, the two should always be considered together.

    Delegated Governance

    Some shared aspects of the environment are centrally managed like networking, identity management or infrastructure, but in a true DevOps fashion, teams delivering a service are responsible for operating the service. This is allowed only with strict governance, enforced through checks in the continuous delivery pipelines, giving greater control over rate of change. Business agility is improved as applications have better visibility into the operations of their service with tighter feedback loops that ultimately improve quality.

    Independent Lifecycle

    Independently upgrading, scaling and deploying each microservice is paramount for supporting other cloud-native principles as well as minimizing the amount of change in the system at a given time. Furthermore, such decoupling makes other principles, such as repaving, easier and promotes easier isolation of issues.

    As 5G introduces increased connectivity and speed, along with the need for more security and reliability, service providers will need the agility, flexibility and security of the cloud and cloud-native principles. These principles are enablers for better cloud operations. Together, they provide the ideal context in which to implement a broader view of the Cloud Native Computing Foundation (CNCF) landscape, giving developers a robust Platform-as-a-Service of backing services beyond just containers.

    As 5G moves from a fabled future to a reality, the market for digital services that reap its benefits is likely to continue to grow. By leveraging these principles, along with DevOps and the CI/CD pipeline, organizations will be able to evolve and prepare for 5G’s promise for innovative business models and new revenue streams—be they digital services or beyond.

    — Shirin Esfandiari

  • Is DevOps in the Enterprise Real?

    Is DevOps in the Enterprise Real?

    Is DevOps in the enterprise real? The short answer is yes, but you may assume it’s only relevant to the world’s leading cloud companies because they’re the ones that make the headlines. DevOps offers the promise of agility, quality and ultimately better-performing software. While DevOps processes can increase agility, and agile approaches are a great help in improving responsiveness to change, the overall process still needs a clear objective, measurable KPIs and a finite scope.

    In other words, unlocking the promise of an agile (product) organization requires a few complementary approaches. If those are ignored or applied incorrectly, DevOps agility can become an impediment to adaptability and agility for your enterprise.

    Yet, I’ve read so many blogs about how the cloud and DevOps processes solve problems. It’s true they can, but the nuance is that, while a few teams can coordinate change amongst themselves, when you attempt to deploy a DevOps practice at scale, challenges are quickly apparent. For example, if I’m working for a startup that has fewer than 50 developers and very few layers of management between the CTO and her team, the management and communication lines are likely short enough that strategy and direction can be conveyed directly to the teams. However, for larger organizations—where there are many often geographically distributed teams with silos of responsibility and layers of management—far more coordination and communication are required.

    In these environments, it is more likely the business will achieve agile teams but not an agile culture. This is because it’s too simple and, therefore, commonplace for these environments to execute in silos not aware of changes to other silos and where environmental constraints and dependencies are not considered throughout the development process.

    The best solution to these challenges is to focus on a cascading framework of objectives and goals. Every company has its mission-critical goals—some call them strategic imperatives, others call them (or include in them) board-level mandates—and those goals should cascade into a more refined product, program and team goals as you traverse the management tiers. This ensures the business leaders can set a strategic direction that will be measured in a certain way, and every subsequent layer below them understands how their initiatives align with supporting that direction.

    The first critical element for building a successful, sustainable DevOps culture is understanding your goals and how you’ll define and measure success.

    The next element is to establish which decisions each level of management can make autonomously. For example, risk tolerance is a strategic decision, architecture and security posture are typically defined for a product, platform-level technology decisions can be delegated to program teams and project teams can then focus on making the more granular technology decisions that will differentiate their product, service or feature.

    Finally, communication is key. This sounds trite, but communicating this cascading decisioning framework, exposing the decisions each group makes that could impact the particulars of an environment and then discussing requirements and challenges of architecture and software choices can ensure that each team, at each level, can remain agile and adapt to change effectively.

    The question is: Do you have the management rigor to dig into these challenges and own them? The answer likely lies in how important the pursuit of agility is to you and your business.

    — Ari Weil

  • Collaboration Inside and Out for Innovation

    Collaboration Inside and Out for Innovation

    Across all industries today, organizations increasingly are migrating their infrastructures to the cloud in a bid to boost agility, lower the cost of IT ownership and reduce the risk of outages.

    Firms are under more pressure than ever before to innovate new products to keep up with newer, more agile firms. But before they can reap the benefits that come with going totally serverless, organizations must deal with the immediate challenge of meeting the ever-growing expectations of today’s digital-first customer.

    For newer firms, this is arguably a much easier undertaking, as their IT infrastructures will have been built using modern programming languages, technologies and software development practices. They also will most likely have adopted an agile approach and be highly adaptable to changing business needs. Conversely, older firms typically have a large body of IT that lives in an entirely different world. With infrastructures made up of a patchwork of interdependent legacy applications, built on top of monolithic architectures, these firms struggle to innovate customer-facing applications at pace. But if they are to compete, established players must adopt a similar approach to their more agile counterparts.

    Don’t Hate the Players

    It is completely natural for technology to evolve. The problem faced by many organizations that were pioneering in their use of technology is that they have now become victims of their own success. Take the world of financial services as an example. Banks that began building out their IT infrastructure decades ago have had to adapt gradually to new technologies. But it’s only in recent years that digital transformation has become a key business objective. In the not-so-distant past, banks may have been able to get away with taking their customers for granted, as the competitive landscape lacked any real diversity. But today competition abounds, with challenger banks and fintechs bringing innovative new products and services to markets traditionally owned by the banks.

    If the banks are to compete, they must seek to collaborate with the fintechs. Cloud-based open platforms that focus on open APIs are the most effective means of achieving this. By providing fintech partners with access to core systems via open APIs, the banks get to concentrate on their core operations while innovation from the outside helps them to deliver new applications to their customers.

    Historically, the banks would have been fiercely protective of their IP and core systems, but in collaborative environments, it is exactly this IP that can be used to create value in a safe and secure way. This is why banks increasingly are seeing fintechs as partners rather than poachers, as they are above all technology providers that are eager to have their services leveraged by large financial institutions. Similarly, banks understand that they must become more agile and entrepreneurial to deliver what their customers want. So, working with third parties that embody these characteristics is the most effective means of doing so.

    Embrace Internal Collaboration

    As well as overcoming legacy systems, legacy culture must also be addressed if true digital transformation is to be achieved. The first way to do this is to align application development with business goals, showing how a focus on the former helps to achieve the latter. Here, the adoption of a DevOps mindset can bring about the right culture for increasing innovation within. Though not entirely applicable to legacy systems, which must be evolved at a much more gradual pace using a waterfall approach, DevOps can be applied when it comes to systems of differentiation—which include decision-making, pricing, analytics and risk management tools in the middle office, as these tools will need updating more often to accommodate changing business practices or customer requirements.

    Creating cross-functional teams that include business analysts, developers, data scientists, QA, UAT and compliance experts means there is collective focus and responsibility for the delivery of applications. It also enables more agile development so that applications can be pushed through to the production environment continuously, rather than simply throwing a finished product over a wall with little care as to how it performs.

    In recent years, IT increasingly has been seen as a business driver. As software development methodologies and practices that rely on a collaborative culture continue to mature and further prove their value, partnerships between larger organizations and disruptors will be viewed in much the same way.

    — Mitesh Soni