Tag Archives: QA

All Team Quality Standards Should Be Part of the Definition of “Done”

The other day a technology leader was asking questions as if he didn’t agree that things like pair programming and code review should be part of the Definition of “Done” because they are activities that don’t show up in a tangible way in the end product. But if these things are part of your quality standards, they should be included in the definition of “Done” because they inform the “right way” of getting things done. In other words, the Definition of “Done” is not merely a description of the “Done” state but also the way(s) of getting to “Done” – the “how” in terms of quality standards. In fact, if you look at most of any team’s definition of “Done”, a lot of it is QA activity, carried out either as a practice or as an operation that is automated. Every agile engineering practice is essentially a quality standard and as they become part of a team’s practice, should be included as part of the definition of “Done”. The leader’s question was “if we’re done and we didn’t do pair programming and pair programming is part of our definition of “Done”, then does that mean we’re not done?” Which is sort of a backwards question because if you are saying you’re done and you haven’t done pair programming, then by definition pair programming isn’t part of your definition of done. But there are teams out there who would never imagine themselves to be done without pair programming because pair programming is a standard that they see as being essential to delivering quality product.

Everything that a Scrum Development Team does to ensure quality should be part of their definition of “Done”. The definition of “Done” isn’t just a description of the final “Done” state of an increment of product. In fact, If that were true, then we should be asking why anything is part of the definition of “Done”. This is the whole problem that this artifact solves. If this were the case, the team could just say that they are done whenever they say they are done and never actually identify better ways of getting to done and establishing better standards. We could just say (and we did and still do), “there’s the software, it’s done,” the software itself being its own definition of “Done”.

On the contrary the definition of “Done” is what it means for something to be done properly. In other words, it is the artifact that captures the “better ways of developing software” that the team has uncovered and established as practice because their practices reflect their belief that “Continuous attention to technical excellence and good design enhances agility” (Manifesto for Agile Software Development). The definition of “Done” is essentially about integrity—what is done every Sprint in order to be Agile and get things done better. When we say that testing is part of our definition of “Done”, that is our way of saying that as a team we have a shared understanding that it is better to test something before we say that it is done than to say that it’s done without testing it because without testing it we are not confident that it is done to our standards of quality. Otherwise, we would be content in just writing a bunch of code, seeing that it “works” on a workstation or in the development environment and pushing it into production as a “Done” feature with a high chance that there are a bunch of bugs or that it may even break the build.

This is similar to saying a building is “Done” without an inspection (activity/practice) that it meets certain safety standards or for a surgeon to say that he or she has done a good enough job of performing a surgical operation without monitoring the vital signs of the patient (partly automated, partly a human activity). Of course, this is false. The same logic holds true when we add other activities (automated or otherwise) that reflect more stringent quality standards around our products. The definition of “Done”,therefore, is partly made up of a set of activities that make up the standard quality practices of a team.

Professions have standards. For example, it is a standard practice for a surgeon to wash his or her hands between performing surgical operations. At one time it wasn’t. Much like TDD or pair programming, it was discovered as a better way to get a job done. In this day and age, we would not say that a surgeon had done a good job if he or she failed to carry out this standard practice. It would be considered preposterous for someone to say that they don’t care whether or not surgeons wash their hands between operations as long as the results are good. If a dying patient said to a surgeon, “don’t waste time washing your hands just cut me open and get right to it,” of course this would be dismissed as an untenable request. Regardless of whether or not the results of the surgery were satisfactory to the patient, we would consider it preposterous that a surgeon would not wash his or her hands because we know that this is statistically extremely risky, even criminal behaviour. We just know better. Hand washing was discovered, recognized as a better way of working, formalized as a standard and is now understood by even the least knowledgable members of society as an obvious part of the definition of “Done” of surgery. Similarly, there are some teams that would not push anything to production without TDD and automated tests. This is a quality standard and is therefore part of their definition of “Done”, because they understand that manual testing alone is extremely risky. And then there are some teams with standards that would make it unthinkable for them to push a feature that has not been developed with pair programming. For these teams, pair programming is a quality standard practice and therefore part of their definition of “Done”.

“As Scrum Teams mature,” reads the Scrum Guide, “it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.” What else is pair programming, or any other agile engineering practice, if it is not a part of a team’s criteria for higher quality? Is pair programming not a more stringent criteria than, say, traditional code review? Therefore, any standard, be it a practice or an automated operation, that exists as part of the criteria for higher quality should be included as part of the definition of “Done”. If it’s not part of what it means for an increment of product to be “Done”—that is “done right”—then why are you doing it?


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Ranking: the Best and Worst Roles to Transition to ScrumMasters

So you’re trying to do Scrum well because you heard it gave you great results.  You know that the ScrumMaster role is critical.  How do you find the right people to fill that role?  Here is a list of several roles that people commonly leave to become ScrumMasters, and a few not-so-common roles as well, all ranked by how well those people typically do once they become ScrumMasters.  From Worst to Best:

  • Worst: PMI-trained Project Managers (PMPs).  Too focused on control and cost and schedule.  Not easily able to give teams the space to self-organize.  Not able to detach themselves from results and focus on the process, values and teamwork needed to make Scrum successful.
  • Bad, but not awful: Functional Managers.  The power dynamic can be a serious hindrance to allowing teams to self-organize.  But, good functional managers already are good at building teams, and empowering individuals to solve problems.
  • Bad, but not awful: Technical Leads.  Here, the biggest problem is the desire to solve all the team’s technical problems instead of letting them do it.  Now, instead of detachment from results (project managers), it’s detachment from solutions.
  • So-so: Quality Assurance people.  Good at rooting out root-cause for problems… just need to shift from technical mindset or business mindset to cultural and process mindset.  Another problem is that QA is not nearly as respected as it should be and QA people typically don’t have a lot of organizational influence.
  • So-so: Junior techies: Enthusiasm can make up for a lot of gaps and naiveté can help solve problems in creative ways, but there will be a huge uphill battle in terms of respect and influence in an organization.
  • Good: non-PMI-trained Project Managers: rely on teamwork and influence rather than tools, processes and control (of course there are exceptions).
  • Awesome: Executive Assistants.  Respected and respectful, use influence for everything, know everyone, know all the processes, know all the ways to “just get it done”. Of course, they don’t usually know much about technology, but that often turns out to be good: they don’t make assumptions, and are humble about helping the technical team!

