Tag Archives: DAD

An Exploratory “Lean Startup” Lifecycle

One of the key philosophies of the Disciplined Agile Delivery (DAD) framework is that it presents software development teams with choices and guides them through making the right choices given the situation they face.  In other words, it helps them to truly own their process.  Part of doing so is to choose the software delivery lifecycle (SDLC) that is the best fit for their context.  In this blog posting we overview the DAD Exploratory lifecycle which is based in part on Lean Startup strategies.

This lifecycle can be applied in two ways:

  1. As a replacement of the Inception phase of other lifecycles.  In the Inception phase we invest a short yet sufficient amount of time and effort to validate that the initiative being considered makes sense and to gain agreement on the stakeholders’ vision.  In a situation where the actual need and value of what is being proposed is in question this approach is a very good way to determine the true market need before scaling up the initiative and moving into the Construction phase.
  2. As the implementation approach in the Construction phase.  After applying the Exploratory approach to validate your vision, a decision needs to be made regarding which of the four DAD lifecycles to apply as we move into Construction. For instance, you may choose to use DAD’s Scrum-based basic agile lifecycle if there is sufficient confidence from the learnings in the Inception phase regarding the viability of the vision.  However, if there remains some uncertainty regarding the feature set to be delivered it may make more sense to continue using the Exploratory lifecycle to build out the product in Construction.

The following diagram overviews the DAD Exploratory lifecycle.  This lifecycle is followed by agile or lean teams that find themselves in startup or research situations where their stakeholders have an idea for a new product but they do yet understand what is actually needed by their user base.  As a result they need to quickly explore what the market wants via a series of quick learning experiments.

Disciplined Agile Lifecycle Exploratory

Now let’s describe how the Exploratory lifecycle works.  There are six activities to this lifecycle:

  1. Envision.  Your team will explore the idea and identify a potential implementation strategy for implementing it.  This could be as simple as getting a few people together in a room to model storm both the business vision and your technical options on whiteboard and paper.  You want to do just enough thinking to identify a viable hypothesis for what your customers actually want.  This hypothesis needs to be testable, which implies that you need to identify how you are going to measure the effectiveness of the new functionality that you produce.
  2. Build a little.  Your team should invest just enough effort to build a solution that tests the hypothesis.  In lean parlance you want to build what’s known as a minimally viable product (MVP).  The amount of effort will vary, from several days to several weeks – your goal is to make something available very quickly so that you can test your hypothesis.
  3. Deploy.  Once your current solution is ready it is deployed into an environment where you can test your hypothesis. This deployment may be to a subset of your customers, in many ways what used to be called an “alpha” or “beta” release, so that you can determine whether the solution is of interest to them.
  4. Observe & measure.  Once the solution is available in production you want to determine what aspects of it, if any, are of interest to your user base.  To do this you will need to instrument your solution so that it logs data regarding important events within it.  For example, you may decide to record when a screen/page is accessed, when a sale occurs, when certain business functions are invoked, and so on.  The idea is that you want to understand which functionality end users find useful, which functionality leads to customer retention, which functionality leads to greater sales, … whatever is important to you.  Generation of this data enables you to monitor, to observe and measure, how well the new functionality is received by your user base.  This in turn allows you to make a fact-based go-forward decision.  If the functionality is well received then you may choose to continue with the existing strategy and add more functionality.  Or your strategy may be so successful that you decide that you’re ready to productize the development of this solution. If the functionality wasn’t well received your team might choose to pivot and continue in another direction or even give up completely.
  5. Cancel.  Sometimes you discover that the product idea isn’t going to work out after all.  In fact, this is particularly common in research and development (R&D) environments as well as start ups.  The advantage is that if an idea is going to fail, then it is better that you learn that it’s a failure quickly so that you can devote your energies into other strategies.
  6. Productize.  After several iterations of building a little, deploying, and then observing & measuring that you’ve identifying a product that will be successful in the marketplace (or in the case of internal application development successful with your user base).  As described above, although you may choose to continue following this lifecycle, a common decision is for the team to adopt one of the other DAD lifecycles – such as the Scrum-based agile lifecycle, the Kanban-based Lean lifecycle, or the Continuous Delivery lifecycle – and effectively treat the time they spent following this lifecycle as their Inception phase.

