Category Archives: DAD roles


On August 8th I facilitated a workshop at Agile 2018 that focused on agile architecture. I promised everyone, we had over 150 people in the workshop, that I would post the pictures of their strategy canvases online so that they Read more…


One of the age-old debates in the software world is whether software architects need to write code.  We suspect that as an industry we’ll never reach consensus on this topic. Here are our thoughts on the subject. Short Answer: Hell Read more…


We are often asked what makes a Disciplined Agile (DA) coach effective.  The features to look for in a DA coach include: People skills.  First and foremost, effective DA coaches need solid people skills.  They need to be prepared to work with Read more…


Recently on the Disciplined Agile Delivery LinkedIn discussion group we talked about how people in an existing traditional role fit into a disciplined agile team.  The challenge is that in organizations new to agile will have people who take on traditional roles such Read more…


The Team Lead Role in an organization that is performing Software Development using DAD is the most influential role and the role can be both challenging and fun.  You do not need to be a technical expert to be a Read more…


The Disciplined Agile (DA) toolkit suggests a robust set of roles for agile solution delivery.  These roles are overviewed in the following figure: For a detailed description of these roles, please visit the page Roles on DAD Teams.


As you can see from the above diagram, the DAD primary roles are similar to those of Scrum.  In Scrum, the product owner decides what will be built and in what order.  In DAD we recognize that architecture is a Read more…


Why does DAD not have an explicit role for an Analyst?  This is a hot topic for those in this profession, and a subject that I have been asked to talk on, notably for the IIBA.  Without question classically trained Read more…


Mainstream agile methods would suggest that we should have one product owner, being the “one” voice of the customer for matters related to release/iteration scope, priorities, and requirements clarification. The reality that I see on most enterprise agile projects is Read more…

Categories

Archives