Anything Connected customer storysee all customer stories

Product company 🚀

1-10 ppl 🎩

IoT Hardware + Software 👻

Switched from Trello 😎

How to organize hardware & software development in Fibery

We use Scrum as our main software development process, using 2-week sprints. Every Monday we have a Backlog refinement meeting, where we discuss the Backlog items. At the start of each Sprint, we also join that with planning of the upcoming Sprint. Retrospectives have been few and far between, but we try to do those as well. Until a while ago, we did those at Friday 16:00, but have now moved it to the next week (and next Sprint), for obvious reasons. Every day, with the exception of the Backlog refinement days (it’s kind of part of it when it’s the mid-sprint “check-in” session), we have a daily standup at 10:00.

From a technical standpoint, once a Sprint has been planned, software development starts. We use mostly Linux, Git, VSCode, Docker and a few other tools for our software development. E.g. for our embedded development, we use a Remote Container which houses our entire dev environment for the embedded side, simplifying setup and maintenance. When sensible, work is committed to git, and when pushed, a Gitlab CI/CD pipeline runs some build and test things (and also e.g. a security scan), and a build artifact (Docker image) is ready if everything passes. Eventually a merge request is created for a branch implementing some Feature, and it gets merged to develop/master/etc. We use git-flow as a branching model. We have AWS for our cloud hosting, which has our Django backend, and after a successful merge to e.g. master, a new container of the resulting image is deployed on ECS.

How do you scope & plan development?

We do software and hardware development, which is one of the main reasons we actually use Fibery. We have a very clear idea about organizing hardware development and were trying to look for a way to truly combine software and hardware development in 1 team. We ended up taking Scrum as a starting point and deviating wherever we could. This meant we really needed to be able to customize everything, which is not really possible in normal tools for software development.

As mentioned before, we do 2 week Sprints, with a ‘Kanban meeting’ at the start. In this meeting, team members write their own Tasks and Stories, which are then discussed and given an amount of effort. Scoping is done during this meeting as well. Tasks and Stories are then moved to the Sprint, after which they automatically turn up on our Kanban board, where they are tracked between Backlog, To do, In Progress and Done.

At the same time, Domains and Categories for the product have been determined, which cover the different components of our solution. We have created categories of criteria for these, that we iteratively build upon. This allows for the exact scoping of the criteria that we need to reach for a Release.

How do you track and analyze progress?

We are working on a hardware development timeline.

Hardware is in the lead. So every Sprint, new Stories and Tasks come and go, until we reach a Release. At that point, we check off whether we fit with all of the criteria all at once.

We don’t have a Bug entity (at the moment), but we have Stories, Tasks, and Subtasks. Our Backlog view is a List view of those Databases. We have created one Timeline view which represents some kind of Gantt chart with blocked/blocking Stories, but we currently don’t really use it.

Our retrospectives currently solely answer these 3 questions:

• What went well last Sprint?
• What could be improved?
• What did we learn?

Sometimes, we create Action Items for the next Sprint based on the results of those questions. However, for the past few months, not much has been done to address the workflow-related feedback raised during those very few retrospectives, only a few other things.

We also use Fibery to carry out our Failure mode and effects analysis, here is how is look like 👇

How do you store a development wiki?

We store some of our development info in docs. We have also used Fibery whiteboards, but a team member once accidentally removed a large amount of data from the whiteboards and then spent time remaking them with inaccurate info. We never really got back into using whiteboards since.

Note: This was not a fault of or due to the whiteboards, but solely of said user. At the time, reorganizing Entities/Databases was a bit more error-prone/buggy than now, and it resulted in the user deleting one of those Databases which they thought to be empty. One view showed no more of those entities, but they only later realized that it had a filter active. Deleting those entities also deleted the visualizations of them on that whiteboard, as well as its visual links to other entities. Currently, we use Sticky Notes a lot on those whiteboards, so as not to interfere with “actual data”.