Technical dependency

Hi , 

So this team does not have enough technical skills to deliver the new features of the 'domain' there are part of ?

What does your PO has to say on this ?

What other possibilities you can think of apart from having some trainings each sprint to enable team to deliver the increments? 

What do you think about getting this 'domain' expert as a part of your team ? would it help ?

Thanks Harshal for your comments. 

We are part of automotive domain and there are always new features coming in. My team consists of freshers and 3+ years experience members but yet they are struggling with work. 

Hiring an expert is no longer a option for us as company is on a budget. When i inquired about training team's response was negative. company cannot afford to provide training every sprint for new features. We are kind of stuck in between. 

What do you suggest, how can we tackle this issue effectively?

What where the choices to compose the team the way it is not versus the backlog?

not=now

How well are the team able to estimate this work, given that they are struggling to complete it?

We are part of automotive domain and there are always new features coming in. My team consists of freshers and 3+ years experience members but yet they are struggling with work. 

>> Totally second the question put up by @Sander . Why the team is composed in this composition ( not as per the skills this product requires) ? What does your organization think about the increments the team intends to deliver with limited expertise ? Is there enough transparency between stakeholders and team over the skills the team is lacking of?

Higher management is familiar with the situation and still expects team and scrum master to work it out. As a scrum master i tried to help my team by taking small user stories with some buffer for analysis but then management did not approve the resolution as team is responsible to meet strict deadlines. 

as team is responsible to meet strict deadlines.

Is the team really responsible for that, or is it forced to ???

How can the team be commited if they can't be heard by "higher management" ?

@Shivani - Hi, Your situation sounds like ' Team of rugby players trying to play football' and management still wants them to deliver the good results. As per me this an organizational impediment and you should try to convince the management supported with facts and data. They need to realize without supporting team they cannot achieve their so called deadlines. But i think you must act now on this.

@Harshal What do you mean by data here? Velocity, failures, impediments, Capacity etc? 

@Olivier  Team is trying their best to meet deadlines but still they are lagging behind. I have tried to explain this situation to management but all my efforts went in vein. 

By data i mean , you need to present how much time it might take to convert the PB into an increment as per the current performance of team.

Does it match the deadlines of your management ? What you can do to make it within the deadlines ? 

How aware is your management of how Scrum works?

Shivani, it would be interesting to hear what your management is basing their expectations on.   Past performance/delivery?   Wishful thinking?

In my opinion, Scrum is not compatible with strict deadlines and scope being imposed by senior management.

Does your Development Team work with a Product Owner?   If so, is that Product Owner 100% responsible for value delivery by the Development Team?   If not, why not, since that is obviously not Scrum?

@Shivani, The things you are saying about management leads me to believe that they have the common misconception that Scrum will make you faster.  It doesn't make you faster. It provides you to iterate on the deliverables in order to get feedback sooner and often.  This enables the Scrum Team to adapt the work they are doing so that in the end, the product delivered is actually what the stakeholders want and not what the stakeholders thought they wanted at the beginning of a 10 week project. It may end up taking 12 weeks but the final deliverable should meet the stakeholders current needs instead of the needs anticipated 12 weeks previously. 

In my opinion the only deadlines in Scrum are created by the time box allocated to the Sprint.  This gives the Development Team a target for doing their work in order to receive feedback on the work that have done. But notice I said the deadline is to receive feedback, not to complete their work.  Their work is completed when the Stakeholders say "this is what we want". 

The problems inherent with building something that someone asks for by a specific date is part of why the Agile Manifesto for Software Development was written. It is also what propelled manufacturing companies to develop agile practices from which software development adapted. The best measure for products where requirements are fluid or the work is extremely complex is how much valuable product is developed based on stakeholder feedback. That is not measured by time. If you have an environment where your requirements are fixed and the time it must be done is also fixed, you might be better offer switching to project management based on PMBOK structure rather trying to force Scrum to work for you. I am sure that I have a different view from others, but I see pointing this out to the organization as part of my Service to the Organization "Leading and coaching the organization in its Scrum adoption". If adoption of Scrum is wrong, I'm going to point that out and explain why as the transparency principle of agile/Scrum prescribes. 

@Daniel - Hi, I agree most of what you wrote and suggested. But I have a question (may be i got confused with time fixed part) - What if a product has 'time to market' fixed but scope can be variable (What can be delivered till this date is not fixed or agreed)?

To start, team forecast the number of sprints based on the requirements and after few Sprints team decides on the MVP. Is scrum not efficient in such cases ? 

The way I view Scrum differently than traditional waterfall PM is around the 4 aspects of project management (Time, Cost, Quality, and Scope).

In traditional PM, these 4 "levers" can be adjusted as needed in order to adhere to a given target date for delivery.   Please note that adjusting these levers, like quality for example (reducing QA testing from 8 weeks to 4 weeks), can help meet a deadline, but may negatively impact the quality or value of the final product.

In Scrum, 3 of those 4 levers are fixed.   Time is the length of the iteration.   Cost is the resource expenditure (hardware, software, team members, etc.) over that time period.   Quality is fixed at the DoD level.   

Therefore, the only lever that can be adjusted in Scrum is Scope.   

You can set a deadline for delivery, but what is unknown is what may actually be delivered.   Perhaps it is all of the original scope, as planned.   Perhaps it is some of the old scope, plus some new scope identified through inspect/adapt and feedback as the deliverable is incrementally created.   Perhaps it is a % of the original scope, but through value prioritization, it consists of the most critical features.

@Harshal,  @Timothy answered your question to me better than I could have. I honestly have nothing to add to his answer.  (Yeah, surprising for most people that have seen me post but true.)

Thanks @Timothy.

In Scrum, 3 of those 4 levers are fixed.   Time is the length of the iteration.   Cost is the resource expenditure (hardware, software, team members, etc.) over that time period.   Quality is fixed at the DoD level.   

Therefore, the only lever that can be adjusted in Scrum is Scope.   

@Timothy - Thanks !! Thats  make it clear enough !! 

@Daniel, @Harshal

You are both more than welcome.   Your responses in this forum are equally valuable to me.