Vision, Value, and the Guy With the Dough

Vision, Value, and the Guy With the Dough

The Secret Sauce to Agile Development Part 1

30 years of experience getting it right distilled into my new blog!

Can your team deliver production-ready, fully tested software at the end of a sprint or are you always falling back to running sales demos from your laptop? Are your planning sessions a nightmare due to constantly changing requirements, is everyone knackered at the end of a release and does the thought of the overtime required to actually get the project out the door fill you with fear?

If any of these statements apply to you or your team then you’ve not got a good hold on Agile! You’re missing that Secret Sauce, the magic ingredient needed to ensure your efforts are fully rewarded with high-quality software delivering maximum value to the customer with only minimum effort from your side.

Through twelve sizzling episodes in this incredible blog I’ll demystify agile development and show you How to Get Things Right, (also called How Not To Royally Stuff Things Up).

Whilst software development has many complicated skills and concepts, I’m going to focus on the basic concepts and keep things simple. That means everyone involved in development can read this, from the BA writing down the requirements, the dev churning out code, the tester, the PM or even the customer wanting to know more about what goes on underneath.

Don’t worry Kung-fu Panda fans, (and let’s be honest who isn’t), I’m not going to show you an empty scroll. When it comes to agile, it isn’t just you, there are important concepts to understand, Wisdom Of The Ancient Masters that’s maybe been forgotten but is far more relevant and useful today than ever before.

Kung-fu Pandas Eat, Shoot and Whoop Butt

Who on earth am I to be talking about this sort of thing?

I’m not just a keyboard jockey, my name is Graeme Clarke, I’ve been a software engineer and architect for over thirty years and recently worked as a director and global head of DevOps at Expleo, one of the world’s leading IT consultancies. I’ve spent a lot of my career helping some of the biggest companies in the world get this sort of stuff right and I’m not finished now. Don’t believe me, why not check out more of my technical articles or conference presentations right here on my personal website:

Throughout this blog series, I’ll employ first principles and best practices to illustrate how to get things right but, I’ll also use the most modern tools and technologies. Look out for the How Does AI Make All This Stuff Better sections scattered throughout, where I’ll be illustrating where AI is of vast benefit, however, be aware that sometimes using AI is actually a bad idea that may even prove a hindrance. No, I’m not off my rocker, and yes, believe it or not, I’ve been working with AI for thirty years or so now and there really are times where it’s just going to stuff your project over but don’t worry I’ll explain where and why when we get there.

To demonstrate that I know what I’m talking about, I’ll present an Actual Live Project throughout these blogs, with plenty of examples at every stage of the journey.

Every article has a Takeaway Today right at the bottom, so if you can’t be bothered reading all my Inane Ramblings you can go right to the good stuff.

If you find any benefit in these blogs or even have a good laugh, then please, please, please give me a share on your social media feeds or around your teammates.

So without further ado let’s dive into it:

Blog 1:

Vision, Value, and the Guy With the Dough

So what really is agile all about? Surely because we have stand-up meetings, sprint planning and use IM instead of writing boring old Word documents, that we are agile??

One of the big words in agile and one that surprisingly few teams ever talk about is VALUE. In fact, if we navigate right now over to the Principles Of Agile Development on the agile manifesto website, we can find this statement right at the top:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Come on, be honest, how many people out there working on an agile team have actually gone and looked at the Agile Manifesto?

This word Value is very important and it’s something we’ll be coming back to. As stated above, it basically means, ‘what the customer wants to get out of the project’. Now, before we get into the detail, I invite you to consider the essential question How Will We Measure The Value Our Customer Wants To Get Out? 

Closely linked to Value is another key term, Return on Investment, which means The Measurable Value Divided By The Amount Of Cash It Costs To Get It.

If you think the point of your project is to deliver lines of code or numbers of tests or perhaps a certain number of story points, then you are sadly mistaken. I’ve met many people who have done a great job closing all their tickets on the Kanban board, thought that everything was going peachy, just to have the whole SCRUM team fired at the end of the project because the guy with the dough didn’t get what he wanted!

No but really, you’re fired!! The copy right police wouldn’t let me use a pic of Alan Sugar so I've had to resort to Copilot instead!

It’s really, really important that everyone involved with the project, including software developers, testers, infrastructure engineers, everyone, understands the value the stakeholders or customers are expecting to receive. This will empower them to make decisions that will positively affect the outcome of the project.

INANE RAMBLING, the POC that went pop

