Project Management

Disciplined Agile

by , , , , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog

RSS

View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes
Kashmir Birk
Klaus Boedker
Mike Griffiths

Recent Posts

The Disciplined Agile Enterprise (DAE) Layer

Disciplined Agile (DA)'s Value Streams Layer

The Disciplined DevOps Layer

Would you like to get involved with the 20th Anniversary of Agile?

The Four Layers of the Disciplined Agile Tool Kit

Strategies for Capturing Quality Requirements

Agile modeling

Quality requirements, also known as non-functional requirements (NFRs), quality of service (QoS) or technical requirements, address issues such as reliability, availability, security, privacy, and many other quality issues.  The following diagram, which overviews architectural views and concerns, provides a great source of quality requirement types (the list of concerns).  Good sources for quality requirements include your enterprise architects and operations staff, although any stakeholder is a potential source for them.

Figure 1. Architectural views and concerns.

Architecture Views and Concerns

 

Why Are Quality Requirements Important?

Stakeholders will describe quality requirements at any time, but it’s particularly important to focus on them during your initial scoping efforts during Inception as you can see in the goal diagram below for Explore Initial Scope.  Considering quality requirements early in the lifecycle is important because:

  1. Quality requirements drive important architecture decisions. When you are identifying your architecture strategy you will often find that it is the NFRs that will be the primary drivers of your architecture.
  2. Quality requirements will drive some aspects of your test strategy. Because they tend to be cross-cutting, and because they tend to drive important aspects of your architecture, they tend to drive important aspects of your test strategy.  For example, security requirements will drive the need to support security testing, performance requirements will drive the need for stress and load testing, and so on. These testing needs in turn may drive aspects of your test environments and your testing tool choices.
  3. Quality requirements will drive acceptance criteria for functional requirements (such as stories).  Quality requirements are typically system-wide thus they apply to many, and sometimes all of your functional requirements.  Part of ensuring that your solution is potentially consumable each iteration is ensuring that it fulfills its overall quality goals, including applicable quality requirements.  This is particularly true with life-critical and mission-critical solutions.

Capturing Quality Requirements

Figure 2 depicts the goal diagram for Explore Scope.  As you can see, there are several strategies for exploring and potentially capturing quality requirements.

Figure 2. The goal diagram for Explore Scope (click to enlarge).

Explore Scope process goal

 

Let’s explore the three strategies, which can be combined, for capturing quality requirements:

  1. Technical stories.  A technical story is a documentation strategy where the quality requirement  is captured as a separate entity that is meant to be addressed in a single iteration.  Technical stories are in effect the quality requirement equivalent of a user story. For example “The system will be unavailable to end users no more than 30 seconds a week” and “Only the employee, their direct manager, and manager-level human resource people have access to salary information about said employee” are both examples of technical stories.
  2. Acceptance criteria for individual functional requirements.  Part of the strategy of ensuring that a work item is done at the end of an iteration is to verify that it meets all of its acceptance criteria.  Many of these acceptance criterions will reflect quality requirements specific to an individual usage requirement, such as “Salary information read-only accessible by the employee,”, “Salary information read-only accessible by their direct manager”, “Salary information read/write accessible by HR managers”, and “Salary information is not accessible to anyone without specific access rights”.  So in effect quality requirements are implemented because they become part of your “done” criteria.
  3. Explicit list.  Capture quality requirements separately from your work item list in a separate artifact.  This provides you with a reminder for the issues to consider when formulating acceptance criteria for your functional requirements.  In the Unified Process this artifact was called a supplementary specification.

Of course a fourth option would be to not capture quality requirements at all.  In theory this would work in very simple situations but it clearly runs a significant risk of the team building a solution that doesn’t meet the operational needs of the stakeholders.  This is often a symptom of a teams only working with a small subset of their stakeholder types (e.g. only working with end users but not operations staff, senior managers, and so on).

Related Resources

Posted by Scott Ambler on: January 23, 2018 01:17 PM | Permalink | Comments (0)

Should Software Architects Write Code?

Source code
One of the age-old debates in the software world is whether software architects need to write code.  We suspect that as an industry we’ll never reach consensus on this topic. Here are our thoughts on the subject.

Short Answer:

Hell yes!

Detailed Answer:

In the following table we list the advantages, disadvantages, and considerations (when does the strategy makes sense) to compare whether a software architect should write code or not.  You may recognize this approach from our book Disciplined Agile Delivery.

