Seven Changes that Will Shift Your Software Development Approach for the Better

Like many of their business and IT counterparts, application development organizations are at a crossroads. To deliver software offerings that hone their competitive edge, they can’t continue doing business as usual. And yet, in the face of day-to-day maintenance, integration and delivery challenges, many organizations find it challenging to adopt the new behaviors, processes and skills required to affect needed change.

In many cases, the difficulty lies in simply knowing where to get started. Here are seven essential steps that can help application development organizations get started on delivering the right software at the right speed to drive competitive advantage.

Step 1: Pair Programming

Pair programming involves two developers working together at one machine, with one programmer (the “driver”) writing code while the other reviews it and considers its strategic architectural implications. Together, the developers can identify more solutions to problems than they could on their own. As team members rotate among these roles, they gain more confidence in identifying issues and offering resolutions. Paired partners can also step in for one another when fatigue sets in, increasing productivity.

Step 2: Continuous Integration and Continuous Delivery

The traditional approach of delivering and integrating code every 12 to 18 months doesn’t work anymore, as customer requirements will have changed by the time the code is delivered. Instead, businesses need to deliver and integrate code four, five, six times a day — and often more — to enable rapid feedback cycles and validate that what they’re building makes sense to the customer. Continuous delivery and test-driven development (see Step 3) enable developers to work in small batch sizes and deliver changes immediately to obtain fast customer feedback.

Listen to Brian Roche, a Cognizant Digital Business VP of Digital Engineering, share his views on CI/CD across multiple dimensions.

Step 3: Test-Driven Development

No longer can quality assurance be pushed downstream, when it’s most costly to fix issues. Testing processes need to occur earlier in the software development life­cycle and be executed more frequently. A test-driven development approach involves first writing the test code that describes the expected behavior of the implementation, and then running that test. Once changes are made, and the test passes, the code is refac­tored to remove extraneous code and make it as efficient as possible. Refactoring is essential because the more code that’s written, the more code that must be maintained over time, thus increas­ing long-term costs.

Step 4: Balanced Teams

A balanced team is a self-contained DevOps group that is interconnected with but independent of other groups in the organization. Its members, who rotate among various roles, use their different but complementary skills and perspectives to help each other reach a shared goal.. By keeping the team small and structured, no voice or opinion goes unheard, and no task is too big to tackle.

Step 5: Feedback

Building teamwork and trust requires delivering the right kind of feedback in the right way. In addition to eliminating finger-pointing, this requires acknowledging the time pressures and priorities faced by different team members. It’s also important to encourage all team members to report problems and suggest solutions. In weekly retrospective meeting, teams should discuss what went well, what was “meh” and what didn’t work. Weekly meetings clear the air of miscommunication or misunderstandings, and prep the team to resume work more efficiently the following week.

Step 6: Build-Measure-Learn with MVPs

The build-measure-learn process involves building a minimum viable prod­uct, measuring its acceptance and use, and enhancing or adapting it as needed. This approach allows developers to build code in relatively small increments (as discussed in Step Two), based on a hypothesis of the cus­tomer or user need.

An MVP is a feature that is functional enough to generate customer feedback, with the understanding that it will be tweaked and improved over time. By delivering the first MVP very early in the development and product definition phase, businesses can reduce wasted effort and speed results by identifying which features users don’t care about, and highlighting the ones that are most important.

Step 7: Eliminate Waste

Developer resources need to be focused only on what helps them meet their daily and weekly goals. For example, required meetings should be limited to three per week. This includes the daily stand-up, capped at 15 minutes, where each team member tells the group what they did the day before, what they will do today and the obstacles, if any, they face. A second meeting is the daily iteration planning meeting, in which the team ensures it understands the stories designed by the project manager. It’s also an opportunity for developers to understand their paired goals, and discuss how to mitigate identified roadblocks. The third is the retrospective meeting dis­cussed in Step Five, in which the team reviews issues and plans course corrections. Outside of these three meetings, developers should be protected from any distractions.

It may be tempting to turn back when inevitable roadblocks are encountered. When such problems are encountered, businesses can’t afford to give up. Instead, they should work through the challenges the same way that they iterate code: by continuously tweaking, testing, communicating and improving.