In these cases, the better is to align how it should be done the definitions (if they should) with the stakeholders with major strength and impact. I will leave here another article that I wrote about it called “Stakeholders – improving your power and impact.”

In case you are already a leader with sufficient power and autonomy, I will share with you first the concepts of SAFe and right after how I use these them.

SAFe's definition of ready and definition of done

Shift learning left

The development of products includes many unknown scenarios that the team is going to discover as they advance with the project, and this statement is valuable to its tasks. The later you find these new scenarios, the worse it is to adjust them. Impacting on scope, quality, schedule, and costs. A process to verify and validate possible scenarios becomes crucial to the good progress of a project.

Pair programming and peer review

This is a good, common practice, but little used by technology teams. Two professionals work together on the same task, where one of them makes the construction and the other serves as a navigator, providing feedback and promoting improvements in real time. The idea here is to have more than one perspective about how the task will be better built, bringing major knowledge not just about the product but how it works internally.

Collective ownership and T-shaped skills

Here, SAFe tells us that every person within the team must have the skills and sufficient authority to modify a delivery, independently of the moment of the process it is. No professional owns the delivery or the product. Another point in this concept is to have professionals that, even being specialists in one type of work, know the project as a whole.

Artifacts standards and definition of done

The deliveries tend to have a manual process to pass the task between professionals of the same team, generating delays. Within these construction processes of a product, there is also the loss of time inspecting tasks or even the loss of searching for components already created that can be used to speed up and/or improve the delivery’s performance. The automation of these processes helps to diminish the time and costs, generating productivity increases and improving the deliveries’ standards.

Workflow automation

Flows tend to have manual processes of passing tasks between professionals within the same team, generating delays. Inside these construction processes, there is the loss of time in inspecting the tasks or even the loss of time searching for components already created that can be used to accelerate and/or improve the performance.

The automation of these process helps to diminish time and costs, generating productivity increments and improving the deliveries' standard

These were in part the definition of what SAFe understands as quality built in. As you may have noticed, the definition of ready (DoR) and the definition of done (DoD) come as a sub-concept within something bigger called quality.

Let’s move on about how I use these concepts to have a better definition of ready and done in the projects that I manage.

Definition of ready/done and quality in practice

As a way of clarity and documentation, I use the tripod: PO, UI, and tech leader to build the definition of ready for any task, using the following:

• UI documents the expected flow and parallel ones
• PO documents what is expected as delivery from the business area
• Tech leader documents how it must be built

Why? Honestly, I have never seen a project where all the members have the skills and authority to take decisions. It becomes necessary to create technical leadership from the interested parties to guide and validate the tasks. Within the knowledge that I have acquired, having someone to guide the team technically is necessary until the team becomes self-sustainable.

In the case of definition of done, I use these professionals to validate and finish the delivery too. That said, I will detail with greater depth using the SAFe’s processes.

Shift learning left

In this case, with the initial documents provided from my tripod of professionals, the development team can start constructing the task by the tests (famous TDD), and the QA team can already work with test scenarios (BDD). I can even use here the agile world’s concept: if there hasn’t been an understanding by the team regarding what should be done in refining events, the task isn’t ready to go to the sprint. From this point, we return the task to my tripod with all the questions made by the team, and we refine the documentation until the task is crystal clear to everybody.

Pair programming and peer review

I love pair programming, but I will arise an inconvenient truth that nobody has the courage to say:

“If you put two people to make one task instead of two people making two tasks, or you have considerable power inside your company, or your boss will be angry at you.”

The truth is that almost anyone wants to sacrifice time over quality (except the Japanese). That said, one of the actions that I always impose on my team is that my tripod: PO, UI, and tech leader serve as oracles during the construction. No matter how much time we have spent documenting what we must do, questions can still happen in the middle of the process. The faster we answer these questions, the faster we advance. In general, I ask for my tripod to take 1 hour of their days every day to answer questions. It would be like a daily, but with more time for complex explanations.

Collective ownership and T-shaped skills

Here again, I rely on my tripod of professionals as responsible for any modification to the tasks, but why?

At the beginning of the project or even at the first contact by new professionals, knowledge, and experience are zero or too low related to the business rules, what must be done and what are the expectations regarding the deliveries. For this reason, they rely on the people’s knowledge with more time on the project or experience, like the PO, tech leader, and UI. These are the people who have the keys to enter and modify any process or delivery. Throughout the time, the team gains confidence and can intervene in any phase of the process.

However, there’s a specific point here: human beings are narcissistic by their nature. If you remove someone’s authority conquered previously, you will have behavioral problems, coming even to layoffs. Let’s say that when these professionals go on vacation, you will have an already trained team to modify the deliveries if necessary.

At the end, the T-skills question: using Pareto’s rule, I would say that in 80% of cases, this just doesn’t happen. First because it takes much time to have overall knowledge, and projects don’t last too long. Second, because it is too difficult to find professionals interested in knowing a bit of each new thing involved in a product construction.

Artifacts standards and definition of done

We will enter a little in the definition of done, but first I will start with the standards. Every professional has patterns of work, and, when these patterns are printed on the documentation, they become the patterns of the project. I will open an exception regarding the case of patterns that come from outside (for example, a company pattern or from the PMO). Let’s say that patterns happen.

Related to the definition of done, I commented previously that one of the points is my tripod’s validation and formal acceptance. Besides this, I use the test cases and Unity tests’ automation as definition of done. The main reason is to make a safety lock and avoid problems in production. If the tests fail, it isn’t a product for my customers.

Workflow automation

To give a greater agility on the process to finish the tasks, from when they start until when they finish, the best way is to have a balance between what needs to be done VS how many people I have to. In case you need to choose, better leave the people waiting for the tasks rather than the tasks waiting for the people. In the end, we want to deliver a product fast and with high quality, don’t we?

Related to the inspection of tasks, with the test cases and unity tests automatized, the manual inspection isn’t necessary anymore. At last, the search of components can be described on the task’s initial documents and, in case it doesn’t, will be answered by one of our oracles.

I arrive here at the end of this article. Here you have learned some concepts of the SAFe about quality and how I use them to create the definition of ready and definition of done with efficiency for your projects.

Do you want to continue this talk? Give a like to the article, comment on LinkedIn, or share it on your social media.

See you soon!

Erik Scaranello