What are the DAD Certification Levels

DAD Certification Levels

In adopting a Shuhari strategy for their certification program, the Disciplined Agile Consortium has established a program which allows an individual to achieve measurable and incremental success (belts) that can be achieved using an iterative approach to their learning and practical experience.


Here is a summary of the stages

  1. Shu (Learn) or beginning stage focuses on learning the basic techniques and philosophies of disciplined agile development. With a goal of achieving a White Belt and/or Yellow Belt
  2. Ha (Detach) or intermediate stage is represented by Green Belt certification and is based on seeking to understand the range of strategies available to you and when they are best applied
  3. Finally, Ri (Transcend) is the “master” stage, is represented by the Disciplined Agilist-Black Belt certification, is where you are consistently sharing your learning with others.


Here are the DAD consortium has established four certification levels:

  1. Disciplined Agilist-White Belt(Shu)
  2. Disciplined Agilist-Yellow Belt(Shu)
  3. Disciplined Agilist-Green Belt(Ha)
  4. Disciplined Agilist-Black Belt (Ri)

For more details, here is a link to DAD certification philosophy


IBM DevOps – Self Assessment survey

Reedy Feggins Jr

Recently read a good article on adopting “Continuous Delivery practices”. In the white paper, “Adopting IBM’s approach to continuous software delivery,” the author, Paul Bahr discussed IBM’s adoption framework for iteratively introducing new capabilities and planning improvements.

Capability Adoption Framework

In the  our-part blog series that outlined a good four-step process for getting started on your improvements journey (step 1, step 2, step 3 and step 4). The author also discussed that the first steps for planning your DevOps adoption was to take a 

For those organizations interested in baselining where they are with DevOps adoption. Here is an article describing a self-assessment survey you can take. http://ibm.co/1zOMkqH

Here is the link to the actual
IBM DevOps Practices Self Assessment survey.


DevWorks Article describing a self-assessment survey:  http://ibm.co/1zOMkqH

DevOps Survey:    https://ibm.biz/BdRVGy

View original post

Scaling Agile Planning to Support Large Distributed Programs

Earlier this month during the 2014 IBM Innovate Conference, I delivered a 1-hour seminar on scaling agile planning to support large programs.  If you didn’t get to travel to Florida for the conference, here is the session material for you to review.

DAG-2333: Scaling Agile Planning to Support Large Distributed Programs

Many organizations have embraced agile practices such as only Scrum and eXtreme Programming (XP), only to discover that while these practices provide great benefit to individual development teams, they don’t always scale when used at the project or program levels.

In this session, we explore real-world challenges and discuss how some of organizations have used practices from other agile methodologies such as Disciplined Agile Delivery (DAD) and Scaled Agile Framework (SAFe), to successfully scale to these levels





Agile Delivery Model

Now let’s take a look at the Scrum framework. Scrum is the best known and most widely adopted agile framework in the world today.[1]  With its emphasis on delivery high quality solutions faster and continuous improvement, Scrum teams value commitment, openness, and respect.

Agile teams respond to change by focusing on the customer’s immediate needs and by not doing anything that is not required immediately.  The Product Owner, the person that best represents the customer, selects the stories (or feature) that provides most valuable to the customer, and the whole team works on that feature.

  RTC ALM for Scrum


Agile is about delivering software as soon as possible, and then regularly and frequently. Scrum teams focus on working on valuable tasks each day until the PO is satisfied.

Rapidly responding to change and delivering in short intervals is often the most challenging part of adopting agile for those people who have spent most of their careers working with a traditional or waterfall method.

In addition, agile is about enjoying your work. Agile team are self-organizing, meaning the team, and everyone on it, is empowerment to make decisions that would otherwise be made by the project manager.  For example agile teams estimate their own work, work with the PO to decide which stories are prioritized for delivery.

Finally, Agile is about using the knowledge, ideas, and inspiration of everyone in the company.  Agile teams take time out to reflect on the recent past and to identify ways removing blocks or impediments to producing high quality code.

[1] Core Scrum — Values and roles, http://www.scrumalliance.org/why-scrum/core-scrum-values-roles

Comparing Waterfall and Rational Unified Process

