PDD In a Team

The basic approach is outlined here. However, there are team level issues that should be elaborated on.

Teams using PDD essentially use ATDD/BDD - I'll just say "ATDD" - except that for complex stories - that is, stories for which the implementation requires complex algorithms or complex structures - PDD practices are used. That provides the level of assurance and agility that one might derive from using a TDD approach, although I would argue that TDD seldom actually achieves a high level of assurance or agility.

Incompatibility With Scrum

It is my experience that Scrum is not a good fit for ATDD. The reason is that ATDD entails a sequence of activities for each story that are better addressed through a Kanban-like flow. I would not propose Kanban either, however, because some of the activities can be done in parallel. What works best, in my experience, is when the flow is actively managed by someone. If the team has a Scrum Master, that person is a good candidate for managing the flow.

A pull approach to controlling the flow is not sufficient. Tests must be ready to run when needed, and so they must be started in advance - not "just in time". There is an inherent critical path for the work needed for each story. Someone needs to manage that, because the time that the various activities take is variable.

It is possible that a pull system could be set up. For example, when someone starts working on a story, they could "pull" a request that someone else starts working on the tests for that story. I have not tried that, but I plan to in the future. What I have done, and it worked well, was to have someone maintain a table on a whiteboard that showed the stories being worked, and which had tests under development and when they were expected to start to be ready. That table was used to balance the work every day. It was clunky: there must be a better way.

Scrum is not a good fit though: that is something I am confident about. The arbitrary sprint boundary means that work on a story cannot start before the sprint starts, but that means that some stories will be ready for running tests before those tests are ready. Scrum assumes that every story is independent of every other, but the ATDD process has many steps that are dependent on prior steps. When using Scrum and ATDD, one ends up starting the test specs for a story in the prior sprint, so that the test coding can start in the same sprint as the application coding, which means that one must decide on the sprint's stories well in advance of the start of the sprint - breaking the Scrum cycle. It just doesn't work well.

Definition of Done

It is really important for ATDD that a story not be considered "done" until it has been integration tested, and ideally end-to-end tested. I touch on this in The Basic Approach. That means that a pull request (PR) should not be submitted until a reasonable number of integration tests have been run and pass - enough to give confidence that a full regression will pass. The reason is that we want to keep the integration regression test job "green". But it will only stay green if we run integration tests before they hit that job.

To achieve that, people must perform local integration testing. When local integration tests pass for a story, the PR can be submitted, and if approved, the story can be marked done. The DOD should be defined accordingly.