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.

This may of course be heresy in some organizations.  The danger with “repeatable processes” is that they grow in size over the years to address all possible situations, and as a result address none of them very well.  Imagine a project team that is large and has regulatory compliance concerns.  This team will tailor its practices accordingly.  Now imagine a small team that doesn’t have to address regulatory concerns.  An organization focused on repeatable processes might have that team follow the same process that the previous team followed, even though some of the practices had been tailored to meet scaling factors that don’t apply.  In other words, the repeatable process included some aspects that were overkill for the second team, thereby impacting their ability to deliver in a timely manner or in a cost efficient manner.  In the vast majority of organizations, when given the choice, stakeholders prefer to spend the money wisely and have the solution delivered in a timely manner, not to have the team follow a consistently “repeatable process.”

1. Pre-delivery activities.  There are portfolio management activities which occur long before your project begins, including the initial identification of potential projects, their prioritization, and finding initial funding for the Inception phase.
2. Three-phase delivery lifecycle.  Projects have phases that they go through.  All efforts are initiated at some point, all of them go through a construction effort (or a configuration effort in the case of purchased solutions), and hopefully some sort of deployment effort.  This is why the DAD lifecycles include explicit Inception, Construction, and Transition phases to respectively address these aspects.  I’ve confirmed via surveys that the average agile team invests about a month in project initiation/inception activities, often referred to as Sprint 0 or Iteration 0, as well as about a month performing release/transition activities.  From a product point they will go through at least the Construction and Transition phase many times throughout the life of the solution.
3. Post-delivery activities.  The fact that your solution is operated and supported in production, or in the marketplace for commercial products, is included.  We do this to reflect the DevOps reality many DAD teams are in the position that they are working on a new release of an existing solution, and therefore are very likely to be getting defect reports and enhancement requests coming in about previous versions.  As a result they require the discipline to treat these things as potential new requirements and act accordingly.

Without a doubt construction is an important aspect of the overall Disciplined Agile Delivery process, but it’s not the only aspect.  Yes, for many people this is the fun part of delivery, it certainly is for me.  But the reality is that as development professionals we need to explicitly consider more than just construction if we’re to be effective.  It takes discipline to adopt a broader lifecycle that goes beyond the fun stuff that we would prefer to focus on.

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!

Goals addressed throughout a DAD project.

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.

Are you guys able to quote any studies in your book on the increase in effectiveness that can be achieved by establishing permanent dedicated cross-functional teams as opposed to teams that get torn down and re-assembled for each project? I am looking for a solid industry study that is widely excepted. Our company currently has a mix of both types of teams and I am looking for some industry data to compare against.

regards,

Bob

The presentation shares his experiences of using DAD practices to enable his clients to achieve agility in their software delivery, even when their projects are large, complex and distributed.

To find out more and to register visit the Rational User Community site.

• Working software that is “done”.  Your software should be tested to the best of your ability.  Ideally this includes pre-production integration testing and acceptance testing of the functionality delivered to date.  The software should not only fulfill the functional requirements but appropriate non-functional requirements (NFRs) as well.  Some of this testing may require the help of an independent test team, particularly at scale.
• Continuous documentation.  Deliverable documentation, such as operations and support, system overview, and end user documentation are part of your overall solution. Evolving this documentation in sync with the software requires greater discipline than simply leaving this documentation to the end of the lifecycle.
• Consumability. Your solution should be more than potentially shippable, it should also be consumable.  This requires investing some effort in user experience (UX) design throughout the lifecycle, particularly early in the project.
• Organizational change.  The business processes around using your system, and potentially even the organizational structure of the stakeholders involved with it, may need to evolve.  The implication is that your team needs the discipline to recognize and explore these issues throughout the project so that your stakeholders are prepared to receive your solution.
• Operations and support issues.  Your solution should be consumable by all stakeholders, not just end users.  Your operations and support staff should be able to work with the solution efficiently.  To understand these needs your team needs the discipline to work closely with operations and support staff throughout the lifecycle, an important aspect of your overall DevOps strategy.

