Skip to main content
Project Management

Return to Answer

Avoid usage of signatures. Check https://pm.stackexchange.com/help/behavior
Source Link
Tiago Cardoso
Tiago Cardoso
  • 8.7k
  • 6
  • 31
  • 73

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.

Hope this helps--Jim

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.

Hope this helps--Jim

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.

Source Link
The Radical Agilist
The Radical Agilist
  • 554
  • 2
  • 5

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.

Hope this helps--Jim