To summarize, the DAD process framework takes a flexible, non-prescriptive approach to software-based solution delivery.  As a result of this philosophy DAD supports several development lifecycles, one of which is the Lean-Startup-based Exploratory lifecycle described in this posting.  This lifecycle is typically followed in situations where you are unsure of what your user base wants, and sometimes even when you are unsure of who your user base (your customers) will even be.

Got Discipline?

Got Discipline

A common question we get regarding Disciplined Agile Delivery (DAD) is “What makes DAD more disciplined than other approaches to agile?”  It’s a fair question, particularly from someone who is new to DAD.  This blog posting explores this question, explicitly summarizing the critical strategies that exhibit the greater levels of discipline in DAD as compared with what Mark and I see in many agile teams today.

It is clear that many common agile practices require discipline.  For example, agile teams it takes discipline to hold concise, streamlined coordination/Scrum meetings; to consistently deliver business value every iteration; to test continuously throughout the lifecycle; to improve your process “in flight”; to work closely with stakeholders and many more things.  Discipline is very important to the success of agile teams, see The Discipline of Agile for a detailed discussion, and DAD takes it to the next level in the following ways:

  1. Reducing the feedback cycle. Techniques that shorten the time between doing something and getting feedback about it are generally lower risk and result in lower cost to address any changes than techniques with longer feedback cycles.  Many of these techniques require agile team members to have new skills and to take a more disciplined approach to their work than they may have in less-than-agile situations.  There are several common ways to shorten the feedback cycle that are common to agile software development that are adopted by the DAD framework.  These techniques, listed in order of immediacy, include non-solo development (e.g. pair programming), active stakeholder participation, continuous integration (CI), continuous deployment (CD), short iterations/sprints, and short release cycles.
  2. Continuous learning. Continuous learning is an important aspect of agile software development in general, not just DAD.  However, DAD explicitly addresses the need for three levels of learning: individual, team, and organizational/enterprise.  It also addresses the need for three categories of learning: domain, technical, and process.  Continuous learning strategies include active stakeholder participation, coaching, mentoring, individual learning, non-solo development, proving the architecture with working code, spikes, retrospectives/reflections, sharing lessons learned between teams, and stakeholder demonstrations.
  3. Incremental delivery of consumable solutions.  Being able to deliver potentially shippable software increments at the end of each iteration is a good start that clearly requires discipline.  The DAD process framework goes one step further and advises you to explicitly produce a potentially consumable solution every iteration, something that requires even greater discipline.  Every construction iteration your team requires the discipline to create working software that is “done”, to write deliverable documentation such as operations manuals and user documentation, to address consumability (usability), to consider organizational change issues pertaining to your solution, and operations and support issues (an aspect of DevOps).
  4. Being process goal-driven.  The DAD framework promotes a process goal-driven approach. For each goal we describe the issues pertaining to that the goal. For example, with initial project planning you need to consider issues such as the amount of initial detail you intend to capture, the amount of ongoing detail throughout the project, the length of iterations, how you will communicate the schedule (if at all), and how you will produce an initial cost estimate (if at all). Each issue can be addressed by several strategies, each of which has trade-offs. Our experience is that this goals-driven, suggestive approach provides just enough guidance for solution delivery teams while being sufficiently flexible so that teams can tailor the process to address the context of the situation in which they find themselves in. The challenge is that it requires significant discipline by agile teams to consider the issues around each goal and then choose the strategy which that is most appropriate for them.
  5. Enterprise awareness.  Whether you like it or not, as you adopt agile you will constrained by the organizational ecosystem, and you need to act accordingly.  It takes discipline to be enterprise aware and to work with enterprise folks who may not be completely agile yet, and have the patience to help them.  It takes discipline to work with your operations and support staff in a “DevOps” manner throughout the lifecycle, particularly when they may not be motivated to do so.  Despite the fact that governing bodies such as project management offices (PMOs), architecture and database authorities, and operations may indeed be a source of impediments to your DAD adoption, these authorities serve important functions in any large enterprise.  Therefore a disciplined approach to proactively working with them and being a positive change agent to make collaboration with them more effective is required.
  6. Adopting a full delivery lifecycle.  Despite some agilists reluctance to admit that projects go through phases the DAD process framework explicitly recognizes that they do.  Building serious solutions requires a lot more than just doing the cool construction stuff.  It takes discipline to ignore this rhetoric and frame your project within the scope of a full delivery lifecycle.  The basic and advanced DAD lifecycles explicitly depict pre-delivery activities, a three-phase delivery lifecycle, and post-delivery activities (operations and support).
  7. Streamlining inception activities.  We devoted a lot of material in the DAD book to describing how to effectively address how to initiate a DAD project.  Unfortunately in our experience we have seen many organizations treat this phase as an opportunity to do massive amounts of upfront documentation in the form of project plans, charters, and requirements specifications.  Some people have referred to the practice of doing too much transitory documentation up front on an agile project (known as Sprint 0 in Scrum) as Water-Scrum-Fall.  We cannot stress enough that this is NOT the intent of the Inception phase.  While we provide many alternatives for documenting your vision in Inception, from very heavy to very light, you should take a minimalist approach to the Inception phase and strive to reach the stakeholder consensus milestone as quickly as possible.  If you are spending more than a few weeks on this phase, you may be regressing to a Water-Scrum-Fall approach.  It takes discipline to be aware of this trap and to streamline your approach as much as possible.
  8. Streamlining transition activities.  In most mid-to-large sized organizations the deployment of solutions is carefully controlled, particularly when the solutions share architectures and have project interdependencies.  For these reasons release cycles to your stakeholders are less frequent that you would like because of existing complexities within the environment.  However, the ability to frequently deploy value to your stakeholders is a competitive advantage; therefore you should reduce the release cycle as much as possible.  This requires a great degree of discipline in areas such as pre-production integration and deployment testing; regular coordination between project teams and with operations and support staff; Change management around both technology and requirements; and adoption of continuous deployment practices to such a degree that very frequent deployments are the norm and the Transition “phase” becomes an automated transition activity.
  9.  Adopting agile governance. It is easier to avoid your traditional governance and tell management that “agile is different” than it is to work with your governors to adapt your governance to properly guide the delivery of your agile teams.  Every organization has a necessary degree of governance and there are ways to make it especially effective on agile initiatives.  It takes discipline to work with your governors to help them understand how disciplined agile teams operate and then discipline to accept and conform to the resulting governance process.
  10. Moving to lean. For all DAD process goals we describe a range of options to address the issues pertaining to that goal.  These options ranged from traditional/heavier approaches that we generally advised against except in very specific situations to agile strategies to very lean strategies.  Generally, the leaner the strategy the greater the discipline it requires.

