Category Archives: Uncategorized

For the want of a whiteboard….

For the want of a whiteboard the vision was lost,

For the want of a new vision the release was lost,

For the want of a new release the product was lost,

For the want of a new product the customer was lost,

For the want of a new customer the company was lost,

And all for the want of a whiteboard.

With a nod to Benjamin Franklin.

Do Agile Teams Pay Down Technical Debt in Practice?

Technical debt is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”. Technical debt can be compared to monetary debt in that if it is  not repaid, it can accumulate ‘interest’, making it harder to implement changes later on.  Important questions to ask are “How common is it for agile teams to run into technical debt in practice?” and “When they do run into technical debt, are they paying it down?”

The following diagram summarizes responses to our question from our 2016 Agility at Scale study around technical complexity.  As you can see 84% of agile teams are working with legacy functionality and 51% with legacy data sources (so yes, the vast majority of teams are working in environments that are likely to have some form of technical debt).  More importantly, 38% of teams are actively paying down functional technical debt and 32% are paying down data technical debt (48% are paying down one or the other).

Technical Debt in Practice


Related Posts



Can You Outsource and Still Be Agile?

We often hear that agile software development is fine for small co-located teams, but that you couldn’t possibly take an outsourcing approach with agile.  The customer organizations would love to do agile but are convinced that vendors are unable to do so, and the vendor organizations typically say they’d love to be agile but that the customers don’t ask them to work that way.  It’s a fair question to ask if agile and outsourcing are being combined in practice, so we decided to look into this issue.

The following diagram summarizes the responses to our question from our 2016 Agility at Scale study around whether agile teams were organizationally distributed (one of the tactical scaling factors potentially faced by agile teams).  As you can see, over half of agile teams are organizationally distributed in some way, with 58% of agile teams including contractors, consultants, or outsourcers in some way.  Interestingly, about one agile team in six includes outsourcing.

Agile and outsourcers, contractors, and consultants

Answering the question of how to be successful at agile and outsourcing is worthy of a detailed article in its own right, something we’ll do in the near future.  Until then, here are some initial thoughts based on our observations at multiple organizations around the world:

  1. It starts with procurement.  If you want a service provider to provide a team that is capable of working in an agile manner then that is what you need to procure.  A traditional procurement process that is looking for a team to work from a detailed requirements specification up front, that is expected to focus on development and then hand off their work for another team to perform “final testing”, is pretty much hobbled from the very beginning.  It is very possible, and highly desirable, to have a procurement process that is capable of procuring agile software development services.  In fact, there is a wealth of knowledge out there about agile contracting if you choose to look into it.
  2. The customer must work in an agile manner.  There are several key strategies to support this:
    • Negotiate how you will work together up front.
    • Take a light-weight, evolutionary approach to requirements.
    • Provide a technical roadmap.
    • Fly a few key people to the service provider.
    • Consider co-locating your Product Owner with the service provider.
    • Provide your development guidelines to the service provider.
    • Actively govern the team.
    • Respect the service provider.
  3. The service provider must work in a disciplined agile manner.  There are several key strategies to support this:
    • Be trustworthy.
    • Be truly transparent.
    • Have one-week iterations/sprints.
    • Include code analysis tools in your builds.
    • Provide the customer access to your team’s automated dashboard.
    • Align your culture to that of the customer.

We will write a more detailed article that expands on these points in the near future.  Stay tuned!

Related Posts

Vertical Slicing for a Data Warehouse (DW)/Business Intelligence (BI) Solution

There are several strategies that you can choose to employ with vertically slicing the requirements for a DW/BI solution. These strategies are described in the following table. There are example stories for each strategy as well as some advice for when to apply each strategy.

Table 1. Vertical slicing strategies for a DW/BI solution.

Slicing Strategy Example Stories When to Do This
One new data element from a single data source
  • As a Professor I would like to know the names of my students so that I know who should be there
  • As a Student I would like to know what courses are taught at the university
Very early days when you are still building out fundamental infrastructure components. Very common for the first iteration or two of Construction. These slices still add real business value, albeit minimal.
One new data element from several sources
  • As a Professor I would like the student list for a seminar that I teach
  • As a Student I would like to know what seminars are being taught this semester