Tell you a wee story. I was asked to review a project for a big European car manufacturer. This was a POC, (that means Proof of Concept for any rooks joining us today), with a single release with a timeline of two months; however, it had been delayed by over three weeks (that’s almost fifty per cent)! The customer wanted to know why the delay had occurred before awarding the supplier any more business.

The project was to extend their mobile app to successfully park a driverless vehicle in a car park with minimal fuss using their extensive suite of REST APIs.

What the customer was looking for was proof that the crack team of engineers could handle complex algorithms; they didn’t care about things like project management, quality strategy or release, as these had already been proven in other projects. They just wanted to see that the team could write hard code in a simple way. Once the POC was completed, the intention was to bin the lot and start on a completely new project, (as quite frankly the client already had a car parking app which worked pretty well).

Unfortunately, no one had bothered to tell the development team. The coders decided to build in extra resilience, the testers went deep into non-functional testing and the ops guys wrote way too much hand-over documentation.

Fortunately, these were all nice things to showcase and the supplier managed to win the new business. However, the customer didn’t want and refused to pay for any of it forcing the supplier to foot a three-week bill and putting them firmly into the red for the project.

Best way to go out of business, make a loss on every project!

If only they had all understood what the client actually wanted in the first place!

That’s why our Take Away Today is To Understand The Value Of What The Customer Wants And How It Will Be Measured.

In the next blog, I’m going to talk about Epics, Features and User Stories and how to write these stakeholder requirements down properly and make sure the information is communicated to everyone in the project. But for now, let’s just focus on getting that conversation with the customer and finding out what it is they want.

It may be we’re talking to their CEO, a sales manager, or an end-user focus group. They may also have written down some requirements, or they might be able to draw a picture on the whiteboard, or maybe it’s a Caffeine-fueled Fever Dream brought on by Fifteen Straight Espressos. No matter, let’s just get something down on paper.

One of the pillars of the Agile Manifesto is Customer Collaboration over Contract Negotiation. That’s why it’s so important to actually go and talk to the main stakeholders. Let’s just be clear, by Main Stakeholders I mean those people with the cash what are actually going to pay for the project.

What you need to do is to get a good understanding of what it is they really want, let me rephrase that, What Value They Want To Get Out Of The Project and then agree to how it’s going to be measured.

REAL WORLD EXAMPLE, Gamifying the Storefront

Ok, so for an actual example, here’s a bit about the project that I’ll be following through on each of these blogs.

Our client is a small-time entrepreneur and Dell-Boy wannabe who has written books, games, mobile apps and has a whole bunch of revenue streams that bring in small amounts of money. He wants to tie all this together in an online store where his full range of products can be purchased.

This time next year Rodney, we’ll be millionaires!

We took him out for an extra-large Americano and on a caffeine high and talking at four hundred words a minute, he outlined his vision for the software.

First of all, our customer is a massive Pokémon Go nut, (tbh I’ve started playing it as well, if you’ve not got sucked in then I recommend downloading it right now and watching all your free time go up in smoke).

Pokey has this awesome achievement system where you can earn coins by catching Pokémon, taking down Pokémon Gyms and completing research. These coins can then be exchanged for digital content, including power-ups within the game itself. If the end-user doesn’t have enough coins, they can even purchase them for hard cash, (yeah it’s a total money spinner, wish I had invented it).

Our customer envisions using the same approach. Coins could be earned through achievements in his games and mobile apps, they could also be obtained by purchasing and reading books and then, most importantly, leaving reviews.

Coins could then be exchanged for some products or put towards the cost of new stuff in the online store.

Our customer outlines in true sales fashion that even the data from where these coins were earned would be incredibly useful, as it would show what products the end users enjoy most and where he should put further investment.

Here's a picture of the Pokémon Go store from the app on my iPhone just to give an idea (yes, I’m hooked too). It’s got the total number of coins available to spend, (currently 939), and some of the different products that coins can be exchanged for.

And, further down, we’ve got options to purchase more coins using hard cash. Wow, who in their right mind is actually going to spend like ninety-nine quid on Pokecoins? Knew I should have taken up a job for Nintendo.

OK, good background, worth keeping notes on this. If you don’t have some sample screenshots like this for your project, then it may be good to draw a diagram or perhaps your stakeholders have another picture that’s worth capturing. Now, don’t get confused or jump the bandwagon, this diagram most definitely isn’t the high-level architecture, this is just a picture to help us establish the vision.

Although the Agile Manifesto does say that We Value Working Software More Than Comprehensive Documentation, it also says that while there is Value In Having Documentation, We Value The Working Software More.

