18

Hiring and Personnel Management are Organizational Problems Testing is a Design and Programming Concern Modern TDD and BDD are architectural and programming concerns. In fact, I'd go so far as to say that any developer who hasn't embraced best-practice techniques like test-first design, continuous integration, DevOps pipelines, and so forth isn't really well-...


17

Testing should not mean executing tests (I expect that's what you mean by manual testing). The main business of testing comes in designing, developing and curating automated tests, analysing and understanding defects and fixing them. These are absolutely "development" tasks because development can't be complete without testing. Doing these testing ...


12

There is, almost certainly, a mismatch in expectations here. First, if you are practicing Scrum, the Scrum team is responsible for delivering an increment that meets the definition of done. There are no subteams - no such thing as the developer and tester from the perspective of who is responsible for the increment of work being done. Next, there needs to be ...


9

It depends pretty much on the Organizational Structure each company wants to follow. I believe that what you meant by a cross functional structure would follow a Matrix Management. As your question is related to the disvantages of it, follows the quote from Wikipedia: Key disadvantages of matrix organizations include: Mid-level management having multiple ...


9

First off, I should note that, as per my understanding of the term 'cross-functional team', it is not a team where every member can do everything. Rather, it is a team that is capable of doing everything. If your team is capable of taking a project from start to finish without waiting on dependencies, then it is cross-functional. If the team has to spend a ...


9

Your question itself raises several questions. If the developers are responding like this to the business need to test, there is probably a bigger problem. The other answers here assume that you have a properly functioning scrum environment with automated tests, continuous delivery, and all the other modern hallmarks. Based on your question, I suspect the ...


7

They will do other work that needs doing. Keep in mind that "being in the sprint" means that the story is important. Not being in the sprint means the story is not that important. Looking for something that falls in line with a person's specialty is nice, and making sure that over the long term your team's capabilities align with the kind of work requires ...


6

Optimize for Flow, Not Utilization In Scrum, when picking a set of stories to accomplish in one sprint, some sprints will have mostly art-heavy stories queued up, and some sprints will have mostly engineering-heavy stories queued up. By picking the next most important stories, we'd be committing to having some disciplines sat idle once their part is done, ...


5

There are three independent questions in your question and so let’s attempt to answer each one of them one at a time. Your first question – "Are there reasons why companies prefer this type of structure?" - has two Reasons depending on the kind of organization you are dealing with. Reason 1 – Organizations / Managers who believe in the idea of focus and ...


4

Yes, put them together. There is only one way the teams will ever get shared knowledge, by sharing. It's also the only way you'll ever get to continuous integration/ deployment. Example: In a previous organization, we eliminated the HR job of QA. All the existing QA people were moved over to a development path. They did not share the same skills as the ...


4

Your biggest problem is a toxic work environment. As you note, we yell at the technical person telling him almost literally that he is "not smart" enough to understand what we are trying to do. If someone were to do that to me, I'd immediately demand an apology. If I didn't get one, it'd clearly be time to update my resume... or perhaps even go to HR ...


3

A simple operational solution is to require developers to check in their unit tests along with the code. No unit tests, no code review. No documentation, no code review. This does not address the cultural issues, though.


3

Good question, first off. Here are my suggestions, and you pretty much already said it without knowing it is to adopt a more-or-less hybrid framework: Scrumban. You can have you Kanban Board setup in the way you suggest, in the normal 'To Do', 'Doing', 'Done' fashion (with QA/UAT anything else the actual Programmers/Devs will be doing) and with breakdowns ...


3

Ideally a user story is a complete business value statement and the estimate is the total estimate for all tasks and testing that are required to deliver the user story. What you are describing sails into component territory whereby you write up user stories dedicated purely to one component As a Front End Dev I want make a Button because the Back End ...


2

I've observed many organizations using Project teams from different functional groups. Functional groups allow people with the same or similar functions to learn from each other. This assumes interest on the group members, and opportunities for sharing knowledge. These don't always exist. This structure works well for establishing best/standard ...


2

The Scrum Guide states a few things about the Development Team - it is "self-organizing" and no one can tell "the Development Team how to turn Product Backlog into Increments of potentially releasable functionality", that there are "no titles for Development Team members, regardless of the work being performed by the person", there are "no sub-teams in the ...


2

I agree with Joel's answer regarding: There is only one way the teams will ever get shared knowledge, by sharing. Which addresses your first concern of the two groups cannot help each so much due to little shared knowledge and unidirectional dependencies Regarding your remaining concerns: the two groups frequently get out of sync because, e.g., ...


1

Tell them to shape up or ship out It really is that simple. Every dev I know (and I include myself!) hates testing. But every good dev recognises the need for it, because we all make mistakes. And anyone not yet skilled enough to recognise the need for it, pretty much by definition, is more likely to need it. It's no-one's idea of a good time, sure. But it's ...


1

It's worth noting that a team is not only cross-functional, but also self-organizing. The team is empowered to use their skill constraints as a means to address work that is deemed valuable for the sprint goal. This means the team can, and should, reach out to subject matter experts to help them understand their gaps in order to achieve the sprint goal. ...


1

in video games there's generally there's not a hard dependency between the disciplines (don't need to wait for all of one discipline to be done before the other can work), and if there is, the disciplines will work closely together to iterate on that one task/story You are already cross-functional (CF) to some extent. As Marut pointed out, a CF team ...


1

A common approach is to split sprint planning in to two parts. In the first part of planning the team works with the Product Owner to allocate stories to the sprint. They estimate in story points as a team and base their capacity on the velocity calculated from previous sprints. In the second part of planning the delivery team breaks each story down in to ...


1

I address this topic in detail in my upcoming book: Agile IT Organization Design. In brief: Cross-functional teams are indeed the way to go to reduce cycle times and improve business agility Traditionally, a functional organization is seen as more cost-efficient since it affords greater utilization of specialists across several teams. However, this reduces ...


1

I think the biggest advantage of creating functional teams is that it is easy...or perceived to be easy. And, I think there is a huge perception of control. By control, I mean the organization would believe that if you put an entire function in one team led by a functional manager, you would naturally build a high performing competency and set of very ...


1

TL;DR Motivation is a separate problem, and is largely about making the process appeal to team members' enlightened self-interest. The process, on the other hand, is definitely something you can improve. Knowledge-Sharing as Process The Scrum framework encourages knowledge-sharing and cross-functional teaming through a number of practices and framework-...


1

I have always found it quite useful to have everyone physically close, ideally in an open floor-plan. That is, no closed offices, low cubical walls. This kind of proximity gives rise, assuming the people are so inclined, of everyone seeing and hearing what is going on with every other member at all times. The moment someone encounters a new (for that person)...


1

I think you'll find that this is a structural problem and not related to individual attitudes or understanding of scrum. Whenever I have encountered devs who won't do testing, testers who want the code handed to them on a platter, and so on, it is because they are doing what they are told or what is implied by the circumstances of their employment. If devs ...


Only top voted, non community-wiki answers of a minimum length are eligible