Very old fashioned management is based upon the theory that people don't want to do a good job and we need to use carrots and sticks to motivate the team to do their work. However this is not true. Most people come to work every day wanting to do a good job.
If you feel motivation is low make it your top priority to diagnose the underlying cause and address it.
Treating employees like volunteers means engaging with them and making sure they want to do what they have been asked to do. Or better yet let them select what task they do. Everyone understands that you can't get your own way the whole time, can't always do the interesting, exciting tasks. But if the team understand how a task contributes to a bigger goal and why it is important they should be happy to do it. If they still aren't happy than they probably don't agree with the bigger goal. We need to make it clear why the bigger goal is worthwhile or in their interests. Maybe we can 'trade favours' to get something disliked done.
But coming down heavy handed and using power is a bad idea because the long term cost of a disgruntled employee is almost certainly more expensive than the cost of the work not being done in the first place.
Creating software attracts people who like to solve problems and who like to be challenged. Solving problems releases feel good endorphines, we literally get a buzz out of it. If work is too easy we get bored and demotivated. If a piece of easy work needs to be done, and there is no one suitable to give it to, the unluckly person who has to do it needs to know they will get more challenging work soon. If there is a lot of easy work to be done consider hiring someone less experienced to do it, or automating it.
However if the work seems to be impossible and is far beyond their comfort zone the team will be equally demoralized. In this case we need to break down the work into chunks which are manageable. An experienced agile team will do this instinctively, but if our team is still transitioning to agile it might be the act of breaking down work into chunks which is scary. If this is the case maybe they can at least agree what the first chunk is. If the chunks are investigation tasks then they probably need to be time-boxed to keep the project moving forward and not stalling in analysis paralysis.
If the work is broken down into small chunks and the chunks are still scary then we need to encourage a culture where it's OK to failure. As Thomas Edison famously said "I have not failed. I've just found 10,000 ways that won't work." Allow the team the freedom to experiment and fail. If they can't choose between two or three ways of doing things encourage the team to try all of them. Maybe split the team into sub teams and get each sub team to spend an iteration trialing an answer. At the end of the iteration the team will know more. Perhaps with experience rather than theory one way will stand out. Perhaps a combination of approaches becomes apparent. Perhaps the experiment needs to run for another iteration. Don't view this duplication is waste, but rather is a quick way to learn and a cheap way to mitigate the risk of making the wrong decision.
Show that you value important things like releasing valuable software and continuous improvement, rather than unimportant things like time sheets and dress code.
Caring for our team as people as well as staff is also necessary. What's going on in their personal life? How's it affecting their work? How can we help?
A team lunch or a team drinks are a great way to both celebrate success and inrease team bonding.