Component or Feature Teams for Scrum in Hardware Development
These days we try to expand our Agile Transformation also including hardware developing teams. I know in the perfect world, the teams should be in charge of a product and there should be a cross-functional team being in charge of software and hardware.
But during an Agile Transformation of course, we don't live in the perfect agile world, yet, and maybe never. So we are still split in SW and HW teams.
The SW teams are doing okayish and improving continuously. To get our hardware teams somehow started and used to Scrum, I was preparing a seminar. During my research for Scrum used in hardware-only-projects(!) I found a lot of experts like Jeff Sutherland slice the product into components. From a hardware perspective that also seems more comfortable.
In my believe, a car buying customer does not buy the chassis, the engine and the entertainment system of a car, but a car which might be split into a minimum viable product (not "bike to car" but "no-engine car to sportscar" ). So going with feature teams makes sense to me in an agile customer-centric perspective.
Nevertheless my management and the tech leads feel more comfortable in the component thinking. So I agreed.
So nowadays I am tempted to get them going with component teams. This resulted into the first sprints bringing as an outcome nothing more than hardware part orders to external companies and a few technical drawings. The obligatory increment of the first sprint was far from having any business value, being able to get any customer feedback etc. . So what happened is that the new-to-this-role Product Owners pressed the waterfall approach into Sprint Iterations. And that's for sure not what I wanted, because the spirit of customer-centric agile mindset of course got lost.
I wonder if I start with a new set of agile pilot products whether I should push through to build feature teams.
Or was the problem that they didn't build prototypes?
Any opinions welcome, please help me improve my coaching.
How is empirical process control being maintained in those cases where features are absent? If there is a failure to leverage empiricism, what pain point is the organization experiencing as a result? From what you say, people are comfortable right now, and perhaps they see no problem to solve.
Yes, exactly. They don't see any problem to solve, because they are not used to an idea of customer-centric development.
I think, if they would be feature teams, they would be more encouraged to build prototypes. As long as they are just focused on their component and not caring for integration, there is no urgent need to build a prototype.
And then as I said, isn't it bad to just press the waterfall into sprints? So having a Technical Drawing Sprint, having an assembly sprint etc.etc.?
On the other hand how do I slice big hardware products into features? I find it hard to come up with features which are of a decent size fitting into a sprint.
Is there any literature being focused on feature teams for hardware? I couldn't find any.
How did they work before? What do you want to achieve when the HW team uses Scrum? What parts of the Agile Manifesto can be achieved easily?
When company starts Agile transformation, they should first ask themselves a key questions:
WHY ARE WE TRANSFORMING TO AGILE?
WHAT ARE WE TRYING TO ACHIEVE BY TRANSFORMING?
and then HOW ARE WE GOING TO DO THAT? ARE WE GOING INTO THE RIGHT DIRECTION
If answers are unclear and the company is doing it because everyone else does, then the way will be more rocky and difficult. Key phrase in what you describe is " new-to-this-role Product Owners pressed the waterfall approach into Sprint Iterations"
If the product owner is able to push anything into Sprint, then you are already moving in a very wrong direction, disregarding if you are methodically following all events and set of rules. The first and most important aspect of Scrum (as the biggest part of Agile) is achieving team self management, and clear understanding of the roles, including absence of hierarchies.
As for Feature teams vs Component team, Scrum is not against the component teams per definition, it is just better to evolve into multifunctional teams who can use different skills to produce increment
From what you wrote it seems more that you are struggling with creating proper Definition of Done and establishing the value of increments for your product, which is a bigger aspect compared to the team architecture.
Scrum starts with a Product backlog, which corresponds with Product vision, which then will provide guidance into a roadmap towards more self management and cooperation.
And lets please remember that its a Scrum masters responsibility to establish, safeguard and promote scrum within the organization, and to find a ways and tactics to do that; so if not experienced Product owner is making the steps in the wrong direction, scrum master should find ways to help him correct his course. Its a part of the job.
I think, if they would be feature teams, they would be more encouraged to build prototypes. As long as they are just focused on their component and not caring for integration, there is no urgent need to build a prototype.
What would they gain from building prototypes? Is this going to reduce uncertainty? improve "the ability to innovate" or maybe "time to market" by unblocking software development? If, so, is there any way you could quantify that? That would be very much needed to make the case for this change.
Meanwhile, while debating the agility of the entire HW/SW product, you may still find it beneficial to use Scrum on the software components level. Where components are becoming internal products with the "component owner" being a PO for the given Scrum Team. Everything else, including the HW, is the external dependency. Other component owners are the stakeholders etc..
The 'real' HW becomes the dependency that the Scrum Team needs to address. They may come up with the idea of emulating HW to some extent. The DoD for the software component may allow testing with emulated HW when real HW is not available. Further, in the future, the DoD will be improved by the necessity to test with real HW.
It is important to keep a high level of transparency and make sure the integration work is included in the Product (Component) backlog.
They don't see any problem to solve, because they are not used to an idea of customer-centric development.
What pain points is the company experiencing as a result of not having empirical, customer-centric development?
It isn't enough for an agile change agent to be right. Where is the sense of urgency for change actually coming from?
It's perfectly OK to have 'component' teams, but as platform teams. Such deps should be treated as optional and it should be a self service approach. Platform teams treat consumer teams as internal clients. With such rules it works pretty well 🙂. Team Topologies concept - highly recommended to have a look at.