Category Archives: Goal-Driven

New goal: Develop Initial Test Strategy

Fire works

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.
Develop Initial Test Strategy

Figure 2. The process goals diagram for DAD.

Process Goals of Discipined Agile Delivery

Update: Identify Risks goal

Update

We’ve updated the goal diagram for Identify Risks, an Inception Phase goal.  The new version of the diagram is follows, as does a summary of the changes that we made and the previous version of the diagram.

The New Version of the Goal Diagram

Identify Risks

We made the following changes to the diagram:

  1. Introduced the Identify Risks process factor.  This factor came about from our observation at several organizations that teams go about identifying risks via several techniques, so we decided to explicitly call them out.  Yes, this name can be a bit confusing seeing as it’s the same as the goal name.
  2. Introduced the Classify Risks process factor.  There are several ways that risks can be classified.  We’ve added qualitative risk analysis (something we’ll blog about in the future) as well as options for quantitive analysis for teams working in situations where sophisticated analysis is warranted – our advice is always to keep it as simple and light-weight as possible.
  3. Updated the Capture Risks process factor.  We added Risk register/database as an option after seeing several organizations use reasonably sophisticated tooling to track their risks.  Please note that Capture Risks was originally Documentation Strategy.
  4. We renamed the process factors to begin with a verb.  This is something that we’re doing with all goal diagrams.  So for example, Risk Views became Explore Risks and Level of Detail became Document a Risk.
  5. We removed the “None” options. Our new style is to only indicate None as an option when not doing something is an important choice, particularly in an organization that is early in its transition to agile ways of working.

 

The Previous Version of the Goal Diagram

Identify Risks

Update: Form Initial Team

Update

We’ve updated the goal diagram for Form Initial Team, an Inception Phase goal.  The new version of the diagram is follows, as does a summary of the changes that we made and the previous version of the diagram.

The New Version of the Goal Diagram

Form the Initial Team

We made one change to this diagram: We added the process factor Team Evolution Strategy to indicate that there are different ways to evolve a team once it’s been initiated.  One thing that we did not do to this diagram is to rename the process factors to begin with a verb.  In the case of this process goal most of the verbs would be “Identify” or “Select” so we felt this would add clutter more than it would clarify.

The Previous Version of the Goal Diagram

Form the Initial Team

Update: Move Closer to a Deployable Release

Update

We’ve updated the goal diagram for Move Closer to a Deployable Release, a Construction Phase goal.  The new version of the diagram is follows, as does a summary of the changes that we made and the previous version of the diagram.

The New Version of the Goal Diagram

Move Closer to a Deployable Release

We made the following changes to the diagram:

  1. We renamed the process factors to begin with a verb.  This is something that we’re doing with all goal diagrams.
  2. We removed several of the “None” options. Our new style is to only indicate None as an option when not doing something is an important choice, particularly in an organization that is early in its transition to agile ways of working.
  3. Introduced Maintain Traceability.  Used to be lumped into Asset Management (now Manage Assets).  Generating the traceability from test code is a fairly common strategy for teams following an ATDD/BDD approach to requirements specification and TDD to design specification (with a test-first/driven approach traceability is a side effect).
  4. Indicated that Manage Assets options are ordered.  The strategies towards the top of the list are generally more effective that the strategies towards the bottom.

 

The Previous Version of the Goal Diagram

Move Closer to a Deployable Release

Update: Secure Funding

Update

We’ve updated the goal diagram for Secure Funding, an Inception Phase goal.  The new version of the diagram is follows, as does a summary of the changes that we made and the previous version of the diagram.

The New Version of the Goal Diagram

Secure Funding
We made the following changes to the diagram:

  1. We renamed the two process factors to begin with a verb.  Funding Strategy is now Choose Funding Strategy and Access Strategy is now Access Funds.
  2. We renamed the T&M plus performance bonus to Cost plus, the colloquialism for that strategy.
  3. We added Charge by feature as an option to fund an effort.

The Previous Version of the Goal Diagram

Secure Funding

Update: Explore Initial Scope

UpdateWe’ve updated the goal diagram for Explore Initial Scope, an Inception Phase goal.  The new version of the diagram is follows, as does a summary of the changes that we made and the previous version of the diagram.

The New Version of the Goal Diagram

