If you come from a traditional development background, one of the more difficult transitions you will make is moving from working solely in your area of expertise to doing whatever it takes to finish a Story.
You’re used to having your assigned tasks and being responsible for completing your tasks. You might be paid to write software, or create designs, or write test cases, or execute and automate tests. Suddenly you’re part of a Scrum Team and you’re paid to finish Stories. (That’s not absolutely true, of course. You’re actually paid to add Business Value. But the way a Scrum Team adds value is by finishing Stories.) So you get paid to make sure the Story is designed, coded, tested, fixed, reviewed, and finally accepted by the Product Owner as ready for Production. If the code is amazing and the Product Owner loves the approach, it adds no value if there are open bugs and it’s not Production ready.
Doing whatever it takes means that you have to become competent at areas outside of your expertise. You will rely on the experts to provide direction, but you will need to help out with something that wasn’t originally in your job description. And this means that you need to take every opportunity to learn. What makes a good test? What do the ETL guys do? What are the elements of a good user experience, or a good design? How do you optimize your access to a database? Ultimately you’re asking, “What can I do to get this Story to done?”
The more things you know how to do, the more of a Scrum MVP you become.