Contrary to popular opinion, not every IT project can successfully adopt agile practices. Location of resources, team structure, corporate culture and even technology used, can all play a key factor in determining which development practices will work in an organization.  While many companies are actively seeking to use agile practices, such as XP or Scrum to help streamline production with fast, effective development practices that can give their customers what they want in the shortest time possible, elements of some of the traditional software development methods such as the “Waterfall” or “Rational Unified Process (RUP)” are often required to bridge the gaps that some of these new practices have. In the end, most organizations must adopt a blended approach that bests fits their software project, business culture, and development environment.

In this blog, I compare the strengths and weakness of some of the traditional software development practices – Waterfall and RUP – along with providing guidelines for adopting them. In a subsequent blog will compare these process to agile practices.


The traditional software development process, is often referred to as “Waterfall”, is a highly structured and sequential process that relies heavily on up-front planning and prescribed tasks that flow from one to another like a waterfall.[1] Typical phases in a project using Waterfall development are shown below.

Waterfall Process

Each phase usually requires its own set of subject matter experts (SME) responsible for creating the deliverables (requirements documents, design document, test plans, detailed designs, etc…) to meet carefully scripted milestones. In Waterfall, the next phase typically cannot be started until the previous one has been completed. The goal is to gather and analyze all the detailed requirements early in the process so that a complete solution can be architect-ed and build with highly predictable results.

Waterfall development can work well for complex or mission-critical systems or for and for organizations that require the highest levels of fault tolerance (such as the military or aerospace).  However, projects using Waterfall processes take too long, in many cases months or years, to produce results that can be verified by the user and often and lacks the flexibility for today’s environment. In addition, because Waterfall projects require that all the requirements be defined upfront (often referred to as Big Up Front Requirements – BUFR), these projects often do not provide business value in today’s fast-paced software market as in many cases requirements changes result in expenses change requests or buggy systems.

Rational Unified Process

The Rational Unified Process® is a Software Engineering Process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end-users, within a predictable schedule and budget.  RUP is “use-case driven, architecture-centric, and incremental and iterative”.

RUP Diagram

Software projects that use RUP divide the project time-line into four consecutive phases.

Inception, where the project’s scope, estimated costs, risks, business case, environment and architecture are identified.

Elaboration, where requirements are specified in detail, architecture is validated, the project environment is further defined and the project team is configured.

Construction, where the software is built and tested and supporting documentation is produced.

Transition, where the software is system tested, user tested, reworked and deployed.

Each phase is concluded with a well-defined milestonee—a point in time at which certain critical decisions must be made and therefore key goals must have been achieved. Iterations occur in each phase.  Activities in iterations are focused on one of the four activities: gathering requirements, analyzing, designing, implementing, and testing.  Each of these activities place a more or less important role as the project moves from phase to phase.

RUP also defines the roles and activities of team members in-depth and relies at each stage on the production of visual models, which are rich graphical representations of software systems, and specific use cases rather than the large amounts of documentation required for each stage of Waterfall. All team members have access to the same large knowledge base of guidelines, templates, tools, and other items to ensure that they share the same language and perspective on the project.[2]

Proponents stress that it enhances team productivity by providing each team member with guidelines, templates and tool mentors for all critical development activities. While critics consider it to be too heavy, sighting the large number of documents and other artifacts that must be created to successfully adopt RUP properly. Also while RUP is an iterative approach, the Inception and Elaboration, still provide plenty of opportunity for BUFR to be produced and the remaining development cycles follow somewhat of a waterfall approach to code development and doesn’t stress the need to produce working code as fast as possible.

RUP has been around for 20+ years and has evolved into a proven software development method that has been used by many different teams in many different situations.  It is easy to find resources and skills and has many advantages over traditional waterfall approach


  1. Waterfall, RUP and Agile: Which is Right for You? (n.d.). Retrieved 03-02-2011 from http://www.ebizq.net/topics/dev_tools/features/11821.html
  2. Philippe Kruchten, The Rational Unified Process, An Introduction, Second Edition, Addison-Wesley, 2000.
  3. David Kohrell, Using RUP to manage small projects and teams, retrieve 03-01-2011, http://www.ibm.com/developerworks/rational/library/jul05/kohrell/?S_TACT=105AGY82&S_CMP=MAVE
  4. Goran V. Grahn, Boris Karlsson, Implementing RUP in an organization, ftp://ftp.software.ibm.com/software/rational/web/whitepapers/2003/rup_volvo.pdf

[1] Waterfall, RUP and Agile: Which is Right for You? (n.d.). Retrieved 03-02-2011 from http://www.ebizq.net/topics/dev_tools/features/11821.html

