How We Transformed Our Product Management
At sewts, we automate processes that have never been automated before. Therefore, there’s a unique challenge in combining our software development with our hardware and process design efforts.
Last year, we changed our development process to be more product-driven and to work around a few challenges we had been facing. In this insight article, we want to share the knowledge we’ve gained from our experiences with these modes of working.
There are multiple challenges within our development process:
- Configuration management: Multiple system components (e.g. robots, PLC, the vision system) need to have software configurations that are compatible to each other while also being compatible with different hardware components (e.g. grippers, sensors, cameras etc.).
- Integrated features: There are features that require work on soft- and hardware and therefore need to be managed between our software team and our hardware team.
- Dependencies of system components: Implementing a feature on one system component (e.g. the first robot) can have implications on a different system component (e.g. the second robot) or even contradict a feature that is implemented at the same time.
- Different development cycles: Software development cycles are in general faster than hardware development cycles.
From reading this, you can probably imagine the complexity of structuring out day-to-day work. So let’s look at how we handled this before our switch.
Our Previous Development Framework
For a long time, our two development teams were working quite differently. While the software team was working according to Scrum methodology and organized their work in sprints, the hardware team was adhering to an iterative process based on Kanban.
Both teams were organizing their work separately from each other with different development cycles. Communication between the teams happened mostly via the team leads of both sides as well as informal meetings between developers.
Needless to say, we were very dependent on productive and sufficient communication between individuals without having a process to guide that. This led to many cases where information regarding the aforementioned challenges was not shared as needed, a problem occurred and the system was not operational or delivered a sub-par performance.
A change needed to happen.
Our New and Improved Development Framework
First and foremost, we created one big cross-functional “product team” with both soft-and hardware development that follows Scrum methodology.
In every current sprint, cross-functional and temporary sub-teams assemble to implement integrated features. Those sub-teams self-organize and report their progress in a daily where the whole team can attend but doesn’t need to. It’s clear at all times which features are being worked on in parallel, which prevents misunderstandings.
We create high level user stories for these features that entail a lot of freedom, but also responsibility for the developers. I mean, that’s what you want in a job, right?
Two quality gates ensure every feature fulfills the business and quality requirements. There are regular and coordinated releases with new soft- and hardware versions that are compatible to each other, reducing configuration problems to a minimum.
So, what do you think of our new process? If you have questions or feedback, feel free to message our CPO Till at email@example.com. He’d love to read your input!