Explore Initial Scope
We made the following changes to the diagram:

  1. Renamed several process factors so that they would start with a verb.  For example, Level of Detail was renamed Choose the Level of Detail.  This is basically a style issue that we will be applying going forward.
  2. The biggest change is that we split the factor View Types into Explore Usage, Explore the Domain, Explore the ProcessExplore User Interface (UI) Needs, and Explore General Requirements.  We want to make the model type options clear as many people found View Types to be too abstract of a concept.
  3. We reworked the options for Apply Modeling Strategy to be clearer – Informal modeling sessions became Agile modeling (informal) sessions and Formal Modeling Sessions became Joint Application Requirements (JAR) sessions.
  4. In Choose the Level of Detail the “None” option was reworded to “No Models” to a make this more explicit.

The Previous Version of the Goal Diagram

Explore Initial Scope

Update: Identify Initial Technical Strategy Goal

The past few months we’ve been queuing up potential updates to several goal diagrams, updates that we are now applying.  Over the next week or so we will be releasing these updates to the site.  The first goal that we are updating is Identify Initial Technical Strategy, an Inception Phase goal.   The new version of the diagram is follows, as does a summary of the changes that we made and the previous version of the diagram.

The New Version of the Goal Diagram

Identify Initial Technical Strategy
We made the following changes to the diagram:

  1. Renamed several process factors so that they would start with a verb.  For example, Level of Detail was renamed Choose the Level of Detail.  This is basically a style issue that we will be applying going forward.
  2. The biggest change is that we split the factor View Types into Explore Technology Architecture, Explore Business Architecture, Explore User Interface (UI) Architecture, and Consider the Future.  We want to make the model type options clear as many people found View Types to be too abstract of a concept.
  3. We reworked the options for Apply Modeling Strategy to be clearer – Informal modeling sessions became Agile modeling (informal) sessions and Formal Modeling Sessions became Joint Application Design (JAD) sessions.
  4. In Choose the Level of Detail the “None” option was reworded to “No Models” to a make this more explicit.

The Previous Version of the Goal Diagram

Identify Initial Technical Strategy v2

 

Principles for Effective Software Process Frameworks

Principles

The Disciplined Agile process decision framework is guided by the following principles:

  1. Choice is good, and making informed choices is better.  Every team is a collection of unique individuals that face a unique situation within the context of a unique organization. One process size does not fit all. To provide choice the DA framework supports several delivery lifecycles and is process goal driven. Most importantly the DA framework describes the tradeoffs involved with a myriad of agile and non-agile practices enabling people to make intelligent decisions regarding which practices to adopt given the current situation that they face.
  2. Optimize the whole. The DA framework addresses the full IT lifecycle, showing how it all fits together. Without an understanding of the larger process environment teams run the risk of locally optimizing their own processes to the detriment of the whole. For example, your data management team may have their own streamlined process based on traditional DAMA strategies, your delivery team may have their streamlined process based on the principles of the Agile Manifesto, and your operations team may have their streamlined process based on ITIL. Yet your overall process is ineffective because these three locally optimized strategies contradict and degrade one another when combined.
  3. Every team owns its process. Teams, and the individuals on them, must be free to improve the way that they work based on their learnings over time. In agile parlance we say that these teams “own their process”.
  4. Improve continuously. Individuals, teams, and organizations must strive to continuously learn and improve the way that they work. The DA framework includes the process goal Improve Team Process and Environment which describes options for doing exactly what its name implies. It also has an explicit process blade Continuous Improvement that describes strategies for sharing improvements across teams, thereby speeding up your organization’s process improvement efforts.
  5. Embrace process change. IT departments are complex adaptive systems. One implication of this is that any improvements that a team makes may change the way that they work with other teams, motivating process improvements within those teams. Those changes may motivate improvements within other teams and so on. Disciplined agile teams are enterprise aware and understand that they will need to work with other teams to help them to understand and adopt new innovations, and be prepared to be helped by others to do the same.
  6. Repeatable results are far more important than repeatable processes. Effective teams focus on producing repeatable results, such as delivering high-quality software that meets stakeholder needs in a timely and cost effective manner.  Because each team finds themselves in a unique situation, to be most efficient they need to follow a unique process tailored to reflect that situation.  That “unique process” may be comprised of a relatively standard lifecycle and common practices such as architecture envisioning, database regression testing, non-solo development, and many others (granted, those practices may be tailored to reflect the situation too).  Each team in your organization must be allowed to follow their version of the process, ideally sharing similar process components defined by a common process framework, to achieve the results required of them.
  7. Empiricism is far more important than theory. Observing how well a technique works in practice, and more importantly the context of the situations in which it (doesn’t) work is far more valuable to practitioners than theories or prognostications about what should work. Theory has its place, but it is a poor cousin to empiricism. The DA framework was originally developed based on observations of dozens of organizations worldwide, and has evolved since then based on learnings from many more. Furthermore it is backed up by our ongoing industry research.

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.

