The NEW way of working at YPA

Each company has its own way of working and so do we. Our journey started 3 years ago and over time we figured out what way of working fitted the needs of the client and ours. We went from working the waterfall way to working agile with sprints, but why? Read more to find out.

8 min leestijd

Working post its

From Waterfall to Agile

The way of working for our agency has developed over time. We used to work with the waterfall methodology. By using this method you have everything of the whole project planned out when you start, from beginning to end. This means that there is no room for adjustments during the project. We found out that this didn’t work, because of the workfield we are in we have to be able to be flexible and change quickly.  So that is the reason why we changed to Agile.

MVP

Picture: crisp

Now you are probably wondering, what is agile working then? The agile approach is developed out of a response to the stiff way of working of waterfall. With the Agile approach, a team works in phases on a project. Instead of making a project piece by piece, like making a car, first the wheels, then the middle part and so on (see visuals). With Agile you work on a project and try to make it better throughout the process. For example, you walk to work everyday, but want to get there faster. You start with a skateboard and see if that is faster than walking to work. After using your skateboard for a month, you see that this is faster than walking, but you want to be even faster. So you decide to upgrade your skateboard to a scooter. You upgrade with little steps, because you want to know what impact the change has. The focus is on continuous innovation within a project. Because the digital world changes so quickly it is better to use the agile approach.

The main difference is that waterfall is a linear system of working that requires the team to complete each project phase before moving on to the next one, while Agile encourages the team to work simultaneously on different phases of the project. The goal of an agile sprint is to get quick results and test if the idea you have works.

What is a sprint

We work agile in a combination with sprints. A sprint refers to a period of time in which certain tasks or activities are completed and reviewed. Sprints make a project more manageable because you know what you can complete within a certain amount of time.

At YPA a sprint can take up to 1 or 2 weeks. We offer multiple types of sprints. We do a lot of Design and Develop sprints, but we prefer including a sprint 0 and delivery sprint (the full package) to deliver the best results.

Sprint 0 (1 week)

A sprint 0 is something we start with to fully understand what the client is looking for. We do a workshop to get to know each other and see what the goals and needs are for the client. During the workshop, we make sure that from the side of YPA, team Design and Development are involved. This makes everything much easier during the whole process

The client only has to have an active role during the workshop. This will create the best outcome.

Design sprint (1 or 2 weeks)

In a design sprint the website comes to life. Our design team creates the first  designs. We really see all the excitement in the client’s eyes when their idea comes to fruition. Depending on the request we can make a complete custom design for a website or we can work based on a template. 

To make sure we have the best design result we decided to do the design and development sprint separately from each other, so that the client has time to think about the design. We experienced the design needs to be finished before development so we have a clear overview of what needs to be done. You don’t want to rewrite code because the design changed over time.

Development sprint (1 or 2 weeks)

Once design is approved, the Development Sprints will start. During these sprints, the team works together with all parties to develop the agreed User Stories. During development, we work with JIRA to keep track of all User Stories and Issues submitted by our team, the automated tests and of course  our client. The team and customer track progress in JIRA where all User Stories and issues from the sprint are documented. When the team is ready, they release a trial version for internal testing.

At the end of each sprint, our team will test the product for technical and user errors to ensure that all users can use the website. Only when the product has passed our internal tests will the product be deployed in the acceptance environment. When the product is ready in the acceptance environment, the product can be tested with the User Stories we created in Sprint 0.

At the end of each sprint there is a demonstration of the sprint in which we show the new functionalities of the sprint. This is also the time to discuss the scope of the next sprint together.

Delivery sprint ( 1 week )

After we have done the demo in the development sprint, we give our client 2 more weeks to test and see if there are still some bugs or small things that need to be fixed. After those 2 weeks we plan in a week to solve those ‘problems’ and after that we can go live with the website we have worked on!

Ingredients  to a successful sprint

If we prepare a sprint we always write user stories. A user story is there so make sure what the end user wants and why he or she needs it . A user story is written  like this: ‘As a (client)… I want… so that…’ See the visuals as an example.

It is very important that you have a Definition Of Done(DOD) in the user story. This will explain the user story even more and here you can set up the goals you want to achieve with this ticket. Based on the DOD you work out a story.

visual ticket

We have very close contact with our clients if we are in an active sprint. We have a channel in Slack with our clients, so we can ask questions right away. We have a daily stand-up in the morning with the client and the team. Within this meeting we will discuss per person ‘What did I do yesterday’, ‘what am I going to work on today’ and if there are any blocking issues. By talking about these specific points every morning we can be very transparent about the progress and quickly address potential blockers with all stakeholders.

Sprint retrospective

At the end of each project we do a retrospective.  In a retrospective you reflect, with the whole team, on the work you delivered during the sprint. You do this to see what can be improved for the future and the upcoming sprints. The sprint retrospective takes place after the first review of the sprint and before the next sprint planning session. 

During the retrospective you write down for yourself:

  • What went well
  • What could we do better
  • What do we have to stop 
  • A compliment for a team member (because we also need to highlight the good vibes in a sprint)

After discussing this with the team we will make a list of action points. By addressing all the pain points, it will improve the speed of the next sprint.

Some tips on working agile sprint

Over time we have learned a lot of working with sprints. If you decide to also start working with agile sprint, then we have some tips for you. This will make sure you will not make the same mistakes as we did over time 😉

Set a goal for each sprint

Have a clear overview of where you are working on and what the end product of the sprint is. Most of the time you will have to use multiple sprints to complete a whole webshop. That is why it is good to give a goal for each sprint.

In and out of scope

Make sure you have clear what is in and out of scope before you start the sprint! Once you have made an overview of the workload you can start the sprint.

Don’t change or add to the DOD

Once the DOD is set and you start the sprint, you don’t want to change this anymore. We see that clients want more and more during the sprint. But by setting up the right DOD and not adding work to it, your work will be done in time for the sprint.

Make sure you have a rest week

It is important that you don’t do more than 3 sprints after each other! We like to have a rest week in between, so that the team can charge up and start a new sprint after the rest week with new energy.

Why you should also work Agile Sprint

This new way of working gave us a lot of benefits, here is a quick recap of why working agile sprint is better than waterfall:

  • We can easily change the planning and adapt onto a different direction in a later stage of the project
  • We can keep on improving and making a website better and better by adding new features each sprint.
  • We finish up a sprint on time.

Do YOU have a challenge for us? Don’t be shy and send us a message to [email protected] or fill in our contact form and we will get in contact with you!

Wil je meer weten?

Fleur helpt je graag verder. Fleur is een van onze te gekke designers! Haar leergierige houding en nieuwsgierigheid vormen de basis voor bruisende designs die perfect aansluiten bij de behoeften van gebruikers.

085 060 9386 [email protected]