Are Your Software Development Practices Jumping the Shark?

By Ellen Gottesdiener and Mary Gorman

In September 1977, the TV sitcom Happy Days had über-hip Fonzie, clad in leather jacket and swimshorts, water ski over a shark to prove his mettle—and at that moment even diehard fans knew that the show was past its prime. They were right. After that episode, ratings plummeted, and the expression “Jumping the Shark” was born. When a TV show, or anything else, jumps the shark, you know it’s on its way out.

Our question this month: have any of your software development practices jumped the shark?

For example, are there boundaries around people’s roles? Some organizations tend to confine people to roles such as developer, architect, business analyst, user experience expert, database administrator, network administrator, project manager, tester, and quality assurance analyst. Deliverables are role focused, and cross-fertilization is discouraged or even prohibited. Among the worst effects of role-boundary-itis is handovers. Each player focuses on a discrete deliverable, throwing it over the wall from one “role” to the next.

Agile and lean methods challenge role segmentation. Just as in the early 1990s, product development using cross-functional “heavyweight teams” boosts design and development efficiencies and productivity. These methods aim toward a delivery team focused on the goal, not the role. Many times we’ve seen how adopting a tester mind-set increases a team’s ability to explore requirements, how looking at a project through the eyes of an architect helps business people reduce risk and increase quality, or how channeling a business analyst helps avoid costs and protect revenue.

Or maybe your team has jumped the documentation shark. Is the documentation you create truly valuable for its consumers—both usable and useful?

Do your development practices focus on projects, rather than products and portfolios? For your business partners, the value of the software you create doesn’t come from project completion but from delivering business value.

Hit the Pause Button

Stop and consider. Hold a team retrospective session, and take a close look at your last two or three efforts—or even one that’s going on now. Actively seek feedback from your team members and business partners.

What are you doing well? Those are practices to leverage.

What slows you down, causes friction, rework, delays, or defects? Look closely for waste—wasted time, wasted expertise, wasted money.

Be sure to retrospect not only the product but also the process. One team we worked with assessed its product release process by mapping the value stream from request to delivery. They were surprised to discover bottlenecks in the process, including delays due to late handovers as well as extra testing and rework caused by late engagement of business partners.

Another team explored how they communicated among themselves, with their business partners, and up the line to their IT management. This led them to collaborative portfolio and product roadmapping and greater transparency. Still another group, which built complex systems that involved regulatory compliance, analyzed their process and product data. They uncovered patterns of behavior that helped—and some that hindered—their practices.

Other ways to search for signs? Ask your team to identify their most useful and most wasteful practices. Take your customer to lunch, and be transparent about your quest for a sharp critique. Conduct a short online survey to identify suspect practices. Be on the lookout: if you find nothing, your team may have issues with trust.

Stop doing something you suspect is unproductive, and see if anyone notices. Hold lunch-and-learns so that folks can share recent learning, improvements, and suggestions. Use short facilitated activities to identify problems and opportunities in your development process.

As you seek out shark jumping possibilities, include all the types of development you do—new software, enhancement, or brownfield development, as well as acquiring and integrating COTS packages. Some teams suffer from amnesia—they forget to apply good practices used in one type of development to another.

Fast Forward

We’re not suggesting you have to jump on the agile, scrum, lean, or any other bandwagon. Effective software development stands on the shoulders of sound sustainable practices that still provide value.

Taking a collaborative and courageous look at current practices can uncover uncomfortable truths—and lead to stronger teams and partnerships. Consider how your teams use practices whose time has come and gone. Or, how they misuse or ignore practices whose time is now. By pausing to reflect, you might find ways to put your best foot forward on terra firma, not shark territory.

Authors’ note: a version of this blog posting will be published in SD Times, April 2011

Resources:

• See Fonzie Jumping the Shark
• Learn more about retrospectives: by reading the article “Team Retrospectives”, another short article on Retrospectives, Norm Kerth’s seminal book on Retrospectives, Diana Larsen and Esther Derby’s fabulous book on Agile Retrospectives
• A positive way to reflect on current practices is to integrate appreciate inquiry (AI) into your retrospective. Read how AI is used to improve practices, in this case, agile requirements practices.
• Heavyweight teams are described in Clark and Wheelright’s 1992 book Revolutionizing Product Development: Quantum Leaps in Speed Efficiency, and Quality . Read an article on how they were used at Eli Lilly and Company to develop and launch Evista