This question came in today, and I suspect some other people might be thinking through who needs to be on the team versus who needs to be a friend of the team.
>>Question that came in:
Hi Joe, HW question for you … I’m helping a LeSS adoption. The current client makes (or procures hardware), then modifies drivers and a variant of Linux then software group adds apps. Regulated industry (airline). What have you seen with team composition having hardware people on them? I assumed Kanban for hardwaree team (lead time of weeks/months), but they are also travelers on feature teams. Much TIA!
>>Reply from Joe:
Good to hear from you. The fastest teams I’ve ever seen have all had an independent path to production. In this case, that would mean the team is composed of people who, if they all worked together on just this one product at the same time, could add the value they needed to add (sounds like modifying drivers is part of this team’s value add), test, integration test, update the docs, package, and ship it. There are many other team composition possibilities of course but I did want to share the absolute fastest I am yet aware of.
And some more information:
I’m often asked if procurement or legal or people operations (HR) should be on Scrum teams delivering a product. Here’s an analogy that may let us answer each of these cases in our own company. If your company mails packages between an office in Shenzhen China and an office in Seattle, WA, USA, you could ask, “should the mail carrier be part of the team? They are often required to get your release to production.” There is a very sensible answer here. If the mail carrier is not your bottleneck, then the mail carrier does not need to be on your team and continue using the mail carrier vendor you are using. However, if the mail carrier is the bottleneck, and any one team member is experiencing downtime waiting for this package, then a team member needs to take on the courier roll and get ready for 3 scheduled international flights a week every week. You will find that the air travel is less expensive than the lost work time in salaries from the teams spent waiting, even before calculating the cost of delay of the product being released for use.
So what about finance and legal and people operations? If they are not the bottleneck, I encourage them to develop their own scrum teams to improve purchasing and vendor relations, reduce company exposures while simplifying internal policy, and replacing annual reviews with team compensation and so on. However, if any of these groups is the bottleneck, and a team is waiting 2 days or even two weeks from a supply request being made until the procurement approval is granted, procurement should absolutely be dissolved. The former “procurement team” members would then be encouraged to select a product delivery Scrum team, join it, cross train, and coordinate with other procurement interested team members through a Community of Practice or even better a Quality Circle.
Joe Justice is the CEO of Team WIKISPEED and the president of Scrum in Hardware at Scrum Inc., where he is rented as an interim executive to manage organizational change and critical large hardware projects worldwide.