Definition of Ready and Done in a Waterfall-Scrum Process (Global Definition as Solution?)

Question

I am currently working on a project in which a so-called Waterfall-Scrum process is completed. This includes one week of development and one week of testing.

Each team (currently 7 teams building on each other!) currently has its own Definition of Ready and Definition of Done. This means that there are often strong problems in the process of testing and delivery to the next stage.

Problems that arise:

• Partly late deliveries, from development to the next development stage
• Unclear definition of when, what, where to ship (even with different build times)
• Unclear circumstances which team tests when, where, what. It starts with the team that should use the Unit Test, only doing Functional Tests.
• However, other teams build on the only partially tested products. This results in a spiral of mistakes.
• Some teams have a staging process, others only partially. Pre-production is missing.

Approach (My suggestion)

• Analysis of the process with all participants
• Use a new global definition of Ready and Done that clearly defines all teams when something needs to be done.
• Standardize the staging problem by introducing clear structures and unit testing. This allows you to intervene at an early stage in case of misconduct.

I've thought about some points, but I need your advice here:

The team's own definition of Ready and Done should remain in place. The global definition of Ready and Done should only describe the individual stages (delivery to the next test days).

Questions:

• Am I right with my approach?
• Should a Global Definition of Ready and Done be able to solve problems within delivery and testing?
• Do you have other approaches?
• Should you only adapt the cross-team definition of Ready and Done?

Perhaps one or the other has already experienced something similar in another project?

Answer 1

Without understanding fully, I don't think we can suggest the best approach. With that in mind, here is my approach based on the information given.

1) Remove the concept of 1 week development, 1 week testing. It should be test as soon as developed, fix bugs as soon as it is tested. This will ensure that your deliveries have as little amount of bugs as possible.

2) Divide the teams based on different modules. 7 teams mean you can have 7 business functions in progress at a time. Maybe a team that focuses on just payment systems, one on just user accounts. Idea is to reduce the dependency on other teams. One team should deliver a releasable increment without external dependency (in ideal case, obviously).

3) Have a global definition that is agreed upon as minimum required. Individual team should have their own definition. This means even if the teams are working separately, your global definition can be considered as "lowest quality gate". Some teams might add their own additional items and provide better quality.

4) Ensure every team has proper pipeline in place. Staging or not, they should have automated quality gates for every code pushed into the master repo.

5) Stagger the release schedule. Every team works on their own schedule and own sprint length. Account related features can wait for 3 weeks, but main business process should not wait for 3 weeks. So, have different schedule based on what is right for that team. Another advantage is that you are releasing in smaller batches instead of a full fledged release, which means your support team can manage a smaller load of production bugs.

6) In future, plan to move into a scaled version of Scrum. This will just help the team be more consistent with their approach, and help you facilitate their Scrum events more effectively.

Again, this is just my approach. It might change based on more information, or on based of team's understanding of agility, management's interest in adopting change etc.

Answer 2

If you can make this work for your teams then that is fine.

I would caution that a global definition of done has several drawbacks, including:

• Getting consensus over several teams is challenging. If not all the teams agree with the final solution then they may ignore it or work around it.
• Some aspects of the definition of done may be specific to each team.
• With the definition of done used so widely it will become difficult to make quick changes to it. So you may lose some of your ability to adapt to change.

Also, the definition of ready is a solution to a problem and not a stand-alone method. Teams typically introduce a definition of ready as a temporary way of reducing the number of requirements that are not ready to be estimated in planning.

It is temporary because the long-term solution is to ensure everyone understands what is needed in a story being ready and that your process supports this.