Scrum implementation questions

Teams should be cross-functional and self-managing, so that PBIs can be based on features and not technology layers. 

Each team member should try to become "T" shaped instead of dedicated specialist only. 

The Developers can use whatever method they wish to forecast what work they believe they can do during each sprint, as scrum does not dictate any method or technique.  Remember that a forecast is not a commitment by the Developers that they will do all of that work. 

During sprint planning, the Developers only decompose PBIs that will be worked on during the first couple of days, and will do the rest throughout the sprint. 

Your list of questions indicates that your company has not implemented scrum.  Please review the scrum guide in order to understand this framework, as perhaps even your scrum master may not understand it full.  Are they even a qualified scrum master? 

Transparency over value delivery is greatly improved when each team has all the skills needed to produce a Done increment, and external dependencies are minimized. Have the teams borne that in mind when deciding how best to self-organize?

The hand-off of work from one developer to another can lead to inefficiencies. Has transparency been established over any bottlenecks and other waste?

The Developers on a Scrum Team ought to be responsible for their own estimates, since they are the ones who will be doing the work. They should also plan to meet a Sprint Goal by means of which value, and not velocity, will be delivered to stakeholders. What does the Scrum Master think about these matters?

Well, some of these questions often happen when you are trying to apply predictive lifecycle ideology to scrum. I would suggest to start with value-based metrics first, such as time-to-market and value realized. Some answers become obvious if your and your team is more concentrated on the value delivered.

p.s. Considering the phrase about English and the name, I may guess that Russian might be more comfortable for you. If so, please feel free to get in touch with me, I am open to discuss these questions in Russian. 

Each team member should try to become "T" shaped instead of dedicated specialist only. 

Codebase is complex enough, have people proficient with tech stack and the project in company, but no specialists at all assigned to support it. It's seems very strange to me not to choose simplest option with specialists.

Your list of questions indicates that your company has not implemented scrum.  Please review the scrum guide in order to understand this framework, as perhaps even your scrum master may not understand it full.  Are they even a qualified scrum master? 

No prior experience with Scrum or Agile, even not sure if Agile Manifesto was readed.

The hand-off of work from one developer to another can lead to inefficiencies. Has transparency been established over any bottlenecks and other waste?

There were attempts to do so, i'm waiting for an outcome.

Thank you all for answers. For me situation seems pretty messy, but better get few independent detached opinions on all this, perhaps will show this discussion to colleagues and SM.

It's seems very strange to me not to choose simplest option with specialists.

The option is simplest if you primarily evaluate the efficiency of the resource utilization. And this true; when we speak of resource utilization, the predictive lifecycles are way more successful. 

The problem is that high-level resource utilization does not help a lot with higher quality (if we mean quality in terms of ISO 9000: the product's ability to satisfy the customers' needs and expectations), faster releases, early MVP, and, last but not least, handling the complex problems. The latter is a typical reason to implement an Agile and/or Lean lifecycle. 



It is almost impossible to explain all nuances on how Agile/Lean teams are designed to overcome the complexity and produce the outcome fast and early, but in few words sticking with specialists.



1) Specialization cultivates "I did my job very well, and this limits my accountability in the successful product release" attitude. "If the product fails - it somebody else mistakes". In other words, it is the attitude "I do the best I can" instead of "I do the best I can to make the product be successfully completed".  You may want also to google "silos". DevOps sources have a lot of reasoning why silos affect the project performance. 



2) Early and fast delivery requires timely and fast decisions. Unfortunately, no matter how good is the specialists - the specialist is a human. And people have irregular performance. So, while one specialist can make a perfect decision, it may happen only when time and the conditions permit. A group of diverse T-specialists supported by generalists has way higher chances to make a good enough decision, and do it exactly when/where it is needed. 



This is why I suggested start using value metrics. "You always have what you measure"(c).

And, by the way, T-specialist is not the other name for "generalist". It is a specialist in one particular area who else can be used as an ordinary specialist to support other areas. E.g. a senior-level C# developer may also be familiar with SQL development and testing enough to pick up a task specified by the specialist and continue it.



This changes the strategy from "well, let's split the work to pieces and assign to whose who can do this job" to "well, what is the most important to complete the product in time and who is the best possible option at this time to do this job". 



I hope this helps. 

To `Nikolay Gekht`
I mean should have at least 1 specialist and other team members can be less experienced, don't mean team only from specialists.
Can remember few times when team only from juniors(or unexperienced with new stack) made too many bad decisions. Much harder to fix it later on.

>> And, by the way, T-specialist is not the other name for "generalist". It is a specialist in one particular area who else can be used as an ordinary specialist to support other areas. E.g. a senior-level C# developer may also be familiar with SQL development and testing enough to pick up a task specified by the specialist and continue it.

In my view it's 1 specialization, Tests can't be separated from coding and DBs seems like common task for backend on C#, mostly I saw C# on backend.
I mean situation when frontend developer can be assigned with backend task(or whole project) and visa versa.
E.g. company has job position for "Senior Software Engineer" without any details about tech stack or even backend/frontend/mobile specialization, just Senior for everything.