Tailoring Agile Processes to Empower Your Team

November 12, 2014 Adam D'Angelo 0 Comment

An Agile team’s Scrum process is constantly shaped and guided by the individuals and their interactions on the team. By empowering the team to change the process instead of conforming to a predefined notion of how they should be working, the team’s morale will be higher because of their involvement. The quality of work will also be better because things that do not work will be proactively identified and changed.

Copyright: idspopd / 123RF Stock Photo
Copyright: idspopd / 123RF Stock Photo

After a Sprint ends, it is common for the Sprint team and the ScrumMaster to get together for a ceremony in which the group discusses the good, the bad, and the ugly of the Sprint. In this open-forum discussion, called the Sprint Retrospective, the team volunteers and captures the thoughts on what the team did well, what could be done better, and what were the effects of changes made for this Sprint.

This tailoring of processes for your team will best set the team up for continued success, and it will keep morale high while the team pushes to deliver the best possible software. For example, if after a few Sprints, the team finds that it is working many extra hours late in the Sprint to finish user stories, it may be because the user stories are not being broken down into small enough stories, or that the team is doing a poor job of estimating the stories. It’s now up to the team to decide how to best fix this problem moving forward, and then evaluate if the solution was successful.

On a Scrum team I was a part of, we found that we kept leaving user stories incomplete because the stories required resources from another Scrum team within the organization to complete work before we could complete our stories. The team suggested to the ScrumMaster that we should go through the product backlog, identify stories that require the work of external resources, break out those components, and then reprioritize the product backlog so these components could be managed within a Sprint before actively completing the next work items. We were then able to add some of these external items to the next Sprint backlog alongside user stories that our team could complete without the external pre-requisite. Our team was better able to manage and coordinate the external work components, and complete our next Sprint with 100 percent user story completion. In the Sprint Retrospective, we identified that this change was successful, and we continued to do our best to identify external dependencies early.

It is the ScrumMaster’s responsibility to own and manage the team’s Scrum processes and to solicit feedback from the team. He or she is the champion of the processes and is accountable for implementing the changes identified by the team and for making sure the process is constantly improving. No two Scrum teams will work exactly the same way since different individuals, work environments, and projects are involved, so taking these actions to tailor processes is essential to maximizing a team’s productivity.

This is the second post in a series where Adam D’Angelo–one of Dev Technology’s Project Managers and an experienced developer–shares his experience using Agile development over the years to continue the conversation on how we can use Agile to build better software. View the full series here.