Translations

Disciplined Agile Release Management: A Goal-Driven Approach

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) framework 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.

Release Management Goal Diagram

The process factors that you need to consider for release management are:

  1. Plan IT release schedule.  Your organization’s overall release schedule needs to be planned and communicated.  Many organizations have blackout periods where teams are not allowed to deploy into production (for example, many retail organizations will not allow non-critical production releases near the Christmas holidays).  There are many strategies that organizations may choose to adopt when it comes to scheduling releases, including release trains, release streams, ad-hoc releases, and release windows.
  2. Schedule solution release.  The release of an individual delivery team’s work needs to be scheduled so that it does not conflict with the releases of other teams who want to deploy into the same operational environment.
  3. Manage infrastructure configuration.  The release management team will work closely with your operations team, in fact they are often members of your operations team, to perform configuration management of your operational environment.  To safely deploy into production you must know what is currently in production and how those hardware and software elements depend on each other.  The more complex your operational infrastructure, and the more IT delivery teams you have, the more important this process factor becomes.
  4. Determine production readiness.  Part of the release process is to verify that the solution is ready to be deployed and that the stakeholders are ready to have it deployed to them.  The bigger and more infrequent your releases, the more this becomes an issue.
  5. Support delivery teams.  The release management team, when a separate one exists, will work closely with the IT delivery teams to help them deploy successfully.  This help may take the form of coaching the team on deployment techniques, on planning, and even working with them to automate their deployments.  The release management team will often help with deployment testing, the verification after the fact that a deployment was in fact successful.
  6. Govern releases.  Your organization’s overall release efforts should be governed, ideally with the aim to streamline those efforts as much as possible.  This governance will include the development of policies and guidelines pertaining to the release process as well as the identification and collection of pertinent metrics.

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.

 

Related Postings

Disciplined Agile Enterprise Architecture: A Goal-Driven Approach

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 Delivery (DAD) framework 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.

Disciplined Agile Enterprise Architecture

The process factors that you need to consider for enterprise architecture are:

  1. Support stakeholders. Enterprise architects will work with business and IT stakeholders on a regular basis to understand their needs and to help them develop a vision for the organization.
  2. Support delivery teams.  Enterprise architects will work with IT delivery teams, and ideally be active members of IT delivery teams, on a regular basis.  They may guide the teams in the business and technical roadmaps, help them to identify potentially reusable assets, to identify technical debt, and transfer their skills and knowledge to team members.
  3. Negotiate technical dependencies.  Like it or not, there are dependencies between the solutions that we create.  For example, if your system invokes a web service, or calls an API, provided by another system then you have a dependency on that system.  Enterprise architects will often find that they need to negotiate these dependencies with other teams, either at a high-level in their role of Enterprise Architect or sometimes at a detailed level in their role of Architecture Owner on a delivery team.
  4. Tailor architectural framework.  The enterprise architecture team may choose to adopt, and likely tailor, an existing enterprise architecture framework.  These frameworks typically suggest a multi-view collection of artifacts to create and techniques for doing so.
  5. Explore architectural views. Organizations are complex and as a result they must be understood from a variety of view points.  It’s not just a matter of writing “architectural epics” on a collection of index cards.
  6. Evolve enterprise architecture. Enterprise architects will collaborate with one another, and with their stakeholders, in a variety of ways.  They may choose to hold architecture envisioning/modeling sessions or regular meetings where they share learnings with one another.  They will often work together, or with IT delivery teams, to investigate new technologies or identify candidate architecture strategies.
  7. Evolve roadmap(s). An important output of your enterprise architecture effort will be one or more roadmaps describing your technology strategies and/or your architectural strategies. In agile organizations this roadmapping occurs in a rolling wave approach where the roadmap(s) are updated regularly.
  8. Capture enterprise architecture.  There are two broad categories for how enterprise architects can capture their work: as documents or as working/executable examples.  High-level models work well for documentation, although sometimes you may find the need for detailed documentation as well.  Executable artifacts, such as executable reference architectures or architectural runways, are usually preferred over documentation by delivery teams.
  9. Govern architecture. Architectural activities within your organization should be governed in a lightweight, collaborative manner.  This is an important activity for enterprise architects as well as for your IT governance team.

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.

Related Readings