Quality, Done Increment

Every Sprint in Scaled Professional Scrum requires a completed, ready to ship increment of functionality. The ubiquitous “definition of done” spells out the characteristics of such an increment. The end result should include software that has: Presence of valuable functionality for customers to use; Absence of low value functionality that must be maintained and sustained regardless; … Continue reading

Practitioner Certification

The PSM, PSPO, and PSD I assessments have proven extremely useful. The role-based assessment helps people validate their knowledge of Scrum. A resulting certification demonstrates that knowledge to others, including potential employers. Scrum teams that bring these people on board are assured that the person knows their role. We are introducing the next level assessment. … Continue reading

Scaling, the Nexus, and Scrumbling

I will be conducting a Nexus workshop in Boston on November 17-18, with Richard Hundhausen and Rob Maher, based on the Nexus Guide. Of interest to many, SDK, API architectures, and remediation Scrumbles, and DevOps. Many Scrum teams deliver a “done”, potentially shippable increment at the end of each Sprint. As the number of teams rises, as the project scales, … Continue reading


I will be conducting a Nexus workshop in Boston on November 17-18, with Richard Hundhausen and Rob Maher, fleshing out the Nexus Guide with examples, case studies, practices and tooling –         Why Nexus? The word Nexus refers to a connected group or series that are integrated, linked together. When I use the phrase Nexus. I also … Continue reading

What is Scaling Scrum?

Scaled Professional Scrum is based on unit of development called a Nexus. The Nexus consists of up to 10 Scrum teams, the number depending on how well the code and design are structured, the domains understood, and the people organized. The Nexus consists of practices, roles, events, and artifacts that bind and weave the work … Continue reading

Scale Scrum Development, not Technical Debt

Creating software with Scrum is difficult. Creating one integrated piece of software with multiple Scrum teams is a managerial and technical drama, requiring sophisticated techniques, tools, and collaboration. In my last two blogs, I shared my opinions about the skills and knowledge to scale Scrum. I could be wrong, but in my experience many people … Continue reading