Look at Capability, not Title.

Categories cross functional teams, Culture, Job classification, Scrum Improvements, Scrum.org Team 24 Comments

Ever since Scrum became widely adopted in the early 2000’s, discussions have arisen whether the Scrum Team consists of programmers, designers, or other titles specific to the needed skills. Should they be called out by title, or is this a cross-functional team?

With the arrival of Dev/Ops, a surge of opinion pushed that Developer team should be replaced with Delivery team, especially for non-software development (like marketing). Yet, from a Scrum user’s (Product Owner?) point of view they are everyone and anyone necessary to research, develop, deliver, and sustain the increment.

This has unearthed strong opinions. Unfortunately, they don’e converge on a single word or phrase.

A Developer is on the Scrum Team … we have listened to discussions about where this leaves the architect, tester, infrastructure setup, and other non-programmers required to “create”  a “Done” increment.

We decided this is one of the changes that Scrum requires. All team members work to convert product backlog into a Done increment. Not just programmers, everyone who”s skills, temperaments, and background helps.

Questions:
1. Does a Developer also deliver software, particularly if “Done” calls for it to be live when delivered. Or can a Developer only Develop?
2. As Scrum has moved to areas such as AI, autonomous intelligence, robotics, material science such as carbonate, advanced hardware development in the quantum space … the skills of the people that are needed to convert PBI’s to increments changes radically. We have to build on software development knowledge to do this.
3. If a Delivery team also develops what it is delivering, is it still a delivery team?

Should we employ Develop/Delivery to include all possibilities that we are aware of, or what suggestions do you have? The name should be all inclusive.

Regardless of the final choice (if change occurs), I’m sure that a sizable minority will not be satisfied. They need to study the Scrum values more to reach an appropriate conclusions.

Ken