Early days during Construction when you are still building out the infrastructure. These slices add some business value, often fleshing a DW data element to include the full range of data values for it.
A change to an existing report
  • As a Professor I would like to know the standard deviation of marks within a seminar that I teach
  • As a Student I would like to know how many spots are still available in a seminar
Evolution of existing functionality to support new decision making
A new report
  • As a Professor I would like to know the distribution curve of student marks in a seminar that I teach so I may adjust accordingly
  • As a Registrar I would like to know what Seminars are close to being full
Several iterations into Construction when the DW/BI solution has been built up sufficiently.
A new reporting view
  • As a Registrar I would like to know what the prerequisites are for a seminar so that I can advise students
  • As a Professor I would like to know the current course load of each student within a seminar that I teach
Several iterations into Construction when the DW/BI solution has been built up sufficiently.
A new DW/DM table
  • As a Chancellor I would like to track the revenues generated from parking pay meters to identify potential profits to divert to supporting students
  • As a Professor I would like to recommend suggested readings to help people prepare before taking a seminar
Several iterations into Construction when the DW/BI solution has been built up sufficiently.

There are several interesting things about the stories in the table:

  1. They are written from the point of view of your stakeholders. They aren’t a technical specification. For example, the first story describes how professors want a list of student names but it isn’t saying from what data source(s), what the element names are, … These are design issues, not requirement issues.
  2. They always provide business value. The first story appears to be the beginnings of an attendee list for a seminar. Having something as simple as a list of names does in fact provide a bit of value to professors.
  3. Sometimes that business value isn’t (yet) sufficient. It may take several iterations to implement something that your stakeholders want delivered into production, particularly at first. For example, although a list of student names is the beginnings of a class list it might not be enough functionality to justify putting it into production. Perhaps professors also need to know the program that the student is enrolled in, their current year of study, and basic information about the seminar such as the course name, time, and location of it. The decision as to whether the functionality is sufficient to ship is in the hands of your stakeholder (this is one of the reasons why you want to demo your work on a regular basis).

I’ve written a detailed explanation of vertical slicing for a DW/BI solution, and of course there is a wealth of information about agile database techniques in general for those of you interested in greater detail.  You may also find our one-day Disciplined Agile Data Warehousing/Business Intelligence Workshop to be a valuable learning experience too.

How Geographically Distributed Are Agile Teams in Practice?

Many people, particularly those new to agile, will tell you that agile teams must be small and co-located.  That is certainly a smart way of organizing a team, but is isn’t required.  In fact agile teams are more likely to be geographically distributed in some way than they are to be co-located.  In practice, not theory.

In November of 2016 we ran the 2016 Agility at Scale survey.  It was targeted at people who were currently working on agile teams, or who had recently worked on agile teams, and we asked them straightforward questions around the size of the team, how distributed it was, what complexities they faced, an so on.  The following graph summarizes the responses around geographic distribution.

Geographic distribution and agile teams

The survey found that less than one-third of agile teams are near-located, where all of the IT members are either co-located or at least in a shared open space.  Previous studies have found that this number drops to one-in-ten teams being near located when you also include primary stakeholders.

Don’t let anyone tell you that you can’t do agile with a geographically distributed team because others are clearly doing so in practice.  Yes, geographically distributed agile is different than near-located agile, which is one of the reasons why you need to take a pragmatic, context-sensitive approach to agile solution delivery.  The Disciplined Agile framework provides the foundation from which to scale your approach to solution delivery to address a range of scaling factors, including geographic distribution.  In fact, you may find our article around geographically distributed agile teams to be an interesting read.

Related Posts:

How to Choose an Agile Release Cadence


One of the things that a delivery team needs to do, often in collaboration with product management, is choose the release cadence of their product. This is an important aspect of, you guessed it, release planning.  Your release cadence defines how often you release your solution both internally and externally into production (or the marketplace). The issue is how to determine how often the product should be released into production. In this blog we explore:

  1. Where are you deploying to?
  2. What affects release cadence?
  3. What release cadence choices do you have?
  4. What do we recommend?


Where Are You Deploying?