[2] David Kohrell, Using RUP to manage small projects and teams

How are Epics, Stories and Tasks related to each other?

Written by Reedy Feggins, IBM

Work items are the fundamental mechanism in Rational Team Concert (RTC) used to coordinate, and track development tasks.[1] RTC provides several out-of-the-box work items types including Epic, Story, Task and Defect.  Each work item has its own workflow and associated set of attributes used to govern progress status, reporting and collaboration.  Work items are the hub for linkage between many Rational Team Concert artifacts (e.g. other work items, builds, work items, and change sets), as well as providing support for integration with other products.

While RTC allows teams to link work items in any manner they choose, to keep it simple in when the customer is using the SCRUM Process Template, several of my customer implementation, I have recommended the following work item hierarchy: Epic story->Story -> Task/defect, see figure below.

Epics, Story andTask - Typical RTC work item hiearchy

User stories are a good approach to capturing customer requirements without having to create formalized requirement documents or incurring the extra effort to maintaining them. The intention is to speed up the requirement definition process, respond faster to changing requirements and communicate requirements in the language of the customer using scenarios that can be easily validated.

By default the RTC Scrum process template, Epics Stories are defined as top-level-item while Tasks are not.  Each Story can be broken down into smaller tasks but it is not required. In addition we recommend that the RTC process template be updated to make the Defect a top-level-item.

RTC Epic Work Item - Screen Capture

Finally, RTC allows team to use the Work Item customization to create new work item types or modify existing ones in order to support the development process that your team follows. For additional information see Work item tracking on Jazz.net.

[1] APA: Work item tracking – Rational Team Concert – Projects – Jazz … (n.d.). Retrieved 02/20/2011 from http://jazz.net/projects/rational-team-concert/features/wi

An Agile Approach for Adopting Agile Practices

Written by Reedy Feggins, Jr, IBM

Agile is all about people, flexibility, trust, communication, and feedback.  To be successful, an organization must instill these values at all levels in the organization.  In this first of a multi-part blog, author Reedy Feggins Jr, IBM Solution Architect and Agile Coach, describes some of the common challenges that many large organizations face when attempting to adopt Agile practices on an enterprise scale,  techniques that he has used successfully in the past with these organizations and the critical success factors from these Agile transformation efforts based on his four years experience helping organizations inside and outside IBM adopt agile practices.

Introducing Agile in an Organization

Within almost every business domain, companies are working to transform their software development organizations by adopting agile practices to improve product quality, team efficiency and on-time delivery.  While once considered viable only for small, co-located teams, these practices are now being successfully implemented by organizations with larger distributed teams through the effective use of collaboration software development tooling such as those found in the IBM Jazz Platform to assist with  in an effort to achieve these same benefits). Most successful transformations must have strong support from the top and the needs of this critical set of stakeholders must be understood.  To get solid agile transformation, most organizations must focus their improvement activities on three critical aspects.

People, Process, Tools


  • What skills do the  resources have
  • How are the teams organized
  • What practical experiences do they need


  • What processes are currently being used?  Waterfall, iterative, hybrid
  • Depending on the process different practices may need to be adopted or emphasized.


  • What tools are needed to support the practices?
  • Continuous Integration, Automated Testing,  Agile Planning and Collaboration support

While each adoption effort is different, over the course of several agile adoption projects inside and outside IBM, a common set of principles have begun to emerge. Agile adoption efforts must be

  • Driven from Top down and implemented from the bottom up
  • Business-value focused
  • Adopted Iteratively
  • Agile in its approach (Learn and Grow as situation evolves)
  • Adopt a test-driven adoption strategy

Driven from Top down and Bottom Up

Large-scale agile transformation requires the entire organization to be committed to its success. Most organizations can be roughly grouped into three viewed to be made of three layers of people with a varying degree of authority. Figure 1: Stakeholders in a typical organization Interests / Needs

  1. How productive are our delivery teams
  2. How accurate is our planning and estimation
  3. What are our development costs?
  4. What is our return-on-investment? What business value are we achieving
  5. What is our teams velocity
  6. Is our Sprint burn-down on track
  7. What risks have we identified / mitigated
  8. What is our Defect Density / Test Coverage

