This is the governing body for certification in Disciplined Agile.

Chapter 4: Roles, Rights, and Responsibilities

  • 16 Nov 2018 12:41 PM
    Reply # 6910792 on 6887764
    Scott Ambler (Administrator)

    I just uploaded the revised version.  

  • 16 Nov 2018 11:16 AM
    Reply # 6910606 on 6887764
    Scott Ambler (Administrator)

    @Joshua - Great feedback, all of which we're incorporating.  Daniel Gagnon sent us similar feedback privately which we're also in the process of going through, so expect a revision later today I hope.

  • 06 Nov 2018 5:10 PM
    Reply # 6892021 on 6887764

    General Question, should all of the roles be capitalized, Product Owner vs. product owner, etc…?

    Page 1

    Rights and Responsibilities Section

    • Could add a bullet for “Self-organize and plan our own work, sign up for tasks we will work on”.  This one is so difficult for organizations to embrace when transforming to agile…

    Page 3


    • First paragraph, 2nd sentence is quite lengthy…could consider using a bulleted list of all the listed Stakeholder types?

    Page 4

    Product Owner

    • Could add into the 3rd bullet that the prioritization of all work includes user stories and technical/enabler stories (if stories are being used) to make it clear that all (material) work should be represented on a backlog or work items list and the PO prioritizes all of the kinds of work represented…
    • You could add a bullet for this role being the one that accepts work as done or not, it looks to me like it is missing.
    • Some guidance on if this is a “full time” position and when it may need to be vs. when it may not would be very valuable.  So often this role gets staffed with someone that is going to allocate x% of their capacity while still doing their “day job”…

    Page 5

    • Figure 4.2., not sure if you will use the higher res version that has the colored line boxes around the team and the stakeholders but in the current one, “stakeholder” blends in like the other roles around it and could easily be missed/misinterpreted.

    Page 7

    Team Lead

    • Similar to the PO, some context about if this is a full time role, can one TL support more than one team concurrently, or can they support 15 teams concurrently ;)!!...
    • Some content about how this role is a new role for organizations/teams adopting agile and how important it is to staff it correctly.  I don’t think anyone has ever seen a “Waterfall Coach”, ok maybe in the US DoD projects, but in all seriousness, this is such a critical role to support teams filled people new to agile and the challenges they face to be coached by someone that has skills and experience vs. a charlatan that is looking for a big bill rate.  Transformations need to choose wisely and in the start of the journey not use this as a landing spot for “senior” employees or the cheapest labor they can find in the market.
    • May also add in that although is may be a critical role to have staffed initially, over time any team member should be able to fill this role as the WoW is known and practiced to a good level of maturity by all…

    Page 8

    Team Lead continued…

    • 2nd bullet could change cooperation to collaboration.  Tiny change but…

    Page 9

    • Obtains resources bullet, looks like an extra word “Ensures” is in there…

    Page 10

    • 1st bullet, bit of conflict with the 3rd bullet on page 7 which notes the AO has the final say as to the arch direction and in the 1st bullet on this page notes the AO is not solely responsible, they lead discussions.  May consider updating.
    • 3rd bullet, “and may even be an enterprise architect” I think this could be confusing as in most organizations (at least those that are somewhat sizable) the EA staff would rarely “work like any other team member, signing up and delivering work related to tasks…”. May consider taking that out or putting in a little context such as in a smaller organization this may be possible?
    • Could add a new bullet or work into one of the others that this role is most often going to identify and write technical stories and they must closely collaborate with the PO to make sure the PO understands the value of mitigating tech risk and therefore prioritizes accordingly.
    • Potential Supporting Roles – could add in some context that when needing one of these types of temporary roles, if the organization is new to agile some agreements will need to be made so that an adequate amount capacity of the person supporting that agile team.  So often there is a disconnect when we need a supporting role to be ready soooo much earlier in the lifecycle (if using one) with agile vs. traditional…

    Page 12

    • Figure 4.4 the center sweet spot… could add in that this 3-way overlap may be quite small initially, but the TL, PO, and AO as well as the entire team needs to strive to keep growing this…

    Page 16

    • Figure 4.5… not for the book but this figure in the latest revision of DA101, Mod 3 still has the old with the PM having a solid line to the TL and dashed to the PO…

  • 04 Nov 2018 7:15 AM
    Message # 6887764
    Scott Ambler (Administrator)

    We just published Chapter 4 and would love to hear your feedback!

© 2013-2019 Project Management Institute, Inc.

14 Campus Boulevard

Newtown Square, PA 19073-3299 USA

Powered by Wild Apricot Membership Software