The best DevOps teams exhibit a high level of cross-skilling. They are able to draw work from a backlog and action it as a team rather than as individual people with specialized skillsets. DevOps team members should always take the next highest priority item from the backlog, assuming that there is no other work in progress or which is impeded and needs their attention. No team member should ever try to "pre-book" or otherwise "cherry-pick" an item, regardless of whether they simply want it or because they think they are best qualified to handle it.
The principle is that each team member should go to where the work is, whatever that work may be, exactly when it needs to be done. That's how the Development-Operations gap is essentially bridged. No time should be wasted waiting for the "right" work to be ready for the "right" person. In a Kanban-based DevOps system, this elimination of waste by means of lean flow is highly valued.
If a DevOps team is using Scrum, then there is a further consideration that has to be borne in mind because a Scrum development team will have a Sprint backlog. This backlog is drawn up by the team in Sprint Planning so that they can meet a Sprint goal that has been agreed with the Product Owner. This means that it's quite possible for a self-organizing team to decide up-front, during Sprint planning and subsequently during each daily stand-up, which team member will do what.
It's important to be able to distinguish this behavior from cherry-picking. It's particularly important for a Scrum Master to be able to smell a rat and sense when teams genuinely have a good plan that demonstrates self-organization at work or have started to cherry-pick to form undesirable skill silos.
In this case, the principle is that a good Sprint backlog will forecast, through priority or dependency, an order of work. What it won't do is to mandate that only a certain team member is allowed to do that work. As the Sprint progresses, the next available team member should action the next highest priority item from the Sprint backlog. If that work is allocated to team members in the plan itself, or if they are otherwise allowed to "cherry-pick" certain items, inefficiencies such as skill silos can easily become normalized. Self-organization then suffers because a team with silos will find it harder to re-plan and to decide "who can do what" in response to any change during the Sprint.
If a Scrum development team does have skill silos (and the vast majority will have them, to some degree), then they should decide during Sprint planning to remove those silos instead of planning to accommodate them. For example, they may plan to pair certain members with each other so they can cross-train and become more DevOps enabled. They may also reduce the capacity of work done in the Sprint so that this improved agile capability is given the time to be nurtured.
Select the most desirable item from a backlog without reference to priority or plan.
Glory built on selfish principles is shame and guilt.
Team members are often tempted to select those items from a backlog that they expect to be the most gratifying for them or the easiest to do.
A team member lays claim to an item that was not the highest priority for actioning. The claim is made by placing his or her avatar on the item. They may assert ownership either while the item is still in the backlog or by bringing it into work in progress.
Cherry-picking often occurs in teams in which the members are not cross-trained. Members may regard certain items as “their” work rather than the team’s work and try to lay claim to them accordingly. Backlogs items that have been insufficiently groomed for actioning may be avoided by team members who attempt to cherry-pick others.
If cherry-picking is left unaddressed, it will reinforce skill silos and reduce team cohesion, cross-functionality, and trust.
Cherry-picking can occur in Kanban. There is a danger of confusing this anti-pattern with Quality of Service since different terms of service can imply that certain backlog items are preferentially treated. Cherry-picking can also occur in Scrum, where the selection of an item by a developer is not in accordance with the team’s Sprint plan. This anti-pattern is associated less with XP since pair programming limits the opportunity for individual developers to cherry pick.