The question begs a few other questions. What do you think qualifies you to tell a team of fellow software engineers what to do? Is it your experience? Is it the funny little title your boss handed you? Is it your ego? Your tenure at the company? Is it your "panache?" Your "style?" Your "leadership skills?"
Agile teams don't hand out badges or hats to one another that say "Congratulations, you're our super genius -- you're the only one allowed to do super secret double genius work." Rather, the focus is THE WORK AT HAND. If you're indeed more experienced, then that experience should SHOW in how well your designs push the work forward toward completion. Your self-chosen assignments (cards) should reflect the areas you're most expert in. On the other hand, if some kid right out of college has a better idea, and it fits the context better than something some 40 year veteran comes up with, why on earth would we go with the poorer design? Our workplaces aren't therapy offices -- they're where we come to build great things.
That begs another question: who gets to decide what "better" means? The answer: the team of stakeholders. That means the developers, requirements people, testers, business people, etc. who are the builders and users of the thing in question. If you have a great idea, you better be able to demonstrate why it's better. If you can't do that, then there is no reason for the team to believe that your idea is better. Agile encourages meritocracy.
So, what happens to the "development team lead?" in agile? Nothing -- they just better live up to that name -- they better ACTUALLY be able to produce better software than the other people on the team. Otherwise, there's no reason to call them a "lead" -- it's just a little badge or funny hat, and it's meaningless. Lots of people find this threatening. They feel like they've been "working for" a badge or funny hat. Good developers don't work for funny hats. They work to build great software, and they plan to do it until they croak -- their goal is to get better at building software, every day. If that's not you, maybe you might want to look into project management. You'll probably be happier.