Capping IT Off

Capping IT Off

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

Alternate title: 

Impact of Digital, Agile and DevOps on the delivery model of vendors, and more importantly on the business competitiveness of clients (1/3)

Agile, DevOps, Hackathons, Two-speed-IT, delineation of systems of record vs. systems of engagement etc. stem from IT’s aspiration of accelerating time-to-market of usable code in production, in places where it matters the most. These are potent constructs when applied well, since they take an end-to-end view of IT development and deployment (rather a software development only view), and focus on IT output.

The aspiration of business is however different: everything needs to be compelling from a business and user impact standpoint and is needed yesterday (faster release of a larger quantity of code into production does not per se excite the business). Hence the practical notion of Business competitiveness is: compelling business-technology capabilities that are released rapidly to the market accompanied by the requisite levels of rigor (spanning business processes and IT) coupled with breakthrough user experience. The traditional IT approach of ensuring that the new business-technology capabilities are compelling relies on the strength of the Requirements Management process, the business case, user inputs, involvement and feedback, ROI measurements, etc. While useful, these constructs have fallen short in securing the success of many IT projects. The story of a large organization that follows spotlights why Digital and IT Agility by itself is not sufficient to ensure business competitiveness: The organization had many accomplishments to its credit, including a league table-topping enterprise grade App Store with several revenue generating apps incorporating powerful industry insights and cutting edge IT capabilities, and supporting transactions in excess of tens of billions of $ per year. Owing to market dynamics, the organization entered a tough period and at a critical juncture the CEO issued an open message to all employees with multiple remarks: “Our cost base is swollen by poor and ineffective processes, antiquated and inadequate technology, too many tasks being completed using manual labor, and, too frequently, unsuccessful investments in our infrastructure. Too much of our hard-earned revenues are used up this way. We must re-engineer our internal processes. We must standardize our systems and procedures, decommission legacy software, standardize and enhance our data, and improve our reporting. We absolutely must wean ourselves off the proliferation of committees.” Given this let us try to get at the secret sauce of enabling business competitiveness of clients while leveraging Digital, Agile and DevOps in this blog series.

In the first blog, I will cover a few best practices of Agile and DevOps at a high-level in the context of IT project implementation. In the second blog, I will cover instructive experiences of how clients and vendors have adjusted their working methods to deliver high-impact digital IT projects using Agile and DevOps, without compromising on the use of Global Delivery Model. In the third blog, I will cite examples to outline methods to realize business competitiveness based on well-considered leverage of Digital, Agile and DevOps.

Capgemini’s next generation Application Management platform embraces the DevOps approach to IT development as a way of working that emphasizes collaboration, continuous integration, ongoing testing, continuous delivery and continuous deployment, supported by high levels of automation and delivery industrialization. While Agile management helps ensure that software functionality is developed in a time-bound manner, DevOps focuses attention on the last mile readiness, i.e. the developed functionality is deployed effectively in production. Best Practices to apply Agile and DevOps are (additional coverage will be provided via an example in Blog 2):

  • All projects can benefit from the adoption of Agile and DevOps principles (they both go well together). Based on the nature of the project the appropriate SDLC model needs to be selected and tailored. As an example Agile is likely to be well suited for a medium size Digital project, whereas implementation of an enterprise system across 100 Markets may not lend itself to a simple User Stories based Agile adoption (since coverage for 100 Markets requires a lot of upfront definition work on the Business-IT Target Operating Model) - yet here too many Agile principles can be adopted to accelerate time-to-market. The diagram below provides a representative view of the considerations that influence selection of SDLC model, and this to be refined on a case-by-case basis

