By definition, agile development is a team sport. The emphasis is on teams working and delivering together. It’s not measured by how many user stories the development team produces, but by how many completed/done stories the team can produce.
Quality is not something “owned” by the testers, but the responsibility of the entire team. In fact, you don’t try to “test in” quality, but rather “build it in”.
It places collaboration and teamwork above individuals working alone. It values pairing and swarming around work. It values limiting WIP so that team members work together.
Several years ago I went to an agile conference, actually the annual agile conference put on by the Agile Alliance. One of the sessions was a 90-minute workshop put on by an incredibly experienced agile practitioner. In fact he was one of the original 17 signatories of the Agile Manifesto.
I got to his session early and I’m glad I did. The room became packed, with every seat take about 15 minutes before the session was scheduled to start. Then the floor started to fill up. By the time he arrived, the room was over capacity and the anticipation was electric.
I saw the following question in the Agile and Lean Software Development group on LinkedIn:
As an Agilist, what kind of constraints do you use to ensure quality?
There were quite a few thoughtful comments, for example:
- Definition of and adherence to a – Definition-of-Done
- Collaboration and pairing
- Unit, integration, and regression testing
- Sustainable pace
- Measuring defect and process “escapes”
- Appropriate testing as EARLY as possible
Not that long ago, I received an email from someone in the Northwestern part of the US. They were thinking of moving to agile approaches and they wanted to pick my brain surrounding the logistics of “going Agile”. It was an introduction of sorts, but it was also an assessment.
They were assessing whether I knew what I was talking about and whether they’d allow me to help them. They were also assessing cultural fit. But I was also assessing. Were they “ready” to try agile, were they serious about it, were they self-aware, and would I like to work with them.
It was a great meeting and it led to some interesting follow-up activity. But I remember a conversation distinctly to this day that I wanted to share with you.
This update is from the STP conference I’m attending in Denver the week of November 3, 2014. Software Test Professionals is a conference mostly focused towards testing, so the slant of all of the talks is that lens or perspective. That being said, the agile topics are by definition broader and more whole-team centered.
I just attended a session by Jeff Porter where he was exploring agile practices in a talk entitled: Agile – Where the Rubber Hits the Road.
Now let me start by saying that I liked Jeff’s talk. It was very pragmatic and practical. He simply shared what they were doing at FamilySearch.org. Practitioner reports like this one truly enhance the state of practice in the agile community.
Introduction
There are several terms used for it within agile contexts. Sometimes you hear:
- Done
- Definition-of-Done or DoD
- Done-Ness Criteria
- Acceptance Criteria
- Release Criteria
Sometimes you even hear it repeated, as in: This story isn’t complete until its—“Done…Done…Done”.
Apparently the more “done’s” you have, the more emphasis there is on completeness. Although I don’t think I’ve heard more than four “done” used in a row.
We just finished the 2014 Raleigh Scrum Coaching Retreat in Chapel Hill, NC and I was lucky enough to participate. The event sold out months ago and was capped at 75 attendees so we could immerse in some intense working groups and Open Space sessions.
I suggested an Open Space session entitled as this post is. My inspiration was Adam Weisbart’s famous video by the same name, but targeted towards Scrum Masters. In that video, Adam and his band of actors demonstrated all of the things a good Scrum Master should do by demonstrating the things a bad Scrum Master did. He packs a tremendous number of anti-patterns into 3 ½ minutes.
In 2009 I wrote the first edition of Scrum Product Ownership as a way of helping Product Owners understand their roles and responsibilities better. Before that, it was mostly an exercise in guessing and survival. In 2013, I updated the book in a second edition[1]. In both books I took on the topic of Backlog Grooming.
As it turns out the term “grooming” is losing its luster in the community and terms like maintenance and refinement are replacing it. I believe the latest copy of the Scrum Guide uses the term refinement. So I will try to start using Backlog Refinement consistently throughout this article. That being said, I really, really like the implications of the term grooming.
The five Core Scrum Values have been defined as:
- Commitment
- Openness
- Focus
- Respect
- Courage
The reference I’m using for this include a blog post by Mike Vizdos here. And you can see them articulated on the Scrum Alliance site here.
Tobias Mayer wrote a counterpoint blog post on these values and suggested a different set and focus all his own. Here’s what Tobias had to say:
My friend Lee Copeland [i]asked me the following question:
Bob,
I'm putting together a keynote talk and need some examples --
projects that were successful in the sense that they implemented the requirements, within budget and time BUT didn't return any actual value to the business.
Got anything you can share?
Thanks,
Lee
