In this series, we pull back the curtain on the art and science of our work. Each part of the Project Blueprint series offers a deep dive into the minds and methods of each team member of a software development project at Zure.

From the initial spark of inspiration to the final keystrokes of code, we want to give you a glimpse into our project landscape, the complexities of software development, and our ways of working. First up to tell their side of the story, the team lead:

At Zure, we actively seek challenges. For us, it’s about questioning the status quo and diving into the unknown regularly. While it can feel daunting at times, it often enhances problem-solving skills and might even contribute to personal growth. One thing is certain: repeating the same tasks can lead to boredom.

While portion of our projects is unknown, we have lots of battle-tested practices that help us along the way, and I will walk you through some of them. It’s good to note that despite our projects usually involve experts from multiple fields of expertise, in this post of the project blueprint series, I’ll focus on the developer perspective.

Project kick-off

Before we are lucky enough to start working on a brand-new development project, series of sales and negotiation actions have already successfully taken place. At this point, we have gathered up a team of developers including a named team lead. At Zure, team lead concept is constantly evolving, and its characteristics would require blog post of its own. But to make it short, team leads have bit more responsibility to look over the team functionality, customer communication and making sure the project stays on its track.

First milestone of the project is the customer kick-off meeting, where the team and customer meet each other and can discuss what the project and business domain is all about. Also, we want to hear what challenges the customer has, what do they expect from us, and what are the core features we are supposed to be implementing. We also need to agree on how requirement specification is done and by who. Requirements are sometimes overlooked leading to confusion whether a feature is done or not. Being agile does not mean changing requirements on the fly.

We have few requests towards the customer as well. We do work in an agile way, that is using 1-3 week-long implementation sprints separated by sprint review and sprint planning sessions. Which agile framework the team should follow, whether it’s scrum or Kanban, is left for the team and customer to choose from.

We’ve noticed that when a customer has a dedicated and proactive product owner who has sufficient time to communicate with the team, we often achieve success.

After the kick-off, we should have next appointments scheduled, communication channels agreed and a clear understanding on what happens during the next iteration.

Implementation phase

From as long as I can remember, our primary internal goal for every project has been to make something meaningful for the customer already during the first iteration. That means we don’t start from the technical challenges but instead try to make it visible to the customer that we’ve understood what we are supposed to be doing. As developers, it might be tempting to us to start from technical issues such as user authentication or CI/CD pipelines, but customers kind of expect us to nail these things anyway. It’s the core business features, that made them choose us in the first place – so why not start from there?

To get in speed, we have built an extensive project template, Zure Template, where all projects start from. While we don’t restrict too much what tools can be used, we have some constraints in place like that we build frontend applications with React and only use C# and .NET in the backend. And as we are focusing solely on Microsoft Azure, we have example starter bicep templates and Azure DevOps YAML pipelines ready to go, as well. While not all the projects benefit from all the bells and whistles template has to offer, it saves developers’ valuable time to concentrate on working with the actual business requirements from day one.

After the team has completed their iteration, they’re expected to share their results with the customer representatives. The sprint review starts with going over what happened during the last sprint followed up by demo presentations by individual developers. For Zure, it’s important that every team member gets their voice heard and a moment to share (and be proud of) their work. Sometimes results are not satisfactory, but that’s part of the game and crucial moment to learn from, and to improve in the next sprint.

Usually, we like to combine both sprint review and planning into the same calendar event to save both us and the customer from context switching (which is usually the result having the meetings in separate occasions). Sprint planning meeting is all about organizing the prioritized tasks for the next iteration. Our goal is to have pre-planning sessions the day before where we go through the backlog, estimate stories and finally have suggestion of our own for the next sprint. This way, the official planning session is more about fine-tuning and valuable time is left for requirement specification, prioritization and knowledge sharing.

Measuring team and customer satisfaction is something we deeply care about. We conduct team and customer surveys on a regular basis to gain insight whether the team is doing fine and if the customer thinks project is going as planned. Both surveys have open questions and Likert scales from 1 to 5 covering the most important aspects to measure project and team success. We aim at keeping both scores above four and take actions if they drop below that.

Autonomy, purpose, mastery

It’s important to note that while our teams operate with high autonomy, we have robust support mechanisms in place. Alongside the Zure Template, our core guilds maintain updated tech radars and standard operating procedures called “defaults”. They also allocate time to engage with individual project team members. Given the diverse expertise needed for our projects, it’s essential to have DevOps, QA, and design professionals in the team.

In addition, as we are working mainly from our own office, we have bunch of people to ask help from everyday. If live conversations are not an option, there’s always open and productive knowledge sharing dialogue on our Teams channels “Halp” and “TIL (Today I Learned)” just to name a few. Autonomy is all about finding the right level between banging your head into the wall and asking for help. Saying out loud “I don’t know” is maybe the best cure for imposter syndrome, that all of us developers suffer from.

It feels great to solve a difficult technical problem on your own, nobody can deny that. But I think after a while, the professional fulfillment comes from, let’s say a bit softer things. Helping each other out and completing challenges together is something that you don’t get bored with. Solving the right business challenges and seeing people benefit from something you built, is a great motivator to get up from the bed in the morning.

We’ve seen that in order to grow and do bigger things, we need to embrace failure. Instead of blaming each others, we focus on learning and improving ourselves every day. If things are not going how they should, we try to be as open as possible towards the customer. It is hard sometimes to see yourself in a hole but it’s just a mandatory step on a path to mastery.

Summary

If you read this far, it might be obvious to you that I didn’t write much about coding practices, newest frameworks or not much about anything technical. The reason is, as our average experience at Zure is well above 10 years, we rarely have technical struggles that define whether or not we can build something or not. Our challenges lie in things that code cannot resolve like team work, understanding the requirements, managing expectations and all sorts of things that require open and constructive collaboration between all stakeholders in the project.

Stay tuned for the next part of the series where our Quality Assurance Lead Virpi Tuohisto sheds some light on our ways of working from quality assurance perspective.