Skip to main content

Full stack teams

Last post 06:38 am April 18, 2018 by Martin Chung
3 replies
02:37 pm March 25, 2018

Have been reading about Full Stack teams (example: https://www.alexandercowan.com/full-stack-product-team-3-sketches/)

Currently we have:

Architects (design the solution)

Engineer (low level design/implementation)

Developers

QA people

These are all in separate teams. My understanding of a Full Stack team is a virtual team where there are representatives from each group within it? Is that correct?


05:43 pm March 26, 2018

Do you think this might relate to the idea of having a cross-functional team? One with all of the skills needed to meet a Definition of Done and create product increments of release quality?


11:27 am April 16, 2018

Alexander introduced the Full-Stack-Person. A person skilled not only in their own silo (architecture, engineering, development etc) but open minded and knowledgeable in the other domains as well. When full-stack-people from different teams interact there are interesting dynamics created that help gain better solutions. That is what he looks at in his post.

He does assume one single person has Full-Stack capabilities, not only the team as a whole. Especially for Product Owners I see an advantage if broad capabilities allow to communicate on a technical level and a management level as well.

Even if that was not what Alexander described in his post, I agree that your team should be "full-stack" in the sense you describe. Be it a virtual team or not.


06:38 am April 18, 2018

I agree with Stefan.

The article basically suggests that traditionally non-technical people (I should really say non-Development Team members, perhaps) should understand some standard software development concepts (that Alexander has listed in the diagram). These are people like Marketers, Project Managers, Account Executives, etc. having "Full-Stack" skills and being able to be more effective in communicating with clients or their own technical teams.

Perhaps it's his use of the term "Full-Stack" that is confusing? Full-Stack skills in his article do not refer to the regular development team use of Full-Stack (i.e. programming at all levels - hardware, DBMS, web services, server-side code, client-side code, HTML, etc.).

Instead, "Full-Stack" is used to signify having at least some basic idea how software is put together, not necessarily having programming skills. It's not much different than requiring drivers to have to learn car basics like a car has an engine that needs fuel, has oil that needs to be changed, has a battery, brakes, a steering wheel that turns the tires. Drivers do not need to know how to fix their cars.

Likewise, "Full-Stack" skills are not deep skills, but broad skills that can be important foundational knowledge. And a "Full-Stack" team is not a virtual team with members from architecture, development, and QA. Instead, I think he means just any bunch of people whose members have "Full-Stack" skills.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.