There are several target environments that you might choose to deploy to. These environments include:

  1. Demo environment(s). Many teams maintain a demo environment for their solution so that their stakeholders can see what has been developed to date at their leisure. Demo environments support transparency with your stakeholders, reduce the number of “one-off” requests by stakeholders for demos (because they can simply see the solution for themselves), and of course they provide a stable environment in which your teams can run demos.
  2. Testing environment(s). Many teams have their own testing environments, or they work with independent test teams with their own testing environments, or both. You should strive to test as often and early as possible, an implication being that want to deploy into your test environment(s) as often as you possibly can.
  3. Production/marketplace. Some teams will release their solutions into their production environments (or to someone else’s cloud) where end users will use the systems. In the case of commercial software companies they will release their solutions into the marketplace where they are then sold to customers. Throughout this blog whenever we use the term production we also mean the marketplace.

For the sake of terminology, deploying into demo or testing environments are often referred to as internal releases and into production as an external release.


What Affects Release Cadence?

There are several factors that affect the choice of release cadence:

  1. Stakeholder needs. How often do your stakeholders, and in particular your end users, want your solution to be released? This can be a difficult issue because very often your stakeholders might not be able to perceive what is appropriate for them. We’ve seen stakeholders ask for quarterly releases, be delighted when then get monthly releases, and then start asking for weekly releases once they realize the potential of modern agile strategies.
  2. Stakeholder capability to accept change. We like to think that more often is better, and in the vast majority of situations it is. As difficult to believe as this may seem, at the far extreme we’ve also seen some systems where the natural release cadence is once every three or four years because that’s the rate at which stakeholders are able to accept change. In this case the product was a transaction processing (TP) system infrastructure product, but we’ve heard similar stories about major database management systems (DBMSs) products too. Granted, a release cadence this long is very rare but it does happen in a small number of situations. Far more common is the mistaken belief by IT professionals that their stakeholders are unwilling or unable to accept shorter release cycles. We’ve seen numerous organizations where the IT people tell us that their stakeholders can’t handle anything more regular than a quarterly or bi-annual release, yet these same stakeholders regularly use commercial software that is updated several times a week.
  3. Your organizational culture. Some organizations, particularly those with an existing traditional release management team, often have release cultures that lean towards larger and less frequent releases. These organizations often have significant investments in legacy systems and insufficient investments in automated regression tests/checks. As a result releasing solutions into production tend to be seen as a risky endeavour. At the other extreme we’ve seen companies with more of a continuous delivery mindset that have a “release as swiftly and often as you can” culture. These organizations have typically invested heavily in code quality, automated regression testing, and automated deployment thus making deployment a simple and virtually risk-free effort.
  4. The team’s ability to deliver. Of course a primary determinant of your release cadence will be how often you’re able to actually produce a potentially consumable solution. This is affected by the skills of your team members, your ability to collaborate, your ability to vertically slice functionality into small features, and your delivery infrastructure.
  5. Your delivery infrastructure. How easy it is to release a potentially consumable solution into production is determined in part by your technical environment. This includes the extent of your automated regression tests, your automated deployment scripts, and your capability to monitor production. In general, the greater the level of automation the more often you can release.
  6. Your solution architecture. Is your solution architected to be released incrementally? Is it possible to enable/disable functionality at a granular level (perhaps via feature toggles or a similar technique)?
  7. The cost/risk to release.   Cost and risk tend to go hand-in-hand when it comes to releasing solutions into production. This is because the more manual your release/deployment processes the more expensive they become and the more likely there are to be problems somewhere in the process. Conversely, the more you automate the overall deployment effort the cheaper it is to deploy and the less risky it becomes as you’re more likely to run into, and then automate a solution to, deployment problems. The less expensive and less risky it is to release your solution the more viable it becomes to release more often.
  8. Release cadence of other teams. Like it or not your team is likely dependent on the work of other teams. For example you may need web services being built by another team, and you can’t fully release your solution until those web services are available in production.  We’ve written detailed articles about how to manage dependencies between agile/lean and traditional teamsdependencies between agile teams, and dependencies between agile and lean teams.


Release Cadence Choices

Table 1 lists many common release cadences, from more than annual to several times a day. It also lists the potential tradeoffs of each approach and indicates when you may want to adopt each one.

Table 1. Comparing external release cadence options.

Strategy Potential Advantages Potential Disadvantages When to Apply
Many times a day Enables very short time to market

