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.