Is technical training for agile Development Team the solution?
Hi all.
I've been working for a team for about 6 months, the organization was trying to implement some kind of scrum that makes me very nervous and the development team was new to scrum (I'm not the S.M), they see it's benefits but sometimes they feel they can not apply this framework in real life.
eg. during refinements we play scrum poker online to estimate and the guys in the development team that code the new functionalities do not get to understand why the tester is also estimating some PBI (I know there are no titles in scrum but this is to explain the context as they see it).
I've approached it from this perspective:
1.Ask them what would be their approach --> One answered that splitting the coding and testing estimations and summing them.
Of course I do not like this approach so I tried to redirect the situation by
2.opening the DoD in which testing is needed and telling them that if testing is needed for a PBI to be Done, the tester is part of the Development Team and asked them to forget about the titles, that scrum was about generating productive discussions to learn from them and that getting the opinion from somebody with another perspective could add tons of value.
While going home I felt like I had been to directive telling them to do it because it was written in a guide but not giving them the chance to think what not letting the tester estimate could cause so the following day I asked them.
3. In which cases have the tester's estimations has caused damage? and added value?
They were able to identify the added value of the estimations from the tester but they also found the "damage": the tester is hired by the organization and also de S.M and the P.O and they were seeing the tester as a mechanism of control to lower the estimations.
4. After some talk we saw that the tester was not lowering the estimations it was just their feeling.
So here the question:
Could it be that a lack of knowledge in agile development is being a problem to the Development Team?
I have the feeling that if they had knowledge on how to work with Continuous Integration, Test Driven Development... their work with the tester could be smoother and they could see Scrum as a framework for the real life.
Any advice on this situation?
Putting estimation to one side, how well do team members collaborate when implementing work during the Sprint? Are team members sufficiently cross skilled to do whatever work (programming, testing etc) needs doing, when it needs doing?
Or do they stick to their skill silos and job titles, and effectively wait for the work to come to them? If so is there evidence of waste such as bottlenecks, and do the team recognize skill-silos to be a problem?
First of all thanks for the quick answer and for making me think a little bit further.
I'll ask the Team tomorrow.
From what I've seen:
The team collaborates quite well during the sprint, there is good communication even though it's located in different countries.
Programers are sufficiently cross skilled but tester does not, and from a realistic point of view I can not ask a tester to code or am I wrong?
The programers are really proactive, they don't wait for work to come and they have offered themselves to test but they prefer coding.
I think there has to be a way to merge those "two world" that should be one. Training the programers and the tester in a way that they can work more effectively seemed a good way to generate empathy and respect for each others background and work.
Is this a usual situation?
Can programmers help the tester to execute the test cases he or she writes? Can they collaborate on test-first development and test automation?
That can be one way to gradually break down skill silos, even if it is just to the point of being able to appreciate each other’s work so joint estimation is facilitated.
Programers are sufficiently cross skilled but tester does not, and from a realistic point of view I can not ask a tester to code or am I wrong?
What background does the tester have? Do they have skills in test automation for example?
Programers can help on executing the test cases, but certainly there are skill silos, like the ones your both are mentioning. The team has to be accountable as a whole and not by specialty but also as you are saying Ian, to appreciate each other's work.
Thanks for your help.
Training the programers and the tester in a way that they can work more effectively seemed a good way to generate empathy and respect for each others background and work.
Has the team thought about pair programming? I think of it not in a profound level, but simply sharing their plans on how the tester is going to test a PBI and how a programmer is going to program the PBI:
a) creates collaboration
b) saves time and avoid surprises.
c) both skills meet each other at the same level sharing needs and understanding, which usually leads to appreciation and respect.
d) more is learnt while (possibly) their skills become extended.