If you are a developer, a designer or a product manager but never worked in a software development consultancy, it may not obvious what all these people do together day-to-day. We get asked that a lot. Not only by potential talents who want to join our team but also by companies and organizations looking to collaborate with us.
Today, I’m giving you a behind-the-scenes view of what it’s like to work with us. I will show you what a typical week with Nimble looks like.
Because we follow agile methodologies, a week is the base measurement for many of our activities. It’s the length of a development sprint, it’s how often we release software, and it’s how often we gather as a team to review our accomplishments.
Development Sprint
A development sprint is a time-box (one week for us) during which the team creates new features (or improvements) that can be released to the world.
A dedicated team leads each project that we work on. A project team is usually made of 3–4 people and is broken down as such:
-
Product Manager: the single point of contact with the external stakeholders. The Product Manager and the stakeholders define the project (vision, goals, deliverables). The PM then defines epics, user stories, and acceptance criteria. He/she also performs quality controls on the work delivered by the developers.
-
UX/UI designer: conducts market, competitor, and user research. He/she delivers the User Experience (UX) and User Interface (UI). Designers are part of the project team from beginning to end. As we continuously iterate along the project, the UX/UI changes and we need design work done.
-
Team Lead: participates in the definition of user stories, finalizes and decides the technical implementation. The Team Lead assigns user stories to the developers and leads the code review efforts. Team Leads also work on the user stories alongside the developers.
-
Developers: make magic happen! They write clean, maintainable and thoroughly tested code.
The decision to have a fixed and dedicated team for the entire project follows our core principle of product ownership.
Each team has a dedicated project on Pivotal Tracker (our favorite) or Jira.
Before the project starts, we create and prioritize the backlog for the entire project. The backlog usually contains 20–30 epics and 150–250 user stories.
Before every sprint, we check-in with the stakeholders and make sure that their goals are still reflected in the backlog. It is done during our weekly meetings between the Product Manager and the stakeholders. If necessary, we adjust the backlog following the weekly meetings. Planning is paramount, but flexibility is equally important.
Weekly sprints start on Mondays and end on Fridays. We aim at creating a well-balanced backlog with a mix of features, chores and improvements/fixes. Doing so ensures that we can keep a good momentum, but at the same time, that we keep building on solid foundations. We usually allocate anywhere between 5–10 agile points worth of user stories per developer.
When a developer tackles a user stories, (s)he creates a pull request. At least two developers must review the pull request before it can be merged.
As a developer, doing code reviews is equally important as writing code. All developers allocate a block of time every day to review the code of their teammates. This continuous review process allows our team to merge changes with confidence.
Releases
Shipping often is essential. We strive to put the product in the hands of users as fast as possible. We love to get feedback early so that we can continuously improve and build the right product.
We release to production at the end of every sprint. If necessary, we also release *during *the sprint.
Our team manages to release that often to production because our process is fully automated. All our projects are set up for Continuous Integration and Continuous Delivery (CI/CD) from the beginning.
For web applications, we use Semaphore CI. We recently migrated to their Docker container services (read more on this here. As for mobile applications, after having used Travis CI for a few years, we have recently decided to update our setup. We migrated to a self-hosted Jenkins CI server ( more on that in a future post).
With CI/CD in place, we feel very confident about shipping code to production. All our test suite is executed on every single build. Because no human interaction is involved, the possibility of error is extremely low.
Releases happen on Mondays after the end of the previous weekly sprint.
The main reason behind this schedule is that the whole team is up and around, ready to act if something goes wrong. Same with the support teams of the external service providers that we use (e.g. Heroku, AWS, Azure). Releasing at the end of the sprint, before the weekend, would be irresponsible and impractical.
A Monday release is also a great way to start the week, pumping up everyone’s energy 💯
Retrospectives
On Wednesdays, teams gather by stack (Web, iOS, and Android). They review the achievements and the bottlenecks for the past two weeks. To allow our multi-stack developers (yes, we have a few) to contribute to all relevant retrospectives, we desynchronize the meetings. Web one week, iOS and Android the next.
One by one, all developers share their accomplishments and their blockers. This leads to a better understanding and more empathy across the team.
The main goal of the retrospectives, however, is to identify potential bottlenecks in our processes. By flagging issues early on, we can work on removing the bottlenecks and blockers for our team members.
We also use these sessions as a knowledge sharing platform. Because our teams work on different projects and applications, they face different situations and challenges.
When a developer finds a better way to do something, or when they work on something entirely new, they do a presentation to share what they have learned. They can then propose a way to implement the novelty in existing or future projects.
Just like the products that we are working on, we are always iterating on our processes and reflecting on how we build software. We include everyone on this journey.
Daily Activities
At the beginning of each day, the whole team gathers for the stand-up meeting. Everyone participates except for our Office Manager.
We follow the standard “Yesterday, today, obstacles” pattern. We keep it fast and dynamic. Because not everyone works on the same project, we encourage sharing some context too. This daily ritual is vital to us. It helps us come together as a team and share achievements and obstacles.
The development backlog is groomed on a daily basis.
Designers and developers make sure that the status of their tasks is up to date.
The Product Manager inspects and accepts or rejects the features delivered the day before.
It’s this daily and constant internal feedback loop that allows us to move fast and efficiently.
Conclusion
Planning stories, designing, testing code, pushing code, reviewing code, shipping software, retrospectives, standups… Phew! Lots of things are happening in a week with Nimble.
That’s what makes us who we are and we would not have it any other way.