Enables teams to adapt quickly to changing stakeholder needs

Enables granular release of functionality

Requires extensive continuous integration (CI) and continuous deployment (CD) automation

Requires high discipline to maintain quality

Your solution architecture must support toggling of features to enable deployment of larger functions as a collection of smaller features

Effective for high-use systems, particularly those used by external customers in highly-competitive environments
Daily Same as above

Provides a regular (daily) release cadence that is predictable

Same as above Same as above
Weekly Provides a regular (weekly) release cadence that is predictable

Enables quick time to market and responsiveness to changing needs

Same as above Effective for high-use solutions, particularly e-commerce or BI/reporting systems

Appropriate for teams following the Lean lifecycle

Monthly Provides a regular (monthly) release cadence that is predictable

Enables quick time to market and responsiveness to changing needs

Requires extensive continuous integration (CI) and continuous deployment (CD) automation

Requires high discipline to maintain quality

Effective for medium-priority solutions

Appropriate for teams following the Agile/Basic lifecycle with one-week iterations or the Lean lifecycle

Quarterly Provides a regular (quarterly) release cadence that is predictable

Enables quick time to market and responsiveness to changing needs

Enables simpler requirements management practices (compared with longer release cadences) due to lower impact of a feature moving to the next release

This is a major milestone for teams moving towards an “advanced” lean-agile strategy as it motivates greater discipline.

Requires continuous integration (CI)

Requires automated deployment strategies

Effective for medium-priority solutions

Appropriate for teams following the Agile/Basic lifecycle with one or two week iterations

Variable Works well with a project mindset (although that’s questionable in and of itself) Teams need to be able to judge when their work reaches the minimally marketable release (MMR) stage and the business value added exceeds cost of transition. This decision point is captured in the DAD project lifecycles by the “sufficient functionality” milestone

Politics can hamper this decision point. You should put an upper limit on the acceptable time between release

Project teams

Stable teams assigned large “projects”

Bi-annual Good starting point for teams new to agile who are currently working on traditional projects with longer release cadences because it motivates adoption of disciplined strategies Can be difficult for stakeholders who are used to less frequent releases The team may need significant agile coaching as they will run into many of the “but we’re different and that agile stuff can’t possibly work here” type of problems
Annual Provides a regular (annual) release cadence that is predictable


Very risky, the team is likely to miss their date

Requires internal releases to obtain feedback

The deployment has likely become high risk because you do it so infrequently (self fulfilling problem)

Appropriate for low priority systems or for high-risk deployments (note that the deployments may have become high-risk because you do them so infrequently)
More than annual See annual


See annual

This is common for infrastructure systems, such as a database or transaction managers, that have many other systems highly dependent upon them


Our Recommendations

When it comes to releasing your solution, we have several recommendations for you to consider:

  1. Automate, automate, automate. The more you have automated, the lower the cost of deployment and the lower the risk. This enables you to release more often with confidence.
  2. Release internally very often. This is your opportunity to get good at releasing your solution, at squeezing out the cost and the risk.
  3. Release externally as often as possible. The faster and more often you can release into production the more competitive your organization will be.
  4. Always look for ways to release more often. Impressed with your ability to release once a month? Aim for bi-weekly. You’ve now releasing bi-weekly? What’s stopping you from releasing weekly? Weekly releases? Meh! Release daily! Your team is releasing daily grandpa? How about automatically releasing many times a day every time you have a working build?


Further Reading

Lean Thinking Provides a Philosophical Foundation for Scaling Agile

Little ideas add up