1. Non-solo development.  Non-solo development strategies such as pair programming and modeling with others provide feedback within seconds.  These techniques are great strategies for reducing the feedback cycle within your team but they often require initial discipline to adopt because it can be difficult to break your former solo working habits.
2. Active stakeholder participation.  It can require significant discipline to work closely with your stakeholders, to seek and then respect their opinions, and to allow them to set important aspects of your project direction.  Working closely with stakeholders typically has a feedback cycle on the order of seconds when they are co-located with your to hours or days when you need to wait to interact with them.
3. Continuous integration.  Building, regression testing, and potentially running your work through code analysis on a continuous basis is a fairly straightforward concept which provides feedback on the order of minutes.  Doing it in practice, and more importantly the habit acting on the feedback provided from the tests and code analysis requires discipline to adopt at first because you often want to work on the next thing instead of cleaning up the work on what you’re currently doing.
4. Continuous deployment. By regularly deploying into more complex environments – to your project integration environment from your individual environment, from your project environment to your demo or independent testing environments – you put yourself in a position to receive more meaningful feedback.  Continuous deployment requires you to have the discipline to have multiple environments, to work with people external to your team (such as stakeholders and independent testers), and to seek and act on their feedback.
5. Short iterations. The length of an iteration defines the feedback cycle between promising your stakeholders you would do a bundle of work, the end result of your iteration planning session, to demonstrating what you actually got done.  It requires significant discipline to work in short iterations.  The average agile team has construction iterations of two weeks, although some teams have shorter iterations and some advanced teams have evolved beyond iterations to take a lean approach.  Then again some agile teams, particularly those at scale, may have slightly longer iterations.  The shorter the iteration the greater the discipline required to make it work because you will need to adopt many, if not all, of the techniques listed in this section.  You will also require the discipline to identify, and then address, wasteful activities that add little or no value in your current process.
6. Short release cycles.  The length of your release cycle defines the feedback cycle from promising stakeholders to deliver a new release of a solution to actual use by end users in production.  The feedback from real users is the key information to determine if you’ve delivered the right thing for them.  All other stakeholder feedback is merely an approximation up until that point.  As with short iterations, it requires increasing discipline to move from annual to bi-annual to quarterly to monthly to weekly or even daily releases into production.

This posting was modified from Chapter 21 of the forthcoming book Disciplined Agile Delivery to be published in June by IBM Press.

• Hold short, focused, and to the point daily coordination meetings rather than infrequent and time consuming status meetings.  It requires discipline to keep these meetings focused on coordination activities and thereby short and to the point.
• Commit to delivering a set of work items each iteration rather than letting deadlines slip.  It requires discipline to consistently fulfill the promises that you make to your stakeholders.
• Remove impediments in a timely fashion rather than procrastinating in pursuing a solution.  It requires discipline to tackle tough issues that are easier to ignore in the short term.
• Take the time to write tests before code rather than writing code,  It takes discipline to consistently work in a test-first manner instead of leaving testing to some time in the (distant) future.
• Test to the best of their ability instead of throwing artifacts over the wall to testers or reviewers.  It takes discipline to actively take responsibility for the quality of your own work.
• Reflect on the team’s experiences and improve their processes proactively rather than relying on process dictated by project managers or external governance bodies.  It takes discipline to stop and take time to reflect on how well your team is working and then act to improve it.
• Have a continuously working, integrated, and tested solution rather than waiting to do so when you’re “done” at the end of the lifecycle.  It takes discipline to stop all work when the build is broken so that it is repaired and the state of working, high quality solution is restored.
• Work together in a common area rather than in comfortable but isolated workspaces. It takes discipline to work effectively in a team, to do so in a respectful and trusting manner.
• Collaborate constantly with the stakeholders or their representative(s) to ensure that their expectations are met.  It takes discipline to accept that it isn’t your place to define the requirements or set priorities, particularly when you believe that you know better.
• Create and evolve deliverable documentation continuously throughout the project.  It takes discipline to accept that there’s more to successfully solution delivery than producing potentially shippable software.
• Self organize and plan the team’s work amongst themselves rather than relying on a traditional project manager to define, estimate, and assign work. It takes discipline to take responsibility for your own work and to respect the collective decisions of your team.

In our next few blogs we’ll discuss how Disciplined Agile Delivery builds on these practices to take discipline to the next level within the Enterprise.