This is the governing body for certification in Disciplined Agile.
@Paul, great feedback. Good catches. You are right, there are a lot of quality improvement strategies scattered throughout the book that we should have pointed out.
If I look past the points described in my other post, there were a few typos and things that stood out to me.
Hi there, sorry that I am late to this review/feedback process. I started with this "Improve Quality" section and it left me a bit confused. Perhaps I am missing a bigger context that helps to explain how this section fits into a bigger picture?
When I consider the topic of improving Quality, or improving a quality process, there are usually a few things that immediately jump to mind. First is the feedback mechanism (i.e. to whom are you validating your notion of "quality"?), and second is the continuous improvement process. I saw a quick/passing reference to a continuous improvement section elsewhere in the book.
If that's the case, then I might suggest that all the related sections to this topic should be highlighted at the top/intro to this section.
For instance, if we are talking about Product Quality, then I would like to see some references at the top to:
Aldo, very good point. In hindsight I can't believe we missed this, given how many times we've seen this too.
We're doing the update.
Improve Quality --> Improve Implementation
I think we also need to identify that technical debt can also accumulate in testing artefacts, as well as test automation resources, documentation and even tools; not just UI, code and data.
In my current engagement, there is significant automation and testing debt that causes significant delays of getting builds into production, and I think things would have been better if they were able to articulate this type of debt earlier in the product's existence.
I just published v2 of the excerpt.
I've been acting on this great feedback and hope to post an updated excerpt for this goal soon (I'm on the road this week, and to make the updates I need to do some graphics work which I prefer to do on my workstation at home which has multiple large monitors and a mouse, unlike my laptop).
Improve Quality: Improve Implementation - asses debt
Beyond refactoring (before, during and after refactoring), we should asses the technical debt vs. quality needs. More we should asses the skills of the developers on paying and avoiding the technical debt. Sometimes, the result of this assessment is a no-go! In most of the cases, these problems are discovered too late, at delivery or later.
Improve Quality: Improve Deliverable Documentation
A big problem with the documentation is missing documentation (it is a form of technical debt). Imagine that we need to change and deliver some components that have no documentation and no auto-tests.
The solution is to restore the necessary documentation, good usage of Agile Modeling practice Document Late.
Restoring missing documentation could benefit from refactoring or will need refactoring, to understand what that code does.
Improve Quality: Reuse Enterprise Assets, common guidelines
To get effective guidelines: reuse industry, organization, and team experience; use lesson learned when you build it. I saw too many times ineffective guidelines and guidelines that are not updated with the new experience. Such guidelines could harm instead of help.
Important: it is important to have explicit and managed guideline. No-guideline is an illusion: people will reproduce anyway some legacy works in an uncontrolled manner.
Improve Quality: Reuse Experience – a larger sense
Reusable assets and knowledge will be optimum when:
The first question that I always use is “why”?
In case of quality, this question is fundamental, because many problems of development (or produced by…) are triggered by serious misunderstandings related to the role of quality.
Why we need quality? Quality need in context
We need to respond to business needs of quality & business criticality (we can damage, for example, comfort, money, essential money, life). That means each product and release will have a different context (!). From a development point of view, quality care will reduce the magnitude of main problems of software development: (undesired) complexity and incertitude. For both Agile and Lean, quality is a core aspect. Again, the context count: the complexity of the products, requirements incertitude and others.
The developers/teams/organizations must be aware of their context and try to figure out which techniques will count more.
Why technical debt? TD in context
Again, we need to answer this question. Simple: technical debt is the main source of non-quality in software development.
Again, the context count: we need to be aware of the amount of technical debt versus the needs of quality in context. We need to be aware of technical debt trends in context. Sometimes technical debt is too high from the beginning, and it does not result from design deterioration. Having this context awareness, we could decide properly.
These are the starting points that need to be short, but more explicit ime imo.
Improve Deliverable Documentation --> Single Source Information
What did you have in mind here as examples of such single source information? Story maps in a tool like JIRA? Perhaps allude/ provide ideas of what can work as single sources of information?
Improve Deliverable Documentation --> Executable specifications
Gojko Adzic is a great source to reference here: He talks about "Living documentation" (by using automated tests as the latest deliverable documentation). One point to add is that tools can also be used to transform the automated test scripts/ scenarios into a more readable formatting for end users. Automating the generation of user documentation requires technical know-how, but can help with delivering up to date user documentation every time.
© 2013-2019 Project Management Institute, Inc.
600 Crowfoot Crescent NW, Suite 340
Calgary, Alberta, CANADA T3A 5A2