A thoroughly subjective and potentially inaccurate extended metaphor about why weddings are Agile but pregnancy is Waterfall
Note – I wrote this 3 days before I went into labour.
There are entire books dedicated to the difference between Agile and Waterfall approaches to project management and delivery. Websites, blogs, training courses, conferences, motivational speakers – the topic is vast, and clearly a money spinner for many different companies and individuals.
Officially, I’ve been working in an Agile manner, or at least on projects which claim Agile adoption, for a little over four years now. But in reality every project and team has had a different level of Agile adoption and no single project has really been a “true” Agile development where the team in question had the ability and authority to pivot or self organise. Instead those different teams have been working under the auspices of larger organisations with specific expectations about delivery which limited (to one extent or another) the team’s abilities to adopt Agile fully.
This is not a criticism. This is reality.
I have not yet had the opportunity to work in a smaller start-up environment where an entire company is dedicated to a single product and there is no external oversight insisting on set delivery dates or resource budgets. I’m told they exist and have even talked to friends who’ve been there and done that – but they admit that even then Waterfall has a way of trickling back in. Water after all does that; liquids find all the cracks.
But this is not intended as a criticism of Agile or Agile implementations. It’s not an attack on Waterfall approaches or methodologies. One of the benefits of having managed projects and deliveries using both methods is the ability to see both sides, and their advantages and disadvantages. An Agile solution (while still currently incredibly fashionable) does not solve all problems. Waterfall is not (always) the devil.
Choosing what approach to follow should really come down to what the nature of the project is.
And here I come to my extended (and potentially inaccurate) metaphors.
In 2017 my husband and I planned and delivered our wedding. We (or should I say I?) will also see the birth of our first child in October (he was clearly involved in the initial requirements gathering for that one but has had a limited role in the following 9 months so has been downgraded from delivery team member to stakeholder). In fact at the time of writing, my due date is tomorrow.
It’s been a very busy year.
Planning a wedding is incredibly demanding. Fortunately (or I suppose from some people’s point of view, not) this was not the first time I have planned a wedding. This is my second marriage and I intended to use every bit of insight and knowledge that came out of the first one to ensure that this is my last marriage. But anyway, planning a wedding takes a lot.
Conceiving a child, depending on various health conditions, is also not without challenges. Pregnancy, while it has certain set conditions, also has a lot of unknowns. And childbirth… well I’m looking forward to the end result. The path to that delivery does not thrill me.
Before I departed my job for maternity leave I chatted to a colleague about all of the change in my personal life, and she, knowing of my training as a scrum master and product owner, teased me about falling back onto Waterfall ways in terms of carrying a bun in the oven. And it got me thinking.
A wedding is a thoroughly Agile project, but pregnancy can only be Waterfall.
For a wedding, what really matters, what you truly need, what constitutes your Minimum Viable Product (MVP) is the ceremony and certificate. Regardless of. your faith (or lack thereof) the core component of any wedding is the ceremony and (under British law at least) the signing of the wedding certificate before witnesses and officials.
Hilariously this is the part that it seems most people spend the least on during weddings.
But you do that and you’re married. Without the MVP of the ceremony and certificate, you’re not married. You may still adopt each other’s names and throw a great party, but in the eyes of the law, that’s not a wedding.
Your MVP can be a civil ceremony or a religious one, it can be in a church or a town hall or on a beach or in a legally sanctioned function room at a country hotel, but so long as the ceremony is completed (by whatever stripe of official meets your needs) and you sign a weirdly shaped bit of paper, you’re married.
It can be long or short. You can make your guests sing, dance, or as at one of my brothers’ weddings, come up on stage to literally tie bride and groom together; it doesn’t matter. You complete the ceremony, do the paperwork and wham! Married.
Weddings are Agile. Pretty much everyone has an idea about what they want (for my husband-to-be and I it was good food, good booze and good dancing – though I was only able to really partake in one of those due to being six months pregnant at the time) but all of those things are flexible and changeable. If you decide the day before you tie the knot that you want white doves to fly across the room post first kiss, you can do that. It’ll be a last minute logistical nightmare (I’m told dove excrement is a particular delight) but this is the 4G enabled 21st century, if you can imagine if and are willing to pay for it, you can have it at your wedding. It’s the wedding version of Rule 34.
Weddings also have multiple stakeholders (your families, friends and any professionals you’ve hired to help you deliver) and as bride and/or groom you need to be able to prioritise and balance them all, ensuring everyone feels involved but you still manage to get the final say about what you want. This is the exact definition of a product owner.
(Suggestion for learning and development programmes – all newly engaged staff should be offered PO training. It will save tears later.)
So, weddings have:
- An MVP
- A flexible list of requirements that can (and will) change up until the last possible moment
- A core delivery team who take input from stakeholders and use third parties to complete tasks the core team cannot personally deliver
- No set length of project (engagements vary), resource (how do you want to spend) or scope (beyond the MVP anything is possible)
Yes, weddings are tied to a delivery date, but this can and does change. We intially planned for an Autumn wedding. Plans we had to change when we were informed of the October due date of our new baby.
And weddings last for a finite period – generally one afternoon/evening though I know a few couples who for religious or holiday based reasons managed to have weddings lasting several days.
There is no second release in weddings, no continual iteration of development, nor the gradual improvements following customer feedback over time.
Or rather, we hope there won’t be. When we each make our promises to love and cherish each other forever, I do hope no one is thinking “next time I do this I’ll opt for personalised vows” or “my next wedding will take place on a yacht.” Though I’m sure that someone out there probably has thought that. Not for me though. Two and done. I had a practice run at matrimony and I did learn lots from it on how not to plan a wedding which I’ll admit did make the second time around a lot easier. But I don’t recommend intentional iteration for weddings. It may happen, and if it does there may be insights gained which can improve a second release (for example, I discovered that wedding favours are an unnecessary waste of money and spent that cash on hiring an ice cream vendor instead), but as with all customer feedback, the costs can be higher than you expect.
A final note on matrimony – weddings often don’t benefit from iterative development, but marriage is a constant process of iteration and discovery. Again all marriages are different, but the most successful ones I have personally witnessed are where the couple in question grow together, learning from any mistakes and constantly working to prioritise and groom the backlog of their relationship, together.
Pregnancy on the other hand is a pretty Waterfall experience. Every gestation is different – will this expectant mother have morning sickness, will that one have twins – both the basic framework of the project (conception, 9 months development, delivery) is set. Some projects may come in early or late. Some may end early. Others may result from medical intervention or need a helping hand to correct any non-standard development along the way.
Waterfall doesn’t mean identical or without deviation – just as with Agile projects, Waterfall ones can grow and vary and need support to go the full distance. As do babies.
With pregnancy, for the most part, the requirements are set at the beginning and (barring any emergency interventions) will remain unchanged until the end. There are some small influences you can exert: prenatal vitamins improve the quality of the deliverable, as does avoiding certain food and beverages, but for the most part, your baby is set from the moment of conception. Eye colour, hair colour, skin colour and the rest are all defined by the genetic material provided at conception. There’s no possibility that eating carrots will give your child orange hair or that you could spontaneously generate a twin at 30 weeks by wishing for it.
Your (or rather, the child’s) requirements are set on day 1. Then, typically, somewhere between 38 and 42 weeks later they are born.
There’s no scope for last minute additional requirements. No ability to pivot to a different MVP. The resource for delivery (being one womb) is set.
Pregnancy is Waterfall. The side effects and impact vary from mother to mother, but so much of it is out of your hands, set by biology at a moment when you were (probably) paying attention to other things.
And as a final point in the Waterfall argument, less than 5% of pregnancies deliver on the due date. Most first pregnancies are late. Just like most of the Waterfall projects I’ve been involved in.
- set requirements from the start
- no ability to accept later requirements
- generally accepted timeline for delivery of 38–42 weeks
- single delivery (even if it’s twins) with no chance of iteration
- all development happens in a set order that can’t be changed
- no MVP, the deliverable is set and the delivery complete
It has been a very busy year for me. I got married, got pregnant and will soon have a child. My entire life is changing. So far everything has gone as it should and I hope things continue to progress in this manner.
But if there’s anything I’ve learned as the project manager/product owner of my wedding and pregnancy, it’s that most things are not purely Agile or truly Waterfall. Both experiences required me to think on my feet and be able to make decisions quickly about what I wanted/needed. Both had some set elements that could not be changed. Both have been physically and emotionally impactful. Both, contrary to the paragraphs above, have felt both Agile and Waterfall at different times.
I suppose the easiest way to put it is the reminder that very few things in life are purely one or the other. Almost every project you will attempt to deliver will, regardless of whether it is officially classed as Agile or Waterfall, have elements that blur the lines.
We are all Wagile. Perhaps we should focus less on our methodologies and more on our outcomes, because in the end, whether we’re smiling at our spouse or holding our child, the deliverable is more important than the journey.