Strategy Advantages Disadvantages Considerations
Software architects also develop
  • Helps to keep the architects grounded
  • Developers are more likely to respect the architects and follow their advice
  • Architects are able to create working examples of their strategies, increasing the usefulness to developers
  • More people with architecture skills are needed to support your development teams (arguably a good thing)
  • Apply when you have an ample supply of people with architecture skills, or at least are willing to invest in developing sufficient people
  • Apply when it is critical that developers build well-architected solutions
Software architects don’t develop
  • Architects can focus on architecture
  • Architects can support multiple delivery teams
  • Developers are far less likely to follow the advice of such architects, effectively forgoing any benefit the architects could have brought to your organization
  • The architects are forced to create less-effective artifacts such as white papers and models, as compared with working reference architectures, due to lack of coding skills
  • When you have very few people in your organization with architecture skills
  • The software architects should pair with others so as to transfer their architecture skills to them, thereby growing the pool of software architects and thus making it more viable to allow the software architects to code

In the Disciplined Agile (DA) toolkit we’ve made it very clear that we expect Architecture Owners to be actively involved with the development of the solution.  On Disciplined Agile teams the Architecture Owner is effectively a team member with additional responsibilities around leading the team through architecture decisions, in coaching them on architecture skills, and in working closely with your Enterprise Architecture team (if any) to ensure their development team understands and is working towards your organization’s technical roadmap.

We’re often told that it isn’t realistic to expect architects to write code.  Invariably this is coming from people who are currently working in traditional IT organizations that have very well-defined roles, IT organizations that more often than not are struggling to be effective.  Our response is always the same – Really?  Are development teams following your architectural strategy?  Are they eager to work with you, or are they forced to work with you?  This generally leads to a discussion that reveals that things aren’t going so well for these architects in practice, and sometimes leads to a positive discussion as to how we can move towards a more effective approach for them.  They kind of approach described in the Disciplined Agile (DA) toolkit.

 

Additional Reading:

 

Posted by Scott Ambler on: February 08, 2016 11:00 AM | Permalink | Comments (0)

How Enterprise Architecture Enables Agile Software Development

Layered Architecture

Enterprise architecture, when performed in a disciplined agile manner, is an important enabler of agile software delivery.  This is true for several reasons:

  1. Common architecture enables agile teams to focus on value creation.  A common enterprise architecture enables reuse across delivery teams.  When agile teams have high-quality assets – such as micro-services, legacy data sources, and frameworks – available to reuse they are able to focus on creating new value for their stakeholders and not on reinventing new versions of existing assets.
  2. Common technical guidance enables greater consistency between teams.  When team follow effective, common conventions it results in greater quality.   This makes it easier to learn about assets that are new to them, in particular existing source code, and to evolve those assets as needed.  Greater consistency also makes it easier for people to move between teams because it will be easier for them to come up to speed on what the new team is doing and to share their skills with those team members.
  3. Agile architectures enable disaggregation.  When your solutions are built from loosely coupled, highly cohesive components it is easier to spread development work across smaller teams.  This reduces overall risk and organizational complexity, which in turn reduces time-to-delivery.  It also allows agile teams to focus on what they’re building instead of coordinating with other teams or mocking out the (undelivered) work of other teams.
  4. Common infrastructure enables continuous delivery.  When there is a common technical infrastructure to IT delivery teams to deploy into it is easier to deploy.  The easier it is to deploy, the more often it makes sense to deploy.
  5. Enterprise architecture scales agile.  A disciplined agile approach to enterprise architecture enables organizations to scale agile strategies “horizontally” across their entire IT department.

The Disciplined Agile Delivery (DAD) 1.x framework purposefully included the philosophy of enterprise awareness, the need for agile delivery teams to look beyond their immediate needs and consider the long-term needs of their organization.  A common example of this is to work closely with your organization’s enterprise architects.  The Disciplined Agile 2.0 framework, which we are incrementally publishing here at DisciplinedAgileDelivery.com, explicitly addresses Enterprise Architecture so that organizations may see how it fits into the overall strategy to build an agile organization.

Posted by Scott Ambler on: July 06, 2015 11:41 AM | Permalink | Comments (0)

Identifying your Initial Architecture Strategy

