Although Agile writers and thinkers agree that “there is no sign-off” in Agile methodology, the practice of requiring product owners and business customers to sign off on requirements and delivered work products persists in Agile settings. I’ve seen it most when an agile team faces delivery challenges and leaders perceive the problem is scope creep or failure of the UAT process before delivery. In those situations, adding a formal sign-off provides an illusion of a stronger process but does nothing to resolve the underlying issue.

Sure, sometimes sign-off is necessary, especially when two or more separate organizations work together on a project. For example, consulting contracts often require sign-off on interim and final work products. However, addition of a sign-off step is common within organizations in hopes of a remedy for delivery or quality challenges.

The commenter David on this post says that “the purpose of a sign-off (or whatever you wanna call it) is a confirmation from a product owner that artifact A is fine for the time being, and can be used as basis for work on artifact B.” That’s all well and good, but in a well-run Agile context sign-off is a meaningless formality that’s dispensed with because it’s unnecessary.

How could that be? Others have written, often emphatically, on why sign-off is unnecessary in an agile context, including here and here. This quick video explains how “definition of done” and a fully committed, reliable team work together together make sign-off irrelevant.

The subtext of the Agile approach is that the team is all working together to solve business problems. For small efforts, Scrum and similar methods enable teams to work closely and constantly with product owners and other business stakeholders to understand business needs and deliver relevant solutions. Scrum emphasizes improving understanding among project participants to improve team effectiveness. The Scaled Agile framework (SAFe) scales Agile team techniques up to enterprise scale, but still bases project control on teamwork and communication. Even in compliance-related projects, “the goal is to conduct … reviews as the solution is being built, reducing the last sign-off activity from a large, extended event to a quick and boring ‘non-event.’”

The bottom line is that if the team and product owners work hand in hand and understand the goal in the same way, they’ll all work together to build a quality product. If that’s the case, what creates the issues that drive teams to want to add a sign-off step? My experience suggests two underlying causes:

• Incomplete commitment to Agile methods
• Competing leadership motivations

Incomplete commitment to Agile methods

The fatal flaw of waterfall development is the delay between product conception and delivery, during which time customer memories fade and business conditions change. Teams that use, for example, 8-week sprints risk disengagement of business stakeholders and “bad surprises” at sprint demos. These teams tend revert to waterfall-style sign-off of requirements and final products as a CYA measure.

Similarly, hybrid methods can generate testing and quality challenges. Citing weaknesses like scope management and resulting software product performance, hybrid advocates to varying degrees embed agile teams within work breakdown structures. Unless very skillfully designed, such structures lack collaboration and consensus mechanisms built into enterprise Agile methods like SAFe, generating inefficiencies that lead to disconnects between teams and stakeholders. As those disconnects result in project challenges, project leaders attempt to resolve the disconnects by adding delivery sign-off.

Competing Leadership Motivations

Another situation I’ve seen where sign-off arises is when different departments don’t collaborate as well as they should. When an IT development team works with business product owners, the dev team might request sign-off from the product owners as a way of assigning responsibility for any defects to the product owner and absolving the IT developers.

This kind of political wrangling might also occur if there are two distinct user groups served by the target application. An Agile team might have to use sign-offs in order to demonstrate that a feature that one of the teams did not want was requested by the other team. 

If you see calls for sign-off on your Agile or hybrid project, look for signs that your project isn’t working as well as it should. Correct barriers to efficient communication and teamwork, and as much as possible, correct organizational and political inefficiencies that impede collaboration. Specific solutions will depend on your specific situation, and some will depend on the willingness of participants to pull in the same direction.

But keep in mind that sign-off is a symptom of, not a solution for, project challenges.