Scrum offers an acceptable way to describe iterative development to middle and upper management. Scrum recognizes that complex systems, such as software development, must be allowed to self organize in a distributed fashion. Scrum specifically recommends that teams actually performing work be allowed to self organize.
Scrum ignores technical practices entirely. Program management alone does not guarantee that any Agile principles are followed.
Seven of twelve XP practices are explicitly technical practices, designed for better software. All twelve practices are chosen for their improvement of software. For example, constant refactoring takes the place of big upfront design. Pair programming takes the place of formal code reviews.
Managing software defects requires specificity. You must actually understand the technical issues. Metrics just create distorted priorities and are only followed by those who did not actually need them.
User stories can be prioritized. Technical issues should be managed by the team. Task backlogs should be managed by a team.
Iterative development is not incremental.
A sustainable pace gets more done than alternating emergencies and burnout.
Breaking stories into tasks and their coding by individuals should be left to the technical team. Tracking hours spent and remaining for individual developers is micromanagement. Developers hear the message that "Nothing else you could be doing is important." Those other things, which may not be user stories, include refactoring, writing unit tests, and talking with users.
Doing those things may improve the software and yet slow a visible velocity. If a scrum schedule is seen as inflexible, against all Agile principles, then velocity becomes a promise of how hard everyone is supposed to be working. Velocity can become a performance metric that distorts all other priorities, and loses any predictive power it might have had.
You need users and customers. Where are the users? How are you getting a reality check to what really matters?
Product managers want everything; they are aware of many stakeholders and often have a hard time priortizing. Marketing wants cool tech and big stories. Sales wants whatever lost their last sale. Program managers want everything on schedule. All are useful points of view, but not comprehensive. Only a real user can tell you want matters more to a real user.
Bill Harlan, 2011
Return to parent directory.