Adopting a disciplined approach to agile delivery requires the courage to rethink some of the agile rhetoric and make compromises where necessary for the benefit of the “whole enterprise” and not just the whole team.  In our experience most agile projects make certain compromises that are not classically agile in order to get the job done.  Rather than hiding this and fearing reprisals from those who would accuse you of regressing to a traditional approach, it is better to have the courage to take a pragmatic approach to using agile in your situation.

Effective application of DAD certainly requires discipline and skill, but in our experience the key determinant of success is the ability and willingness of the team to work well together and with  stakeholders, both within and external to the team.  For more writings about discipline within the DAD framework, select “Discipline” from the blog category list.

Comparing DAD to the Rational Unified Process (RUP) – Part 2

This post is a follow-up to Comparing DAD to the Rational Unified Process (RUP) – Part 1.  In that post I described in some detail why Disciplined Agile Delivery (DAD) is not “Agile RUP”.  DAD is quite different in both approach and content.  There are however some very good principles that the Unified Process (UP) incorporates that are not part of mainstream agile methods.  This post describes what parts of the UP made it into the DAD process decision framework.

DAD suggests a full delivery lifecycle approach similar to RUP.  DAD recognizes that despite some agile rhetoric projects do indeed go through specific phases.  RUP explicitly has four phases for Inception, Elaboration, Construction, and Transition.  For reasons that I described in the last post, DAD does not include an explicit Elaboration phase.  However the milestone for Elaboration is still in DAD which I will describe shortly.  As the DAD basic lifecycle diagram shows, DAD has three of the four RUP phases.