24 thoughts on “Look at Capability, not Title.”

  1. To have a product for me somebody has to build it. So if “Developer” is no longer appropriate, shall we use “Builder”? Otherwise “Maker”, “Producer”, “Manufacturer”, “Artisan”, “Fabricator”, “Constructor”? I think my choice would go for “Maker”.

  2. At my work, a big global company, we call the team that works directly on the product creation the “product team” (a different name was “core team”), e.g. developers, testers designers. They work daily and closely together. The people that support them we call “project team” another name was “support team”), e.g. regulatory affairs, project lead and managers, department lead. They usually do not collaborate so closely and work not only with team and they also have other responsibilities. I personally like more “core team” and “support team” because that shows where the focus is, on the product – not on the project. If there should be only one team and one name At my work, a big global company, we call the team that works directly on the product creation the “product team” (a different name was “core team”), e.g. developers, testers designers. They work daily and closely together. The people that support them we call “project team” another name was “support team”), e.g. regulatory affairs, project lead and managers, department lead. They usually do not collaborate so closely and work not only with team and they also have other responsibilities. I personally like more “core team” and “support team” because that shows where the focus is, on the product – not on the project. If there should be only one team and one name then I would choose “product creation team” and the team members would then be called “product creators”.

  3. Most near-synonyms have significant etymologies beyond Scrum. ‘Delivery’ team is often suggested: but that term will certainly saddle those people with responsibilities for which they don’t have authority; ‘Product’ team is often suggested: but that term is already used in many business environments when referring to ‘our team of product managers’.

    I believe ‘Development Team’ and ‘Developer’ are suitable terms – if not the best, perhaps the least worst.

    I wonder if, rather than change the term, perhaps the Scrum Guide could be more *assertive* about the characteristics of the Development Team? For example, note that the bulleted-list of characteristics of the development team implies, but doesn’t explicitly include, a statement about dependencies.

  5. Hi Ken,
    Nice to read from you! 
    I believe the desire for a new name comes rather from the misunderstanding about the accountability of this team: It is and remains quality and delivery! And those who have not understood this accountability and didn’t understood the meaning and state of Done are always looking for a new names for the development team. The same applies to the role of Scrum Master, which unfortunately mutates into Team Master! Or the role from product owner to requirements creator or team owner.

    This discussion about belonging to the Development Team has not only become popular since DevOps, but also before, when many organizations started to convert their product development to Scrum. And there was the question, where to go with all the other people who also do something for the product increment?
    Many organizations just put everyone into the Development team. No matter how much these people do in a sprint of their capacity for the current increment. Most of the time these people are working on something different than the rest of the team. We notice this in the discussions and plan creation in the Daily Scrum towards Sprint Goal. Subgroups within the team emerge and the team begins to lose its collaborative nature. Sequential work prevails in the teams: specification, development, testing. Etc…

    Yep, having a cross-functional, full-functional team with all the necessary skills to deliver a Done Increment is indeed not easy. Especially with the fabulous wish to have “stable Scrum Teams”. Someone once told this fairy tale and spread the word that Scrum teams have to stay stable until the end of their lives!
    And yep, the more cross-functional a team is, the more independent it is of its environment and thus more self-organized. But our product development is complex. In this age, teams need more skills than ever. And in some products a professional development team is no longer enough, we need several of them.

    Not only Scrum and the development teams should work on these challenges, but also their organizations. New platforms, programs and opportunities for further education need to be established. Based on bottom up intelligent, the development teams need to be empowered to self-organize new team members for short or long periods of time and to regroup in order to have and learn certain new skills and abilities for certain sprints.

    I am more guided by the clear accountability of the team: Quality and Delivery. If that is clear, then it doesn’t matter which name it is.
    I personally like the term Development Team!

    Best Regards
    Fahd

  6. “Delivery” is just one task that’s part of the complex, creative, high-order work of *Development*. I would never want to call them just a “Delivery Team.” This would reenforce the misconception that teams are merely ticket takers at the bottom layer of a SAFE/JIRA factory.

    The Scrum Guide should change infrequently, and only for very good reasons. Let’s focus on changing organizations.

  7. The focus should remain with Scrum as a thinking tool and framework for managing an experiential process, not a control mechanism for folks that like to argue over titles, tools, and relabeled ticket taker teams. The SAFe implements Scrum in this way as self-organized Scrum or Kanban teams that use the value stream as a guideline and guardrail in the virtual construct of the ART.

  8. I think with delivery team we havebthe risk of some interpret it as the main thing is to deliver even when there is no value to do so, or at any cost.

    I agree that the “Development Team” it is highly focused or orieneted to Software, while in marketing, sales, R&D or other industries using Scrum, might not fit as good.

    I believe it will be better using “The Scrum Team” or if making it agnostic “The Sprint Team”, even calling it just “The Team” might be better.

    My two cents 🙂

  10. I thought it was clear enough, but if there is such a need: how about leaving the name as it is (after all, it has been a part of Scrum for a while) and maybe just adding a further clarification that in Scrum terms “Developer” means everyone who is contributing directly to the Increment. If it being “potentially usable” requires deployment that means “Developer” covers DevOps or whatever you call the discipline of deploying to servers. If it requires machining metal parts it means whatever specialty does that part too. Maybe the explanation should also include a reminder that people have usually more than one skill and that skills/competencies can be learned. When a part of the Development Team in Scrum each Developer uses all of the skills he/she has to contribute to the Increment & achieving the Sprint Goal as well as improves those skills and learns new ones to better contribute in the next Sprint.

  11. Great post Ken. How about updating development team to the ‘integral’ team; necessary to make a product whole/complete; essential/fundamental. No matter what cross functional skills are required, the combination of them are integral to the successful delivery.

  13. The developers at the software company at which I work, Digital Maelstrom, abide by what the customer wants in terms of delivery. Obviously the majority of the work is development- however, if a client requests that the development team delivers the software, then why not assist them with this step?

  14. Hi Ken,
    This is certainly a challenge. In my view, you do not need to change anything. I have looked upon the Development Team as not only developing the product, but via their actions, developing themselves (individually and as a team), along with mainly developing the organization. The delivery part, in my mind, happens metaphorically at the Sprint Review, where the increment is delivered to the organization and stakeholders. The effort and action is in the “development” whose end result is a “delivery”.

  15. Thank you, Ken, for this post. I did my own research on “delivery vs development” topic and facts says that development is used more in the context of something complex – real estate development, city development, financial instruments development, skills development, woman deliver baby once and develop until they get matured. Development Team in Scrum sounds amazing and reflects complex nature of work they are supposed to do.

    “Developers buy land, finance real estate deals, build or have builders build projects, create, imagine, control, and orchestrate the process of development from the beginning to end”

  17. You say: “They need to study the Scrum values more to reach an appropriate conclusions.”

    People love to hear such statements in churches, but your values cannot define how the world will evolve. Like it or not, Scrum fails to deliver software to production. You will either fix it or you will disappear.

  19. I think what James ment is that if the Team fails to deliver during a Sprint they will disappear. But the correct way to adress this problem is making sure everyone gets the support they need. The Scrum Master should, for example, assist the Team AND the Product Owner in every way possible without leading them. The Product Backlog is administered by the Product Owner but the Scrum Master assists in making it as effective as possible. That way the Team can always feel that they are able to deliver increments and potentially usable products in the end of evey Sprint.

Leave a comment