Building DeliveryOS: 5 Learnings about Agile Development from Team Deazy

“We’re building the plane while flying it” - is the phrase many agile product teams are familiar with. This phrase also definitely applies to our soon to be revealed platform, DeliveryOS.

Building a digital product while also testing, tweaking, and adapting is extremely challenging, however there are some tips which can help. That is why we wanted to pass on 5 key learnings we’ve picked up while working on our platform in the past 18 months!

01 Don’t invest too much into the UI for the first version - it will need to be updated sooner than you think!

When building a new product, teams will often get carried away with the UI of their product. This is understandable, since this is the first thing you see. However, through previous projects, we found out just how quickly a version of a UI, a team once loved, can become old.

The first version of DeliveryOS (above) looked very different to what it looks like today!

During the building of our platform, DeliveryOS, we chose to prioritise functionality instead - creating the user interface using a prebuilt dashboard template, coupled with our own components. While this by no means looked sleek to begin with, it allowed the team to do what might be the most crucial part of agile development: testing.

User feedback is the lifeblood of any good platform or product. That is why we chose to prioritise this over a beautiful interface. By choosing to optimise the existing version of the platform first, we were able to test internally and get qualitative feedback from our users. In fact a coherent user interface only began to be developed 1 year into the project. This meant we could create an interface after we truly understood how our users worked with the platform, creating a functional UI experience.

However, it is also important to note that, at least in our experience, UI design never ends. In order to keep the platform looking sleek we’re always on the lookout for how we can update existing interfaces. In fact, we’re currently in the middle of our second big redesign! Nevertheless, understanding our users’ behaviour first will help reduce the frequency of redesigns down the line.

[testimonial]

02 Spend time thinking about how users will interact with the platform, and don’t immediately discard edge cases.

Ruling out edge cases is an easy mistake to make - we had to refactor major functions (multiple times!) because we didn’t think the edge cases were important enough. We found ourselves in this situation exactly, when creating version one of DeliveryOS’s invoicing system. For V1 the team created a rigid but efficient way of invoicing, which covered most of the ways our team created invoicing. Since edge cases couldn’t be standardised, our team decided it would be easier to do these invoices another way or to eventually bring the process inline with the standard invoicing process we use across most of our business.

However, we quickly realised that standardising edge cases was easier said than done, with some processes being impossible to tweak enough to fit the in-platform invoicing. Perhaps the most important learning we took away from this process was: all user interactions need to be understood before building functionality. The creation of the invoicing process was built based on assumptions only, meaning edge cases were ignored.

An example of Deazy's process planning ahead of development for DeliveryOS.

It’s also important to consider that there is often no hard and fast rule for edge cases. It is often best to examine them one by one. Having a great process for discovery, validation, and feedback can help organise edge cases and weight up effort vs impact. We say, if you can cater for an edge case with just a little extra work - build in that functionality!

03 Ensure there are documented ways of working so that the whole team knows what their responsibilities are!

Similar to many agile project delivery teams, the Deazy platform team grew organically. Over the past 18 months we’ve gone from 2 nearshore devs working on the platform to 10. While organic growth is great and expected, if processes aren’t adapted in accordance, you can miss out on establishing responsibilities, ways of working and output expectations.
DeliveryOS was built using pre-vetted developers from Deazy’s own limitless ecosystem.

Since the full team works remotely, we found that formalising meeting culture helped create a more collaborative, outgoing and communicative team. This also gave our team space to become confident in their own roles, take ownership of their own part of projects and raise issues whenever they needed help.

Another area where our growing team needed more structure was the actual agile building process. Since we began as a very small team, these processes weren’t established from the start. Making sure that you have a well thought out and communicated plan from the beginning can help you avoid growing pains.

It is also important to understand that processes always need to be reviewed, and tweaked if they don’t work. To this day, our team reviews their processes every month. This gives people an opportunity to voice concerns, and make sure the whole team is working as efficiently as possible. We found that during the first few months there were lots of overhauls to our processes. However, as people begin finding a good rhythm as a full team, this becomes less and less frequent.

[banner]

04 Implement best practice architecture and CI/CD from the start (before you really need it) - as you have less time to make technical improvements when in full feature development flow!

We all know that when working on a new, exciting project, it's very tempting to dive straight in! One of the benefits of working with a small team is being able to give the one or two developers working on a project freedom to build, test and deploy new features how they want. To begin with we ran the delivery of our platform without many rigid processes and this proved to be effective. However, as a team grows this can often cause a huge number of difficulties and create bottlenecks.

Setting up best practice for deployment processes from the start may take a little bit of extra time, but pays off massively in the long term. For example, choosing to rethink our process made onboarding new team members easier as the project grew. What’s more, setting up processes which are automated as possible helps rule out human error, and makes your product more secure.

Not sure where to start with creating this process? You don’t have to reinvent the wheel when figuring out what works best in agile project delivery - start with best practice and tweak! This is exactly what we did when examining and updating our development process. Building a process based on other people’s learning saves you time, allows you to keep up to date with the latest tools, and gives you access to the newest methodologies.

05 Get early user feedback mechanisms established early, and don’t be afraid to discard functionality if the feedback suggests so.

As mentioned above, feedback has been key to the agile build and delivery of DeliveryOS. At Deazy we’ve worked hard to have regular, short, internal feedback meetings allowing our Senior Project Manager, Andrea, to get insights into how our team uses the existing features, what they would like to change and how new features could make our life easier.

We have also worked hard to give people multiple, simple ways to give feedback. From a built-in feedback form within DeliveryOS, to external feedback forms and regular qualitative feedback for external users, our team has been able to build up a variety of feedback loops. Feedback is incredibly important for evaluating functionally. What’s more, as we operate in an ever evolving business and market, it is extremely important to keep up and be able to adapt with this change.

We’ve learned first hand that there is no better way to do this than via feedback. When creating DeliveryOS’s developer proposal process, we conducted a number of one to one coaching sessions with some of Deazy’s delivery partner. Watching users navigate the platform and try to fill out proposal forms in the platform allowed us to understand people weren’t able to immediately understand how parts of the page worked - something we aimed to do. Using the expectations and feedback of delivery partners in these sessions helped the team create a second version which was easier to use and was more inline with expected user flow.

An example of Deazy's platform design process in Figma. Each design is reviewed by our internal team for feedback before we begin development. 

All feedback is also always carefully organised and analysed, to allow our team to look back at the reasons for feature build. We store feedback on ProductBoard which allows our team to compile all insight into one place. Another tool which has been incredibly useful for our team is Hotjar. This gives users the ability to give feedback as soon as they spot a bug, and automatically takes screenshots so the team knows exactly where the issue or suggestion for better features is.

Agility doesn't mean instability!

Perhaps the overarching theme of the 5 learnings mentioned above is that moving fast, and building in an agile way doesn’t have to be a mad rush. You can create great products, fast, while also sticking to a stress-free, well thought out process.

Making sure you plan ahead, see your vision clearly, but also staying adaptable is key to a successful product delivery! So when building a new product, think about how you can stay flexible, while also laying the groundwork.

Are you looking for a way to stay agile while building a new digital product? We can help! Deazy’s limitless ecosystem of world-class developers gives you access to thousands of developers, at the right time, the right price, the right commitment and the right engagement model. Working with near-shore teams allows you to flex up and down as needed, meaning you are only paying for the talent you need!

Get in touch now - and start seeing just how easy product development can be!