It never happens how you expect

There's a lot of advice out there for parents; books, TV shows, blogs, NCT classes, midwives, family, friends etc.

Thing is, none of them are written specifically for your children or you. It's a bit like that with Agile, or Waterfall. And Scrum, Kanban, Crystal and Extreme. I'm not going to explain what all of these are as a lot has been written already (even I had to Google the last two, so you can too). Over the years, as I've experienced many of these different approaches to software delivery and team organisation, culture & structure, there's one thing I've observed - it's very rare that an organisation adopting one of these approaches follows it to the letter. There's usually an adaptation here or there - sometimes big, sometimes small.

Methodologies are created to tackle real-world issues and make real-world improvements, but they're based on the hypothetical, not on the business you're in today and the people in your team right now. It's exactly the same as all the material written to help parents be better parents and improve the way they raise children - amazing to read, full of good ideas and advice, but when it comes down to guiding your own child, or working with your own team, you kinda have to keep all the knowledge in your head but learn and adapt to what does and doesn't work as you go along.

One of the best digital teams I worked with were quite happy to flip between Scrum and Kanban depending on what they were working on (and who was in each squad). This is because they were focussed on outcomes, not on their output or the methods they used. Outcomes ruled, and as long as the team found their groove to give them the best chance of reaching the outcome, it didn't matter how they did it. I've also delivered huge digital change projects with a blend of Agile and Waterfall - it's really hard, and not for the faint-hearted, but it can be done. It works for businesses where some parts of the company can move quickly, but others are more time-bound - perhaps there may be a need to train hundreds of agents in a call centre, or expensive TV advertising booked for a certain date where the digital product needs to be completed by a point in time. Agile purists will sometimes groan at this, but it's an operational reality in many large businesses. If that's your reality, you just have to adapt as you go and focus on the outcome. It really is just like raising kids - you let a few things go here for a benefit over there, and get the improvements or outcomes that you wanted. Hopefully!

It's hard to know what it's going to cost

The one thing that digital development and children have in common here is that the more you do it, the more expensive it is! However, as you gain experience you can also become more efficient, learn short-cuts and be more prepared (I was way quicker at nappies with child #3...).

One of the arguments against Agile is that it's hard to manage and forecast budgeting & cost. A more traditional waterfall approach to software delivery says that if you define exactly what you're going to build up front, how you're going to build it and who you need to build it for you, then you can very accurately predict how long it will take and what it will cost. Great! The problem with this is that what you start to build in February may not be what users want any more by the time they get it in August, so you risk building in redundancy, waste and re-work to stay relevant to your customers. Agile tackles this by promoting a working culture that values working software over documentation, and facilitates techniques such as Minimum Viable Product (MVP) & iterative discovery & delivery. All of these allow you to develop gradually, with users at the centre of your process (not just being consulted before you start and after you launch). It enables you to change course should you need to, and maybe even stop all together if you discover that it's just not what users want. This is a huge benefit over Waterfall as it de-risks almost everything you do.

When a business tries to introduce Agile working, it almost always falls down when the culture is only there in the software or digital team, and not in the other departments that are needed to support, finance, interact with or operationalise the end product. I've worked in a few places where the biggest sticking point has been finance; how do you get approval to spend £1m on a project in a more Waterfall organisation that's to be delivered by Agile if you can't guarantee that what you start building will be the same thing that you finish with, and that it may not even be a success? Believe me, it's hard.

To solve this, again, you have to bring the organisation along with you to focus on the outcomes, not the outputs. You have to move the conversation away from asking for £1m to build a new e-commerce website to asking for £1m to deliver 50% more sales after 3 years. Focus on the outcome not the output - trust the team to discover how to get the sales and deliver the right things to do it, don't specify WHAT they should build before they even start. And be prepared for them to tell you after while that it's impossible to increase sales by 50%, but that they've managed 35% and discovered a whole new revenue stream along the way by listening to and really understanding customers' needs...

As for children, most of us really just want the outcome of them turning into happy, loving, healthy, self-sufficient and responsible adults. What we can do as parents is to give them as many of the frameworks, space, time and resources that we can to get there. You don't know at the start what it will cost or when each outcome will happen, and you can't tell them they HAVE to do it the way you want them to (well, you could, but see the 2nd paragraph above - you may get the output you wanted at the start, but not the outcomes I've just mentioned).

They're both extremely rewarding from day one

This last one is a bit quicker.

Agile also enables teams (as long as they have a good Product Owner, ahem - here's one if you need one!) to deliver value from the start of a project, not just waiting until launch at the very end before measuring the impact. Remember the MVP thing? An early first version of a product, no matter how many features it's missing or bugs it has, can deliver value for the business even if it's not complete or perfect. The value may be in finding out it's not right, or that it's exactly right (it's likely to be somewhere in-between).

It's like that with growing children; every developmental step is incredibly rewarding for you, no matter how wobbly the step or unclear the word, its progress. Kids don't wait to try walking until they know exactly how to walk, or learn an entire language before saying their first word. With software or digital products, you will deliver value much quicker by giving your first customer your early proof of concept trial instead of waiting until you've built in multiple features that you think all work perfectly. You can develop and deliver the right things faster with Agile.

Talking of first versions of things that are a bit rough around the edges - remember that podcast I mentioned briefly last week?

Here's the pilot episode. It's not even on a podcast platform yet. This is an unedited, uncut first episode of "Three Shaved Heads", a podcast of product development musings (covering UX design, product management & software engineering). There are audio issues, pauses and some mistakes, but we did it, and we want your feedback please!