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 tool kit 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.
There is no such thing as a “best practice”, except perhaps from a marketing point of view. All practices (and strategies) are contextual in nature. In some situations a practice works incredibly well and it other situations a practice can be the kiss-of-death. Two of the philosophies behind the Disciplined Agile (DA) tool kit are that choice is good and that you should understand the trade-offs of the options available to you. In short, practices are contextual in nature and you should strive to adopt the ones that work best for the situation that you find yourself in.
Let’s work through an example. A hot button for many people are strategies around cost estimation, typically used for budgeting and forecasting purposes. In DAD initial estimation is addressed by the Plan the Release process goal, the goal diagram for which is shown below. As you can see with the Estimating Strategy factor there are several options available to you. We’re not saying that these are all of the potential estimating options available, but we are saying that this is a fairly good representative range. The arrow on the left-hand side of the strategies list indicates that the strategies towards the top of the list are generally more effective for initial planning than the strategies towards the bottom of the list. Your mileage may vary of course.
The following table summarizes the trade-offs involved with two of the estimating strategies, in the case formal point counting (such as function points) and an educated guess by an experienced individual. One of the reasons why Choose Your WoW! is so thick is that much of it is tables like this communicating the trade-offs of the hundreds of practices and strategies encapsulated by the toolkit. As you can see, there are advantages and disadvantages to both strategies. You can also see that there are situations where each strategy potentially makes sense. Although you may not like a given strategy, I personally abhor formal point counting, you should still respect the fact that the strategy is viable in certain situations (perhaps not yours).
There are several reasons why DAD’s goal-driven approach is important:
For a more detailed discussion about the challenges around “best practices”, you may find the article Questioning Best Practices to be an interesting read.