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 environment. I’m not an Agile nor a Scrum guru, but I’ll be giving you what I have been both from my experience and what I’ve been retrieving from some books and articles. This is part 1 of 3. agile learning 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 idea. MVP MVP stands for and is one of the most important 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 Minimal Viable Product lean startup time boxed vs feature boxed deliveries . Waterfall model follows the . 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. feature boxed model environments follow the 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 ( ). Agile time boxed model, 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 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 and what vs how certainity agreement. Following MVP, you’ll have more iterations between all the project’s stakeholders and you can minimize lack of and agreement 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 “ ” from . The Scrum Field Guide Mitch Lacey And I couldn’t lose the opportunity to share these videos from spotify with you: _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 1) _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 Spotify engineering culture (part 2) These videos were a big source of inspiration for me and my friend who has been working with me in this “Moving to an agile environment” path in the company. @dpcardoso 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 ”. Find some way to state your vision so you can communicate it to the rest of the company. future 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 and We decided to work with Scrum and that’s what I’ll be addressing in the parts and . Scrum Kanban . II III

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

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

Too Long; Didn't Read

Rodolfo Goncalves

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

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

Too Long; Didn't Read

Rodolfo Goncalves

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES