Disciplined Agile

An important philosophy within both the agile and lean communities is that a team should own its process. In fact, one of the principles behind the Agile Manifesto is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” The idea is that teams should be empowered to choose their way of working (WoW), to "own their process," including both their team structure and the process that they follow, to meet the unique needs of the situation that they find themselves in. Teams that own their process will tailor it over time as they learn how to work together, adopting new techniques and tweaking existing ones to increase their effectiveness.

As with most philosophies this one is easy to proselytize but not so easy to actually adopt. When it comes to process improvement, teams will exhibit a range of behavior in practice. Some teams see process as a problem and actively seek to ignore process-related issues. Some teams are ambivalent towards process improvement and generally stick with what they’ve been told to do. And some teams see process improvement as an opportunity to become more effective both as a team and as individuals. This range of behaviors isn’t surprising from a psychology point of view although it can be a bit disappointing from an agile or lean point of view. It has led me to think that perhaps some teams choose to “own” their process but many more still seem to prefer to simple rent it.

The behaviors of people who rent something are generally different than those who own something. Take flats for example. When you rent a flat (called an apartment in North America) you might do a bit of cosmetic work, such as painting and hanging curtains, to make it suitable for your needs. But people rarely put much more effort than that into tailoring their rental flat because they don’t want to invest money in something that isn’t theirs, even though they may live in the flat for several years. It isn’t perfect but it’s good enough. When you own a flat (called a condo in North America) you are much more likely to tailor it to meet your needs. Painting and window dressings are a good start, but you may also choose to renovate the kitchen and bathroom, update the flooring, and even reconfigure the layout by knocking down or moving some walls. One of the reasons why you choose to own a flat is so that you can modify it to meet your specific needs and taste.

You can observe similar behaviors when it comes to software process. Teams that are merely “process renters” will invest a bit of time to adopt a process, perhaps taking a two-day course where they’re taught a few basic concepts. They may make a few initial tailorings of the process, adopt some new role names, and even rework their workspace to better fit the situation that they face. From then on they do little to change the way that they work together. They rarely hold process improvement sessions such as retrospectives, and if they do they typically adopt changes that require minimal effort. Harder improvements, particularly those requiring new skills that require time and effort to learn, are put off to some point in the distant future which never seems to come. Such behavior may be a sign that this “team” is not even be a team at all, but instead a group of individuals who are marginally working together on the same solution. They adopt the trappings of the method, perhaps they spout new terminology and hold the right meetings, but few meaningful changes are actually made.

Process owners behave much differently. Teams that own their process will regularly reflect on how well they’re working and actively seek to get better. They experiment with new techniques and some teams will even measure how successful they are implementing the change. Teams that are process owners will often get coaching to help them improve, both at the individual and at the team level. Process owners strive to understand their process options, even the ones that are not perfectly agile or lean, and choose the ones that are best for the situation they find themselves in.

The Disciplined Agile (DA) tool kit is geared for teams that want to own their process. The DA tool kit is process goal-driven, not prescriptive, making your process choices explicit and more importantly providing guidance for selecting the options that make the most sense for your team. This guidance helps your team to get going in the right direction and provides options when you realize that you need to improve. DA also supports multiple life cycles because we realize that teams find themselves in a range of situations – sometimes a Scrum-based life cycle makes sense, sometimes a lean life cycle is a better fit, sometimes a continuous delivery approach is best, and sometimes you find yourself in a situation where an exploratory (or “Lean Startup”) life cycle is the way to go.

You have choices, and DA helps guide you to making the choices that are right for you in your given context. By providing process guidance DAD enables your team to more easily own its own process and thereby increase the benefit of following agile or lean approaches.

One of the process goals that a disciplined agile team will want to address during construction is Accelerate Value Delivery.  Ideally, in each construction iteration a team will move closer to having a version of their solution that provides sufficient functionality to its stakeholders.  This implies that the solution is a minimally viable product (MVP) that adds greater business value than its cost to develop and deploy.  Realistically it isn’t a perfect world and sometimes a team will run into a bit of trouble resulting in an iteration where they may not have moved closer to something deployable but hopefully they’ve at least learned from their experiences.