Disciplined Agile Lifecycle Basic

  • The Inception phase.  An important aspect  of DAD is its explicit inclusion of an Inception phase where project initiation activities occur.  As Scott Ambler says in one of his posts “Although phase tends to be a swear word within the agile community, the reality is that the vast majority of teams do some up front work at the beginning of a project.  While some people will mistakenly refer to this effort as Sprint/Iteration 0 it is easy to observe that on average this effort takes longer than the general perception (the 2009 Agile Project Initiation survey  found the average agile team spends 3.9 weeks in Inception)”.  So in DAD’s Inception phase (usually one iteration) we do some very lightweight visioning activities to properly frame the project.  The milestone for this phase is to obtain “Stakeholder consensus” on how to proceed.  In the book we describe various strategies to get through the Inception phase as quickly as possible, what needs to be done, and how to get stakeholders consensus.
  • The Construction phase.  This phase can be viewed as a set of iterations (Sprints in Scrum parlance) to build increments of the solution.  Within each iteration the team applies a hybrid of practices from Scrum, XP, Agile modeling, Agile data, and other methods to deliver the solution.  DAD recommends a risk-value approach of prioritizing work in the early iterations which draws from the RUP principle of mitigating risk as early as possible in the project by proving the architecture with a working solution.  We therefore balance delivering high-value work with delivering work related to mitigating these architectural risks.  Ideally we deliver stories/features in the early iteration that deliver functionality related to both high business value and risk mitigation (hence DAD’s “risk-value” lifecycle). It is worthwhile to have a checkpoint at the end of the early iterations to verify that indeed our technical risks have been addressed.  DAD has an explicit milestone for this called “Proven architecture”.  This is similar to the RUP Elaboration milestone without risking the confusion that the Elaboration phase often caused for RUP implementations.  All agile methods seek to deliver value into the hands of the stakeholders as quickly as possible.  In many if not most large enterprises it is difficult to actually deliver new increments of the solution at the end of each iteration.  DAD therefore recognizes this reality and assumes that in most cases there will be a number of iterations of Construction before the solution is actually deployed to the customer.  As we make clear in the book, although this is the classic DAD pattern, you should strive to be able to release your solution on a much more frequent basis in the spirit of  achieving the goal of “continuous delivery”.  The milestone for the end of Construction is that we have “Sufficient functionality” to deploy to the stakeholders.  This is the same milestone as the RUP’s Construction milestone.  During the Construction phase it may make sense to periodically review the progress of the project against the vision agreed to in Inception and potentially adjust course.  These optional milestones in DAD are referred to as “Project viability”.
  • The Transition phase.  DAD recognizes that for sophisticated enterprise agile projects often deploying the solution to the stakeholders is not a trivial exercise.  To account for this reality DAD incorporates the RUP Transition phase which is usually one short iteration.  As DAD teams, as well as the enterprise overall streamline their deployment processes this phase should become shorter and ideally disappear over time as continuous deployment becomes possible.  RUP’s Transition milestone is achieved when the customer is satisfied and self-sufficient.  DAD changes this to “Delighted stakeholders”.  This is similar to lean’s delighted customers but we recognize that in an enterprise there are more stakeholders to delight than just customers, such as production support for instance.  One aspect of RUP’s Transition phase is that it is not clear on when during the phase deployments actually take place.  Clearly stakeholders aren’t delighted and satisfied the day the solution goes “live”.  There is usually a period of stabilization, tuning, training etc. before the stakeholders are completely happy.  So DAD has a mid-Transition milestone called “Production ready”.  Some people formalize this as a “go/no go” decision.

