Forming a cross functional team - moving from "Developers" & "Testers" to "Engineers"
Good morning all!
I have a case study I'd love to share and get feedback on. I've also got a very specific question: how best to go about building a cross functional team in terms of blending the traditional roles of "Developer" & "Tester" into "Engineers" to facilitate "agile" delivery?
My example is likely a familiar one that many of us will have faced in many of the organisations we've either worked with, or in:
The organsiation I work with is trying to transition to agile delivery; i.e. using scrum as a framework for delivery; defining MVPs for the products they build and ring-fencing people to product teams aligned to a product roadmap (i.e. some of the basics in place).
One problem area the organisation face is understanding how to move beyond the traditional roles of "developer" & "tester" and towards "engineer"; thereby removing the constraints of the traditional waterfall delivery method: where a developer codes and then throws over their work to a tester to test. The problem is moving away from testing being left until the end of the sprint hindering product meeting our internal definition of "done" which, in this case, means "potentially releasable".
In my experience "Developer" & "Tester" are 2 distinct roles, albeit with some overlap. Using automation to reduce manual testing can help bridge this gap but getting developers to do "more testing" is a paradigm cultural shift.
Can anyone provide any pearls of wisdom or sources/content that I could use to tackle the above?
Thanks in advance -
Conor
I've also got a very specific question: how best to go about building a cross functional team in terms of blending the traditional roles of "Developer" & "Tester" into "Engineers" to facilitate "agile" delivery?
Doing so would help to develop cross-skilled people, which might be advantageous. Why though would you need to blend developers and testers into "engineers" just to have a cross-functional team? Why can't developers and testers collaborate with each other, during each Sprint, to create increments of "Done" and release-quality work?
Ian - good question & thanks for your feedback.
At this point the team composition & some background context should help make the picture clearer: :
- the team is comprised of 3 developers, 1 automation tester (working solely on refactoring existing out-of-date automation tests) & another tester who's capacity in the product team is 25%.
In answer to your question:
"Why can't developers and testers collaborate with each other, during each Sprint, to create increments of "Done" and release-quality work?"
- they should but currently there's insufficent test capacity in order to support this; the expectation is therefore that the developers pick up more of the testing responsibility - i.e. going beyond writing unit tests but also producing automation, integration & code-based tests.
In my experience "Developer" & "Tester" are 2 distinct roles, albeit with some overlap. Using automation to reduce manual testing can help bridge this gap but getting developers to do "more testing" is a paradigm cultural shift.
So development team (developers+testers) is responsible for producing the Done increments at the end of the Sprint. What do you think the result might be if they don't share responsibilities or collaborate on testing when needed? Are they aware about the results ?
Consider how you might define cross functional as well. The team should have all the skills among them to produce a Done increment but they don't all necessarily need to have the same depth of each skill.
Your testing specialists may not necessarily become adept software developers, however, while collaborating closely they may take on additional responsibilities that would normally fall into the developer domain in order to help the team. Same goes with developers picking up some testing if needed - it doesn't mean it would be their primary role within the team but they can step in where needed.
This can be somewhat of a paradigm shift for these teams but I believe the first step is asking the question 'how can I help?'.
the expectation is therefore that the developers pick up more of the testing responsibility - i.e. going beyond writing unit tests but also producing automation, integration & code-based tests.
How are acceptance criteria elicited by the team during Product Backlog refinement? Has any thought been given to scripting BDD scenarios?