Make Sure Developers Follow Requirements & Test Their Code

Question

We are a team of 3 developers, 2 QA, a project manager, and me as stake holder (acting Chief Technical Officer in our small company). We have been working on developing a medium software product for a while, following Scrum process.

We do 2 weeks sprints.

The PM is dividing User Interface (UI) tasks into user stories and each user story has a backend and a front end task. We use JIRA for assigning tasks, writing requirements, preparing scenarios and logging work.

We use Gherkin to write requirements/user stories to make them clear. Each user story is an epic which contains subtasks of function.

We are facing a few problems:

• The developers do NOT follow the requirements of the subtasks; they just depend on sprint planning memories and the UI ( add, edit, delete etc. )
• The devs depend on QA to actually test their code and do not do that themselves

This lead to having buggy/missing functionality software delivered to the QA. Thus missing deadlines and affecting the overall quality, and the morale of the team.

What are some suggestions to handle such issues? I do not like to threaten or use warnings. I tend to keep things positive.

Answer 1

This sounds like a team maturity issue regarding software development in general and Agile Software Development specifically; yourself included. I’m not saying this as a harsh criticism, just an observation based on the following evidence.

1. The description of the problem is very tool- and process-centric (JIRA, Gherkin, etc.); whereas the Agile Software Development mindset tends to favor talking humans. (First Agile value.)
2. It sounds like there is no Scrum Master or Coach (someone like me to help guide and condition the team), just a PM (and yourself...maybe you’re the coach??); and PMs don’t actually exist in Scrum (or any Agile framework I’m aware of; the responsibilities typically performed by a PM are divided across the team as a whole).
3. There seems to be a desire to avoid conflict on your part, which is pretty normal for technology people. Having said that...
4. At the end of the day, we create potentially shippable increments every Sprint, if we (the team as a whole, you, the PM, QA, the developers) didn’t manage to put together a potentially shippable increment, then we failed. It’s not dev, or QA, or the PM, or whoever who are to blame. We, as a team, failed. Why didn’t the team follow the requirements? Why didn’t the team write better requirements? Why is QA a separate team and viewed as a step in a process (Scrum is not a process)?
5. It seems like your team is most likely in the “shu” phase, so to speak. There’s nothing wrong with that, we all fluctuate; the hard part is realizing it. The problem/question uses “Agile” terms, but seems to involve blending different understandings of those terms...not everyone uses the term “epic” in the same way, for example. So, saying each user story is an epic, doesn’t really say anything.

To the question:

1. Get a coach; either for yourself or on your crew. Preferably not someone new to coaching. (I tend to think pairing newer coaches with seasoned teams, and vice versa can work out better...but I could be wrong, there’s always exceptions.)
2. Simplify your terminology within your team, and understand that people outside of your team may not have the same understanding. For example, I recommend using the term feature, and only feature, to describe the thing that describes something a user can do with the product (no epic, no user story, forget bananas)...everything else is just a layer of complexity and abstraction that annoys my fragile mind. “I don’t have to think, oh we’re talking about an epic, that means a feature that has these qualities”; instead, it’s “we’re talking about a feature...something a user wants to do” (how long it takes, level of effort, doesn’t matter). But that’s me. That may not work for other people. Which brings us to...
3. Did we create a potentially shippable increment? If not, why not? And how’s the team responding? These questions are my mantra going into the Sprint Retrospective. No, we did not; the developers say it’s QA’s fault for not being fast enough; QA says it’s the developer’s fault for not following the requirements; the developers say that specific complaint is because the PO didn’t write good requirements in the first place; the PO says the developers never asked any questions about the requirements so I thought they understood; and, someone who’s in the position your in is stuck asking, “Who do I believe?” (But it sounds like from the problem description your siding more with QA and the PO than the developers, why is that? Or, you could be totally on point regarding why the developers can’t deliver, at which point, run an experiment to see if that’s really the case, could be an expensive experiment though.) And, this type of interaction demonstrates a lack of trust and presence of defensiveness, fear, and so on within the team. The extreme alternative being the developers asking QA, “How can we make your job easier?” (More of a Lean mindset.) And QA asking the same things of the developers. (Less who’s to blame and more how can I help). Again, question of team maturity.
4. Get a coach. Just to repeat. Someone trained and skilled in observing humans, game theory, and business (it seems like technology isn’t really a concern for you, so having someone like me - developer with a UX background- would reenforce the gap...but you might be running low on business perspective and pressure). Again, could just be a coach for yourself to help with your continuous improvement journey...preferably the team though.

Hope that helps.

https://en.m.wikipedia.org/wiki/Shuhari

Answer 2

I see the following potential problems:

• Overcommitting. If your quality is still lacking after testing and fixing then you've obviously taken on more than your team can handle.

• Definition of Done. You seem to either not have a sufficiently strong definition of done or you seem to be ignoring it and moving on to new tasks without actually completing the current ones.

• Lacking testing. Some quick research indicates that your 3:2 ratio is already pretty generous on the testing side. Is your QA using mostly manual tests? Are you using Gherkin just for specification or are you running tests with it as well? What's the division of responsibilities regarding testing between your QA and your devs? Or to ask in a different way: If your devs were to deliver software to QA in the quality you expect them to. What would QA still have to do? And what are they doing now in addition to that?

Without knowing more details it's pretty hard to suggest concrete steps. The best you can do is talk with your team and find out why things are running the way they are. What does the scrum master have to say? What does the team say in the retrospectives? There are most likely sociological problems going in your team / department.