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 mindset increases a team’s ability to explore requirements, how looking at a project through the eyes of an architect helps businesspeople 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? Is it 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. Seek feedback from your team members and business partners.
What are you doing well? Those are practices to leverage.
What slows you down or causes friction, rework, delays, or defects? Look closely for waste: wasted time, wasted expertise, wasted money.
Be sure to look at 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 with their IT management. This led them to collaborative portfolio, product road-mapping 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 sometimes 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 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 brown-field development—as well as acquiring and integrating commercial/off-the-shelf 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.
Ellen Gottesdiener is principal consultant and founder of EBG Consulting. Mary Gorman is VP of quality and delivery at EBG Consulting.
