Clarification around every member on Scrum team being a "developer"
I was reading through this older thread (particularly the last post), and wanted to clarify some points. I am a burgeoning ATF (Agile Team Facilitator) and will be working with several different Scrum teams in our organisation, most of which will have (at most) half the members being actual software developers. Others will be analysts and testers. To be clear, we are more Business Agility-focused as we are not exclusively building software products in our work. However, we are still being trained in Scrum and general Agile practices.
At heart, I like the idea of treating everyone as a developer / development team member in terms of resourcing. The vision of the team swarming on blocked issues, being able to chop and change the tasks they're working on appeals to me. However, the reality is that these individuals are not trained as programmers / analysts so therefore will have limits (if not outright blockages) on what they can work on. Is this then therefore, a contradiction?
Secondly, if everyone is seen as a "developer", how do we then continue to reconcile the idea of "cross-functional teams"? Despite the label do we still recognise the nuance of people having different levels of aptitudes, and that informs who is identified as a "function" expert?
Thank you in advance for any thoughts you may have.
@Les Miskin, Just a small correction, every moment on the Scrum Team is NOT a Developer. A Scrum Team consists of 3 roles; Product Owner, Scrum Master and Development Team.
Now the Development Team is probably what you were referring to and it consists of Development Team members NOT Developers. Together, as a whole, they need to have all the skills needed to create a “Done” Increment. This is what causes them to be cross-functional. Over a period of time, interested DT members could cross train and upskill themselves, but that’s left up to them how they want to improve. Obviously having multiple skills has its advantages.
I hope this helps answer your question.
Not everyone on the Development Team has to be a developer.
The Scrum framework identifies three roles - "Scrum Master", "Product Owner", and "Development Team member". If you are not the Scrum Master and are not the Product Owner, then you are a Development Team member. It doesn't matter if you're an analyst, a tester, a developer, or something else. You are a member of the cross-functional team of people who have all of the skills necessary to get a Product Backlog Item integrated and Done.
This isn't about resourcing. It's about shared ownership, motivation, and self-organization. The idea is that by removing titles and specific roles, the team as a whole takes the ownership of the work. If certain skills are limited to certain people, then you need to consider that as a bottleneck at Sprint Planning. The capacity to do work is limited by the people that you have who can take the work on and, as a team, those limits would need to be figured out and considered.
Thanks guys, I will try and use the correct terms in this post.
If we are in a situation where team members who have programming skills are happy and occupied with their work in a sprint, but team members who have different skill sets (such as business analysis and testing) don't have any work to sink their teeth into, what problem does this point towards?
Should this second group of team members try to help the first group by learning how to program, try harder to apply their skills to help them (e.g. test something midway through development), or should we pull more work into the sprint so they have something to do? If we do the latter, it feels wrong to me, like we are working on "pieces" of stories in parallel.
I like the idea of all of us pulling together to work on the sprint, but struggle to reconcile this with the realities of skillset differentials. Thank you for your patience.
@Les Miskin, Remember That the product owner can delegate some of the responsibilities or work to the development team members. Perhaps in such a scenario the business analyst may be able to help. I have also seen business analysts Working with testers to verify if the product backlog items meet the acceptance criteria. So sometimes business analysts can acquire skills from testers. However, if business Analysts have no function on the development team, Then maybe, it may be best for them to utilize their skills outside the scrum team but in a different area of the organization. Why don’t you ask your team members what they’d like to do?
Thanks Steve. Sounds like a shift in mindset from "I have nothing (obviously specialty-related) to do" towards "How might I use my skills to help the group meet it's sprint goal?".
I will also be sure to pose the question to the groups once they are formed (these questions are speculative based on past experience with more informal teams).
If we are in a situation where team members who have programming skills are happy and occupied with their work in a sprint, but team members who have different skill sets (such as business analysis and testing) don't have any work to sink their teeth into, what problem does this point towards?
Peehaps it might indicate that work-in-progress is being stage-gated through the Sprint, rather than limited.
Peehaps it might indicate that work-in-progress is being stage-gated through the Sprint, rather than limited.
Indeed! This would be my guess as well. Maybe it is good to check the flow for waterfalls
What about:
"How might I use my skills to help the group meet it's sprint goal?"
toward
"How can I help the Team meet our goal ?" - "Which skills can I teach / learn / grown in order to better contribute to the goal" ?
thanks @Les Miskin for bringing the discussion to table.
My last experience resonates with your thought where team members got the idea of everybody needs to be developer. Testers panicked and started projecting their inclination towards development ( out of fear only) . We don't limit ones willingness towards certain tasks however at the same time people expert in the area makes team CROSS FUNCTIONAL .
Everyone has pointed out that there are 3 roles. I point out that a role describes the work that is done by individuals while a job description points out the work you will need to be able to accomplish. Read any job description for a Developer, QA, BA and you will find elements of Product Owner, Scrum Master and Software development in them. So this is very much as you stated
Sounds like a shift in mindset from "I have nothing (obviously specialty-related) to do" towards "How might I use my skills to help the group meet it's sprint goal?".
I've seen BA's help test. I've seen Developers help test. I've seen QA write code. I've seen QA analyzing data pulled from the database to help validate assumptions being made by the Product Owner. I have seen Product Owners test code. I have seen Product Owners participate in code reviews. A cross-functional, self-organizing team will take advantage of all the skills the team members have to accomplish the goals regardless of what their official title is.
My last experience resonates with your thought where team members got the idea of everybody needs to be developer. Testers panicked and started projecting their inclination towards development ( out of fear only) . We don't limit ones willingness towards certain tasks however at the same time people expert in the area makes team CROSS FUNCTIONAL .
@Ekta Gupta, I am not sure I quite agree with your understanding of cross functionality. The best analogy I can think of to describe a cross-functional team is that from the game of cricket. All 11 players are expected to bat (if the need arises) but there are some excellent batsmen, excellent bowlers and some all rounders (excellent at both bowling and batting)
Does that make better sense?