So in summary, DAD frames an agile project within the context of an end-to-end risk-value lifecycle with specific milestones to ensure that the project is progressing appropriately.  These checkpoints give specific opportunities to change course, adapt, and progress into the next phases of the project.  While the lifecycle is similar to that of RUP, as described in Part 1 of this post it is important to realize that the actual work performed within the iterations is quite different and far more agile than a typical RUP project.

At Scott Ambler + Associates we are getting a lot of inquiries from companies seeking help to move from RUP to the more agile yet disciplined approach that DAD provides.

Comparing DAD to the Rational Unified Process (RUP) – Part 1

Last week I was discussing DAD with a new client and he asked me “Is DAD just an Agile version of RUP?”  In a word, no.  DAD is a framework composed of a hybrid of methods and practices as shown in the diagram.  It includes the best of Scrum, Extreme Programming (XP), Agile data and modeling, and yes, the Unified Process (UP).  DAD also includes additional content such as agile governance that is not present in any of these methods.  As the diagram indicates, probably the method that adds most to DAD is XP, not the UP.
The Rational Unified Process (RUP) started as a small manageable process framework targeted specifically for building software within the context of an iterative lifecycle.  However over time, Rational (and subsequently IBM) added additional guidance and artifacts to extend the applicability of RUP to all sorts of projects, such as package implementation, maintenance projects, technology specific guidance (J2EE, .Net etc.), systems engineering and may other project types.  It became unwieldy and hard to understand and apply successfully.  In fact it is frequently misused (with the Elaboration phase often being treated as a big requirements upfront (BRUF) phase as an example).  This misuse has been described by Julian Holmes as RINO (RUP in name only).  To be clear, RUP properly applied in the right circumstances can be very effective.  Unfortunately though, that often does not happen.  One of the issues with applying the RUP framework to different types of projects is that it is described as a “Use case-driven” approach.  Specifying requirements as use cases, and then creating component-based architecture from these use case realizations is fundamental to RUP.  This presents challenges for maintenance projects or package implementations where it may not make sense to produce use cases at all.

DAD does not prescribe a use case-driven approach, or insist that OOAD be rigorously applied to build out services/components.  A use case-driven approach is a potential practice to apply but there is a danger that this could lead to an exhaustive requirements specification which is not particularly agile.  We would prefer to use a user story-driven approach if that makes sense within the context of your project.  User stories might not be the right choice either.  Perhaps you are in a regulatory environment that demands a traditional software requirements specification (SRS).  The key point is that you will have to adapt to the situation that you find yourself in.  This is why we prioritize the team’s work with a work item list comprised of work items, rather than Scrum’s backlog comprised of user stories.  Using a work item list allows us the flexibility to put any type of work onto our backlog, extending the applicability of DAD to many types of projects beyond those for which RUP or Scrum would be ideally suited.

DAD is goal-driven, not artifact-driven.  It does not prescribe practices or specific artifacts.  Rather, it suggests alternative strategies than can be applied at certain parts of the lifecycle with the pros and cons for each, but which ones you choose is up to you.

In my next post I will describe which aspects of the Unified Process did make it into DAD and why.

The DAD Role of Architecture Owner

As you can see from this diagram, the DAD primary roles are similar to those of Scrum.  In Scrum, the product owner decides what will be built and in what order.  In DAD we recognize that architecture is a key source of project risk and someone needs to be responsible for ensuring the team mitigates this risk.  As a result the DAD process framework explicitly includes Agile Modeling’s role of architecture owner. The architecture owner is the person who owns the architecture decisions for the team and who facilitates the creation and evolution of the overall solution design.  The person in the role of team lead will often also be in the role of architecture owner.  This isn’t always the case, particularly at scale, but it is very common for smaller agile teams.

