Popular Post
-
![Agilemania Blog]()
Continuous Delivery Pipeline – Sca...
Sep 22nd 2022 - BY Agilemania
-
![Agilemania Blog]()
Sep 29th 2019 - BY
-
![Agilemania Blog]()
What is a Continuous Delivery Pipeline an...
Nov 17th 2022 - BY Agilemania
- Agilemania
- Jun 20th 2016
Everyone is developer in development team and not just a coder, a tester etc.
Scrum is a very simple framework to develop complex software products in a complex environment but hard to practice. But why? I am not going into detail about why but wanted to highlight one problem about the development team as per my understanding.
A development team means a cross-functional and self-organizing team of developers. But who is a developer? Isn’t it everyone who contributes to developing software? A coder, tester, dba, UI designer, content writer, or 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. There are just a coder, a tester, a dba, an ui designer, and waiting for their skill related task.
They are not working as developers with the goal to develop software but they are just doing their tasks as per their skills. Some of the key things that will help you to understand the characteristics of a development team. Assume L&D (Learning and Development Dept) is about to organize training and announcing like below. 1st announcement “we are planning to have workshop for Scrum Developer so send your nomination”.
You will find that only the coder has subscribed for this workshop. Another announcement “we are organizing Agile Testing workshop so send your nomination”. This time only the tester will subscribe. What reflects the above? The team is still divided based on skills coding and testing. Tester feels everything related to testing is their domain and similarly coders feel all coding work is part of their work. But in reality testers write code in order to test production code and coders write tests to perform unit and integration tests of code.
Another way of looking at it - During sprint planning team has prepared below sprint backlog. What it reflects? There are tasks but those tasks are skills-based and not components. Isn’t it a bad way of creating tasks? If not? Then read below situation.
Assume there are 2 people Alex (coder) and Martha (tester) working on these 3 stories. Alex has done with the coding part of story 1 in 2 days and Martha has started testing so what Alex will do next? Most likely Alex will start working on the coding part of story 2.
But is it good? Why can’t Alex pick up other work from the same story? Or why Martha was waiting for Alex to complete coding in order 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 below situation.
Alex completed coding of 1st story and started coding 2nd story. Martha found a bug in story 1 so what she has to do? She reached out to Alex and wanted to discuss about it but Alex is busy and asked her to come later. What Martha will do next? Most likely she will open a bug tracking tool and log newly found bug over there.
Is it good? No, but why Not?
I will write about bug logging challenges separately but let's focus on other aspect of it for now. After a day Alex is done with coding Story 2 and started looking into bugs that were logged by Martha. He identified the route cause of a bug and framework level code changes needed in order to fix it. But that will also impact code that he has just completed for story 2. What Alex will do? Good if he changes whatever needed in order to fix the route but it will generate rework and will delay delivery. Another option is the shortcut to fix the bug (patchwork) so it should not have much impact on 2nd story code.
The majority of the time coders choose 2nd option because coders are very emotional about their code (just kidding). There are multiple reasons for choosing the 2nd option but end result will be “Technical Debt”.
What can be done in order to avoid such scenario? Yes. 1st don’t create tasks like above but try to divide in component. The best is not to create tasks but still needed then divide into the component. Work in a pairing. Team should focus on finishing one that already in progress rather than starting a new story.
Thanks for reading! If you have any query then reach out to me.
Find Our Upcoming Trainings
Agilemania
Agilemania, a small group of passionate Lean-Agile-DevOps consultants and trainers, is the most trusted brand for digital transformations in South and South-East Asia.
Sign up for Agilemania Newsletter
Stay updated with the latest Agile & Scrum trends.
Popular Post
-
![Agilemania Blog]()
Continuous Delivery Pipeline – Sca...
Sep 22nd 2022 - BY Agilemania
-
![Agilemania Blog]()
Sep 29th 2019 - BY
-
![Agilemania Blog]()
What is a Continuous Delivery Pipeline an...
Nov 17th 2022 - BY Agilemania
Agilemania is a group of passionate Lean-Agile-DevOps consultants and trainers focused on delivering measurable, sustainable results for our clients.
Connect with us on Social Media
Knowledge Area
Certified Partners
Agilemania Technologies Private Limited © 2024 All rights reserved.
