The changes we’ve made to this process goal include:
We’ve updated Choose Your WoW! to include this release of the Explore Scope process goal. We will soon be updating Introduction to Disciplined Agile Delivery (DAD) 2nd Edition and An Executive’s Guide to Disciplined Agile, so if you have Kindle versions of these books expect updates to come through soon.
We have recently published a new Inception process goal, Develop Initial Test Strategy. The potential need for this goal was identified a little over a year ago by an organization that we were actively working with and since then we have worked with several other organizations where it was also clear that this process goal was needed.
The basic idea is that during the Inception phase the team should consider developing an initial test strategy so as to identify how they will approach verification and validation. This includes thinking about how you intend to staff your team, organize your team, capture your plan, approach testing, approach development/programming, choose a platform for test environment(s) platform, choose a platform equivalency strategy, test non-functional requirements, automate test suites, obtain test data, automate builds, report defects, and govern your quality efforts. The goal diagram is depicted in Figure 1 and the update goals overview for Disciplined Agile Delivery (DAD) is shown in Figure 2.
Figure 1. The goal diagram for Develop Initial Test Strategy.
Figure 2. The process goals diagram for DAD.
The Disciplined Agile process decision toolkit is guided by the following principles:
IT departments are unique, complex adaptive systems. Anyone working in such environments needs a process framework that is sufficiently flexible to address the range of situations faced by your teams. The Disciplined Agile process decision framework is light-weight yet sufficiently flexible to support scaling at both the tactical and strategic levels.
This posting, the latest in a series focused on a disciplined agile approach to release management, overviews the activities associated with release management. The Disciplined Agile (DA) toolkit promotes an adaptive, context-sensitive strategy. The framework does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique. In this blog we present the goal diagram for the Release Management process blade and overview its process factors.
The following process goal diagram overviews the potential activities associated with disciplined agile release management.
The process factors that you need to consider for release management are:
Release Management and DevOps
Release management is an important part of your Disciplined DevOps strategy. Having said that, many IT departments are still in their early days of adopting a DevOps approach yet still effective release management. The implication is that the way that you approach release management will vary depending on how far down the DevOps adoption path you are. For example, with no DevOps in place at all your release management activities are likely to be performed by a team that is completely separate from your IT delivery teams. When you are in the process of adopting a DevOps mindset release management is likely to be a collaborative effort between the IT delivery teams and the release management team. When you have fully adopted DevOps strategies release management is mostly performed by the delivery teams themselves.
This posting, the latest in a series focused on a disciplined agile approach to enterprise architecture (EA), overviews the activities that a disciplined agile EA team may perform. Some methods will choose to prescribe a single approach, such as capturing architectural requirements in the form of epics or pre-building “architectural runways,” but the Disciplined Agile (DA) toolkit promotes an adaptive, context-sensitive strategy. DAD does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique. In this blog we present the goal diagram for the Enterprise Architecture process blade and overview its process factors.
The following diagram overviews the potential activities associated with disciplined agile enterprise architecture.
The process factors that you need to consider for enterprise architecture are:
Our next blog posting will describe the workflow of enterprise architecture with other key IT activities such as portfolio management, reuse management, and IT delivery teams.