The responsibilities of the architecture owner include:

  • Guiding the creation and evolution of the architecture of the solution that the team is working on.  Note that the architecture owner is not solely responsible for the architecture, but that they lead the technical discussions.
  • Mentoring and coaching other team members in architecture practices and issues.
  • Understanding the architectural direction and standards of your organization and helping to ensure that the team adheres to them appropriately.
  • Understanding existing enterprise assets such as frameworks, patterns, subsystems and ensuring that the team uses them where appropriate.
  • Ensuring that the solution will be easy to support by encouraging good design and refactoring to minimize technical debt.
  • Ensuring that the solution is integrated and tested on a regular basis, ideally via the practice of continuous integration(CI).
  • Having the final say regarding technical decisions, but they try to avoid dictating the architectural direction in favor of a collaborative, team-based approach. The architecture owner should work very closely with the team lead to identify and determine strategies to mitigate key project technical risks.
  • Leads the initial architecture envisioning effort at the beginning of the project and supports the initial requirements envisioning effort (particularly when it comes to understanding and evolving the non-functional requirements for the solution).

One of the key reasons for having this role in DAD is that the architecture owner, like the product owner, has a say in work items that are added and prioritized in the work item list (backlog in Scrum parlance).  While business value is certainly a prime determinant of priorities, completing work related to mitigating technical risks is also important.  Additionally, a DAD goal is to deliver consumable solutions, not just working software.  As such, sometimes it is necessary to add work items that are technical in nature, for example related to error logging/monitoring.  Or perhaps work items need to be added to improve the continuous integration and deployment processes.

We have found that the concept of having both product and architecture owners ensures that the solution addresses both functional and non-functional requirements such as usability and supportability adequately.  In fact, on my current project, I worked with the product and architecture owners to negotiate their priorities such that the iteration underway includes not only a selection of high priority stories, but also a set of technical work items related to hardening the solution in preparation for entering the Transition phase of delivering the solution to the stakeholders.  Without a specific role of architecture owner, it can be difficult to escalate important technical work into the work item list.  As as result it is often done subversively without the knowledge of the product owner which is not a healthy practice, or worse it never gets done resulting in a poor quality solution.

Scott has written a good article that describes the architecture owner role in more depth.  You can view it here.

No role in DAD for an Analyst?

Why does DAD not have an explicit role for an Analyst?  This is a hot topic for those in this profession, and a subject that I have been asked to talk on, notably for the IIBA.  Without question classically trained analysts bring much needed soft skills and a structured approach to requirements elicitation and negotiation which may not be present in the other roles such as a product owner or a developer.  However, having these skills alone is not enough in an agile and lean world.

Unfortunately, professional organizations such as the Project Management Institute (PMI) and the International Institute of Business Analysts (IIBA) tend to encourage us to seek specialization and certifications over being cross-functional team members, which will be far more effective and valuable in the future.  This is not to say that these organizations do not deliver value in developing and maintaining standards of professional conduct and capability.  Attaining certifications (that require some degree of commitment and experience beyond a 2-day workshop) demonstrate commitment to a professional specialty.  This is admirable but I would suggest that this base of knowledge is just the start of being an effective team member on an agile project.  We should look outside our area of specialty to learn all we can about other aspects of software development.

It is my belief that in the near future, analysts will need to be competent testers if they intend to prosper in their profession.  An increasingly important skill is the ability to write requirements as executable tests.  My advice to analysts is to learn as much as you can about agile testing and seek opportunities to write your requirements as tests wherever possible.

For Business Analysts that are not interested in moving more toward the testing end of the spectrum there is another way to go.  Analysts can be good Product Owners, representing the customer on the project and by managing the scope and priorities.  In this role they can use their elicitation and facilitation skills to gain a clear understanding of what the customer needs (vs. wants).

Another potential career path is for the BA to move more into the area of traditional management consulting.  The IIBA is positioning the Business Analyst profession to be more strategic, identifying the need to have them present at the management table when key decisions are made regarding how the business and its architecture should evolve.  Our book on Disciplined Agile Delivery is about agile software development.  But not all business issues are solved by software.  Often it is the business process that needs to be fixed, and this is where traditional Business Analysis skills will always be needed.

