It looks like neither Scrum nor the Agile Manifesto say that the practice when developers write code and then hand it over to testers should be avoided. Or do they?
Add a comment
|
7 Answers
It depends exactly what you mean by 'hand it over'.
From the four values:
Individuals and interactions over processes and tools
... Meaning do not hand off work from devs to testers just "because that's our process." Make sure everyone involved actually understands the situation and tradeoffs, and agrees.
From the 12 principles:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
...Meaning don't just hand off the work and then walk away. There should be ongoing collaboration both before and after the hand-off.
From the Scrum Guide:
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.
... Meaning make sure the devs and the testers are on the same Team, not two separate teams.
and
Within a Scrum Team, there are no sub-teams or hierarchies
...Meaning devs and testers are not to be treated as distinctly different entities. You don't have 2 devs and 2 testers. You have 4 Development Team members, whom have different specialties.
Aside from that, do whatever makes sense for your Team. That's what agile is all about.
-
1"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." logically says nothing about how the information transfer is structured. A meeting is a face-to face conversation. This quote does not imply anything ongoing. (Yes, it is in the agile spirit to not leave open issues unanswered, but if you have phases and hand-overs that doesn't mean you cannot talk in addition when issues arise - you should easily trigger that at the daily for instance.A feature can still be in testing phase and therefore in QA responsibility) Commented Aug 7, 2021 at 6:18
-
2
...Meaning devs and testers are not to be treated as distinctly different entities. You don't have 2 devs and 2 testers. You have 4 Development Team members, whom have different specialties.What's the difference?– LucienCommented Aug 8, 2021 at 20:08 -
5@Lolums the difference is you can't say "it's in testing, so it's no longer my problem, and it's their fault if we don't make the sprint". Sort of like "make sure they are in the same team" but re-emphasising that even if they are in the same team, make really sure they are in the same team.– ErikCommented Aug 9, 2021 at 9:30
Neither Scrum (as of the November 2020 Scrum Guide) nor the Manifesto for Agile Software Development say explicitly that phases should be avoided. However, both have underlying principles and intentions that make phase-based approaches less attractive. The Manifesto calls for "early and continuous delivery of valuable software", where the software is delivered on a timescale "from a couple of weeks to a couple of months" (note that this timescale is from 2001 - some organizations are much faster today). Scrum calls for a Scrum Team that contains "no sub-teams or hierarchies" that are "cross-functional" and "self-managing".
The Agile Methods, including Scrum, call for rapid delivery of working software. Scrum, specifically, demands a working and potentially deliverable product Increment at least once per Sprint (and a maximum Sprint duration in Scrum is one month, so at least once per month). One way to ensure that you have a deliverable product at this frequency is by eliminating waste in the process, and the lean methodologies provide insight into how to eliminate waste.
It's well-documented that working as a team to identify and correct problems is more efficient. One of W. Edwards Deming's 14 Points is to "break down barriers between departments". Another one of the 14 points was that it's more expensive to depend on inspection to ensure quality and that building in quality from the beginning leads to a higher quality product at a lower cost. Taking a "finished" product and handing it off to a quality assurance team to test is a form of downstream inspection. These ideas can also be found in The Toyota Way, which informs the Toyota Production System and the Toyota Product Development System, which paved the way for modern lean methodologies, including Lean Software Development.
Although it may be possible to meet the minimum expectations of Scrum and Agile with phases and handoffs, there's plenty of evidence from a number of domains that suggest that eliminating handoffs can improve quality and increase delivery speed.
Just because there are no handoffs doesn't mean that there isn't a need for specialists on a team. For example, the Three Amigos approach to refinement moves tester involvement early on in defining the work to be done by the team. There are also opportunities for developers and testers to pair during the development of the work, allowing for knowledge to be shared and quality built-in during development.
answered Aug 6, 2021 at 13:49
-
can you elaborate how a whole-team approach contradicts handovers? Like if a dev (specialist if you will) finishes something and "hands over" the feature to a tester (test specialist if you want), you have a handover and a phase. It's just applied to features that are small enough cut. Same if you have test-phase where the test(specialists) test one version while the devs start with the next - i.e. I don't see a contradiction to small delivery time, perhaps I'm missing something or we use different understandings of hand-overs and phases. Commented Aug 7, 2021 at 6:25
-
Additional improvement suggestion: what is the essence of the answer: the first sentence says "they don't say phases should be avoided". The following "however" implies they do so implicitly. The points that follow however are either directly refuted (in saying phases should be avoided) or at least can be interpreted both ways. Perhaps an essence like: They don't say explicitly, but can be read as saying implicitly or They don't say , there are a few places that could be misunderstood like they do? Or whatever fits your point of view. [cont] Commented Aug 7, 2021 at 6:28
-
at the moment I get some interesting arguments from it, but have no idea if you would personally tell me to avoid phases when working in your agile team or not ;) Have a nice day! Commented Aug 7, 2021 at 6:30
Strictly speaking it's not possible to code and test at the same time. Testing always comes after. You can write & prepare tests in parallel, but execution will have to be done after devs "handed over" their part to testers.
What's usually advised to avoid though is handing over large chunks w/o involving testers in the middle. E.g. devs working for two months, then handing it over to testers - now testers work for two months. So if devs made a mistake at the beginning - it'll be discovered late, when they based a lot of code off the wrong fundament.
Agile doesn't impose any constraints on this - it's up to your team to decide what's most effective for you. If you find out that working in phases works best for you - go for it. Though it is common for agile teams to work in close collaboration with each other and discuss work which is still in progress to be able to promptly change directions. But the fact that it's common doesn't mean it's the only way.
As for Scrum - early versions used impose a constraint that whatever you planned for the sprint had to be fully finished by the end. So at the beginning of each sprint the team commits to finishing all the tasks they planned for. Which is possible only if testing is intertwined with development. Later versions of Scrum changed it:
Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.
Today Scrum says you should come up with a goal (which usually comprises of some core tasks) and that goal has to be completed. But there will also be tasks which aren't required to be finished by the end of the sprint. So strictly speaking today Scrum doesn't preclude you from doing "phases". But still those phases can't be long.
PS: I don't get why others mention cross-functional teams as this doesn't imply no-phases work flow.
answered Aug 6, 2021 at 20:53
-
1This. Most people seem caught in their particular .... wait for it... process. Especially the Agile Manifesto is so loosely formulated it's ridiculous to argue with "Sprints" as a given. Plus a lot of people seem to over apply. Like many ideas/strategies the manifesto is born from bad experiences that went one way. E.g. huge development phases followed by huge testing phases only connected by a handover mail to the QA department. Doing it agile doesn't mean you cannot have phases, it just means you involve QA early/directly and keep the pieces small enough to have a reasonable iteration cycle. Commented Aug 7, 2021 at 6:14
-
2Testing can certainly start before code is written - stories should already be tested in the "gather requirements" step, where you talk with the people who need the change and sometimes already eliminate some "bugs" from the proposed ideas before the developer turns on their machine. The only thing that can't be done before writing the code is testing the code itself, but testing is much bigger than just code.– ErikCommented Aug 9, 2021 at 9:34
-
1@Erik, yes, this is already covered in the answer. It can start before coding. But it can't be finished. Thus testing has a dependency on development and will always lag. Commented Aug 9, 2021 at 11:16
Where does Scrum or Agile Manifesto say that we should avoid stages (development, then testing)?
As already mentioned in other answers, Scrum or the Manifesto for Agile Software development don't explicitly say this, but it is something that Scrum or Agile teams tend to discover.
In the traditional way of building features, you do have stages, and it's first coding and then testing. When traditional teams start using something like Scrum, they now have to use sprints. Being used to work in a certain way, they keep that style but now do it in sprints. Basically, they start doing mini-waterfalls, keeping the same phases in the sprint.
What happens is that developers work in the first part of the sprint while QA doesn't, while in the second part of the sprint QA does the testing while developers don't do much except wait to fix bugs that QA might discover. Another thing that also tends to happen is for developers to run behind then dump everything on top of QA at the end of the sprint. Then QA is either pressured to finish the sprint, or things fall through the cracks, don't get delivered, ans spill into the next sprint.
Repeat this for a number of sprints and you either end up with people saying that Scrum and Agile suck, or with people that eventually understand that they need to change their way of working and their mindset in order to level out the work (which can happen through various ways, as described here, here, or here, and no longer involves big stages between which people can throw stuff to each other, back and forth over the wall).
You are correct, per a literal reading. The no-phase approach is a tool most Agile thinkers I've read consider vital to implementing several of the Manifesto's 12 "Principles." Scrum and other methods call for each team to be cross-functional, meaning you don't have separate Dev and QA teams, for a host of reasons around higher quality, productivity, and conflict reduction. That is, among other benefits, having those people on the same team:
- Ensures user stories are influenced by QA concerns before they are worked on, and there is dialog during that work as issues arise.
- Prevents the typical scenario where Dev is late delivering stories, meaning QA either gets cut short, or the QA team gets blamed for delaying the project.
- Eliminates Dev and QA throwing things back and forth across the wall, and finger-pointing instead of cooperating to get the job done right
- Enables Acceptance Test-Driven Development, developing to a test proving the Acceptance Criteria were met (not to be confused with TDD)
You could argue for having phases within a team's sprint, but in addition to introducing those problems, you would have QA waiting around for devs, and then devs with nothing to do the rest of the sprint. In short, the no-phase approach is emphasized to eliminate problems that routinely show up in the real world. I say that as an Agilist who is also still a PMP and would consider waterfall for a few types of projects--but not software development, after 20 years in the industry.
answered Aug 6, 2021 at 14:01
The Scrum Guide says that each product increment is "thoroughly verified" and "meets the Definition of Done". So code should of course be tested and can be handed over to testers if that's the process the team uses but that testing should be done within sprints. There is no testing "stage" because each sprint delivers only tested outcomes.
The Agile Manifesto in particular (and organizational agility in general) emphasises that teams ought to be empowered and self-organising, which in software development normally equates to cross-functional teams rather than specialist teams. In other words a team contains everyone needed to build and test the product. Handovers do happen within teams but handovers between teams are minimised.
Agile is about responding well to change.
If you can do this while using a development stage and a testing stage then that would satisfy the agile manifesto.
However, experience has shown that this is hard to achieve. Having a staged development process that includes hand-offs is typically something that works best when following a plan rather than responding to change.
Usually the response time to change will be at the very least the duration of the stages. For example, say a development stage has been completed, but the testing stage has yet to be started. A change happens and priorities are now very different. The teams has the choice of parking the developed code or completing the testing stage before switching to the new priorities.
answered Aug 7, 2021 at 7:33
