Disciplined Agile

To attend Mark’s DAD webcast, register online

I was recently asked a question around the scope of the DAD lifecycle and thought that I would share my answer publicly.

The focus of DAD is the delivery portion of the solution lifecycle, from initiation to delivery into production (or the marketplace in the case of a commercial product).  Any given solution will go through the delivery portion of the lifecycle many times during it’s existence as releases are put into production.

BUT, this isn’t the entire solution lifecycle as you in the following figure.  For example:

1. There are some portfolio management activities before a project starts such as project identification and selection that are outside the scope of DAD.  We show this as input into the DAD lifecycle to help provide context.
2. There are also post-delivery activities, particularly operations and support, that are part of the overall solution lifecycle but outside of the delivery portion of the lifecycle.  In DAD we explicitly show feedback coming back from the production portion of the solution lifecycle because this is a common occurrence.

Note that these comments apply to both the basic (Scrum-like) version of the lifecycle as well as the advanced/lean version.  Because DAD explicitly recognizes that your process improvement activities will include changes that affect the lifecycle, we don’t enforce a single DAD lifecycle.

There are some differences as well as some similarities when comparing agile adoption to agile transformation.  Which does the DAD book address?  One or the other, or both?  I know that I have my opinion, but I am interested in yours.  Add your comments and let us know what you think.  Then we can discuss.

I think that this blog has been quite successful in getting the word out about Disciplined Agile Delivery (DAD) and describing key aspects of the toolkit in advance of the book being released.  However, now that the book is out, it makes sense to evolve the blog into a forum for deeper discussions about DAD.  Scott and I would also like to use it as a medium to answer detailed questions about anything from the book.

Anyone who supports DAD is encouraged to become a contributor to be able to blog a new topic for discussion.  If you wish to become a contributor, send me a note at [email protected]

If you don’t wish to become a contributor directly but have a DAD question, send the question to me and I will post it for discussion.  Thanks!

As you can see from the above diagram, the primary roles of Disciplined Agile (DA) teams are similar to those of Scrum.  In Scrum, the product owner decides what will be built and in what order.  In DA we recognize that architecture is a key source of project risk and someone needs to be responsible for ensuring the team mitigates this risk.  As a result, DA explicitly includes Agile Modeling’s role of architecture owner. The architecture owner is the person who owns the architecture decisions for the team and who facilitates the creation and evolution of the overall solution design.  The person in the role of team lead will often also be in the role of architecture owner, assuming they have the skills and capacity to fill both.  This isn’t always the case, particularly at scale, but it is very common for smaller agile teams.

The responsibilities of the architecture owner include:

• Guiding the creation and evolution of the architecture of the solution that the team is working on.  Note that the architecture owner is not solely responsible for the architecture, but that they lead the technical discussions.
• Mentoring and coaching other team members in architecture practices and issues.
• Working closely with the Enterprise Architecture team, and often being a member of it, to understand and evolve the architectural direction and standards of your organization.
• Ensuring that the team adheres to the architectural direction and standards of your organization.
• Understanding existing enterprise assets such as frameworks, patterns, subsystems and ensuring that the team uses them where appropriate.
• Ensuring that the solution will be easy to support by encouraging good design and refactoring to minimize technical debt.
• Ensuring that the solution is integrated and tested on a regular basis, ideally via the practice of continuous integration(CI).
• Having the final say regarding technical decisions, but they try to avoid dictating the architectural direction in favor of a collaborative, team-based approach. The architecture owner should work very closely with the team lead to identify and determine strategies to mitigate key project technical risks.
• Leads the initial architecture envisioning effort at the beginning of the project and supports the initial requirements envisioning effort (particularly when it comes to understanding and evolving the non-functional requirements for the solution).

One of the key reasons for having this role in DA is that the architecture owner, like the product owner, has a say in work items that are added and prioritized in the work item list (backlog in Scrum parlance).  While business value is certainly a prime determinant of priorities, completing work related to mitigating technical risks is also important.  Additionally, in DA the aim is to deliver consumable solutions, not just working software.  As such, sometimes it is necessary to add work items that are technical in nature, for example related to error logging/monitoring.  Or perhaps work items need to be added to improve the continuous integration and deployment processes.

We have found that the concept of having both product and architecture owners ensures that the solution addresses both functional and quality requirements such as usability and supportability adequately.  In fact, on my current project, I worked with the product and architecture owners to negotiate their priorities such that the iteration underway includes not only a selection of high priority stories, but also a set of technical work items related to hardening the solution in preparation for entering the Transition phase of delivering the solution to the stakeholders.  Without a specific role of architecture owner, it can be difficult to escalate important technical work into the work item list.  As a result it is often done subversively without the knowledge of the product owner which is not a healthy practice, or worse it never gets done resulting in a poor quality solution.

Scott has written a good article that describes the architecture owner role in more depth.  You can view it here.