The ScrumMaster creates high performance teams using the Scrum process and values.  The ScrumMaster is not accountable for business results, nor project success, nor technical solutions, nor even audit process compliance.  The ScrumMaster is responsible for removing obstacles to a team’s performance of their work.  The ScrumMaster is an organizational change agent.

Other things you might want to consider when looking for a ScrumMaster:

  • Does the person have experience managing volunteer groups?
  • Does the person have good people skills in general?
  • Does the person want to create high-performance teams?
  • Can the person learn anything – business, process, technical, people, etc.?

Bottom line: try and avoid having PMI-trained project managers become ScrumMasters.  Even with good training, even with time to adjust, I often find that Scrum teams with PMI-trained project managers are always struggling and almost never become true teams.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Advanced Certified ScrumMaster® (A-CSM)
Online
C$1599.00
Dec 6
2019
Details
Certified Scrum Professional - ScrumMaster® (CSP-SM)
Online
C$2199.00
Dec 7
2019
Details
BERTEIG Real Agility Series: How to Be Agile Without Scrum
Online
C$0.00
Dec 9
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1595.00
Dec 9
2019
Details
Professional Scrum Master® (PSM I)
Toronto
C$1525.00
Dec 10
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1795.00
Dec 11
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1795.00
Dec 12
2019
Details
Certified Scrum Professional - ScrumMaster® (CSP-SM)
Online
C$1869.15
Jan 10
2020
Details
Team Kanban Practitioner® (TKP)
Toronto
C$1015.75
Jan 16
2020
Details
Advanced Certified ScrumMaster® (A-CSM)
Online
C$1359.15
Jan 17
2020
Details
Certified Scrum Professional - ScrumMaster® (CSP-SM)
Online
C$1869.15
Jan 18
2020
Details
Advanced Certified ScrumMaster® (A-CSM)
Online
C$1359.15
Jan 18
2020
Details
BERTEIG Real Agility Series: Five Essential Agile Tools for Project Managers
Online
C$0.00
Jan 20
2020
Details
Professional Scrum Master® (PSM I) [PSF Courseware]
London
C$1296.25
Jan 21
2020
Details
Certified ScrumMaster® (CSM)
Toronto
C$1355.75
Jan 21
2020
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1525.75
Jan 23
2020
Details
Licensed Scrum Master Product Owner® (LSMPO)
Toronto
C$1995.00
Jan 29
2020
Details
Advanced Certified ScrumMaster® (A-CSM)
Online
C$1359.15
Feb 1
2020
Details
Certified ScrumMaster® (CSM)
Toronto
C$1355.75
Feb 4
2020
Details
Kanban System Design® (KMPI)
Toronto
C$1525.75
Feb 6
2020
Details
Professional Scrum Master® (PSM I)
Toronto
C$1270.75
Feb 11
2020
Details
Leading SAFe® with SA Certification (+FREE Scaling Workshop)
Toronto
C$1185.75
Feb 11
2020
Details
Certified ScrumMaster® (CSM)
Toronto
C$1355.75
Feb 25
2020
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1525.75
Feb 27
2020
Details
Team Kanban Practitioner® (TKP)
Toronto
C$1015.75
Mar 4
2020
Details
Advanced Certified ScrumMaster® (A-CSM)
Online
C$1359.15
Mar 7
2020
Details
Advanced Certified ScrumMaster® (A-CSM)
Online
C$1359.15
Mar 8
2020
Details
Professional Scrum Master® (PSM I)
Toronto
C$1270.75
Mar 9
2020
Details
Licensed Scrum Master® (LSM)
Toronto
C$1355.75
Mar 10
2020
Details
Advanced Certified ScrumMaster® (A-CSM)
Online
C$1359.15
Mar 21
2020
Details
Advanced Certified ScrumMaster® (A-CSM)
Online
C$1359.15
Mar 22
2020
Details
Certified ScrumMaster® (CSM)
Toronto
C$1355.75
Mar 24
2020
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1525.75
Mar 26
2020
Details
Kanban System Design® (KMPI)
Toronto
C$1525.75
Mar 31
2020
Details
Certified ScrumMaster® (CSM)
London
C$1525.75
Apr 1
2020
Details
Kanban Management Professional® (KMPII)
Toronto
C$1525.75
Apr 2
2020
Details
Professional Scrum Master® (PSM I)
Toronto
C$1270.75
Apr 20
2020
Details
Professional Scrum Master® (PSM I) [PSF Courseware]
Toronto
C$1270.75
Apr 27
2020
Details
Coach Skills for the Agile Workplace® (IPC-ACC)
Toronto
C$2020.00
Apr 27
2020
Details
Professional Scrum Master® (PSM I)
Toronto
C$1270.75
May 26
2020
Details