Leadership must champion the importance of the adoption activities (such as training and mentoring). An effective program really comes from the top and unless you have their support it’s very difficult for people to adopt the programs and implement them. Recommendations include:

  • The team overseeing the adopting efforts must use agile techniques to Learn and Grow.
  • The team must establish success criteria at each level (Business level, Project level and Individual level)

As organizations scale up their agile transformation efforts, they will need to build a core staff of resources capable of assessing the needs of new teams and helping new teams to adopt the selected practices.  Common challenges include:

  1. Funding training and enablement programs. Most organizations now have budget and travel restrictions that limit most organizations ability to send people to training classes
  2. Finding the right resources to training. Often times getting skilled resources to attend live training sessions is a big challenge in itself as most people have little time of extended formal training.
  3. Convincing people that enablement is important—especially mid-level managers.
  4. Scaling up training was a big challenge and while this can be overcome through virtual enablement sessions and media training, there is not substitute for face to face training
  5. Implementation of training can be a challenge, especially across multiple locations.

While some of these concerns can be mitigated by self-paced training, virtual training and media training videos, there is often no substitute for face-to-face training.  The use of advanced e-Learning techniques addresses several of these issues but there are often communication and technical difficulties that are hard to overcome. Many times scheduling and commitment are some of the largest issues that need to be constantly addressed.

Business Value Focused

First and foremost the agile adoption efforts must be focused on increasing the value of software development to the business.  The practices selected and the order in which they are adopted must be selected to deliver the greatest potential value to the business. In most cases these values fall into one of the following categories:

  • Reduced time to market
  • Increased value to business
  • Increased quality
  • Increased flexibility
  • Increased visibility
  • Reduced cost

Adopted Iteratively

Large transformation efforts especially agile transformations are not easy. But economics are driving all organizations to seek creative approaches for cutting costs, improving performance while delivering value to their clients in this competitive marketplace. More companies are moving towards taking advantage of Lean principles to help cut waste and using Agile for Managing IT and Non-IT project efforts for maximum ROI. At IBM we often recommend an iterative and incremental approach for strategic enterprise agile transformation.  This high level pattern uses adoption “waves” instead of a rigorous step-by-step procedure (waterfall) which won’t account for the evolutionary nature needed for this transformation. During each wave the team overseeing the agile transformation focuses on different agile practices that correlate to the business values driving that wave.

Agile Adoption Waves

Wave One: (or Mobilization) Focuses on establishing a firm agile foundation and deliver initial value by establishing a Center of Excellence (CoE) staffed by resources responsible for the supporting the Agile Transformation. The CoE should be comprised of Agile Transformation team members; Mid-level managers and upper management guide the overall transformation. This team is responsible for

  • Obtaining executive sponsorship and commitment
  • Cultivating experienced agile mentors and coaches from within the organizations
  • Building agile infrastructure (C0E, process, tool)
  • Demonstrating measurable value by piloting agile practices on 1 or 2 process to show quick-wins and increase visibility

Wave Two: (or Early Adopters) Focuses on building on early success by helping a relatively small number of internal employees to become internal coach/trainers.   The Agile Coaches must work with employees to develop a sufficient number of people who are capable agile facilitators (Scrum Masters).  This team engages the trainers/coaches to do the following things roughly simultaneously:

  • Conduct awareness sessions to introduce everyone in the organization to agile concepts
  • Do initial cultural and process assessments to track progress over time
  • Start _everyone_ in the organization using the agile meta-process

These are the people will slowly take over from the external coaches.  They learn about agile methods more deeply: practices, principles, variations, techniques, and tools.  They learn to be effective facilitators who have the trust of their co-workers.  These facilitators then become responsible for ensuring that everyone else is using the agile meta-process for effective learning and simultaneously applying appropriate agile practices.

Wave Three: (or Enterprise Transformation) Finally, the coaches work with the Agile Transformation Team to help a relatively small number of employees to become internal coach/trainers.  These are the people who will take over from the external coaches. As for ongoing assistance, the coaches should be working in a consultative capacity as the organization struggles with obstacles, restructuring, and the deeper culture changes.  Like any change effort, there are five critical components: sponsorship, communication, training, support and strategy.  The coaches should be advising the Agile Transformation Team and management on how these five components can best be handled for the agile transformation.

Agile in it’s Approach

