Member Articles

Enjoy our extensive collection of member-contributed articles to learn how other Scrum practitioners use Scrum in the workplace.

Read about the experiences and ideas of Agile colleagues around the world, and share your own thoughts here. You can also visit Spotlight, which features blogs by experts in the fields of Scrum, Agile, and the broader business world.

Opinions represent those of the authors and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Your project is suffering from PODS -- Product Owner Disappearance Syndrome -- when the availability and commitment of the product owner is not enough to help teams complete the planned deliverables on time.

There will always be memorable moments: post-sprint or project-wrap pizza parties, baby showers for team members (and their significant others), promotion celebrations, weddings, and going-aways. But how many truly proud moments are there?

Do we really handle retrospectives in the way we are supposed to? . . . Retrospectives run the risk of becoming repetitive and boring, especially when (in the case of weekly sprints) they are conducted week after week.

Stand-ups happen, burn-down charts are in place -- and suddenly, toward the end of the sprint, things start falling apart. No matter how many times you meet or try to resolve issues, the comeback is never 100 percent. You have failed your sprint.

In terms of the service industry, while we collaborate with multiple customers, we learn to adapt and implement processes that can bring cohesiveness to teams. In many scenarios, however, we face challenges in understanding the current processes already in place for a customer.

I am sure you all agree that rewarding an individual or a team is a great step across any platform. With my experience in Agile, I am presenting a case on how deeply we are linked to Agile in our organization and how we assess individuals and reward teams.

In the six years that I have worked as a ScrumMaster, I've often been asked if my role is truly essential, and why it should be considered an independent role within the Scrum team. "Why can't the dev manager also perform as the ScrumMaster? Or one of the developers? Or a QA tech?"