A lightweight approach to agile development;
Or, how we build software.
Things do change really quickly. When Moze started as a web agency, we used to organize our work around tasks (Basecamp was a helluva checklist at that time).
When we shifted from doing simple websites to helping startups and companies to build digital products, we made some well-intended but bad attempts to organize our work implementing Scrum, and later Kanban — neither of which were a good fit for us. The first was over complicated for a small studio like us, the latter did poorly in helping us establish clear deadlines.
So we did what any team trying out a theory does: we adapted. We found our own agile development framework, mostly inspired by Scrum.
The following description is what we have found out to be the best way to organize the design and tech work of a small studio of around 10–12 people which designs and builds the front-end of software products.
Stage 1: figuring things out
I love how Ryan Singer of Basecamp identifies two main phases for project work: figuring things out and making things happen.
Every piece of work has two phases. First there’s an uphill phase where you figure out your approach. You have a basic idea about the task, but you haven’t figured out what the solution is going to look like or how to solve all the unknowns.
Then after you’ve explored what works and what doesn’t, you reach a point where there aren’t any unsolved problems anymore. That’s like standing at the top of the hill. You can see clearly all the way down the other side. Then the downhillphase is just about execution.
In the uphill stage we get to know our client, their goals and constraints, the company’s key metrics and past work. We then try to understand what to build (the scope of work) by using an Agile technique called User Story Mapping: a way to describe features from the end–user point of view.
This allows every team member to be aligned on both goals and scope, and to be involved in the conversation from the start.
When the end-user experience is mapped, we usually build a static prototype (InVision works fine). This can be done using co-design techniques with the client or by running a Design Sprint — a five-day process to test a new idea.
2. Prototype and user interviews
A prototype gives the whole team a straightforward idea of the work to be done, minimizing any blindnesses. It also makes estimation way easier for both designers and developers.
At this point we usually test our prototype against a number of potential users looking out for potential usability problems before starting any development effort.
We organize development work in sprints — a two-week fixed period of time with an allocated, fixed team of designers and developers (one full-time developer and one part-time designer usually works well for our projects).
Contracts with our clients are organized in sprints as well, which allows for more leeway and full transparency over our work in a single sprint, demoed to our clients in detail every two weeks.
3. Estimate and plan
With the prototype, the Story Map and estimated story points we can then make a release plan. For example, if a set of features (identified as a release) ends up being around 32 story points — and we know our team can burn eight points per sprint (named velocity in agile) — we can predict we will need four sprints to complete that scope of work.
This works for incremental releases too, even if we tend to avoid doing detailed planning for more than two planned months of work.
Stage 2: getting things done
Between stage 1 and stage 2 we usually conduct technical analysis on technology and general software architecture — since our work focuses mostly on front-end, this is done in conjunction with the client’s tech team.
1. Setup sprint
When everything is ready, our team starts working in sprints. We call the first sprint a “setup sprint”, because we preparare our development environments with the selected technology (front-end development libraries, tests, routing and basic navigation).
User stories from the Story Map are imported into a backlog in Trello. At the end of a sprint we give our client a detailed demo of what we’ve done to and we discuss the scope of the next sprint. Each sprint column in Trello is filled until it matches our expected velocity capacity.
Sprint after sprint we begin to tackle small pieces of the software one by one, following the linear end-user experience described in the initial Story Map (from left to right).
2. Incremental developments
At the end of each sprint we have some working software to try out and we aim at zero known defects. In each sprint we prefer to commit to less things rather than ending up leaving out features (i.e. not delivering at the end of the sprint); This tends to keep motivation higher among the team,avoiding tensions of any kind.
When things are almost ready for a first release, we usually arrange with our client an invite-only beta and we help collect user feedback by using tools like Google Form or arranging interviews.
To understand the impact of the design, or the redesign for an existing product, we usually help our clients implement event tracking using Google Analytics and dashboards using Google Data Studio to have real time reports of the main Key Performance Indicators, usually built around AARRR metrics categories (Acquisition, Activation, Retention, Referral, Revenue).
With this simple yet efficient way of organizing software work we have successfully designed and developed the front-end of several web and mobile apps.
Check out some of our recent work where we’ve applied this
Rataran – Web application (Vue.js)
Rataran enhances the most competent traders and offer them visibility and prestige in the world of finance, rewarding the best performing trading methods.
Talent Garden — Mobile app for iOS and Android (React Native)
Talent Garden is Europe’s leading digital innovation platform and coworking network with 23 campuses in 8 countries.
Wanderio – Android mobile app (React Native)
Wanderio is a web application that completes your online travel experience, comparing different means of transportation (including flights, trains, and transfer services from/to airports) and sorting alternatives to let you choose and book the solution that suits you best.