In the early days the project chosen to pilot Agile practices were often smaller green-field projects that were smaller in scope and relatively low risk if problems arose. But today many companies need to apply agile practices to a broader set of projects requiring the teams to adapt to many of the agile scaling factors spoken of Scott Ambler in his work on Agility@Scale: distribution, organization, and technical complexity to name a few. Agile techniques, such as test-driven development (TDD), continuous integration, iterative development, agile modeling, daily stand-up meetings, and so on are quickly being adopted within large IT organizations. Today most teams usually start with a core set of agile practices such as those found in Scrum and then extend them. For example, where Scrum uses a single prioritized list of User Stories (i.e., requirements) called a product backlog, many organizations need to take this practice one step further and use backlog to track all “value-added” work, even the non-requirement related work such as managing defects, prioritizing stakeholders needs and reviewing products of other teams, and so on. New work items, including those items identified as part of your user testing activities, are added to the stack in the appropriate place. The Product Owner, with input from  the other project stakeholders has the right to define new requirements, change their minds about existing requirements, and even reprioritize requirements as they see fit.  However, the Product Owner must also be responsible for making the final decision and providing information in a timely manner.

Regular Delivery of Working Software

  • Only valid measure of progress
  • Provides visible results to stakeholders
  • True earned value, not documentation-based “earned value”

Daily Stakeholder Interaction

  • On-Site Customer
  • Active Stakeholder Participation
  • A Product Owner that understands business priorities driving change to the backlog

Continuous Integration

  • Automatically compile, test, and style check your code
  • Continuous code integration is nice
  • Continuous system integration is nicer

Use a test-driven adoption strategy. (i.e. validates your results)

Most developers can understand and relate to identifying and fixing code smells as it relates to their development methodology or practices. But agile transformations on a large scale must also watch out for “Business smells” and “Process smells”.  Business smells are issues that affect the business and are visible to customers while process smells are only visible to the development team. Some common business smells include:

  • Time-to-market – delivering new features to the customer takes too long
  • Little or No Real Value – Too many unused features by the customer.
  • Quality Problems – Software is not useful to the customer.
  • Too Expensive – Software is too expensive to build.

Lessons Learned

  • Pilot a proven Agile approach (e.g., Disciplined Agile Delivery) first before customizing it (don’t start by changing an approach that works)
  • Understand the motivation behind a specific practice before (adding / dropping)
  • Start with a small Pilot, prove success, learn from the pilot, and then scale Agile adoption (avoid too much change, too fast)
  • Impacted Teams must see value so  avoid the “Checklist Agile” adoption
  • Avoid WAGILE (Waterfall Agile – e.g, BUFR Big Up Front Requirements)
  • Use a wave of change Adoption Roll out strategy
  • Develop new incentives that recognize team delivery instead of individual delivery


From my experiences, successful  enterprise agile transformations  require the proper mixture of top-down and bottom up activities.   Agile transformation  efforts are much  smoother when buy in and continued support is obtained from  sponsors high up in the organizations.  Results are more tangible when the impacted teams help define the values, practices and tools to be adopted.  With both approaches  in play,  I firmly believe that any organization can succeed.


1.      See http://agilemanifesto.org.

2.      See “Benefits of a Top-Down Agile Adoption Strategy”, Venkatesh Krishnamurthy, Agile Journal,  May 2007

3.      See Patterns of Agile Practice Adoption, posted July 13th, 2010 by John Turner

4.      See Agile Transformation vs. Agile Adoption,

5.      See “Working in Priority Order: Agile Change Management”, www.agilemodeling.com/essays/agileRequirements.htm

6.      See Agile Advice – Working with Agile Methods (Scrum, OpenAgile ..,), http://www.agileadvice.com/page/3/ (accessed February 16, 2011).

About the Author

Reedy Feggins, Jr, is a Solution Architect and Agile Coach at IBM Rational Software, a global software development company. Reedy is a certified ScrumMaster and PMP certified Project Manger. In this role, he trains, mentors and coaches teams in implementing practices such as Scrum, XP and Disciplined Agile Delivery (DAD). Reedy is also a IBM subject matter expert (SME) supporting the adoption of several IBM software development tools: Rational Team Concert (RTC), Rational Quality Manager (RQM), Rational Requirement Composer (RRC), RequisitePro, ClearQuest and ClearCase.  He has extensive experience mentoring teams over the past four years has given him the ability to assess business needs, craft an adoption strategy and provide organizations with practical experience implementing the appropriate Agile adoption strategies.