Think Your Agile Team Might Be Doing Waterfall In Disguise?

At Carbon Five we’re all about process. In many ways, it defines our working style and is something we’re always trying to improve. Given the rise in popularity around agile development, I thought it would be interesting to explore the most common software development characteristics across the wider tech industry. How are most companies developing and releasing products? How does this compare to what industry leaders are teaching? What can be learned for this exploration?

The current state of software development

To start, what development practices are being used at other companies? An interesting study was conducted in which over 50 product manager role descriptions were analyzed across major tech companies (Uber, Visa, Amazon, etc). It’s worth examining PM roles since they’re usually a proxy for a company’s development culture and shed light on how engineering, design, product, marketing, and business stakeholders work together (or don’t).

Among the least surprising insights from the study were that most PMs are expected to constantly prioritize development work, produce product documentation, work closely with engineers, and express customer empathy.

However, somewhat surprisingly, the study also found that most PMs aren’t expected to own metrics of any kind (even though they’re told to be data-driven) or communicate with customers.

These last insights suggest a few things: First, if teams aren’t owning and tracking metrics, it’s likely the simple delivery of a feature is a core metric by which success is measured. Without clear business goals or direction, it’s easy to prove progress by referring to features delivered, regardless of their impact on the business (“Look at how productive we’ve been!”). This quality tends to characterize companies that are focusing on a team’s output instead of its impact on the business and its users. Owning and tracking metrics is crucial to create iterative improvements and measure the impact.

Second, if PMs aren’t expected to speak with customers, we can assume most teams’ processes aren’t user-centric, and user insights aren’t informing product evolution as often as they should.

In all, the insights gleaned from this study paint a contradictory picture of most companies’ process: on the surface, they seem agile but as you dig deeper they’re actually waterfall and feature-driven. What good is being data-driven when you don’t know what metrics to track? And how do you develop and maintain strong customer empathy if you aren’t expected to interact with customers? It’s as if companies are borrowing certain agile concepts and superimposing them on waterfall processes – let’s call it waterfall in disguise. A classic example of this is when companies use short development sprints, daily standups, and planning meetings – all core agile practices – but leverage them to deliver features that have already been fully scoped. What’s agile about a process that’s more about delivering a ‘complete’ feature as opposed to learning and adapting to feedback?

What the industry leaders are saying

Right now leaders are promoting an agile process that enables teams to make data and customer-driven decisions freely and at regular cadences. Their ideal agile process is defined by continual software discovery (proposing solutions and validating hypotheses) and delivery (releases). Marty Cagan does a great job articulating this in his books Inspired and Empowered. His teachings and those of the Silicon Valley Product Group continue driving the greater conversation around modern agile development. This type of agile also lends itself towards being inherently user-centric, a concept being reiterated across the Product Design and UX worlds. If your process facilitates the collection and analysis of user feedback continuously, it’s much easier to develop empathy for users and begin designing and prioritizing around that empathy.

Admittedly, this approach probably doesn’t sound ground-breaking or revolutionary since it’s essentially the classic definition of agile development. What’s interesting is the discrepancy between how most software companies define themselves and their process vs. how they actually operate. It’s as if most companies know what agile is, but again, only implement certain well-known characteristics while neglecting core components. That said, it can be challenging to effectively implement this flavor of agile, especially when a product culture exists that’s at odds with this approach or that’s grown accustomed to working a certain way. For example, a business may love practicing waterfall in disguise because it makes it easier to communicate important feature delivery dates and roadmaps to leadership.

How does this compare to the agile process at Carbon Five?

At Carbon Five, we’re focused on building iteratively, so our process aligns pretty closely to what’s being advocated across the industry. We do leverage traditional agile practices in our process such as daily standups, planning meetings, and retrospectives, but these mainly exist to serve the most important characteristic of our process: continual product discovery and delivery. Central to our process is regularly collecting feedback from clients and end-users so that we can collaboratively leverage insights to plan a product’s evolution. This ensures the right product is built and addresses the highest priority business and user needs.

While each project at Carbon Five is unique, we always strive to get to a place where we can build and learn iteratively with our clients. This often looks slightly different from project to project, but once we achieve this goal we know the chances of project success are much higher. The beauty of our process is its adaptability – across industries, user segments, and use cases – and in this sense, it’s truly agile.

What can we learn from all this?

Waterfall in disguise can have its drawbacks. With a feature-centric process, you naturally sacrifice collaboration and dampen creativity since it’s more about executing on a deliverable than discovering and testing solutions as a team. When execution is all that matters, each team member can get away with simply performing within their swimlane and cross-functional collaboration becomes less important to project success. When it comes to not being user-centric, failing to learn regularly from users leads to important insights being missed and poorly-optimized products. Teams practicing waterfall in disguise often find this out the hard way, and it’s usually not until after a product is live that they realize value hasn’t been delivered.

Lastly, and most importantly, teams should have a clear reason for leveraging an agile process. Borrowing certain agile practices accomplishes nothing if the products being built fail to deliver (the right) business and user value. If the goal is to build products your users will love and continue using, employ whatever techniques you need to ensure you can iterate regularly. Teams must think of agile as a toolbox – it’s up to them to figure out which tools are best suited in producing an environment of continuous feedback. Interpreting agile through this lens will help more companies become truly agile as long as they keep the focus on collecting both qualitative and quantitative feedback and acting on what they learn. Until then, more companies will probably continue operating as waterfall in disguise.

________________________________________________________________________________________________

We’re hiring! Looking for software engineers, product managers, and designers to join our teams in SF, LA, NYC, CHA.

Learn more and apply at www.carbonfive.com/careers