In working with Scrum and attempting to reconcile it against various other development and software project methodologies, I've come to realize it's not the complete solution for all issues with the development process. It's a great step forward however. It makes vast improvements from the waterfall approach.
In waterfall:
- Here's what we (the stakeholders) want (the feature checklist)
- Here's when we want it by (the deadline)
- And if you're lucky, here's some ways to verify you did it correctly.
In Scrum it's more egalitarian.
- Here's what we (the stakeholders) are trying to do to improve the product users' lives.
- Here's what we (the analysts) think would best accomplish that goal
- Here's what we (the development team) think would be the best technical way to implement that
The problem is that there's no overarching design to bring everything together.
What's worse for a business is when personalities get involved. With Scrum, there's team success, and team failure. Individuals don't matter as much in that stakeholders are not really seeing individual achievement. What's the proper reporting structure for a Scrum team member? Who is the manager? The trite answer is that the team is self-managing.
The problem with this answer is in trying to reconcile self-managing teams with things like compensation and reviews. Perhaps the proper answer is to have group reviews where employees are reviewed by their ScrumMaster, some overall department manager, and by their peers.
What's even more interesting is how this can affect career paths. Employees of most career-oriented jobs follow a path from junior to senior to management, etc. until they reach their desired goals, retire, or fail to further advance. However how is it right to advance an employee on the basis of a team achievement? I would contend this would be on the merits of consistent behavior that makes headway in advancing the team unit, but I can see how this can be difficult to measure. This is especially true if the person to review Scrum team members were an employee who is not daily interacting with the team member.
One thing I'd like to note is that this career path for what I consider a driven developer is aside from a personal skills improvement path. This is well known in Mike Gunderloy's Coder to Developer book (which I'd strongly recommend as a great read. The state of realizing you should not just jump to code, over architect, or any number of other mistakes most (well, at least me, anyway!) developers make at some point in their professional lives is one which will personally advance you professionally.