When a disciplined agile project or product team starts, one of the process goals which they will likely need to address is Identify Initial Technical Strategy. This is sometimes referred to as initial architecture envisioning or simply initial architecture modeling. This is an important process goal for several reasons. First, the team should think through, at least at a high level, their architecture so as to identify a viable strategy for moving forward into construction.  A little bit of up-front thinking can increase your effectiveness as a team by getting you going in a good direction early in the lifecycle.  Second, the team should strive to identify the existing organizational assets, such as web services, frameworks, or legacy data sources, that they can potentially leverage while producing the new solution desired by their stakeholders.  By doing this you increase the chance of reuse, thereby avoiding adding technical debt into your organizational ecosystem, and more importantly you reduce the time and cost of delivering a new solution as the result of reuse.  You will do this by working with your organization’s enterprise architects, if you have any.  This is an aspect of Disciplined Agile’s philosophy of working in an enterprise aware manner.

The process goal diagram for Identify Initial Architecture Strategy is shown below. The rounded rectangle indicates the goal, the squared rectangles indicate issues or process factors that you may need to consider, and the lists in the right hand column represent potential strategies or practices that you may choose to adopt to address those issues. The lists with an arrow to the left are ordered, indicating that in general the options at the top of the list are more preferable from an agile point of view than the options towards the bottom. The highlighted options (bolded and italicized) indicate default starting points for teams looking for a good place to start but who don’t want to invest a lot of time in process tailoring right now. Each of these practices/strategies has advantages and disadvantages, and none are perfect in all situations, which is why it is important to understand the options you have available to you.

Develop Initial Architecture Strategy process goal

Let’s consider each process factor:

  • Choose the level of detail.  How much effort should you put into capturing your architectural strategy, if any at all.  A small co-located team may find that a high-level overview captured using whiteboard sketches is sufficient.  A team that is geographically distributed across several locations will find that it needs to at least take digital snapshots of the sketches and share them (perhaps via a wiki) or even capture the diagrams using a drawing tool such as Visio or OmniGraffle.  They may also find that they need to define the details of the interfaces to major components and services, a strategy often referred to as design by contract.  A team in a life-critical regulatory environment may choose to capture more details, even to the point of doing big design up front (BDUF).
  • Explore technology architecture.  Technical aspects of your architecture may be captured via free form layered architecture diagrams, network diagrams, or UML deployment diagrams amongst others.
  • Explore business architecture.  Business or domain aspects may be explored via conceptual domain models, high-level process models, and UML component diagrams amongst others.
  • Explore user interface (UI) architecture.  For end users, the UI is the system.  The implication is that you had better architect it well, and more important ensure that it is usable/consumable.  You may explore the user interface architecture via a UI flow diagram/wireframe model, low-fidelity UI prototypes, or high-fidelity UI prototypes.
  • Consider the future.  A critical thing is for your architecture to be able to accommodate change in the future.  The lean strategy is to consider these changes, and make architectural choices that best enable you to accommodate the changes when and if you need to, but DO NOT overbuild your solution now.  In short, think but wait to act.  To do this you need to consider the potential changes that could occur, often via “what if” discussions.  If you need to capture these potential changes you might decide to write change cases.
  • Apply a modeling strategy(ies).  How will your team go about formulating their architecture?  Will they hold informal modeling sessions in an agile modeling space or formal modeling sessions Joint Application Design (JAD) strategy?  Or both?
  • Select an architecture strategy. Will they identify a single technical strategy or several options which they will hope to explore and eventually choose from (or combine ideas from)?
  • Identify a delivery strategy.  Will the team be building a solution from scratch?  Will they be evolving an existing solution?  Will they be evolving a purchased, commercial off the shelf (COTS) package?  Combinations thereof?

We want to share two important observations about this goal.  First, this goal, along with Explore Initial ScopeCoordinate Activities, and Move Closer to a Deployable Release seem to take the brunt of your process tailoring efforts when working at scale.  It really does seem to be one of those Pareto situations where 20% addresses 80% of the work, more on this in a future blog posting.  As you saw in the discussion of the process issues, the process tailoring decisions that you make regarding this goal will vary greatly based on the various scaling factors.  Second, as with all process goal diagrams, the one above doesn’t provide an exhaustive list of options although it does provide a pretty good start.

We’re firm believers that a team should tailor their strategy, including their team structure, their work environment, and their process, to reflect the situation that they find themselves in.  When it comes to process tailoring, process goal diagrams not only help teams to identify the issues they need to consider they also summarize potential options available to them.  Agile teams with a minimal bit of process guidance such as this are in a much better situation to tailor their approach than teams that are trying to figure it out on their own.  The DA process decision framework provides this guidance.

Posted by Scott Ambler on: February 10, 2014 07:28 AM | Permalink | Comments (0)

11 Strategies for Dealing With Technical Debt