Lean thinking is important for scaling agile in several ways:

  1. Lean provides an explanation for why many of the agile practices work.  For example, Agile Modeling’s practices of light weight, initial requirements envisioning followed by iteration modeling and just-in-time (JIT) model storming work because they defer commitment to the last most responsible moment.  These practices also help to eliminate waste because you’re only modeling what needs to be built at the point in time that it needs to be built.
  2. Lean offers insight into strategies for improving your software process.  Lean principles such as optimizing the whole and delivering quickly motivate you to look beyond your existing specialized processes to explore how everything fits together and to streamline it.  Identifying and understanding the sources of waste in your IT processes can motivate you to improve the way that you work and thereby eliminate the waste.  The lean principle of building quality in
  3. Lean thinking provides a philosophical foundation for scaling agile approaches.  No methodology, process, procedure, or framework is ever complete.  Nor can they be because you can always capture more detail for a wider range of situations.  Because of this incompleteness you need a collection of higher-level principles or philosophies to guide people when their process/procedure/… proves to be incomplete for the situation that they face.  Lean thinking has proven to be a very good source of such philosophies, as do other sources (Steven Covey’s principles come to mind, as does the work of Peter Senge).
  4. Lean provides techniques for identifying waste.  Value stream mapping, a technique common within the lean community whereby you model a process and then identify how much time is spent on value-added work versus wait time, helps calculate overall time efficiency of what you’re doing.  Value stream maps are a straightforward way to illuminate your IT processes, providing insight into where significant problems exist.  I’ve created value stream maps with several customers around the world where we analyzed their existing processes which some of their more traditional staff believed worked well only to discover they had efficiency ratings of 20-30%.  You can’t fix problems that you are blind to.

The Lean Governance Mindset


The mindset required to govern IT in a lean or agile manner is very different than the traditional mindset. In this blog we review the key aspects of a lean governance mindset. These aspects are:

  1. Lead by example. People take their cues from their leadership teams. If your governance strategy is streamlined and light weight then whatever it governs will inevitably become streamlined and light weight. Conversely, an onerous and heavy governance strategy will lead to onerous and heavy strategies by those being governed.
  2. Be a servant leader. The primary function of governance people should be to prevent roadblocks, and if not to get rid of them as soon as they arise. You should strive to get teams the resources that they need and then get out of the way. Wait a minute, isn’t that the job of the Team Lead in Disciplined Agile (DA)? Yes, but who do you think that they work with to actually get that done?
  3. Motivation over management. IT professionals are intellectual workers, and intellectual workers generally don’t respond well to being told what to do. But they can be motivated, and once motivated will actively work on what they’ve been motivated to do. So motivate them to do the “right thing”. One way to do this is to communicate very clearly what your organization is trying to achieve. Another way to motivate people is to ask tough questions such as: What value is there in doing that? What can we do to increase value? How can we eliminate waste in what we’re doing? and What will we learn by doing that?
  4. Enablement over audit. Psychology shows that people, when given the choice, will usually take the easy path. This tells us that if we want people to do something, or to work in a given manner, then if we make it very easy to do so then they likely will. For example, if you want developers to follow common coding conventions then provide easy to understand and straightforward guidelines. Better yet, provide code analysis tools that they can include in the continuous integration (CI) tooling that provides feedback that they can act on. The traditional approach would be to rely on code inspections or code audits to ensure that conventions were being followed. This approach is not only onerous, and thus less likely to be followed, it has a long feedback cycle which means that any feedback resulting from the audit will be much more expensive to act on (on average) than the code analysis tool which has a very short feedback cycle. Yes, you may need to run the occasional audit, particularly when you’re working in a regulatory environment, but you should do so only as a last resort.
  5. Communicate clearly, honestly, and in a timely manner. Effective governors communicate what the priorities of your organization are and what is expected of people. It is crucial to set realistic expectations in an open, honest, consistent, and continuous manner.
  6. Streamline collaboration. Governors should help teams collaborate effectively with others. This not only helps them to achieve their goals but also supports enterprise awareness.
  7. Trust but verify. Agile is based on trust, but to ensure that the right thing is happening within your organization there needs to be verification of that. Governors can do this by monitoring teams via several strategies. These strategies include asking people what’s going on, automated metrics (via team dashboards), looking at information captured by information radiators, attending team demos, and as a last resort asking teams to produce status reports to address questions that can’t be answered via automated metrics.
  8. Focus on mitigating risk, not just reviewing documents. A primary goal of your governance strategy should be to mitigate risk. Sadly, many governance strategies have fallen into the bureaucratic trap of relying on documentation reviews to provide insight into what a team is doing. For example, your “architecture quality gate” might be based on the review and acceptance of an architecture model or document, the idea being that if some knowledgeable people assess the content of the document they will be able to determine whether the described architecture strategy will work. Unfortunately this isn’t the case. We’re sure you’ve seen several IT project teams who had a well-documented architecture, which was reviewed and signed off on, yet the technologies didn’t work well in practice, or perhaps they didn’t perform well, or perhaps they didn’t even integrate easily. The only thing that the review and acceptance of a document tells you is that a document was created, reviewed, and accepted.
  9. Learn continuously. Good governors learn as much as they can about what they’re governing so that they can make better decisions and can make effective suggestions to the people being governed.
  10. Consider both the long and short term. Governance must balance short-term needs with the long-term strategy of growing and enhancing your organization.
  11. Be a great host. People who have fun at work, who enjoy what they do, are much more productive than people who don’t. In this respect being an effective governor is like being a good host at a party – as host it’s your job to see that everyone has a good time and gets along well with each other, and to swiftly deal with any problems that arise.