In my opinion, one career path for analysts is going the way of the dinosaur though.  And unfortunately this career path is often the status quo.  Traditional projects expect Business Analysts to document business processes and requirements in batch up-front in a linear, waterfall fashion.  They then must obtain sign-offs before actually proceeding with implementing any of the requirements.  Subsequent changes to those requirements are discouraged, unless through a formal, time consuming and wasteful Change Request process.  This model clearly is flawed, and eventually most companies will change their approach.  High ceremony and bureaucratic organizations such as government will be the slowest to adapt, but private companies in a competitive environment will adapt their requirements capture approach to a more agile alternative or risk being left behind by their competitors that will be more “agile” in adapting both their business processes and the solutions that support them.

DAD: An Interview with Scott Ambler

Join Scott and I for an interview that both introduces and discusses Disciplined Agile Delivery, what it is, why we need it, and how it helps delivery teams achieve Agility @ Scale.  During the session we will also try to address as many questions from the attendees as we can.

Date: 13:00 EST, 19th January, 2012

For more information and how to register, visit the site for the Virtual Rational User Group for Methods and Practices.

Regards,
Julian

Julian Holmes
UPMentors.com

Chapters 5 & 7 of Disciplined Agile Delivery available on Safari Roughcuts for review

The following chapters  have now been uploaded to Safari Roughcuts here.

  • Chapter 5 – Forming disciplined agile teams
  • Chapter 7 – Case study: Initiating a DAD project

Chapter 6 will be available shortly.

We look forward to your comments.

Mark & Scott

Why do we need the DAD framework?

I’m writing this from the Agile Business Conference in London where I did a talk on DAD yesterday. Unfortunately I didn’t have much time to go into DAD in depth. A gentleman approached me today, saying that he is very interested in learning more about DAD but is not sure why it is needed with all the other methods out there.
This is a very good question, and I guess I should have been more clear in my talk. First of all, DAD is not a new method, but rather a general framework from which you can pick some “good ideas” which might makes sense for your organization or project. It also adds some structure that is missing from most agile methods. Here are some reasons that we think that the framework is worthwhile:

  • DAD is a hybrid of leading agile methods, bringing together a set of complimentary practices from methods such as Scrum, XP, Agile Modeling, Lean, & the Unified Process
  • most existing methods such as Scrum, do not have practices related to the full lifecyle (by design). Scrum for instance is focused mainly on management, rather than say, architecture. DADs hybrid approach harvests leading practices from across the lifecycle
  • DAD goes beyond agile rhetoric and acknowledges that certain enterprise practices don’t go away with agile, such as the need to collaborate with other projects, enterprise authorities such as architecture, database , and PMOs
  • an explicit recognition that most enterprise projects go through startup (Inception) and deployment (Transition) phases
  • DAD avoids branded terminology such as “sprint” and rather uses common sense terminology that is understandable regardless of one’s methodology preference

While the DAD framework is the work of IBM’s Chief Agile/Lean methodologist Scott Ambler, it is open and not trademarked by IBM.  It is meant to help promote and simplify proven agile practices, not replace them.  Rather than having to say “our shop does Scrum, with some XP practices, a bit of Kanban, etc…”, why not say that you are using the DAD framework? You can choose from any of the techniques from these methods without some agilist criticizing you that “you are not doing Scrum actually because it doesn’t believe in the XYZ practice that you are using from ABC method”

If you are doing Scrum now, for instance, you could currently say that you are using the DAD framework, as its guidance is a subset of practices you could use in DAD, As you add agile capability, and want accelerate your projects and increase quality, or add some required scaling techniques, you could draw additional ideas from DAD. BUT only if required and makes sense for you.

In summary, DAD provides a breadth of non-prescriptive guidance (good ideas that MIGHT make sense for you) with non-branded ideas that go beyond traditional agile methods to help deal with enterprise considerations that are a reality on most non-trivial projects.

Is your agile project environment “fragile”?

It never ceases to amaze me how many people and organisations seem to think that to become agile they just need to sprinkle some magic agile “pixie dust” around their projects and all will be transformed.

In my latest blog for UPMentors and IBM developerWorks, “Is your agile project environment “fragile?”, I try to dispel some of the notions and highlight the discipline required for an organisation to adopt agile practices and achieve Disciplined Agile Delivery.