I was recently asked how is technical debt addressed in Disciplined Agile Delivery (DAD), a very important question.  Because DAD promotes a full, explicit delivery lifecycle there are many opportunities to first avoid creating new technical debt in the first place and second to address existing technical debt appropriately.

Here are some of the strategies that DAD promotes when it pertains to technical debt:

  1. Do a bit of up front thinking.  One of the process goals of DAD is Identify an Initial Technical Strategy.  By thinking through critical technical issues before you implement your solution you have the opportunity to avoid a technical strategy which needs to be reworked at a future date.  The most effective way to deal with technical debt is to avoid it in the first place.
  2. Have an explicit architecture owner.  The Architecture Owner (AO) on a disciplined agile team is responsible for guiding the team through technical decisions, particularly those at the architecture level.  AOs often mentor other team members in design skills, skills that should help them to avoid injecting new technical debt into the environment.  They should also be on the lookout for existing technical debt and where appropriate motivate the team to address that technical debt when appropriate.
  3. Be enterprise aware.  Disciplined agile teams are enterprise aware, realizing that what they do should leverage and enhance the overall organizational ecosystem.  They will work close with your enterprise architecture and reuse/asset teams, if you have such, so that they can take advantage of existing assets.   Assets could include code, patterns, services, templates, guidelines, or anything else worthy of being reused.
    An important strategy for avoiding technical debt is to reuse existing assets and not rebuild or rebuy something that you already have.
  4. Refactor technical debt away.  DAD provides guidance for when to apply several forms of refactoring, including code refactoring, database refactoring, and user interface (UI) refactoring.  Refactorings are typically very small, such as renaming an operation or splitting a database column, so should just be part of everyday development.  Rework, on the other hand, is more substantive and should be explicitly planned.  The Architecture owner will often negotiate rework-oriented work items with the Product Owner (the person on the team who is responsible for prioritizing the work).
  5. Regression test continuously.  One of the easiest ways to find problems in your work is to have a comprehensive regression test suite that is run regularly.  This test suite will help you detect when defects are injected into your code, enabling you to fix them, or back out the changes, right away.
  6. Automate code/schema analysis.  There are many tools available for assessing the quality of your code and even your database schema.  Disciplined agile teams will include the use of these tools in their continuous integration (CI) strategy.  Knowing where your technical debt exists is the first step in removing it.
  7. Measure technical debt.  Organizations that are serious about technical debt measure it, something that code/schema analysis tools help with, and more importantly keep an eye on the trends (which should be going down over time).  You may choose to track code quality metrics, data quality metrics, usability metrics, time to address defects, time to add features, and many other things.
  8. Explicitly govern technical debt.  Several of the previous strategies require investment that some organizations wouldn’t normally consider to be part of the mandate of a delivery team.  For your organization to succeed at reducing technical debt it must be governed, albeit in an agile fashion.  This means it needs to be understood by senior management, measured (see previous point), and funded.  The DA toolkit includes explicit guidance around how to govern agile teams effectively.
  9. Reducing technical debt should be part of your culture.  Technical debt isn’t going to fix itself, and worse yet will accrue “interest” over time in the form of slower and more expensive evolution of your existing assets.
  10. Address technical debt before handing over an asset.  Passing systems with high technical debt to other teams, such as a sustainment team or maintenance group is generally a bad practice. It should be ingrained in your culture that each team is responsible for keeping the quality of their solutions high. It is reasonable to expect maintenance groups to resist accepting systems that have high technical debt.
  11. Accept some technical debt.  Sometimes you will decide to explicitly accept some short term technical debt for tactical reasons.  Perhaps you need to get something developed quickly because you are running a market experiment (a la Lean Startup).  Perhaps there is a new component or framework about to be delivered by another group in your organization, so you’re writing a small portion of what you need for now until you can replace it with the more robust asset.  Regardless of the reason, part of the decision to accept technical debt is to also accept the need to pay it down at some point in the future.  Having good regression testing assets in place assures that refactoring accepted technical debt in the future can be done with low risk.

There are many good online resources regarding technical debt, and the best single one that we have found is Israel Gat’s blog.   Technical debt is real and you need a viable strategy to manage it.  Otherwise you run the risk of slowly choking the life out of your organization’s IT infrastructure.  The DA toolkit can help you to understand how the strategies described above fit into your overall agile delivery process.

Posted by Scott Ambler on: November 10, 2013 12:59 PM | Permalink | Comments (0)
ADVERTISEMENTS

If man could be crossed with the cat, it would improve man but deteriorate the cat.

- Mark Twain

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events