Agile teams MUST focus on delivering value.

For a quick recap of Part 1 (available here), we talked about Waterfall’s quest to plan the entire path forward, execute said plan, and then to verify the implementation worked as expected/needed.  Early in the article, I shared how Agile considers Waterfall’s approach naive, because you’ll never know less about the project than you do right now, and stakeholder needs change.

So, how does Agile handle this better?  – Focus on value delivered.  With this in mind at all times, iterate.

I recently had a conversation with a friend (who is also a client of ours) in which I said something to the effect of “Clients would much rather you deliver 3 gallons of their highest priority features than 5 gallons of random unrelated work from the product backlog.”

Don’t ask me what world I live in where we’re measuring features in gallons.  It was a flippant comment I threw out mid-conversation, but I think it holds water (maybe 3 gallons worth?). 😉

Some stakeholders will in fact say they’d rather have more work completed than worry about focusing on the highest priority work.  This is especially true when said stakeholder(s) do not expect anything to be released for a while.  The “Well, it’s all gotta be done” attitude.  In concept, it’s completely understandable.  The problem is that it makes the same assumption that Waterfall does.  It assumes that we can get it ALL done before we HAVE TO release or something major changes in our timeline or budget or scope.

That’s a lot of “or’s”.

I’d be curious to hear your experience, but mine says that this is not ever always a safe assumption.  I’ve also seen dev teams struggle to demonstrate value (or ROI) to stakeholders without tangible deliverables.   Spend 20 minutes explaining to stakeholders that the dev team “got a lot of work done in the database, built a really nice API gateway and also – the UI for a new feature is almost ready to demo but not ready to show today”, and you won’t see emotions that resemble joy or happiness.  On the contrary, if you hand stakeholders 3 feature updates they’ve been asking about for the last two months, you’ll get a much more rewarding reaction.  Stakeholders will associate this success/happiness with a successful dev team.  Do this several sprints in a row and you’ll likely find yourself with some very happy stakeholders that go around bragging about their team.

After experiencing both of these deliverable scenarios throughout my years as a Scrum Master, I coined a phrase that I began repeating often.

“Value that is not perceived (by stakeholders) is not value.”  

Is it shortsighted?  Absolutely.  But, it has served as a constant reminder to whatever team I’m a part of that we must do our best to ensure the stakeholders can see the work we are delivering.

Quick note to my dev friends reading this – YES.  Technical debt absolutely matters.  But, you need to work with your stakeholders (and Product Owner if applicable) to communicate why each technical debt item is really a business need, not a developer preference.  If the dev team truly focuses on perceivable value, the level of trust from the Stakeholders should make the tech debt conversation a little bit easier every day.

I honestly considered ending this post here, but I know based on past discussions and Agile Transformations that there is an “OK, BUT…” that often follows this conversation.

It usually goes something like this,

“It’s great that Agile focuses on ‘delivering value’ and ‘owns’ the fact that teams can’t accurately predict change and therefore shouldn’t try to plan out every detail of software projects.  Great.  So does ‘being Agile’ mean we’re supposed to throw out planning, budgeting, creating roadmaps and instead just require blank checks and unwavering trust from clients/stakeholders?”  

In case I have to say this… Of course not!

A common misconception (and frustration) around Agile is that it devalues the idea of project estimates and roadmaps.  This is so far from the truth.  I would argue that Agile creates a significantly BETTER approach to such management tasks (at least for most modern software projects).

Remember the points of failure in Waterfall that were the cause for creation of the Agile Methodology?  Waterfall projects may boast of ele-Gantt timelines full of keyword-milestones and a detailed software specification, but in the end, they rarely ever stick to any of these timelines (or milestones, for that matter).  Change Requests blow away deadlines and budgets.

Agile, on the other hand, predicts this level of change and encourages you to plan no further than you can realistically see.  Not only that, but it encourages you to develop software in a way that starts providing value/ROI quickly by releasing software early and often in smaller usable portions.  This concept, though seemingly simple, is CRITICAL to understanding the benefits of Agile.  It is called “Vertical Slicing” and would be a great topic for a future blog post…

With vertical slicing and incremental releases, gone are the days of waiting for 36 months to see any return from your new software.  More importantly, you don’t have to wait 36 months to find out what assumptions were incorrect.  By planning and releasing in smaller increments, you get real-world feedback early and often, allowing you to adapt future plans accordingly.  This adaptation is not disruptive when distant project plans are kept very high level by design.  Rather than spending time deciding, architecting and documenting feature details to the nth degree about something that’s a year away only to rewrite three-quarters of the acceptance criteria in 18-24 months (yes, my math was correct there), Agile encourages you to record high-level notes about the conversation that needs to be had and to leave the detailed discussions for when it comes time to prioritize said feature in the release timeline.

So, how does one create Agile versions of roadmaps and software budgets?  The in-depth explanation will have to wait for a different day, but know that it’s very possible and there are many great resources out there available with a quick internet search. The short answer is that if your organization adopts Agile, you must educate your stakeholders on Agile.  Can you give someone a +/-50K price window on a $1.5M project? Absolutely not, but neither can Waterfall with its 110-page SRS document.  All it can do is guess (and then be wrong).

Agile starts the conversation with “I think I’m wrong.  Now, how quickly can we prove that?”

The benefits of Agile start here.  Maybe you should too?

What were your thoughts when reading this post?  Does anything stand out as helpful?  Insightful?  Frustrating?  Short-sighted?  Please join our discussion on LinkedIn to share your thoughts or email us directly below.  We’d love to hear from you!

In my next post, I’ll dive into the topic of “When does Agile Succeed (or fail)?”.  I plan to write on management’s impact on Agile as well as other factors that can make or break an implementation.  If there is something specific you’d like to see in that next post, please let me know!