Archive
Recording of InformationWeek webcast on DAD available
The recording of my 1-hour InformationWeek webcast on DAD is available here:
DAD webcast for InformationWeek
I will be doing a webcast on DAD for InformationWeek on Tue, July 10 at 10:00 PDT. If you are interested you can register here.
YouTube video interviewing Scott on the DAD book
This short video of an interview with Scott on the Disciplined Agile Delivery (DAD) book is worth the look:
Does DAD address Agile Transformation or Adoption?
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.
Taking the DAD blog to the next level
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 framework 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 Mark@UPMentors.com
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!
The DAD Role of Architecture Owner
As you can see from this 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 key source of project risk and someone needs to be responsible for ensuring the team mitigates this risk. As a result the DAD process framework 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. 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.
- Understanding the architectural direction and standards of your organization and helping to ensure that the team adheres to them appropriately.
- 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 DAD 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, a DAD goal 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 non-functional 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 as 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.
DAD Book Launch at Innovate 2012 in June
We are thrilled to confirm that our new book “Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise” will be launched at the IBM Innovate conference in Orlando June 3-7. It will be a busy week with the following events planned:
Scott will be co-delivering the Agile Transformation track keynote on Tuesday morning with Scott Rich, the development leader of the Jazz team. That afternoon he will be a participant at the Agile and Systems goldfish bowl. Wednesday morning Scott will be delivering his Disciplined Agile Delivery and DevOps talk and then in the afternoon giving an overview of Agile Modeling and Documentation strategies. Throughout the conference Scott will be meeting with customers, contact your IBM sales rep if you want to organize such a meeting, and doing several press interviews.
On Wednesday Mark will be speaking on “Disciplined Agile Delivery: Adoption in the Trenches”. On Monday he will be on the “Agile Coaching 101 Panel” with agile/lean thought leaders such as Mary Poppendieck. Mark will also be at the Canadian reception Monday night at Blue Zoo.
Mark & Scott will also be doing a book signing on Wednesday at the bookstore.
If you miss the signing and want a book signed, try the Agile Transformation Zone in the Exhibit Hall. There is a good chance that you will find us there, comparing notes with other agilists and discussing the challenges of disciplined agile adoption in the enterprise.
It promises to be a fun week, with the party at Sea World and the band Foreigner playing. We hope to see you there!
Being Goal-Driven Requires Discipline
The DAD process framework uses a goal-driven approach as we illustrate in Figure 1 below. Throughout our book we described each of the DAD phases in turn and suggested strategies for addressing the goals of that phase. For each goal we described the issues pertaining to that the goal. For example, in Chapter 10 when we discussed initial project planning we indicated that you need to consider issues such as the amount of initial detail you intend to capture, the amount of ongoing detail throughout the project, the length of iterations, how you will communicate the schedule (if at all), and how you will produce an initial cost estimate (if at all). Each issue can be addressed by several strategies, each of which has trade-offs. Our experience is that this goals-driven, suggestive approach provides just enough guidance for solution delivery teams while being sufficiently flexible so that teams can tailor the process to address the context of the situation in which they find themselves in. The challenge is that it requires significant discipline by agile teams to consider the issues around each goal and then choose the strategy which that is most appropriate for them.
Figure 1. Goals addressed throughout a DAD project (updated).
Since the book was published in June 2012 Mark and I have made a few minor refactorings to the DAD goals to increase their consumability. Figure 2 presents the goals as they were originally described in the book, whereas Figure 1 shows our refactoring. As you can see there has been a few minor rewordings but the actual content remains effectively the same. We apologize for any confusion, but process improvement happens. 
Figue 2. Goals addressed throughout a DAD project (original as published in the DAD book).
DAD lays out a set of milestones across the lifecycle that are common across most projects regardless of what agile practices you use. It takes discipline to use a goal-driven approach to reach those milestones. This means that you do not use a cookbook approach to deliver your solutions but rather adapt your techniques to follow the path that is best suited to you. Prescriptive guidance and rules are common in many agile methods and people can easily fall into a trap of doing exactly what is dictated by a particular method without challenging how appropriate it is for their own situation.