Having a lean governance mindset, as described above, helps you to increase your effectiveness at governance. In the next blog we will describe what IT governance encompasses.

Disciplined Agile 2.0 is Under Construction!

Under Construction

You may have noticed that we’ve been making changes here on the site.  These changes include:

  1. We’ve added a new graphic on the home page overviewing DA 2.0.  This graphic is meant to serve as a landing page for the web site and as a printable poster (we printed a 4′ by 3′ version of it for the Agile 2015 conference and it looked great). We will soon have files available of various sizes for printing that you will be able to download free of charge.
  2. We’ve been writing about the new DA 2 process blades.  This includes Enterprise Architecture, Portfolio Management, Reuse Engineering, and many others.  We’ve been capturing ideas for the new process blades for quite awhile now but waited to publish until we were ready.  A couple of months ago we decided to publish “depth first”, hence the detailed descriptions of Enterprise Architecture and Release Management for example.  At the request of several clients we’ve decided to go “breadth first” for awhile to get the new page structure in place with overviews of each blade.  Reuse Engineering and Product Management are good examples of these pages.  Once these pages are in place we’ll start addressing the details again.
  3. Where there are details missing, we’re marking it as such.  You’ve likely noticed a few “TBDs” or “Work in Progress” indications on some of the pages.  Don’t worry, we’ll get to that material in priority order.
  4. Please be patient.  We have a lot of great material to share, but it takes time to publish it.

And yes, we were able to find an under construction graphic with pair programming going on.  😉

Right-sizing your agile process? Start in the Middle

Is your organization concerned with the cost and time required to adopt agile strategies?  Are you just starting out with agile and hoping to improve your chances of success by learning from the experiences of those who have gone before you?  Are you part way into your agile transformation but struggling to figure out how it all fits together?  If you answered yes to any of these questions please read on.

In this blog posting we discuss what it means to “right size” your software process to meet the needs of the unique situation that your team finds itself in.  We discuss two common anti-patterns: starting with a process framework that is much too large for your needs and starting with one that is far too small for your needs.  We argue that it’s much better to avoid these extremes and instead take a middle-ground approach by starting with a framework that is much closer to your actual needs.

Extreme #1: Large process repository

The first process right-sizing anti-pattern is to start with a large process repository, the classic example being IBM’s Rational Unified Process (RUP).  Although RUP is much maligned within the agile community the fact is that if you were to examine it with an open mind that there are many very good ideas promoted by RUP.  Be that as it may. The basic strategy with RUP is that you need to tailor down the process, often dramatically, to meet the unique needs of the situation your team finds itself in.  To do this requires significant process expertise, time, and money.
Right Sizing RUP
In practice, however, many organizations ran aground with RUP when they tailored it to be something similar to the waterfall-style processes from yesteryear that they were familiar with.  This is often referred to as RUPifall.  Another common mistake was to say to themselves “wow, there’s a lot of great ideas here, we need to do them all” and as a result they would create a process that was far too heavy to meet their needs.  In either case the problem was that they often didn’t have the process expertise required to right-size their process.  We also see this with organizations starting from frameworks such as ITIL, COBIT, and CMMI so this clearly isn’t just a RUP problem.

Extreme #2: Small methodology