This is an important process goal for several reasons. First, it encompasses the packaging aspects of solution development (other important development aspects are addressed by its sister goal Produce a Potentially Consumable Solution).  This includes artifact/asset management options such as version control and configuration management as well as your team’s deployment strategy.  Second, it provides deployment planning options, from not planning at all (yikes!) to planning late in the lifecycle to the more DevOps-friendly strategies of continuous planning and active stakeholder participation. Third, this goal covers critical validation and verification (V&V) strategies, many of which push testing and quality assurance “left in the lifecycle” so that they’re performed earlier and thereby reducing the average cost of fixing any defects.

The process goal diagram for Accelerate Value Delivery 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.

Let’s consider each process factor:

• Choose a Deployment Strategy.  Deployment can be a struggle for teams new to agile.  Many teams will start by aiming to deploy their solution into production more regularly, perhaps every few months instead of every six to twelve months.  Then they will start deploying working builds internally at the end of each iteration, perhaps into demo or testing environments.  Finally they will hopefully evolve into a continuous deployment (CD) strategy.
• Manage Assets.  The issue here is how your team will manage the various artifacts, including code, which they use and create while building a solution.  Sadly we’ve found that some teams still struggle with basic configuration management control.  Although they may have their source code under fairly sophisticated control other artifacts such as supporting documentation often aren’t.
• Document.  Supporting documentation, such as user guides and system overviews, are part of the overall solution that the team is working on.  The DA toolkit leverages strategies from Agile Modeling to address this process factor.  Your team may choose to leave such documentation to the end of the lifecycle or to write documentation throughout the lifecycle.
• Plan Deployment.  There are several techniques that you may want to consider for deployment planning, an important aspect of your overall DevOps strategy.  Although some teams may begin such planning with their operations/release engineers late in the lifecycle, many will instead plan throughout the lifecycle.  The DA toolkit recognizes operations staff as key stakeholders, people whom you will actively work with to plan and then deploy your solution.
• Maintain Traceability.  Traceability from requirements through your design to your code to your tests, or a subset thereof, may be required by your team.  This is common for some, but not all, regulations.  Traceability is often perceived as critical to enable impact analysis, although in practice this is questionable as manually maintained traceability matrices are rarely kept up to date.
• Validate.  DAD captures the fact that there are many ways that you can choose to validate your work, including a range of agile quality techniques (TDD, CI, ATDD/BDD) and even a few that are not-so-agile (end-of-lifecycle testing, manual testing, parallel independent testing).  The DA toolkit purposely includes these not-so-agile strategies because in some situations, particularly at scale, they may in fact be your best options.  Furthermore, your team may be in the early stages of becoming agile and as a result then not-so-agile strategies may be the best they are currently capable of doing.
• Verify.  DAD also recommends that you consider verification strategies to help increase the quality of your work. These strategies include reviews, non-solo development strategies such as pair programming and modeling with others (which are effectively continuous reviews), and including code analysis tools in your CI strategy.

We want to share two important observations about this goal.  First, this goal, along with Explore Scope, Coordinate Activities, and Identify Architecture Strategy 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 that teams that are trying to figure it out on their own.  The DA too lkit provides this guidance.

When a disciplined agile project or product team starts, one of the process goals which they will likely need to address is Identify Architecture 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 life cycle.  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 mindset of working in an enterprise aware manner.

This is an important goal for several reasons:

1. You want to get going in the right direction.  Your team needs to have at least a high level understanding of how they’re going to build (or configure) the solution, they just don’t start coding.  This helps the team to avoid potential rework later in the life cycle.  It is critical in situations facing lots of technical complexity.
2. You need to secure funding.  In the vast majority of organizations, teams are asked fundamental questions such as what are you trying to achieve, how long will it take, and how much will it cost.  Having an understanding of your technical strategy is important input into answering those sorts of questions.
3. You want to leverage organizational assets.  Because disciplined agile teams are enterprise aware they work closely with enterprise professionals such as enterprise architects so that they can take advantage of any existing infrastructure and assets.  They also want to ensure that their solution reflects the overall goals of their organization (often captured in technical or business roadmaps).

The process goal diagram for Identify 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.

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 Scope, Coordinate Activities, and Accelerate Value Delivery 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 choose their own way of working (WoW), 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 tool kit provides this guidance, particularly via Guided Continuous Improvement (GCI).

Recently on a LinkedIn discussion forum people were sharing their opinions about agile teams. Throughout that conversation I heard several statements which just didn’t ring true with me. In some cases I suspect that the problem was they were thinking they were agile when they clearly weren’t and in other cases I suspect people were sharing ill-founded rumours about how agile works. I heard that everyone on an agile team must be highly skilled, that everyone on an agile team is a “jack of all trades”, and that people on agile teams are working so fast that they have no time to learn. Let’s examine each myth/misunderstanding one at a time.