Planning for effective use of Agile and DevOps

  • Develop each release in a way such that it is modular and focused on one or a few business deliverables, e.g. for a Consumer Goods organization it could be shelf information, directions for a better merchandising – very much like apps in an Apps store, to improve adoption levels by the business and reduce the time to breakeven
  • Focus on releasing a Minimal Viable Product (MVP) since time-to-market is critical. Also helps to gain continuous involvement of the business, to help business outline their needs in detail and receive feedback from end consumers
  • Build incrementally, in iterations. Decide up front on the number of iterations within each release and incorporate agile practices across the organization (the number of releases is based on back-office or front-office capability, scale). Limit changes within a Sprint
  • Adopt relevant Agile principles: Sprint planning, prioritization, product backlogs, daily scrum meetings, collaboration, feature burn-down charts, build and test daily, etc.
  • Work with simpler, minimal documentation and processes in line with the team dynamics and emphasize end deliverables rather than the activities that make it
  • Adopt a Quality Engineering approach that looks at the run-time engineering quality of the code and not just testing
  • Ensure adequate engineering attention is to be paid to: cycles of integration testing in the overall application landscape; data migration; non-functional requirements such as performance; and best practices from a Cybersecurity perspective, to ensure flawless releases
  • Adopt specialized roles such as Scrum Master, Product Manager, etc. Ensure Business Analysts are part of the offshore team to ensure quicker progress on requirements. A representative distribution of roles in Agile projects is shown below

Development

  • Determine feasibility and freeze core Architecture in Sprint 0 at start of project
  • Wireframes / framework should be frozen before development. However, plan for evolution of Frameworks
  • Dependencies and inter-relationship of configuration items needs to adequately factored in to eliminate issues associated with parallel releases. This is akin to air space management by air traffic controllers at airports
  • Gain from Service Virtualization aided by tools such as CA Lisa and Stubby to reduce dependencies between parallel work streams – this enables development and testing teams to accelerate release times
  • Automate development wherever possible using code generators and 3rd party libraries
  • Use of Reference architecture across Apps and Infra, to aid building and deployment of business-IT modular components adherent to design standards. These would enable development of new products and services based on plug-and-play than coding all the time
  • Rigorous adoption of SCM process - clear branching and merging strategy in a continuous Build environment
  • Use of Agile tracking tool with features for daily stand ups and sharing the whiteboard with story and task cards updates

Environment

  • Development, Testing, Pre-Production boxes should mirror Production to the extent feasible (critical for large / complex projects)
  • Adopt a central integrated platform for Backlog item management and code base
  • Standardize and automate Build and Integration environment

Testing

  • Adopt sanity checks using a Testing Harness prior to code check-in
  • Adopt Test Driven Development (TDD) approach
  • Use extensive automation in Testing
  • Use automated comparison to ensure data accuracy in data migrations

Representative example of automation tools adoption for DevOps

Impact of Agile and DevOps practices in a Digital Commerce project for a large Distribution organization was as follows:

Part 2 to follow citing three examples to show how clients and vendors have adjusted their working methods to deliver high-impact digital IT projects using Agile and DevOps without compromising on leverage of Global Delivery Model.

About the author

Ramesh Kumar Ramamurthy
Ramesh Kumar Ramamurthy
1 Comment Leave a comment
Great article Ramesh. Looking forward to the next in the series. A couple of observations (from experience), though devops is now being touted as the elixir for all ills, I strongly believe (and have experienced it first hand at Tesco), that this works well for fresh implementations. For a system that has been in vogue for a long time, devops does not lend itself to seamless service (devops calls for development, testing and support to be run out of the same "scrum" team). From a HR perspective as well, this is a huge challenge, because the traditional "developers" are now being asked to perform "testing" and "support" (which they consider as lesser activities). The latter issue can be addressed using a well-honed change management with top-management support but the challenge with the former (ideally devops has no time set aside for knowledge transfer) would prove a hurdle. I, therefore, advocate a phased approach to the agile-devops model in which all the new implementations would strictly follow the devops approach with a (progressively decreasing in size) residual team taking care of support of "legacy" implementations.

Leave a comment

Your email address will not be published. Required fields are marked *.