Scrum is a straightforward framework for developing complex software products in a complex environment, but it can be challenging to implement. But why? I am not going into detail about why, but I wanted to highlight one problem with the development team, as per my understanding.
The development team means a cross-functional and self-organizing team of developers. But who is the developer? Isn't it everyone who contributes to developing software? A coder, tester, DBA, UI designer, content writer, and business analyst? Now, look at your team. Is it cross-functional? Yes, you have, because you have technicians for all skills, but are those technicians are developers? Maybe not. They are just coders, a tester, a DBA, and UI designers, and are waiting for their skill-related tasks. They are not working as developers intending to develop software, but they are doing their tasks based on their skills.
Key things that will help you to understand the characteristics of the development team.
Assume the Learning and Development Department (L&D) is about to organize a few training sessions and will announce them as follows.
1st announcement: "We are planning to have a workshop for Scrum Developers, so send your nomination." You will find that only coders have subscribed to this workshop.
Another announcement, "We are organizing an Agile Testing workshop, so send your nomination." This time, only the tester will subscribe. The same happens with Agile Business Analysis and UI/UX training.
What does the above reflect? The team is still divided based on skills: coding, analysis, UI/UX, and testing. Tester feels everything related to testing is their domain, and similarly, coders think all coding work is part of their work.
In reality, testers write code to test production codes, and coders write tests to perform unit and integration tests of code.
Let's look at it differently.
During sprint planning, the team has prepared the following sprint backlog.
What does it reflect? There are tasks, but those tasks are skills-based and not component-based. Isn't this the wrong way to create sub-tasks? If not? Then read the situation below.
Assume Alex (coder) and Martha (tester) are working on these three stories.
Alex completed the coding part of story one in 2 days, and Martha has started testing, so what will Alex do next?
Most likely, Alex will start working on the coding part of story 2. But is it useful? Why can't Alex pick up other work from the same story? Or why was Martha waiting for Alex to complete coding to start testing? Why can't she pair with Alex to test in parallel or at least started testing APIs?
Many people asked me what's wrong if Alex starts working on the coding part of story 2. Let's see the situation below.
Alex completed coding the first story and started coding the second story. Martha found a bug in story 1, so what does she have to do? She reached out to Alex to discuss it, but Alex was busy and asked her to come later.
What will Martha do next? Most likely, she will open a bug tracking tool and log a newly found bug over there. Is it good? No, but why Not? I will write about bug logging challenges separately, but for now, I will focus on other aspects of it.
Alex has completed coding Story 2 and is now investigating bugs logged by Martha. He identified the root cause of a bug and framework-level code changes needed to fix it. But that will also impact the code that he has just completed for story 2.
What will Alex do? If he changes whatever is needed to fix at the root, it will generate rework and delay delivery. Another option is to use a shortcut to fix the bug (patchwork), which should not impact the 2nd story code.
The majority of time coders choose 2nd option because coders are very emotional about their code (just kidding). There are multiple reasons for selecting the 2nd option, but the result will be "Technical Debt."
What else?
It seems you missed another significant issue highlighted in this video, so take a moment to consider why itis crucial to avoid skill-based task creation.
What can we do to avoid such a scenario?
First, avoid creating sub-tasks like above; instead, try to divide into components. The best approach is to avoid creating sub-tasks and keep stories small. Work in the pairing as a unit instead of passing a story from one to another. The team should focus on finishing one that already in progress rather than starting a new.
Thanks for reading! If you have any queries, then reach out to me. I teach and coach the same in my Professional Scrum Developer training.