We all remember “Goldilocks and the Three Bears”: the timeless fairy tale in which a little girl stumbles upon the home of three bears while they’re gone. She proceeds to try bowls of porridge, chairs and beds—experiencing too hot, too cold, too lumpy and too soft—until she finds the taste and fit that’s “just right.”

The premise of this classic fairy tale is applicable to finding the development methodology that’s just right for an engineering organization.

Porridge, chairs and beds
Most engineers and product managers I talk to identify their development methodology as either waterfall or agile. In reality, they’ve usually adapted to one or the other (or both) to suit specific needs.

Waterfall is great for planning, but doesn’t lend itself to course correction over the life of a project. As a result, change is actively discouraged so as to hit a delivery date. However, by then the market need may have shifted away from what you’ve built.

On the other hand, agile development encourages adjustments along the way. It also provides insights into the activities and velocity of an engineering team, but not necessarily progress from the perspective of the business. In other words, how do you ensure each sprint is iterating toward a release so that business commitments, such as marketing campaigns and revenue targets, can be lined up?

Too hot or too cold? Too lumpy or too soft?
To illustrate how a singular development methodology might not fit an organization, I’ll share a real-life story:

Once upon a time (sorry, couldn’t resist), a team with the best of intentions adopted agile in the form of pure, textbook Scrum. A dogmatic approach ensured everyone was trained, work items were broken down into bite size chunks, backlogs were rigorously groomed, burndown charts were visible on wall-mounted displays, and stand-ups were conducted daily where dialog outside the three questions (What’s done? What’s next? What’s blocked?) was strictly prohibited. After several sprints, the team became demoralized, and nothing meaningful was getting shipped.

The problem wasn’t Scrum. In fact, the team loved the concept, but putting it into practice in the strictest sense didn’t allow for unique aspects of the team or the product. The focus shifted to making burndown charts look good rather than delighting customers. Moreover, the rest of the business became frustrated by the team’s inability to make and hit delivery commitments, which eroded confidence and morale.

Just right
The role of engineering teams that I’ve had the good fortune to work with has been to deliver relevant products that meet business objectives. Aspects of development methodologies were adapted to fashion a process that met the needs of the particular organization. Here are some insights gained from past experience.

1. Clarity of purpose. How the organization works must align with objectives of the business. Unless you’re in a university research lab, this means delivering software that impacts the business in a predictable and timely way, such as quarterly releases of an enterprise software product or biweekly deployments of a cloud service. In other words, don’t adopt or craft a methodology that’s at odds with the business.

2. Beg, borrow or steal. There’s no shame in taking ideas and practices from known methodologies and applying them to suit your needs. For example, some advance planning for a large project à la waterfall allows a delivery timeframe to be targeted and communicated to the business with some degree of confidence. Then, executing the project using an agile approach enables adjustments in release content as the committed timeframe approaches.

3. The KISS principle. Keep concepts simple so that the methodology itself doesn’t become an impediment to product delivery. Membership and roles within a project team should be crystal clear—development lead, QA lead, product owner, etc. How the team operates should be straightforward and replicable, using the right tools for planning work, executing activities and tracking progress. Most importantly, the methodology must encourage a team dynamic of accountability—not just to one another, but also to the broader organization that’s counting on what the team is going to deliver.

4. People, not widgets. Part of building and enhancing team culture is a sense of personal and collective ownership. Organize projects to take advantage of each individual’s skills and technical interests. Moving engineers between assignments like widgets based solely on capacity needs is shortsighted and inevitably leads to churn on the team. In addition, factor the work styles and circumstances of the team members into the development methodology; for instance, allowing limited dialog during stand-ups beyond just the three questions, or letting a remote team members e-mail progress updates rather than dialing in for every stand-up.

5. Trust and transparency. The development methodology should offer transparency to the broader organization. This doesn’t mean over-sharing details like status of engineering tasks or backlog metrics. Rather, provide visibility into progress against commitments made to the business. Using a dashboard to routinely convey status against specific milestones and frequently showcasing results in open demos helps build trust and confidence that the engineering team is completely aligned with the rest of the business.

As with Goldilocks, trying different methodologies will reveal which aspects are too rigid, too loose, or simply not a good fit for a particular project or team. Combining the best aspects of practices learned directly, or taken from others’ insights, such as the ones described here, should enable an organization to tailor a development methodology that’s just right.