At the other extreme is the right-sizing anti-pattern of starting with a small methodology, the classic example in this case being Scrum.  Although there is significant support for Scrum within the agile community, or at least among people who are new to agile, we’ve been seeing for a long time now that organizations are also running into trouble with this approach too.  With Scrum the idea is that you add in the techniques that Scrum doesn’t address to right-size your process.  Because Scrum proves to be only a very small part of the overall picture, to do this requires significant process expertise, time, and money.
Right Sizing Scrum
In practice organizations run aground with Scrum because they don’t have the process expertise to expand it to meet their needs.  One only has to count the number of “How does X fit into Scrum?” conversations occurring in agile discussion forums online, or at user group meetings or conferences, to see that this is true.  Step back for a moment and ask yourself how much time and effort has your organization invested in trying to adopt Scrum.  Could it not have been more streamlined?

A few years ago Forrester Research discovered that the majority of organizations “doing Scrum” had actually tailored it into what they called Water-Scrum-Fall (others call this Scrumifall).  As we describe in Going Beyond Scrum this occurs for several reasons.  First, Scrum doesn’t address the full delivery lifecycle, instead choosing to focus on the construction portion of it.  As a result organizations tend to stick with what they know, a heavy project initiation phase and a heavy solution deployment phase.  Second, Scrum only addresses only a small portion of what you need and explicitly leaves technical issues up to you.  These issues include topics such testing, programming, architecture, governance, documentation, deployment and many others.  As a result teams are left to piece together a process strategy that works for them, at the very same time that they’re struggling to understand the fundamentals of agile and lean software development.  They rarely have the process expertise to do that and as a result end up having to hire hordes of expensive Scrum coaches, few of whom seem to understand the enterprise-class realities that your teams actually face.  This is a risky and expensive proposition indeed.

The Effective Middle Ground

Both of these anti-patterns represent extremes: start with something large and cut it down to size, or start with something small and build it up to meet your needs.  Why not start with something much closer to what you actually need?  Doesn’t that make a lot more sense?  Why do you need to do all this process work?  Because someone wants to sell you tooling?  Because someone else wants to sell you expensive coaching and questionable certification strategies?  Isn’t it time to consider a more pragmatic strategy?

The Disciplined Agile Delivery (DAD) framework is a more effective middle ground.  It addresses the full delivery lifecycle, as does RUP (but not Scrum), and even gives you several choices from which to select.  Sometimes a Scrum-based lifecycle is appropriate, sometimes a Lean lifecycle is, other times a continuous delivery lifecycle is best, and sometimes an exploratory “lean start up” lifecycle is.  Different teams, different situations.  DAD starts with a lightweight approach, as does Scrum but not RUP, helping you to avoid the bloatware of RUP and filling in the numerous blanks left by Scrum.  DAD also gives you lightweight tailoring advice in the form of process goal diagrams, in many ways a cross between mind-maps and decision trees, that make your process choices explicit.  The RUP process tailoring advice, if you bother to read it at all, is rather heavy handed and the Scrum tailoring advice boils down to “you’re smart, you can figure it out and if your run into trouble hire a coach.”  Isn’t it time to abandon the extremes?

Right Sizing Disciplined Agile Delivery
This middle ground strategy isn’t without its faults.  A challenge with DAD is that it explicitly reveals that agile software development, or as we prefer to say agile solution delivery, is complex.  This is particularly true in enterprise-class situations where teams are often facing combinations of scaling factors such as larger team size, geographic distribution, and regulatory constraints.  DAD makes it explicit that teams need to invest a bit of time up front to perform initial scoping, initial architectural modeling, and initial planning (all in a lightweight manner of course).  This sort of pragmatic thinking can be inconvenient for less-experienced developers who just want to jump in and start coding.  Because DAD promotes the philosophy of enterprise awareness it purposely bakes in strategies for governance, DevOps, and working with IT-level groups such as your enterprise architects and data management team to name a few.  This can also prove to be inconvenient for developers who want to narrowly focus on doing what’s convenient for their team as opposed to what’s best for their organization.

In Summary

The following infographic summarizes the main points in this blog posting.
Right Sizing Your Agile Process
We hope that you’ve found this blog posting enlightening.  Even if you are well along the way of your Scrum adoption, or of evolving your RUP-based approach, you can still benefit from switching over to DAD.  Scrum teams will find that it addresses many of the issues that you’re still struggling with, and RUP teams will find that it shows how to work in a far more lightweight manner.  Organizations will find that it provides a much better foundation from which to scale agile strategies.