Rename "Development Team" to "Team" and remove "Scrum Team"
* Rename "Development Team" to "Team"
* Remove "Scrum Team" and replace the references of Scrum Team to "Team, PO, and SM"
The purpose of this proposal is:
* Resolving the naming problem of "development team" (as Delivery Team is a terrible alternative),
* Removing a small difference in terminology between Scrum and LeSS.
See my note
17 commentsComments are closed
Agree that "Delivery" team is not appropriate.. Back to "Development" team until something more inclusive come to our mines (like reify).
Tarang Patel commented
I disagree with removing the reference to Scrum Team, as this does help break down the “us vs. them” often enshrined by functional reporting structures that organizations have. Also reference to “Developement” team is valuable to discern the responsibility of “how” ideas/problems are solved and not necessarily “what” ideas/problems to be solved are.
I happen to love Development Team. It always provokes the question why there are no QA's or BA's in Scrum. Why only Developers?
That is my cue to point out that there are no Developers in Scrum just the Development Team. It takes them a while for them to realise that the Development Team has no roles, titles or subteams, the Development Team is the role. It is one of those things that makes people go "hmm..."
The Scrum Guide is brilliant like that. It draws you in to deeper discussions.
If you call it Team then it does not challenge the status quo forcefully enough. They are used to a Team consisting of Roles and this does not sufficiently challenge division of labor idea that we are trying to get rid of.
I like Scrum Team too. It emphasizes that the PO and Development Team are on the same team. It challenges the antagonistic relationship between "The Business" and "IT" found in most organisations.
Michael James (MJ) commented
It takes a while to understand why "Scrum Team" should be removed. And not everyone will get there.
In most companies the word *team* is diluted and there is an unfortunately pervasive idea that everyone who collaborates must be called a "team." And then the word is not available when we really need it, for the actual [Development] Team who have different responsibilities and interactions with each other than they do with the Product Owner and Scrum Master. This is the background of Scrum Team becoming an all inclusive thing about ten years ago. But if everyone must be on the team, why not also include the customer? The HR department? The husbands and wives of the employees?
Declaring that everyone is "on the team" is similar to declaring that all the backlog items are top priority.
Jacky Shen (CST, CTC) commented
yes, "Development Team" is confusing sometimes.What about rename it to "feature team" (or even "squad")?
As per "Scrum Team", I prefer to keep that concept.
Charles Bradley commented
I should also point out that I'm a fan of Less, just not this particular suggestion... lol
Charles Bradley commented
Not a fan so far.
1. I'd like to hear your justification for why delivery team is a terrible alternative?
2. Why is it that LeSS has not kept up with Scrum Guide terminology?
3. It would seem the Scrum community is FAR larger than the LeSS community (one recent survey said only 10% of Agile teams were using LeSS), so why should the Scrum community bend to the LeSS community?
4. Why is "dev team" a naming problem?
I could theorize why you suggested these things, but I'd rather hear your actual justification first, and so far you've provided little in the way of justification.
Brett Maytom commented
I agree with changing “Development Team” but not “Scrum Team”. Here is why
A role is defined as “the function assumed or part played by a person or thing in a particular situation.”
The role is at a person level and not a group level; i.e. You are in the developer role. You do not say you are in the “development team” role. You may say you are a developer in the development team. The semantics of role is being confused with a grouping or collection of a role. These are two different concepts
The confusion arises as we have the “Scrum *Team*” and “The Development *Team*”. This implies there are two teams with different objectives. It is the wrong understanding of what team really means as well as confusing the difference between role. It’s creating a segregation at the understanding level and this is where I have the issue.
I think there are thee roles
Product Owner (singular)
Scrum Master (singular)
An example. The developers are responsible for building and delivery of the product. Each role has a distinct responsibility in the Scrum Team. Often when people speak we use the word “developers” and not “the development team”
People are in the developer role as that role defines their responsibilities. It is impossible to work in the capacity of a “development team role”, instead you can work in a “developer” capacity.
As a group of developers in the Scrum Team, you work together towards your sprint goal. The Product Owner and Scrum Master also work within their role responsibilities.
I agree that we should get rid of the “Development Team” role and change it to “Developer” role only. It just confuses people having two teams.
I do not agree with changing “Scrum Team” to "Team" for a simple reason … the team clearly does Scrum and this is about Scrum.
I do not like the idea of removing Scrum Team. It gives the impression PO & SM are not part of the whole team.
Why do we need to have team after Development? Why not just call them “member” or “team member”. Seems like this would solve it.
So, I might add a proposal to User Voice that was:
1. Remove Developmet Team.
2. Replace with “Team Member”.
The team member does whatever is needed to help discover, design, develop, and deliver a product increment.
Karel Smutný commented
I back this proposal. I repeatedly find Scrum Team a confusing concept in multi-team (on a single product) environments. It (probably unintentionally) reinforces a "common sense" to have a PO per each team, prevalent in our industry, even if Scrum Guide specifically mentions single Product Backlog for a single product (regardless of number of development teams). Scrum.org's PSM and PSPO assessments further assume a single PO per product in multi-team environments. However it's not clear from how Scrum Guide is phrased now. Removing Scrum Team will help remove the confusion.
Alasdair Macleod commented
Are these rush of user voice actions actually being created to improve Scrum or are they being created to benefit LeSS by trying to move Scrum to look more like LeSS therefore giving LeSS more credibility in the market with the other bolt on frameworks and methodologies that have tried to put Scrum at the centre of their particular scaling product for sale.
Boris Kneisel commented
I like the idea very much - esp. when thinking about bullet 1: (Rename "Development Team" to "Team") - in practice, there are many people who struggle with "Development Team" or "DevTeam", when their work is not specifically resonating with their thinking in terms of "development" - so neutralizing the terminology will also help in widening the acceptance of Scrum to further areas of application.
Michael James (MJ) commented
I favor this idea.
There was a related proposal from Rowan Bunning at the link below. Perhaps these ideas should be combined into one proposal?
Alexey Krivitsky commented
Rickard Jones commented
Agree that the "Delivery Team" term is too prescriptive as then it will become to delivery confined and not also about being adaptive, experimental, collaborative, learning and growing, amongst many other things. Call it what we want it to be a real Agile "Team".
Luke Walter, CST commented
Agree. Further, this would work to dispel endemic misunderstanding of 1 PO per [Devt] team / that PO is a 'team output owner' or other proxy without real bu$ine$$ authority. Badly needed in field.
Marc Lustig commented
Until very recently I was also under the assumption that “Scrum Team” is misleading and so would have signed Bas’ proposal immediately. Then one of my mentors (CST) reminded me of the systemic dynamics between the Dev Team and the Product Owner: while the Dev Team is responsible for building the product right, the Product Owner is responsible for building the right product. Furthermore, while the responsibility for the Product Backlog is with the PO only, the proportion of work tasks to maintain the PBL should steadily shift to the Dev Team. Hence boundaries are weak.
Scrum Master is a different topic.
Probably it’s quite clear that Dev Team + PO + SM do not operate as a team in Richard Hackman’s sense (who probably has the most concise team idea).
Perhaps more discussion is needed here.