Mandatory deliverables in Agile development?

I do a lot of Agile transitions as an Agile coach for management. And in every transition, sooner or later, I find myself in a discussion over ‘mandatory deliverables’. But,is that a discussion? Doesn’t ‘mandatory deliverables’ contradict everything Agile embodies and stands for? Aren’t they a relic from ‘desire for control thinking’ by old school management? How could you possibly reconcile this ‘desire for control’ with the Agile ‘team autonomy’?

Well, yes, it is possible,but before you dismiss me as someone that definitely does not understand Agile and the Agile mindset, it certainly is not an unequivocal ‘yes’. So let me set the stage where I think the answer may be ‘yes’.

Agile teams, however autonomous, do not exist in a vacuum; they are part of an organization that provides them with an environment in which they can flourish. This environment may also instigate some constraints, e.g. set by legislation or by internal or external parties, e.g.  by the European Central Bank (ECB)

A recurring example is ‘traceability of test cases. Is it really strange when an organisation requires software not only to be tested before deployed into production but also requires that the coverage of the requirements by the test cases is known? How this coverage can be demonstrated may differ from team to team and relates to the team way of working and the technology at hand: is testing automated, is exploratory testing employed, are certain test types (security/penetration test, End-to-End test,?) ‘outsourced’ to a separate team, etc, are we talking mainframe development or Cloud development?

But even when we agree on an organisation’s legitimate claims for what to deliver, does that transfer to ‘mandatory deliverables’? Don’t the Agile Manifesto and the 12 principles obstruct that? I don’t think so.

Mandatory deliverables may appear at odds with the Agile Manifesto and several Agile principles, but that’s not an absolute truth. Let’s examine some a little further:

“Working software over comprehensive documentation”

It states comprehensive not any (as ‘Agile in name only’ practitioners tend to read it). We still document, often and a lot. Just not as much as we used to, in the good old Waterfall days. We are very conscious as to what we document, and why, and how. So if we have a sound reason to document, we do, and we document it close to its subject, preferably as an integral part. External, separate documents (Word, PDF, Excel, ..) often are the least favourable form! Self-documenting deliverables (Java code with JavaDoc) or (hyper-)linked documentation are our choice of preference. And let’s not forget the final sentence of the manifesto: “That is, while there is value in the items on the right, we value the items on the left more.” Documentation, even some comprehensive documentation has its value!

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”

This principle is often quoted as the basis for a team’s autonomy (“trust them to get the job done”) and by inference the ‘right’ of teams to ignore imposed standards or templates. But there is more to this principle than “trust them to get the job done”, it also states “give them the environment and support they need”. An Agile team can only thrive when the proper preconditions are set. This environment may contain objects that are not self-evidently beneficial or even useful for the team but are of paramount importance to the company as a whole, e.g. guidelines or templates for external compliance. When this is the case, the team cannot invoke their autonomy but must comply for the greater good.

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”

No argument here, but documentation isn’t always about conveying information! The mandatory deliverables may not bear to team-internal information sharing and the like. They’re sometimes required by ‘the environment’ as mentioned earlier and serve a purpose in e.g. the compliance obligations by the organization.

Let’s not get trapped in the pitfall of categorically dismissing mandatory deliverables in Agile development under any circumstances, without ever giving them a second thought.