What to do when a new dev team don't yet know the technology?

Sprint Goals...they are useful in their own right, but really good for wide open huge sprints with unknowns galore.

Scrum Value of Commitment is that members of the team commit to the goals of the team. There isn't really anything in the guide that says members of the team are committed and locked into any particular Sprint plan. That's a bit of an anti-pattern living in the company.

In this instance, if you started with a Sprint Goal, a loose one...perhaps the company will be comfortable with the commit to the goal instead of a list of stories. I mean, it's a bit funny to be asking permission to the company for the team to be able to work they way they need/want to. Let alone 4-week sprints...that's only really good if all the work is pretty known. The more unknown, the more feedback you need, which typically shortens the sprint so you get that feedback sooner.

I hope that helps answer your question. My guess, a Sprint Goal like "Become proficient with X technology by providing Y prototype solution for Z." This way you bake in mostly research/learning, but applied into a non-descriptive prototype but something relatively in-lign with what the technology is used for. The demo would only focus on this Sprint Goal, giving them more focus on the goal and less on the granular specifics for each story along the way.

The company has over 100,000 employees and all following the same WoW.  We must say what we commit to for four weeks. They won't accept goals as a commitment but only epics as they want to know what specifically gets done.

But I guess the answer is that I work in a company that thinks its agile but really isn't and so we shouldn't think in terms of what would the scrum WoW say. I think I will work so that we only commit to epics we are sure of and start other epics but say they won't be done in the four weeks.

Hello Everyone, I had a very big question running in my mind after reading through this topic.

In general, is it a good practice to form a new Scrum Team with lack of Technology? I think the Team can/should have atleast 1 or 2 Technology experts. Else they will run even into assumptions and lack of clarity on what they are doing.

It will be a good learning, agree on that lines. But coming to Org point of view, product will take too much of time to reach so called Incremental stage. 

Is my assumption on this correct? Can someone throw some light on this?

@Alex Smith  I think you nailed it with these statements. 

But I guess the answer is that I work in a company that thinks its agile but really isn't 

What to do in this situation? I guess we should only commit to very basic and small well known items until the team develops?

In order for the team to start feeling comfortable in their problem space, they need to have time and some success.  Taking small well known items can give them both. But do not take too much.  Balance the companies need for the 4-week-Epic against the team's need for gaining knowledge and experience.  Your Product Manager needs to work with the Development Team to craft some epics that deliver value but will not require the Development Team to work solely on the epic.  As the team starts to feel more comfortable with the problem space and technology, increase the size of the epics.  If you want a book analogy, the team is still learning how to read.  So give them a few children's epics and then graduate them up to more difficult ones. 

@Gayatri Rani Matta

Scrum is good for working to solve complex problems.  In the case of new technology use, that is a complex problem. The benefit of Scrum, and agile in general, is that you make decisions based on your current knowledge and then adapt as you gain more information.  There are times that you may have to do something that no one in the company has prior knowledge of.  In your scenario, you would only be able to do that if you go external and hire 1 to 2 new people.  That is not always an option.  

But coming to Org point of view, product will take too much of time to reach so called Incremental stage. 

That is a risk a company takes when they decide to delve into a new technology. And the definition of "too much time" is relative and should be taken as a risk. I would also question how you know what is too much time?  If you are able to deliver small increments of value that increase in complexity over time and eventually deliver the functionality that the user needs at the time they need it, how can you say that took too much time? 

they want to know which epics we can get done during the next four weeks.  

I actually see that as a positive sign, where the company is deferring to the team to inform them on what can be accomplished in a 4-week span.   It should be reinforced constantly that any estimate made should originate from those doing the work.

I read also that the goals should be simple and straightforward until the team grows accustomed to the new technology.   I agree with that approach as well.   

Now, if the business communicates a different expectation than what the team provides on what can be accomplished in that 4-week span, I would simply ask the business what evidence/data they are basing their projections/estimates on.

Wishful thinking is a very poor plan.

They won't accept goals as a commitment but only epics as they want to know what specifically gets done.

Do you think these Epics can fall under the Goals ? Example -

Goal : Improve the customer experience with our top 5 most used Web pages. 

Epic - UX improvements 

I think I will work so that we only commit to epics we are sure of and start other epics but say they won't be done in the four weeks.

What is your role in this? Do you have a product focused organization? Are there products with clear owners who want value to be maximized?