Moving to an agile environment (part I) — Getting started

Dear reader, I came across with this article to tell you about an experience that I’ve been living since a few months now — the experience of moving from a waterfall to an agile environment. I’m not an Agile nor a Scrum guru, but I’ll be giving you what I have been learning both from my experience and what I’ve been retrieving from some books and articles. This is part 1 of 3.

State vs Vision

State

In my entire professional path I’ve been working in a waterfall model. Long projects with long lists of requirements (most of the time not much detailed, or sometimes no documented at all), long periods of development and validation and finally deployments that every one’s afraid of.

When projects were delivered, much of the times users asked for changes or start reporting that some feature is not behaving like they would like to. We all know the following image I think…

All this happens mainly for the lack of feedback from our users during the evolution of the project, this is the biggest problem that most teams face when following the waterfall model.

Don’t take me wrong, waterfall does work! Otherwise it wouldn’t be so popular among the most varied software development companies. But I believe we could do better (here comes our vision).

Vision

You won’t be surprised by the vision, it is in fact very simple. The goal is simply to split our project in several stages so we can ship it more often and therefore, have the opportunity to have our users to give feedback during the whole project evolution. And we can do it so, following the MVP idea.

MVP stands for Minimal Viable Product and is one of the most important lean startup techniques. But it is valid both for startups as for big companies with mature products. The mindset is to deliver often and simple, and this takes us to the time boxed vs feature boxed deliveries.

Waterfall model follows the feature boxed model. You don’t ship your project until a certain set of features is finished. This compromises deliveries dates and can affect the team workflow, because nothing stops or proceeds besides those features that we aim to deliver in the next release. With this approach we can have some feature that takes longer than the other and the whole delivery is compromised by that single feature.

Agile environments follow the time boxed model, it doesn’t matter if a certain feature is delayed, the delivery will happen no matter what! With this model releases are not compromised by the completion of the features and users know that will receive their release at that date. But now you ask yourself… “This doesn’t make sense. How can I ship things that aren’t finished yet? What if I have the “users management module” shipped only with the list of users and we don’t even have a registration form?”… I’ll reach that, but not now. We’ll discuss it when talking about the Potentially Shippable Product (part II).

Why agile?

One of the first questions you should ask yourself about would be: “Why and when should I use agile”.

Agile is a good fit for medium and big projects and is overwhelmed for small ones.

You have to evaluate the what vs how relation. As you have more things to build you’ll have more things to think how to build, and there’s when you start becoming more distant about certainity and agreement.

Following MVP, you’ll have more iterations between all the project’s stakeholders and you can minimize lack of agreement and certainity.

Motivation

Well… I think I just gave you several reasons to motivate you about agile but please, search more about it. Read articles, check some videos, some books... I can recommend you the “The Scrum Field Guide” from Mitch Lacey.

And I couldn’t lose the opportunity to share these videos from spotify with you:

Spotify engineering culture (part 1)_Here's part 1 of short animated video describing our engineering culture (here's part 2). This is a journey in progress…_labs.spotify.com

Spotify engineering culture (part 2)_Here's part 2 of the animated video describing our engineering culture. Check out part 1 first if you haven't already…_labs.spotify.com

These videos were a big source of inspiration for me and my friend @dpcardoso who has been working with me in this “Moving to an agile environment” path in the company.

Are you like us? Would you like to contribute to some big change in your organization, like moving from waterfall to an agile framework?

Let me give you some guide lines about how to get started. I can’t ensure you that it will work in your organization but it did work in ours (we just started working with Scrum some months now).

How to get started

1. Establish a state of urgency

Establish some goals to achieve! What will your proposal bring to your company from useful?

Write down all the advantages you can take and which problems it solves in your organization. You can’t adopt agile just because it is “cool” or “a new thing to try”, you have to identify all the problems that you face every day and how you aim to address them.

But please, don’t be much ambitious and build something reasoned. Otherwise people won’t believe in “impossible things”. The spotify environment is a dream but don’t get lost… You have to think in your company reality, your “real world”. Don’t try to achieve all at once.

2. Create a vision/paint a picture of the future

Do you see that big picture at the beginning of the article? That’s my “picture of the future”. Find some way to state your vision so you can communicate it to the rest of the company.

3. Find a sponsor

This is very important. If you’re just a developer like me or someone with no much authority you need someone that everyone pays attention and listens to. This person has to understand what you’re proposing and has to believe in it! Then he must help you in the communication.

4. Communicate the vision

Now you have all the conditions to state your vision to the rest of your colleagues. I’m sure your vision will have lots of challenges and you must be reasoned about each one of them. Use your sponsor to help you convincing people about your vision.

Like I’ve said, the vision is very simple to understand but is not that simple to achieve. You may have the need to address lots of challenges and to change much things in your environment.

Agile is a methodology but you need a framework to implement it. You have several but the most known are Scrum and Kanban. We decided to work with Scrum and that’s what I’ll be addressing in the parts II and III.