Five Game-Changing Shifts in Software Engineering and How to Respond
Toss out the old rules of software engineering. Today’s new playbook represents five major shifts in how organizations address speed, quality, automation and end-user delight. Here’s how to respond to these shifts to compete in the era of digital product engineering.
Since software lies at the heart of most digital initiatives, how an organization creates and maintains these assets is now among the top business priorities. Many business strategies recognize that market share will be won by those who can quickly deliver quality applications that offer richer user experiences. Newer approaches such as Agile, DevOps, cloud platforms and automation needn’t only be the pride of digitally native businesses. Traditional organizations aiming to modernize archaic IT systems, methodologies and practices must also embrace these approaches, which have emerged though the five paradigm shifts that have transformed the way software is engineered, deployed and maintained.
Agile software development challenges traditional methods as it focuses teams on delivering business value in short and sustainable intervals. Agile runs counter to a big-bang approach where projects might take six to 12 month to deliver as teams lumber through extended phases, multiple document hand-offs, discrete collaborations and inadequate customer input. Test-driven development(TDD), a more modern approach, flips the development process by advocating that teams first write test scripts before they create source code, thus reducing defects and other speed impediments.
Here are the five most critical shifts and recommended approaches to embrace the new world of software engineering.
Teams give way to pods
The traditional structure of teams is taking on a new dimension with the introduction of pods.
Unlike teams which are typically hierarchical with members sharing areas of expertise, pods represent a structural shift to autonomous groups with complementary skills and no formal manager to set priorities and deadlines. Each pod is responsible for a certain aspect of the product. Pod members are responsible for coordinating their own workflows — from task prioritization to deadlines. They apply engineering excellence, and ensure high-quality deliverables and a faster time-to-market through practices such as continuous integration (CI) and continuous delivery (CD). As a result, pods are high-performing Agile teams that are more adaptable to changing business needs than traditional teams.
Increasingly, pods apply design thinking, which focuses on the needs of the people who will use the product. Pod members have a collective sense of code ownership and empathy for each other. They invite quick feedback, measure outcomes and practice team learning to achieve organizational speed. Ultimately, the shift to pods speeds the design, build and run processes to deliver better products faster and makes a technology organization a more exciting place to work. For example, after we deployed a pod approach for one of our telecommunications customers, its team velocity increased 15% and post-production defects dropped 60%.
To effectively create and motivate pods:
Avoid extreme distribution. Ideally, pod members are co-located in open environments and not dispersed across more than two sites when co-location is a challenge. Pods should have the ability to sit together for such actions as pair-programming and brainstorming.
Form pods based around functional modules rather than technology-layer specialties so that every pod owns the quest to deliver end-to-end features more quickly.
Empower pods to implement end-to-end business use cases and deliver the product through to production.
Promote a culture of engineering excellence by having members demonstrate their skills and learn from peers from the very first Sprint.
Offer continuous coaching and intense hands-on learning programs, such as boot camps. Assign Agile coaches in the early going and provide mentoring from more experienced members later on.
Product owners are now experience owners
The product owner role arose with the popularity of Scrum, a framework within which people can address complex, adaptive problems. Scrum ushered in epics, features and user stories as elements of requirement engineering. Continuous collaboration with the business and backlog prioritization became the norm. As defined by Scrum, a product owner is the key stakeholder responsible for managing the product backlog — thereby maximizing the value from working features delivered by the team.
This role is now shifting beyond product backlog management to include ownership of the end-user experience. This new breed of product experience owner is accountable for all outcomes and, with other leaders, helps set and communicate the development vision, strategy and objectives.
This new role supports a more product-centric delivery model, which is essential to retaining and growing the customer base. To firmly establish the role of a product experience manager and its ensuing practices:
Expand the expectations of the most high-performing product owners to also embrace customer, market and performance data to derive strategic insights and actionable plans. If current internal candidates don’t qualify for the new role, consider recruiting an experienced digital product manager.
Ensure leadership supports the new role and practices.
Align the team behind the new approach through learning programs on topics such as human-centric design and customer journey mapping to modernize requirements engineering.
Create and nurture a community of practice for these new product managers.
Agile & DevOps get extreme
In this new millennium, the rise of Agile methods has led to a more incremental product development and delivery model that includes short and sustainable iterations. Agile was followed by a shift to DevOps, which unites development and operations teams in the effort. As DevOps matured, it added new approaches such as a CI/CD pipeline, containerization, auto-scaling and production monitoring.
Today, modern software engineering adds the entrepreneurial Lean startup principles, such as minimum viable products (MVPs) and build-measure-learn. Also entering the picture are extreme programming (XP) practices such as pair programming, CI and test-driven development. Microservices-based cloud native development also is gaining popularity with its greater flexibility, scalability and adaptability.
To adopt the new ways of working:
From the start, initiate a DevOps approach for all Agile projects and promote a culture that bonds development, QA and operations teams.
Adopt Lean startup principles and XP practices by running hands-on workshops and promoting XP practices.
Define and implement a robust DevOps toolchain that can scale across the enterprise.
Design and develop microservices-based cloud-native applications.
IT CapEx shifts to OpEx
IT infrastructure represents a significant capital expense. Project budgets must account for costs associated with stand-alone on-premises servers or sandboxes to develop, stage, QA test and run applications. Moreover, most enterprises have hardware utilization rates significantly below 20% because of the excess capacity required to handle peak demand. This type of application environment also is prone to amass technical debt due to unplanned rework and release-schedule delays.
IT economics has forever changed due to cloud adoption and cloud-native development. A significant portion of capital expenses (CapEx) shifts to an operating expense (OpEx) as subscription models take hold. For one of our healthcare provider customers, we migrated about 50 applications from on-premises servers to the cloud, which yielded a 25% reduction in overall software and infrastructure costs, improved peak demand performance, and greatly reduced technical debt through less rework and more timely release cycles.
To embrace this economic shift:
Identify applications that can be moved from on premises to the cloud through a “lift and shift” migration with minimal or no changes.
Optimize cloud usage by first rightsizing, optimizing for storage, improving elasticity and considering a serverless architecture.
Identify applications that require a rewrite and assign them for cloud-native development.
Jettison legacy technical debt during the application transformation and be cautious not to accumulate technical debt thereafter.
IT shares the reins with business CXOs
In this digital age, C-suite executives recognize that there’s no such thing as a technology strategy — there are only business strategies enabled by technology. As they obsess over improving organizational capabilities, the need to execute fast for strategic and competitive reasons raises a higher bar for IT teams.
There was a time when the CIO led the organization’s technology purpose, but today the responsibility is more blurred. Technical innovation flows through virtually every functional area. In a sense, all executives are now technology executives who must lead the digital migration. As business strategists, CIOs should work closely with functional leaders across the enterprise to help them leverage the power of IT as a strategic force.
To support the C-suite mandate to innovate and accelerate new business strategies:
Create a shared technology vision that becomes part of the CXO strategic agenda, and ensure a close working partnership between the CEO and CIO.
Ensure that Agile-DevOps-driven digital transformation is in the context of this business strategy and team members understand the big picture.
Introduce new roles such as chief digital officer to propel transformation approaches. Within IT, consider new roles such as a full-stack engineer, product manager and site reliability engineer who specialize in modern practices.
Make the customer experience a top priority and engage both IT and the business function to innovate new functionality and offerings.
Ensure that organizational change management practices are applied to these process and cultural shifts and are governed by a collaborative steering committee. Ensure demonstrable leadership support for investments in training, coaching, change management and an overall cultural transformation.
This article was written by Raja Bavani, an AVP in Cognizant’s Digital Engineering Practice.