I recently started a series based on an Esther Derby Amplify discussion about how to demotivate a team. Esther mentioned in her discussion that unclear and changing goals are a big demotivator for a software development team. Besides agreeing whole heartedly my first thought when reading her discussion is how a good Agile implementation combats these demotivators. Let’s see how Agile methodologies thwart some of these potential demotivators for software development teams.
But first, a high level review of some key Scrum concepts; The Prioritized Product Backlog, the Sprint Backlog, and the Sprint Planning Session.
The Product Owner prioritizes the Product Backlog to identify the highest priority / value product features to be delivered by the Agile software development team. By viewing the Product Road Map and the Product Backlog the Agile software development team can get a fairly clear idea about the project’s long term goals.
Scrum and Goal Stability / Clarity
The Product Road map is created by the product owner to provide a long term view of the product vision.
The Product Backlog provides a view of the desired functionality expressed as user stories. The Product Owner prioritizes the user stories to place the highest value user stories to the top of the Product Backlog.
The Sprint Planning Session and the Sprint Backlog; The Scrum team conducts a Sprint Planning Session in which the Scrum team selects from the Product Backlog a set of user stories and then commits to complete the selected user stories in the next Sprint.
It’s important to note that once the Sprint commitment is agreed upon by the Scrum team, the contents of the Sprint cannot be changed by someone outside the Scrum team.
Every day the Scrum Master conducts a Standup meeting with the Agile software team to review progress against the Sprint commitment. Using burn down charts the team can see if they will complete the user stories and meet the commitment (goal) of the Agile team.
Once the Sprint completes, the Agile team demonstrates the completed code to the product owner to validate that the Agile software development team delivered what was expected by the Product Owner.
In the Scrum / Agile environment, the team can see all aspects of the project, from the macro level Road Map to the micro level of the individual task. The Scrum team members set their own commitments on what they can deliver and are responsible to deliver on their commitment. It’s reassuring for the software development team to know they won’t be thrashed with constant change. It’s also very satisfying for an Agile software development team to deliver functionality on time, demonstrate it, and have the product owner validate that the developed user stories are what was expected.