Myth #1: Everyone on an agile team must be highly skilled
Agile lore recommends that you build teams where you ideally have all the skills you need to get the job done, this is called being a “whole team”. This doesn’t always happen at first. Recently I worked with a team that was clearly short on testing skills but they were actively addressing that problem by bringing people into the team with those skills. They will also be pairing to spread the skills out once these new people join the team. Call me crazy, but doesn’t building a team with people that have the requisite skills a good strategy regardless of paradigm?

Myth #2: Everyone on an agile team is a “jack of all trades”
Disciplined Agile Delivery (DAD) suggests that people strive to be generalizing specialists (not generalists, not jack of all trades). This means that you have:

• One or more specialties (you need to be able to do something useful)
• At least a general knowledge of the software process and the business domain that you’re working in (this enables you to communicate more effectively with others and streamline collaboration)
• The desire to increase your knowledge and skills

Granted, this is different than how some people staff traditional projects where they have specialists and then incur an incredible amount of overhead to get the job done. When you are new to agile you very likely have many people who are specialists on staff, perhaps they are focused on being a business analyst, on being a tester, on being a programmer, an architect, and so on. That’s OK, as they say you go to war with the army that you have. Over time you will want to actively support, and motivate people, to learn new skills from other people on the team (see next point). It’s also important to recognize that although someone may currently be focused on a certain traditional role today, that in the past they held other roles and as a result may have a broader range of skills, albeit rusty in some cases, than they may give themselves credit for. Regardless of your situation people can easily gain new skills if they choose to.

Myth #3: People on agile teams are working so fast that they have no time to learn
Yes, agile teams focus on producing real value on a regular basis, and that is often perceived as working fast by people used to the less disciplined strategies of the traditional world. This is overwhelming at first for teams new to agile and it can seem that there isn’t time to learn or to even catch your breath. As you get better at working in an agile manner, as you “figure it out”, your team will settle on a rhythm that works for them.

Agile promotes iterative, collaborative, and experimental strategies. This promotes learning within the team, it doesn’t reduce it. Agile, and lean strategies in particular, expect the team to learn as you go. They’ll learn more about the domain, about the technologies they’re working with, about how to work effectively, and about each other. When people work together collaboratively, not alone at their own desks, they start to pick up skills from one another naturally. This is particularly true when the team adopts non-solo strategies such as pairing (I alluded to the value of pairing programmers and testers earlier). Of course coaching and mentoring are important to support learning as well as training.

I often run into people who are concerned about changing requirements, or evolving requirements if you like that term better, on software development projects (or product teams as the case may be). This is typically a reflection of their training and background in traditional software development strategies where changing requirements are usually perceived as a problem.

In agile we consider changing requirements to be a good thing and we even embrace the idea that this will happen.  In fact, one philosophy of Disciplined Agile Delivery (DAD) is that changing requirements are a sign of a healthy relationship with your stakeholders. Changing requirements indicate that:

• Your stakeholders are interested in what you’re working on
• Your stakeholders are thinking about what you’re producing
• There are feedback mechanisms in place that enable your stakeholders to change their requirements
• It is easy (hopefully) for stakeholders to change their requirements as their understanding of their needs evolve

So how do you support changing requirements in practice?  The Disciplined Agile (DA) toolkit includes the “Address Changing Stakeholder Needs” goal which guides you through understanding and selecting the right strategy for prioritizing requirements changes as they occur throughout the lifecycle.  These strategies include, but aren’t limited to Scrum’s Product Backlog Strategy, a more disciplined Work Item List strategy, or a lean Options Pool strategy.  In regulatory situations you may even want to consider a formal change management strategy.  DAD’s process goal-driven approach enables disciplined agile teams to tailor their strategy to meet the situation that they find themselves in, avoiding the challenges seen with methods such as Scrum that prescribe a single strategy (in this case Product Backlogs) that don’t work in all situations.

And of course, to minimize the pain of changing requirements you will need to adopt disciplined development practices such as:

• Writing high-quality code;
• Refactoring your work to keep it of high quality;
• Continuous integration;
• and even acceptance test-driven development (ATTD)/behavior driven development (BDD).