The agile rollercoaster
We are a startup.
Our daily mission
Always improve our customer’s
learn fast, fail fast
At Parcify we like to think together with our customers about defining new standards in online shopping & delivery of parcels. Technology is a key asset to enable the delivery experience of tomorrow as we want to keep our customers informed at all times and give them control in the delivery process at any time it suits them.
As we need to be able to launch (and test) new features at the speed of light but still deliver software with high quality standards, we have made our lives a bit easier by implementing 2 things:
- A robust IT architecture that is designed for change
- Agile development in our IT team
Today I’d like to share something with you about agile development at Parcify and what we consider as key success factors in agile delivery. Our agile development process is completely based on agile scrum. As this might be an abstract term to you, I’ll explain it by briefly going through each step in the process. Before we start, it’s good to know that the process has an iterative nature, we work in ‘sprints’ that each take 2 weeks and have a clear start and end.
Each sprint is built up like this:
- We start with a sprint planning. The whole IT development team sits together with the product owner to discuss the work that needs to be done in the sprint. Requirements are explained and developers estimate the complexity of the work. At the end of the sprint planning, the team commits on the work to be done in the next 2 weeks.
- Every morning, we have a short team stand-up. Every developer explains what he did yesterday, what he will be doing today and what problems he is struggling with.
- We keep our feedback loops as short as possible. This means that as soon as a piece of work (which we call a user story) is ready, it is validated/accepted by the product owner. If bugs are discovered, they are picked up with high priority.
- At the end of the sprint, we demonstrate the newly built features to a broad audience in what is called the sprint demo. All participants can give feedback on the work that was done.
- We close the sprint by a (1 hour) team retrospective. Each team member can argument on the way we worked in the past sprint. The goal is to identify problems and opportunities related to our way of working. We also define concrete action points to be tackled in the next sprint.
From our experience, we’d like to share 4 key success factors with you:
- Keep your priorities straight and evaluate them before each new sprint
Avoid waste in building features nobody wants
- The product owner should be very close to the IT team
A short feedback loop is essential to answer questions and accept the features
- Organize demo’s and retro’s at the end of each sprint
Demo’s keep you sharp, the retro’s are great for continuous improvement
- Working agile doesn’t mean being a cowboy. It still makes sense to do some analysis and make designs. Find the right balance to achieve the quality and speed you need
Thank you for your interest in our way of working. We are looking forward to bring our new features to you in our upcoming release!