This is the governing body for certification in Disciplined Agile.

Improve Quality

<< First  < Prev   1   2   Next >  Last >> 
  • 06 Nov 2018 8:57 AM
    Reply # 6891244 on 6271127
    Scott Ambler (Administrator)

    @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.

  • 23 Oct 2018 1:10 AM
    Reply # 6865753 on 6271127

    Minor typos.

    If I look past the points described in my other post, there were a few typos and things that stood out to me.

    1. p. 3: Table, row 2, col 1: Refactor databases. "such as renaming an column" >> should be "a"
    2. p. 4: Fig Y, bottom-left quadrant: "UEX design" >> should be UX design
    3. p. 4: Table, row 1, col 1: Single source info. "variety of place even.." >> should be "places"
    4. p. 6: bottom table, row 2, col 2: "(something covered in the Continuous Improvement process blade)." << what's a blade? (did I miss the explanation of a blade in an earlier chapter?)
      • this word appears again at the top of p. 7.. which makes me think that I missed the explanation somewhere else.
    5. p. 7: Table, row 2, col 2: you use "EA" without explaining what that is. In the *next* (bottom) row, you define "enterprise architecture (EA)..". This feels out of order/sequence to me. I suggest that this explanation should go in the row above since it would be the first appearance of the EA term, so you don't need to define it in the bottom row/cell. 
  • 23 Oct 2018 1:00 AM
    Reply # 6865616 on 6271127

    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:

    • [External] Validation/Feedback mechanisms with customers/users (i.e. whether via UX designers or PO, etc.), frequency of contacts, proxies, etc.
    • Building Quality in - ATDD/BDD, TDD, Continuous Integration, managing environments, automating deploys, etc.
    • Quality in communication - team communication, pairing, mob programming, information radiators, etc.
    • Continuous improvement, eliminate waste, systems thinkings, etc.
    If we are talking about Process Quality, then some ideas that jump to mind include:
    • understanding context: know your target audience(s) & purpose/why
    • sunset clauses - i.e. validating assumptions that expire over time (lest you get stuck with a meaningless process that lost it's need several years back but no one bothered to check)
    • Communication - written & verbal, ensuring everyone is on the same page, training, audits, etc.
    • Continuous improvement..
    This section has some good advice but I am struggling to understand the need that it fills. For instance, the "Improve Quality" mind map on page 2 has 4 nodes: 
    • one for improving the implementation (tech debt), 
    • two for improving documentation artifacts, and 
    • one for reusing assets (generic).
    I don't understand the connection here. None of these particularly jump out to me as being high on the list for "Improving Quality". Sure, they contribute to it, but I can't say I've ever immediately talked about these items when this topic came up for me in the past.

    Am I missing something? Please help me to grasp where this fits and how. Thanks.
  • 05 Oct 2018 9:03 AM
    Reply # 6708616 on 6271127
    Scott Ambler (Administrator)

    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.

  • 05 Aug 2018 4:33 PM
    Reply # 6414696 on 6271127

    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. 



  • 26 Jul 2018 7:28 AM
    Reply # 6398987 on 6271127
    Scott Ambler (Administrator)

    I just published v2 of the excerpt.

  • 15 Jul 2018 3:11 PM
    Reply # 6382126 on 6271127
    Scott Ambler (Administrator)

    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).


    • Assessing skills - great thought, I've reworked this to discuss potential lack of skills and need for coaching/training
    • Missing docs - Good point, updating the wording as this is a form of tech debt (similar to missing regression tests)
    • Existing guidelines - Yes.  I'm going to add a reference to the Leverage and Enhance Existing Infrastructure process goal where this is addressed in detail.
    • Existing experience - Agreed, adding it to the decision point
    • Why - added a discussion about this as well as the tech debt quadrant diagram


    • For a single source example I discussed wikis
    • Living documentation - This is also an example of single sourcing info, something I've pointed out and referenced Gojko.  I'd have to go back and look, but I don't think that he referenced the original strategy that was first introduced by Agile Modeling, which in turn was based on the single source strategy which was originally from the tech writing community.

  • 10 Jun 2018 1:37 PM
    Reply # 6302080 on 6271127

    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:

    • It is performed at all enterprise levels: teams, team of teams & enterprise  
    • We do not reuse only assets, but also experience and knowledge (of course, putting this experience in assets it is an extra-optimization, but we do not always have these assets on time, and direct collaboration will always help)
  • 10 Jun 2018 1:01 PM
    Reply # 6302051 on 6271127

    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.

  • 29 May 2018 6:12 PM
    Reply # 6272056 on 6271127

    Hi Scott,

    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. 



<< First  < Prev   1   2   Next >  Last >> 

© 2013-2019 Project Management Institute, Inc.

14 Campus Boulevard

Newtown Square, PA 19073-3299 USA

Powered by Wild Apricot Membership Software