This is one of the big gotchas in Agile, it doesn’t mean that we shouldn’t have any documentation at all. Going down that route invites disaster, as no one will remember exactly what was agreed or what has to be delivered.

Now is one of those important times that we need to get something written down so that there is no ambiguity with our stakeholder. These are the questions we need to answer:

  1. Who are our main stakeholders and what are their roles?
  2. What value do they want out of the project, and how will it be measured?
  3. Are there any constraints on the project?

Let’s write down the answers now:

  • Stakeholders: 
    • Mr. Charlie Bluster: company owner and budget holder. The company writes games, books and other digital content.

    In this example, we have only one stakeholder; if there are more, then we should write them all down.

    • Value: i.e. what goals the stakeholders have and what numbers are important? There may be more than one per stakeholder or a single goal shared amongst multiple stakeholders.

    Wow! Hold on, what value do they want and how will it be measured??

    What is the measurement thing you are waffling on about? Guess what, successful software isn’t just about churning out lines of code or vast quantities of tests. What you’ve got to realize is that the budget holder actually has something he wants and, believe it or not, it’s very rare indeed that this sort of information gets communicated down to the dev team.

    Anyway, let’s ask him now: Hey Charlie, what do you actually want to get out of this project?  “Well, Bob, what I’m looking for is:”

    • Value
      • Increased customer engagement
      • Increased revenue (generated by cross-sales)

    • Measurements: how will this value be measured?
      • Increased number of product reviews.
      • Additional hits and longer time spent on the company website.
      • Additional user time spent playing games and using mobile apps.
      • Increased number of reactions to social media posts.
      • Increased profits from cross-sales across all products.

    Now that we’ve got an idea of the measurements, we also need to have a benchmark, i.e. what numbers do we need to get to ensure the success of the project.

    • Benchmarks
      • 20% increase in each of the five areas listed above.

    Finally, what about the constraints:

    • Constraints:
      • A grant has been provided to develop the software, any runtime costs must be taken out of the profits generated by the new development. That means that the benchmarks we talked about above must be hit once any running costs have been deducted.

      This sort of information is incredibly important to record and communicate to the rest of the team. It means that a lot of potential technical solutions will be ruled out.

      For example, let’s say we decide to use a relational database in the final solution. If we plumb for Microsoft SQL Server running on Azure might introduce significant hosting and license cost that will quickly eat into the profits. Especially as we are talking about low-income revenue streams, such a selection could put the project very quickly into the red.

      What happens if we don’t hit these benchmarks? Almost certainly further development in the project will be cancelled and we won’t get any more work. Therefore, it’s in our interest to ensure the project is a success and that we have a happy client. Now, a lot of this will be down to the appeal generated by their content and the associated marketing and although we may need to support those efforts, it’s firmly the responsibility of the client. Our job is to make sure we provide high-quality working software that will deliver what they are looking for.

      Before we finish this post off, a quick word on where we should store this stuff. Let’s not put too much effort in at this stage just to change everything later on. I recommend just putting it somewhere everyone can access it like the project OneNote or Confluence, or even just a Word document in a Teams folder.

      TAKEAWAY TODAY

      Take Away Today is to understand the value of what the customer wants and how it will be measured.

      Master Shifu says “If you don’t know what success looks like, you won’t know when you’ve missed it.” Well, Ok, maybe he doesn’t say that; instead, he probably waffles on about Inner Peace, but, if he was into software development as well as Kung-fu, then that’s exactly the type of wisdom he would be spouting.

      This may sound stupid but, if you’re able to record and communicate the sort of information we’ve talked about above, then you’re already on the road to success and ahead of half the teams I’ve ever worked with.

      How Does AI Make All This Stuff Better? In my opinion, this is one of those times that it’s best to leave AI out of the equation. The reason is that we’re trying to capture what the customer wants in their own words. This is particularly important to ensure the customer feels they own the project and are fully bought in. Don’t worry, there will be plenty of opportunities to play with AI later.

      TUNE IN NEXT TIME

      Don’t miss next week’s gripping episode in our journey into Agile Software Development, where we’ll delve into actually writing down the requirements, an area that is normally fraught with danger, hair loss and royal stuff-ups.

      Thanks for reading, I hope you’ve enjoyed my inane ramblings and got something useful out of this. If so, can you please share this on your socials, as I need as many readers as possible to keep this blog going.

      Now go build something brilliant. And remember: value isn’t just what you deliver, it’s what your stakeholders actually notice.

      Sayonara and until next time, keep it Agile!

      Additional Image Credits

      .