Obsessed with Quality (…w/ a special bonus: On User Stories)
Guest contributor: Scrum Master Dan-o
I’m working with a team now where code commits literally take years to get to production. Why such a long delay? Months and months of repetitive testing and security checks by numerous teams, departments, outside organizations, ad nauseam - essentially years’ worth of bureaucratic red tape.
I’m not of the opinion that bureaucracy is inherently evil but I do think it is a misguided attempt to solve a legitimate problem. In actuality, I think it winds up being a self-fulfilling prophecy guaranteed to justify its own existence.
Typically, what I’ve seen happen is you have a team deploy say, 100 features to production and one of them has a defect. Rather than do a root cause analysis, management wants assurance that no defect ever makes it to production again so they force EVERY feature to go through an intense series of gates. Developers then, knowing that the robust system of checks will catch any defect (and often getting pressured by management to “code faster”) tend to get more careless.
Now, 100 features get pushed toward production, 75 of them have defects, and our intense checks catch them all and send them back to the programmers to do re-work. Hey - look how well our guardrails are working! But what about the customer? Previously, we deployed 99 working features and now only 25 in the same amount of time. People often talk about speed, quality, and cost - you get to pick two out of three, right?
Well, not necessarily. Re-work costs money and time. Guardrails lead to carelessness, aka a decreased focus on quality. This is why you also hear an alternative take - focus on quality and you get the other two for free.
I recently had a developer tell me he is obsessed with quality. I love that. When I used to code, I took it personally when a feature I built had a bug and I took my time to ensure this rarely happened. In short, I cared. Remember, continuous attention to technical excellence and good design enhances agility.
BONUS addendum - “On User Stories”
Sometimes, I hear people ask “should we write a user story for _________”? In my opinion, the answer is simple. The best definition I’ve ever heard for a user story is that it is a placeholder for a conversation. So, just ask yourself - do we need to have a conversation about this? If so, write a user story, read it to the team ideally in the next grooming or sprint planning session, and have the conversation. Do I need to write a user story to power on my laptop? Probably not. Should I write one for rewriting the build script in our team’s CI/CD pipeline? I would say so because the whole team should want to talk about a big change like that.
Three Anti-patterns:
- We need to write a user story to “track” this
- Can you go write a user story for what you did so the team gets credit?
- I won’t do any work without a user story to tell me what to do
I’m working with a team now where code commits literally take years to get to production. Why such a long delay? Months and months of repetitive testing and security checks by numerous teams, departments, outside organizations, ad nauseam - essentially years’ worth of bureaucratic red tape.
I’m not of the opinion that bureaucracy is inherently evil but I do think it is a misguided attempt to solve a legitimate problem. In actuality, I think it winds up being a self-fulfilling prophecy guaranteed to justify its own existence.
Typically, what I’ve seen happen is you have a team deploy say, 100 features to production and one of them has a defect. Rather than do a root cause analysis, management wants assurance that no defect ever makes it to production again so they force EVERY feature to go through an intense series of gates. Developers then, knowing that the robust system of checks will catch any defect (and often getting pressured by management to “code faster”) tend to get more careless.
Now, 100 features get pushed toward production, 75 of them have defects, and our intense checks catch them all and send them back to the programmers to do re-work. Hey - look how well our guardrails are working! But what about the customer? Previously, we deployed 99 working features and now only 25 in the same amount of time. People often talk about speed, quality, and cost - you get to pick two out of three, right?
Well, not necessarily. Re-work costs money and time. Guardrails lead to carelessness, aka a decreased focus on quality. This is why you also hear an alternative take - focus on quality and you get the other two for free.
I recently had a developer tell me he is obsessed with quality. I love that. When I used to code, I took it personally when a feature I built had a bug and I took my time to ensure this rarely happened. In short, I cared. Remember, continuous attention to technical excellence and good design enhances agility.
BONUS addendum - “On User Stories”
Sometimes, I hear people ask “should we write a user story for _________”? In my opinion, the answer is simple. The best definition I’ve ever heard for a user story is that it is a placeholder for a conversation. So, just ask yourself - do we need to have a conversation about this? If so, write a user story, read it to the team ideally in the next grooming or sprint planning session, and have the conversation. Do I need to write a user story to power on my laptop? Probably not. Should I write one for rewriting the build script in our team’s CI/CD pipeline? I would say so because the whole team should want to talk about a big change like that.
Three Anti-patterns:
- We need to write a user story to “track” this
- Can you go write a user story for what you did so the team gets credit?
- I won’t do any work without a user story to tell me what to do
Comments
Post a Comment
Thank you for your feedback!