Why Is Scrum So Hard?
Jens Østergaard gives an introduction to Scrum and talks about why is Scrum so hard. [youtube q3t8twm3aUk] Video producer: San Francisco Agile User Group
Articles by scrumexpert
The Core Protocols, an Experience Report – Part 1
The Core Protocols are our ‘best practices’ for people, teams of people and organizations that want to get great results – all the time. They are ‘Core’ because they are foundational – they can be used by all teams, anywhere, even if you already have organizational patterns and best practices of your own. They are ‘Protocols’ because they name and prescribe ways that people can interact (behavior), predictably, like the ‘protocols’ followed in diplomacy.
Coaching Scrum Teams
One of the cornerstones of Scrum is the self-organizing team: one able to make decisions in relation to the target to which it has committed. “Coaching Scrum Teams” addresses how to form groups of individualists into cohesive teams, where the members support each other and make use of each other’s strengths.
Leadership is a State of Mind
So much of what is written about leadership is hogwash. There’s no recipe to follow. It starts with you and a belief in yourself. A belief in new possibilities. A belief in your abilities to make changes in the world, and an appreciation that you can’t do it all on your own: Leadership is a State of Mind
Effective Retrospectives and Reviews
In his article “Effective Retrospectives & Reviews” Marco Mulder illustrates how Scrum teams can continuously improve by using a combination of their definition of done, working agreements and the product backlog.
Agile Project Leadership Network
The Agile Project Leadership Network (APLN) is a 501(c)6 non profit organization that is focused on making people great project leaders by focusing on the following:
Writing the Product Backlog Just in Time and Just Enough
Some people want to take the stance that no work should be done in advance of the sprint. That is clearly untenable. To see why, let’s take that view to its extreme: If we did nothing in advance to understand what we’re building, we’d show up at the planning meeting and say, “Hey, what should we build this sprint? We were working on an eCommerce site yesterday, but I think maybe we should switch to writing a word processor…” The team would literally have nothing written down—no product backlog / user stories / prioritized feature list at all.