Team member without task in a sprint
One of team member works only with Database related tasks. If in upcoming 2 Sprints there are no tasks relating to Database, how can we deal with this?
The entire Development Team is responsible for their sprint forecast. Therefore, why is such behavior (team members only selecting work based on their preference) encouraged? What does the team think about this?
One of team member works only with Database related tasks.
If that is the case, where is the teamwork? How can that person be said to be a team member at all?
In my experience, I have seen developers with one primary skill and some secondary skills. DB experts are usually not skilled in programming (Java) or running any functional test or Java unit testing. Hence utilising DB experts in all sprints becomes a challenge.
Kaizar, in working with DB experts, are they open to learning new skills? Are they willing to help in any way to complete forecast sprint items?
The challenge is with specialized individuals who are only comfortable in their area of specialization and are unwilling to change.
If Scrum/Agile is anything, it is about change, at the individual, team, and organizational level.
Different organizations handle it differently.
Some organizations may want to look at individuals as cross-skilled wherein a person has one primary skill and one or more secondary skills.
Some organizations may want to have a smaller central pool of such skilled individuals wherein they take in work from multiple teams based on their engagement with these teams.
Some organizations may want to engage external vendors for specialized services like these on T&M basis.
It is up to the organizational culture and what the individuals are more amenable to in the organizational context.
No database is needed for the new features developed by the next two sprints?
What if the new functionality requires a new database field, or does the requirement change?
If the next two sprint can no longer make changes to the database, how agile?
It seems that you cut software requirements in a layered way. And the database structure has been defined beforehand.
Have you ever considered changing the way the user story is written?
Here we go with that scrum theory thing again. What the guide says and what real teams do.
My question here is this person 100% committed to your team on every sprint? If not, why do you care? Release them to do their other work. Pull them back in when they are needed in 2 sprints. I have done exactly this. My experience has been with these type of team members DBA, Report writers etc they are a shared service type. They hop on the teams as needed to accomplish a sprint goal. This is communicated throughout the org though and not in a void.
If they are 100% committed that person can be cross trained to say write automated tests. If they are open to it do a little paired programming so they can learn a little more to be cross functional. Team decision.
I have had this scenario before with report writers, so we added them as needed. There is some resource planning that goes with that, but it works out.
When a home is built, plumbers do plumbing, electricians do electrical work, masons do masonry work. Plumbers are not qualified to do electrical work, and masons do not know standards to do plumbing work. Why is there this belief that a DBA can do QA or development, and SHOULD do these types of tasks?
Paul,
Using your analogy, what happens in a construction project if plumbing is next on the list, but there are no plumbers available (perhaps called to another job, or out sick)? Does the entire construction project stop until there are plumbers available?
I don't believe the suggestion is that those with highly-specialized skills should become a jack-of-all-trades, but that there is a significant risk to skill silos within a team, and that this needs to be mitigated for the overall health of not only the project, but also of the organization.
There is a significant amount of empirical and scientific evidence showing an increase in productivity through swarming, and having everyone on a team contributing in any way they can, as minor as that might be. This offsets the built-in waste around handoffs and skill silos that reinforce single points of failure.
+1 Timothy
A team that does not embrace T-Shaping or Pi-Shaping will never evolve beyond mediocre.