Agile: Failing Fast the Right Way

Facebook’s motto was “Move fast and break things” before it got tempered into “Move fast with stable infrastructure” in 2014.

Either way, it exemplifies the Agile mindset, which prioritizes adapting to change–and there’s plenty of change nowadays, such that it’s impossible to have project plans carved in stone.

Facebook embraces this, and so do other tech companies. You’d need it, in an industry where you can overthrow the competition from the comfort of your bedroom with countless lines of code.

Linear doesn’t work

Programmers and product leads talk about the Agile methodology, with terms cryptic to outsiders such as “sprint,” “kanban,” and, quite puzzlingly, “Scrum master.” Concisely put, the Agile methodology is a style of project management that started out in software development–but it got picked up so well that it’s wandered over to other departments and even to entire organizations.

As the story goes, it was formed by 17 people up in a mountain ski resort–and to make it definite, they crafted a manifesto.

This was born out of frustration. Software development, for all that it seems to be done by a bunch of people typing away on keyboards, is a beast, especially if it’s a huge project.

The traditional way of doing it–the waterfall model–made sense, to be fair. You talk to the clients, you design, you create the software, you test for feedback–and then you have a readily shippable product, all in one go: a clean, linear process.

But you’re building with code, not with bricks. Imagine putting in all that hard work, and the client throws it back in your face because it’s not quite what they imagined it to be. Or plans change halfway through and you have to scrap everything.

Fail fast, the right way

The Agile method was devised as a solution to this. Instead of trying to do it all at once, you work in iterations.

A common way of implementing this is by doing sprints around two weeks long, after which you should have a product that’s presentable to the client. You then gather feedback about this, coordinating closely with the client and reflecting on how you can improve the next sprint. After this, the cycle starts all over again.

This allows for adaptability–you won’t freak out if you have to change anything because you can work on it in your next sprint. As the manifesto says, the priority is “to satisfy the customer through early and continuous delivery of valuable software.”

It also encourages failure–the good kind. Agile gives enough leeway for experimentation and lets you detect errors early before they even make it to your client. With each sprint, you get an even more refined product.

However, if dealing with ambiguity is a strong point, it can also be a weakness. You can only get estimates, not strict deadlines. Plans are prone to revisions, which might be frustrating for some, and documentation tends to be thrown to the side and ignored for a less formal approach.

Conclusion

More than a methodology, Agile is a mindset–and you can definitely apply it to areas beyond software development.

At Sprout, for example, we’re applying Agile to HR. Businesses all over are starting to pick up on the idea of quick prototypes, especially when they’re just starting out–before they make heavy investments, they validate their core idea with a minimum viable product and test it out on people.

Agile does involve moving fast and breaking a lot of things, but the more things you break, the more you get to fix–and this creates a solid foundation. “Move fast with stable infrastructure,” indeed.

The post Agile: Failing Fast the Right Way appeared first on Sprout.

source https://sprout.ph/blog/agile-failing-fast-the-right-way/