When developing something in a commercial environment, you're generally involved in spending the company's money, whether simply by spending time working on something or by using resources that need to be paid for. There will be an array of corporate stakeholders, with various different interests in tracking what you are doing and how. There will be all the usual corporate departments who want you to do compliance training, fill in security questionnaires, engage in performance assessments, fill in timesheets, etc etc etc.
None of this is specific to the development context, and Agile won't protect you from any of it, with the consequence that you are never a '100%' resource. This is normal, and any sane company will plan on this basis.
However, development can sometimes add some special flavours of data collection bureaucracy. From an Agile perspective, the question is how to assess the value of these things.
A review is a form of test - it is an activity that implements, in some sense, a check for 'correctness' or perhaps 'value'. In this context, this usually refers to a design or code artefact of some sort. Reviews can involve a whole raft of 'stakeholders', who may have very different perspectives and degrees of interest in the material being reviewed.
Reviews can also be used as a form of ass-covering, to ensure that any subsequent complaint about the reviewed material by a stakeholder can be deflected. Reviews can also stray into the realm of project management if they are used as a way to control the work that is done. Aggressive review procedures can easily suck up a huge amount of project effort, not just in the reviews themselves but also the rework cycles that are triggered.
This goes to the heart of the question of empowerment of Agile teams, and the notion of 'done'. Agile is not friendly to the idea of spreading responsibility for deliverables beyond the Agile team.
This does not mean that reviews cannot, or should not, be done. Empowerment does not mean that an Agile team exists in a vacuum, with no need to involve outsiders, or that it should not perform internal cross checks on it's work. But it does mean that reviews should take place only on the team's terms - when the team needs them, with the stakeholders the team deems necessary, and with end conditions defined by the team via their level of done.
If this is not possible - and it may not be, for certain things ( legal review, security review, safety review, etc ) - then that story/workflow transfers out of the team ( i.e. is considered done ) and the team gets on with other things for the rest of the sprint. When the review has been done by the relevant authority/team then the Product Owner can bring the story back. See the section on where the buck stops. Under no circumstances should teams be expected to iterate through review cycles in which they have no control over the end condition - how could anyone estimate story points in such circumstances ?.
Defects happen during the course of development, and any organisation engaged in development has an interest in being aware of these, and ensuring they are minimised or eliminated. There is a huge array of tools that are used to record and track defects, and defect management may even be an explicit role in some organisations or projects. It can certainly be informative to analyse defect information for various purposes concerned with improvement of engineering practices.
What does this mean for an Agile team ? Is the team actually empowered to make decisions about how bugs are dealt with, or is this an engineering process that all development teams are expected to adhere to ? In particular, how much effort must an Agile team devote to documenting defects ?
Part of the issue with defects is that constantly updating the state of numerous defects in code under active development during a sprint ( i.e. code which is not 'done' ) may add no real benefit for the 'outside world' whilst being a drain on developer time. It may fail Principle 10.
The key to understanding this problem is to understand how integration ( in the sense of building a particular codebase - there are other senses ) fits into an Agile environment.
Normally, Agile projects will run a Continuous Integration system, a side effect of which is to expose developer's work ( and any bugs associated with it ) to others on a regular basis. These bugs may be identified by automated integration testing, or they may be found by other teams using the integrated code. These 'externally visible' bugs are therefore the bugs that require formal documentation. They've escaped the testing which the team has done, which is a problem in itself, and so they are worth managing explicitly. Without a record of them, it will be hard to ask the question 'how could we do better ?'.
Bugs found during development, such as via unit testing, in code which is not yet visible outside the team should not require formal documentation, provided that they are not lost - there's no excuse for losing track of a bug. It's up to the team and individual developers to manage how they do this, if there is no overarching engineering practice.
It might occasionally be the case that code with a known defect is checked back into mainline for integration. This depends very much on the nature of the defect. If there's a wrong pixel in a graphic, and it will take a couple of days before the graphic designers fix it, it can certainly be argued that the benefit of getting the associated code into mainline for integration outweighs the negative impact of the defect. Certainly such bugs must be documented.
This begs the question of how often should developers check their code back into mainline for CI to pick up ? Well, they should not check in untested code ! But it's actually much more complicated than that. An update to a feature may require changes to several parts of the code, which the team is handling as separate tasks. Functional dependencies cannot always be avoided in these circumstances. If checking in part of the update would cause a regression, or even worse, cause the build to fail, there is an obvious case for holding off until the complete story can be checked in. Clearly the DoD must mandate that 'Done' items have passed integration testing.
Gaaaargh ! I hope that gives you a hint of where I'm going with this one 🙂.
Traceability is only a good thing when it serves a specific, well defined purpose. There are a small number of such purposes. Otherwise, it is simply ass covering - pure bureaucratic overhead, and a product of 'what if' fear rather than rational thinking.
What is 'traceability' ? This is actually a very interesting question, and one which is not asked anything like enough. People think that they understand it, when what they actually understand is how to link one development artefact to another. This is the mechanism, not the rationale.
Traceability is any technique that allows finding out what caused a system to enter a particular state. It can be applied recursively, to discover a chain of events ( or state transitions ) leading to a particular outcome. This is usually considered to be its purpose. The particular mechanism for inferring the antecedent event or state may differ at different points in the chain. Tracing a set of function calls via return addresses on the stack is one example of a mechanism that provides traceability. Placing reference markers and references in a document is another mechanism for providing traceability.
Traceability often requires the creation and maintenance of metadata. Thus in the case of following the return addresses up the stack, the metadata is actually the symbol table and source code. In the case of the document, the metadata is the actual reference markers and references themselves. It may be worth pointing out here that in the case of documents and references, what is actually being traced is not just the raw data used in the document, but the justification of the arguments the document contains.
These examples highlight a problem with traceability. In the case of the stack, symbol metadata is generated automatically once the correct compiler options are chosen. It may even be that explicit source code references are automatically built in to the program under test. Maintenance is automatic, effort is low.
But in the case of the document, selection and maintenance of references is an entirely manual ( and hence error prone ) process. The mere existence of traceability metadata does not guarantee that the correct antecedent state or event is identified . In other words, if your document says 'as per Katz[4]', and '[4]' points to your mother's fairy cake recipe, or worse, an argument contrary to Katz, then traceability has failed here. It's entirely up to the author(s) to get it right and keep it right. This is just as true for defect databases or other tools allowing the manual creation of links as it is for actual documents.
Now I'll return to the question of 'purpose'. There are two fundamental purposes that traceability serves.
If something goes wrong, particularly if it goes wrong in a dangerous or expensive way, the engineering reaction is to try to identify not just the immediate proximal cause ( e.g. the drive shaft failed ), but also to work out why this problem was not foreseen and avoided ( e.g. the drive shaft manufacturer did not have full information about the environmental conditions in which it would be used ). Then a change can potentially be made which would avoid future problems of this type ( e.g. ensure that environmental conditions are specified completely for all components ).
If something goes wrong, particularly if it goes wrong in a dangerous or expensive way, the business and legal reaction is to find some entity to blame. They may not put it quite like that. Perhaps the term used will be 'responsibility'. Fair enough, it's a semantic detail for my purposes here. In any event, it's important to be able to trace particularly the decision making processes - who knew what and when, and who signed off on things. Of course, this applies equally to many business functions, not just product development.
The Agile angle is simply this - do not impose any non-automated process for maintaining traceability metadata unless you can justify each and every piece of that metadata in terms of one of the two purposes described above. This is an expression of Agile Principle 10.
It's quite possible, depending on the particular industry involved, that traceability may be mandated by regulation. There may even be specific techniques required. But the objectives of that regulation will almost always be covered by one or both of the two purposes above.
Avoid the temptation to manually link together by default everything that can possibly be linked.
Let me tell a story. Imagine that you go to a project kickoff meeting, and you have the compliance people there, the legal people, the head of software, and the project people who will do the work ( :) ).
The compliance guy says 'hey, this product falls into a heavily regulated domain, so make sure you strictly follow the project handbook, and document all communications, all decisions, etc.'. OK, it won't improve the product or the timescales, but the company should cover it's legal ass, no problem.
The legal guy says 'hey, this is a fixed price contract, but we've cut an exception for any requirements defects after milestone 3 to be T+M, so make sure you can trace any customer issues back to requirements if at all possible.' OK, it won't improve the product or the timescales, but the company should maximise it's revenue, no problem.
The head of software says 'hey, I want this thing to be a great example of our technical skills for this customer, so I want all our design decisions fully documented and traceable. Any questions ?'
Well, yes.
Q. Do you want design documents ( UML, Word, Visio, etc ) linked to code ? A. Yes
Q. Do you want design documents ( UML, Word, Visio, etc ) linked to requirements in DOORS ? A. Yes
Q. Do you want bug reports and CR's linked to design documents and requirements ? A. Yes
So at this point it is very tempting , as a project person, to just roll your eyes and think 'we'll just link everything to everything we can, and that will keep everyone off our back'. This is the sense in which I mean 'ass covering' and 'what-if fear' per my first paragraph.
However, this will just make for a maintenance nightmare and frustrated developers. Mesh networks appear robust from some perspectives, because they contain redundant paths, but they are extremely fragile if all of those paths, redundant or not, must be manually created and maintained, and they add no value from a traceability perspective. Whenever you detect a 'loop' in your traceability linkages, you are probably making unnecessary work.
Usually 'lateral' linkages which link things of the same type are just conveniences and are not required for traceability - linking a group of similar bugs together does not enhance traceability, but linking each bug to the commit that seemed to trigger it does. Linking code to the design parts that it implements does. Linking design parts to the requirements they satisfy does. If you also link code directly to the requirements, or you explicitly link down as well as up ( down should be implicit in many cases, but is rarely as significant as up for traceability purposes ), you're falling into the ass covering trap I referred to earlier.
© Mark de Roussier 2021, all rights reserved.