Many people think that waterfall is the only way to work, and they don't understand what is agile.

In waterfall development, a business analyst gathered requirements well in advance, then they created a feature from those, adding detail after detail until they got something they could estimate.

They (or a manager) put them onto a Gantt chart, and threw them over the wall to the programmers, who build exactly what was presented to them, then threw it over the wall to QA. A team-level Project Manager kept them on schedule with regular reports and meetings.

How is that different from what many so-called "Agile" teams do, though they use Jira and a backlog instead of Gantt charts and pretend that the requirements are "stories"?

Agile is a radically different way of working that bears essentially no resemblance to what I've just described. If what you're doing looks like that, my suggestion is to look long and hard at how you work.

Agile vs Waterfall

This is the most commonly seen workflow:

<ol>
 <li>Product managers talk to users, scope requirements, prioritize things to build, and manage the delivery of new features.</li>
 <li>Product designers also talk to users, and then mock up features, bringing requirements to life.</li>
 <li>Engineers build what’s defined in the requirements.</li>
</ol>

I know this is a simplistic view, but many companies operate this way, in effect creating silos between the different groups, which leads to misalignment on what people are trying to accomplish.
Everything I described above is about outputs.
If you ask a developer, “What’s your job?” they might say, “To build what I’m told.” (I’m exaggerating to make a point.) That’s not their job. Their job—as is the case with everyone building stuff—is to solve problems and create value. Defining the specific tasks to get there is much harder, but the outcome is value creation, not lines of code, features, or anything else.

<h2>Outcomes > Outputs</h2>

If you can get your entire team aligned on outcomes over outputs — solving problems and creating value — instead of the details of the work they’re executing, you have a chance of creating something significant.

Building Value

Let me share a story that left a lasting impact on me. I was at work, and the time for the quarterly feedback session with my team lead was approaching. Like most people, I prepared myself for the usual routine of hearing some praise followed by areas that needed improvement.

On the day of the session, my lead surprised me. Instead of immediately sharing his thoughts on my performance, he asked for my feedback first. It caught me off guard, as I didn't have any major concerns to raise. We had been having ongoing conversations, addressing any issues as they arose, rather than waiting until the end of the quarter. When he asked if I felt supported, I genuinely nodded. He had always been there for us.

Then it was his turn to provide feedback. The first point he made was a compliment, bringing a smile to my face. The second point was also positive. I waited for the expected "but," the criticism I assumed was coming. But to my surprise, it never came. "That's all," he said.

I felt a sense of lightness. Leaving the session, I wasn't just relieved, I was genuinely happy. This meeting turned out to be a game-changer for me. It shattered my belief that feedback always had to include negative points. I developed a new level of trust with my lead, which fueled my motivation to work even harder.

That day taught me an important lesson: negative feedback isn't everything. We tend to believe that feedback is solely about pushing people to grow by pointing out their flaws. But isn't it equally crucial to acknowledge their strengths and accomplishments? Sometimes, individuals may not even realize their own value. So, why not utilize feedback sessions to recognize and highlight their contributions as well?

An Awesome Feedback Experience

A familiar knot of dread twisted in John's gut as he saw his competitor's announcement. Three new features, each a perfect echo of their clients' frustrations. Panic gnawed at him. His team, talented and passionate, was falling behind in the startup race.

Back at the office, tension crackled. The sales team was swamped with calls from clients, all asking the same question: "When will I get the feature that you promised me?" In a team meeting, John's voice held a heavy weight. "I know everyone's giving their all," he said, "but we need to be smarter. We need to prioritize features that truly matter to our clients."

John, ever resourceful, remembered As One, that frontend-focused software house known for navigating startups through tech's ever-changing landscape. With a flicker of hope, he reached out, laying bare their challenges. As One swiftly assembled a team, focusing on three pillars:

<ul>
 <li>User-driven choices: Through surveys and testing, they unearthed client needs, empowering John's team to make informed decisions.</li>
 <li>Faster development: As One introduced modular design, allowing them to break down complex features for quicker development and testing.</li>
 <li>Stronger collaboration: They emphasized open communication and collaboration, fostering a culture of shared ideas and building trust.</li>
</ul>

John and his team crafted a clear roadmap. As the new features rolled out, John watched with a swelling sense of pride as his team's hard work paid off. Client satisfaction soared. The road ahead held challenges, but John knew his team, united with the right approach and the right people, was ready to face them.

Have you ever faced such a challenge? How did you tackle it?

Management

Agile vs Waterfall

Building Value

An Awesome Feedback Experience

Client-Driven Innovation: A Startup's Path to Victory

Need some help?

Services

Products

Cases

Blog

Contact