A better way to manage projects

In the 1970's Dr. Winston W. Royce wrote a paper about how to manage projects within the context of large software systems. It was a 10-page document and in page 2 he included a diagram that helped consolidate its nickname: Waterfall. ??

Apparently humanity is too lazy to read past the charts, so we continued on using and building around the waterfall concept, even though it's also stated in page 2:

I believe in this concept, but the implementation described above is risky and invites failure.

But what's the alternative?

As time went on, the methodologies around the waterfall continued to grow resulting in heavier and more complex processes. Then in the late 1990's frustration grew in the industry until a group of like-minded professionals met in 2001 to actively discuss better ways of managing projects. From this meeting sprung the Agile Manifesto.

The manifesto stated what the Agile mindset was supposed to be. The document contained directions like prioritizinginteractions over processes, working software over documentation, collaboration over contracts and responding to change over following a plan. And, from this mindset and existing knowledge, new techniques came up, such as Extreme Programming, Scrum and Kanban (different, but rooted on the original Kanban boards in TPS).

Cool. Waterfall sucks, Agile rocks. Is that it? In my humble opinion, pretty much yeah. Even though Agile was born with the intention of tackling the pains inherent to software development being more suitable for higher uncertainty scenarios, it could be applied in more traditional project management use cases.

In Scrum: The Art of Doing Twice the Work in Half the Time, Jeff Sutherland and Ken Schwaber explore not only the mindset, recommended techniques and key performance indicators, but also share an array of applicability examples ranging from 'pretty obvious' app development style to some very unlikely, such as refurbishing a house or conduction high school classes program.

And is it really that different?

The main differentiator I see between waterfall and Agile is just one: feedback cycles.

In traditional waterfall projects the feedback cycle is long making it less frequent than it could be. Here you could argue, "well, why don't you meet with the customer every 1-2 weeks to review the deliverables?", but then as I ask you: "what deliverables?"

Waterfall projects are usually aiming to deliver the project as a whole or certain phases. This leads to months developing and delivering things that don't necessarily add value by itself like extensive requirement documents, or the infrastructure for a certain feature or even a complete financial module (which by itself may not be solving any of the customers pains).

On the other hand, Agile ensures that every couple weeks the customer will review with the team deliverables that create value to end customers all thanks to the way tasks are broken down and prioritized. Working this way, the customer feedback will be based on something that is done, running free in the wild, thus being based on facts.

Building the path to fast cycle feedback

Having in mind that getting rich feedback as soon as possible is your target, you need to build ways to reach it. You'll need to work with your customer (how might be another company, a buyer, your spouse or even yourself) to define a few basics:

1. In a few years, how does a successful scenario look like?
2. In 2 weeks, what is the first complete step that can be taken towards that future?

Great - with that you'll have a long term vision and you'll have a short term goal. With those in hand you can start mapping all the details and developing what needed to reach the short term while keeping an eye on the long term. Fast forward 2 weeks into the future and you'll get your rich feedback.

An 'obvious' example

Let's say your company builds high complexity websites for your customers nothing basic like my blog. Customer #1 rings your doorbell: they want a full-fledged e-commerce platform, and you sweep them off their feet with an incredible sales pitch. That's it, hands are shaken and you got yourself a project to deliver. Now what?

Maybe you could start with all the documentation, then raise all requirements from the customer, then you could work on all the infrastructure to support the e-commerce transactions, product inventory, etc. With all that done, you could move into designing the front-end (the visible part of the store), testing if everything is working properly, get the customers approval and then finally going live, making the site available to all the citizens of the internet at a beautiful .com address.

Did it sound like months of work? Did it sound like months before getting a single customer to actually purchase anything from the e-commerce? Did it sound like a bad approach?

Let's do over

How about this time you align with the customer what is the simplest smallest version of their final product? By setting a clear minimum viable product and working to deliver that, you'll be able to reach customers much sooner, not only getting their feedback but also generating revenue.

Behind setting this minimum version of the product you'll have to work on requirements, infrastructure, front-end, documentation and other things, but the rationale is to focus on building only what is truly necessary to deliver value to the final customer.

The final product might be turning your physical store into the largest computer accessories e-commerce in the world, but how about you start with 2-3 products that are already your top-sellers? You can always keep growing from what you've built.

A less obvious example

Let's talk about building a house. Maybe the most intuitive way of doing so is from the ground up: foundation, walls, ceiling, roof, all the painting and so on. Working like this you'll have a house when the whole house is done. But what is it that adds value to the customer?

This is probably not applicable to everyone, but what if the customer wants to stop paying rent as soon as possible? Maybe they want to reduce expenses and invest more on building their home. If this is the case and if the customer has enough space, why not start with a small but functional guesthouse while they build their actual dream home? The overall construction may become a bigger investment, but that might be achieved thanks to reducing rental costs several months earlier than the original plan.

Too long; didn't read

When you wake up, everyday repeat 3 times "Agile is awesome" and you're set! Just kidding...

The reality is that all frameworks, Agile or not, will have their downsides. For instance too much focus on the short term of small deliverables might block your way from bigger opportunities or you might even be build several Lego block that won't fit one another.

With that said, I truly believe that defining a long term vision, outlining the first step towards that vision, delivering itand getting rich feedback based on an actual deliverable will definitely pave the way for the following steps in that journey.