Where Scrum and Craftsmanship Converge

"Your team may be dysfunctional … but at least you can see the impediments. Now you have the ability to do something about it!"
- Kane MarScrumology, Scrum Coach

This fantastic statement about Scrum highlights the most important aspect of Scrum that is invariably lost in most Scrum implementations in which an experienced member or coach is not present.  In the context of your Team’s skills and the quality of your product this is an incredibly powerful statement.  One which enables developers to produce high quality software they can be proud of at a sustainable pace.

What is often perceived as a failed transition to Scrum is, in actuality, an organizations first, all be it scary, encounter with the power of the Scrum framework.  By committing to a minimal portion of the Product Backlog to be delivered in a relatively short timebox and, finally, asking the Team to demonstrate this potentially shippable product we ask the Team to expose their weaknesses early and often to a large audience.

Some of the most common weaknesses include misunderstanding customer needs, poor estimation or over commitment, and skill gaps.  These issues existed all along, but Scrum makes them more apparent.  All are essential to the successful delivery of a product where success means a satisfied customer, but some are more recognizable than others.

Misunderstanding customer needs is immediately evident during the sprint review in which Working Software is demonstrated.  An effective Team will increase Customer Collaboration to avoid a future embarrassing sprint reviewThis is also where an effective Scrum Coach makes their mark in guiding the Team into effective practices.

Poor Estimation is also one of those obvious problems, but it takes time for a team to become effective in estimating.  The more critical problem is habitual under estimation or over commitment.  By making available the Team’s actual velocity in the sprint review it becomes difficult for the team to continue over committing time and again, but an effective coach can highlight the importance of velocity when planning a sprint and projecting a Product Backlog.  Transparency has a wonderful way of solving many problems naturally.

Skill gaps, not surprisingly, are the most likely to be overlooked (and often ignored).  A Team which neglects its craft will eventually see decreased velocity as a result of rising bug rates and complexity.  The Team alone is responsible for the quality of the software delivered to clients and it is here that we see the convergence with Software Craftsmanship.

“Scrum’s purpose is not to be sufficient: it is to set the team into an improvement loop whereby they try to build software, observe what is wrong, and fix it.”

- Ron Jeffries – XProgramming, Co-founder Extreme Programming

Software Craftsmanship is an extension to the Principals behind the Agile Manifesto which compels developers to challenge their skills in the craft of software development.  Scrum provides two important tools which integrate this notion of Craftsmanship: the Definition of Done and the Sprint Retrospective.

Definition of Done is whatever the Team means when it commits to a Sprint.  It should be influenced by the environment in which a team operates and be made apparent to the Product Owner and other teams, though the Team is ultimately responsible.  The Definition of Done acts as a valuable tool to enable evolution of a Team’s skills and a product’s quality through expansion and refinement. 

An example of the evolution of “Done” might be seen as initially stating that all new features must include at minimum one automated test.  While rather abstract and vague, this allows the team to experiment and learn the techniques for testing while building an inventory of tests which can validate the existing functionality.  During a Sprint Retrospective a team may come to the conclusion that it has sufficiently exercised its skills and resolve to expand the Definition of Done to state Code Coverage will not decrease from Sprint to Sprint.  This improvement loop continues with each Sprint.

Software Craftsmanship relies on the initiative, abilities, and imagination of the Team.  Scrum provides the framework for a self-organized team of Craftsman to enact their skills.  The result? An engaged team producing ever higher quality software at a sustainable pace.

  • Rob

    I like the way you highlight the misunderstanding customer needs as a weakness in teams. Many people simply call the misunderstood implementation a “bug” and never address the underlying issue as a lack of collaboration.

    Also, many people don’t know what they want when it comes time to specify a requirement. They really only know what they don’t want. So, the Sprint Review can get features that the Stakeholder’s don’t want in front of them sooner and with higher frequency, hopefully leading to a product that they do want.

  • http://blog.cromwellhaus.com ryan

    Collaboration mid sprint with a PO is definitely a learned trait. The “I bet they want…” and “I think what that means is…” can so easily be replaced with lets ask what this means.