Category Archives: People

Agile is supposed to be easy, right?

The Agile manifesto is only 4 lines, there are only 12 principles for agile software and the original Scrum Guide was less than 20 pages, so how hard can Agile be?

 

Chess has only a couple of dozen basic moves so how hard can it be to get to checkmate?

 

 

How many times have you heard?

  • All you need to be Agile is to get the team doing a few funky ceremonies

Or the approach to evolving a team from forming to performing:

  • If the team isn’t performing after a month then the manager is not effective.

Despite the apparent simplicity of Agile, transforming to Agile is hard and the learning curve is very steep.  Depending on the team and the individuals, a transformation from waterfall to a high performing Agile team can take anywhere from 6 months to a year or more.  That’s not to say that they won’t be productive over that period of time.  In fact, they will start delivering business value at the end of the first iteration, but the team will be in constant growth and development over that period of time because not only do the people have to learn a new process, they also need to learn a new way of thinking as well as a new way of working as a team.

1.0 A new process

Aside from being excited to work with the thought leaders in the agile world, the reason I joined with SA+A is because of the Discipline Agile Delivery (DAD) decision framework and the way it captured all the tough stuff that I had been wrestling with for years.  With many years of experience building agile teams, I considered myself somewhat of an expert with answers to a lot of the difficult questions.  When I reviewed the DAD framework I realized that the answers I had gained from my own personal experience would not apply in all circumstances or for all teams.  Context counts.  The DAD Agile/Basic and Lean/Advanced project lifecycles have three phases: inception, construction and transition.  Each phase has a collection of process goals, and each goal encompasses several process decision points.  And, each decision point has a collection of options to choose from.  These process goals, decision points and options have been empirically assembled by analyzing many agile teams to see what makes an agile team successful.  This framework gives a team the ability to define a process that works for them.  Is this difficult to do?  Absolutely!  Defining a process to use is always difficult. BUT…..  The framework provides some guidance. Each goal option has default options that the team can use to get started and the options are listed in preference order so the team can easily pick an initial option.  As the team evolves and matures they can chose the more advanced options and evolve and mature their process.  Does the framework include all possible options?  Definitely not, but the options are certainly extensive.  The framework has evolved over time and continues to evolve as the coaches and thought leaders gain more experience and work with more diverse teams.

No matter which lifecycle the team has chosen to use; whether the team is using classic Scrum (Basic/Agile) or Kanban (Advanced/Lean) or a tailored process created using a framework such as DAD, the team is going to need practice and discipline to get it right.  That means, executing the lifecycle, doing periodic retrospectives, updating the process and then repeating again and again until they get it right.  Changing behaviors is hard and the team will struggle to be successful.

2.0 A new way of thinking

No matter how you cut it, transforming to Agile is a cultural change and culture changes are hard.  Not only is it hard for those who want to make the change but almost inevitably there will be pockets of resistance from people are happy with “the way we’ve always done it”.  Unfortunately, political infighting is the biggest risk to innovation. It is going to happen, you may as well brace yourself for it.

The roles are changing from traditional roles (such as: developer, business analyst (BA), system analyst (SA), quality assurance (QA) and project manager (PM), to new unfamiliar roles (such as: product owner (PO), team lead (TL), architecture owner (AO) and team member).  The traditional roles may be deeply embedded in your HR hiring and performance review processes. Transitioning to the new roles will require a realignment of skills and abilities that is bound to cause great consternation amongst the team members.  Often this is a very difficult transition for project managers, in particular, because they find that a lot of the traditional tasks (i.e. work breakdown structures, planning, estimating, etc.) are now the responsibility of the whole team.

The team needs to start thinking in smaller deliverable pieces.  The concept of delivering a complete system from known specifications at the beginning of the project has been the fallacy of traditional development.  The cost of delaying delivery to the very end of the project and the lack of ability to meet actual customer needs can be eliminated by delivering minimum functionality early and augmenting with new and improved functionality iteration after iteration in close collaboration with the end customer.  But moving to this model of continuously delivering can be a tough adjustment for developers.  Even (or maybe especially) for seasoned developers, the concept of starting to build and deliver not knowing all the detailed specifications up front can be very unsettling. Getting comfortable with this model takes time and experience before developers cease to fall back on old behaviors.

One of the pillars of agile is complete transparency with the business and the stakeholders into the team, the process they are using and the delivery of the business functionality.  With the business embedded in the team on a day to day basis and iteration reviews to demonstration and approve all the deliverables from each iteration, there is no hiding problems when they occur and no hiding late deliveries or failed iterations.  On the flip side, the business is there to celebrate the wins and recognize the deliveries at the end of each iterations and they are part of determining the velocity of the team and adjusting the schedule to match the velocity.

The new way of thinking also requires new tools.  Tools that can build dashboards to automate and display the development intelligence metrics that provide transparency into the team’s performance.  Tools that automate configuration management, continuous integration and continuous integration as well as automated testing.  All of these endeavors are hard and required skilled individuals to lead; none of these comes for free.

3. A new way of working with others

More people skills are required by everyone.  People are now going to be working much closer together physically and will be interacting and collaborating on a much more frequent basis.  Experience working together (often for many years) may give an advantage to some team members, however, they still need to learn how to work together as a team.

3.1 Team Development Phases

Tuckman’s team development model includes the phases: forming, storming, norming, and performing. These phases are all necessary and inevitable in order for the team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results.  The number of iterations required to move through the phases will vary by team depending on factors such as: company culture, skills, experience, familiarity with each other, leadership (or lack thereof), external influences and coaching etc. Teams may also plateau in a phase before entering the next phase.

Agile teams will go through the four Tuckman phases:

  1. Forming. All teams will go through the forming phase. Typically this take 4 to 6 iterations for the team to: understand the lifecycle process, understand how to work together, understand what the team goal is, and most importantly to get comfortable enough with each other to risk the possibility of conflict.  During this phase, the team’s velocity will vary considerably especially for the expected failed iterations although there should generally be a trend upward in the velocity.  Retrospectives in this phase tend to be very cordial and factual because everyone is avoiding conflict.
  2. Storming. The storming phase can be very upsetting to both the team members and team managers. Often managers will step in to solve the storming issues without realizing that it is a necessary phase for the team to work through on their own.  Conflict, disagreements and personality clashes must get resolved before the team can move to the next phase.  Unfortunately, this phase is a make or break phase and it is hard to predict just how many iterations it will take but it is not usual to expect 3 or 4 pretty rough iterations.  Some teams will completely disintegrate during this phase and it is certainly not unusual to have a decrease in velocity during this phase.  Some members of the team may find they have basic incompatibilities and need to move to another team and this change in team membership can revert the team back to the forming phase.  The retrospectives tend to be very interesting and intense during this phase as they deal with the inter-personal issues of the team.  You can pretty much expect that there are going to be some hurt feelings no matter how safe an environment you have.
  3. Norming. The norming phase is when the team comes back together stronger and more cohesive for having weathered the storming phase. They have resolved their issues and have developed a new synergy where the team just “works well together” and it is fun to be part of the team. The team velocity should trend upward and then level off as the team hits its capacity consistently.  With the new-found synergy of the team, the retrospectives can focus on process improvement and optimizing the operation of the team with the hope of transitioning to the performing phase.
  4. Performing. The performing phase is the goal for all teams but very few actually get to this phase. Not all teams can get to the high level of performance of a Special Ops team where each member knows exactly what their team mates are doing and what they need to do to work as a cohesive unit.  A team in performing phase no longer needs a coach or supervision but can operate autonomously and efficiently.

3.2 Team changes everything

With self-organizing teams, decisions are now made at the team level rather than at the PM or manager levels.  This can be a difficult transition for both the team members and the managers.  Team members are often use to others making the decisions for them and wait for decisions or are reluctant to make decisions.  Managers often feel disempowered when decisions are no longer in their hands because the decisions are made by the team.

The team still has the responsibility to do the traditional activities such as; analysis, design, development testing and deployment.  However, under the new model, the team also takes on the inception responsibilities of: developing user stories, sizing the stories, estimating the stories, creating the product and architectural vision, and developing the release plan.   During construction the team also has to: plan the iteration, do look ahead planning, and have an iteration review (i.e. demo) with the stakeholders.  To keep the team working together they need to have the daily coordination meeting (i.e. Scrum) and to keep the team growing and evolving of course they need to do the retrospective at the end of each iteration.

Thinking, analyzing, planning and building just-in-time is a new way of thinking for a traditional team.  The inception phase in particular can be a difficult adjustment.  Designers and developers are used to doing all the analysis and design upfront.  Doing just enough analysis to be confident of a solution and then writing the user stories to do the work and build the plan is a difficult transition.  Writing user stories so they can get started and learn as they go is a very difficult transition.  Building just the simplest framework and then adding required features and functionality as needed requires practice, training and reinforcement.

There is much more focus on delivering quality because the team is responsible for development, delivery as well as product support.

4.0 The Bottom Line

Chess has only a couple of dozen basic moves and so it is simple to learn the basics.  However, after 3 moves there can be several billion moves available making it so complex that it can take a lifetime to master.  Transforming to Agile is a lot like that.  It looks very simple on the surface but under the covers it can get very complex very quickly.  That’s where the value of a good coach comes in.  You need a coach who brings a lot of experience to the table who will be open and honest with you about what needs to be done and how to get a successful transformation.

Where Do Product Owners Come From?

People

A common challenge that we run into when working with organizations adopting Disciplined Agile strategies is helping them to identify and then coach people for the Product Owner (PO) role. This is often easier said than done due to the dearth of people with the required sill and mindset. In this blog we explore several strategies to address this challenge.

What Are You Looking for in a Product Owner?

Let’s begin with a review of the requirements for a good product owner:

  1. Analysis skills. POs need to be able to elicit requirements, explore them with stakeholders, negotiate priorities, facilitate modeling sessions, and in some cases document requirements.
  2. Decision-making authority. POs need to be empowered to prioritize the work of the team AND need to be comfortable with doing so.
  3. Good stakeholder contacts. POs need to know who to work with in the entire range of stakeholders, including both business and technical stakeholders.
  4. Full-time availability. This is a full time job, and at scale often proves to require more than a single person in the role (more on this in future blog postings). They’re available to the team on a daily basis.
  5. You want them in the position for several years. It takes time to grow an effective PO, depending on the background of the person we’ve seen people take between six and eighteen months to truly become comfortable in the role. This is a fairly large investment for your organization, so once you’ve made that investment its reasonable to want someone to stay in the role for at least a few years.
  6. They understand both your business domain and IT infrastructure. When taking a Disciplined Agile approach to product ownership the PO is responsible for representing all stakeholders, including both technical and business stakeholders. An implication of that is that POs should have a good understanding of the business domain and direction as well as your existing IT infrastructure and the direction that it’s going in. These understandings will be very important for prioritizing the work effectively.

Given the skill requirements it shouldn’t be surprising to anyone that there is a shortage of candidates for the PO role in most organizations. Let’s explore your options.

Potential Sources

There are several potential sources of new product owners. The following table compares and contrasts these options. As you can see there is no ideal option available to you, and the reality is that you will likely need to obtain PO candidates from whatever source you can find.

Potential Source Advantages Disadvantages
Business analyst
  • Strong analysis skills
  • May have a very good understanding of the overall business
  • Likely to have good stakeholder contacts
  • Likely available full time
  • May not have decision making authority nor be comfortable with it
  • May not have an understanding of the technical infrastructure
Business executive
  • Has decision making authority and experience
  • Likely has a good understanding of the business
  • Unlikely to have the time to be a product owner
  • Many only be focused on a single line of business (LoB)
  • Unlikely to have a sufficient understanding of the technical infrastructure
  • Unlikely to have good analysis skills
New hire
  • You can potentially hire someone with the requisite skills
  • Available full time
  • They are unlikely to have the stakeholder contacts, or understanding of your organization, required to be effective (in the short term)
Project manager
  • Has decision making authority and experience
  • Might have decent analysis skills
  • Likely available full time

 

  • May not have a sufficient understanding of the technical infrastructure
  • May not have full range of stakeholder contacts
  • May not have good relationship with delivery team
Senior business person
  • Likely strong at a single LoB
  • May have decision making authority and experience
  • Likely to have very strong connections in the business
  • Rarely available full-time
  • May not have an understanding of the full range of business
  • Unlikely to have an understanding of the technical infrastructure nor connections with technical stakeholders
  • May not have analysis skills
System analyst
  • Strong analysis skills
  • Likely to have an understanding of the technical infrastructure and the overall business
  • Available full time
  • May not have strong connections with business stakeholders

An interesting strategy that we’ve found fruitful, albeit one that borders on ageism, is to look for potential candidates whom have been with your organization for a long time and who are getting close to retirement. These are experienced people who therefore are likely to have a good understanding of your organization and where it’s headed, they very likely have a good contacts throughout your organization, and they’re very likely looking for an interesting and stable position that will last until they’re ready to retire.  Given that the investment required to create a Product Owner is rather steep so therefore you want someone willing to stay in the position for at least several years, and given that these are experienced people looking for a position that will last several years, it’s a very good alignment that you should consider taking advantage of.

Have a Clear Career Path

A critical success factor for attracting people to the role of PO is to have a clear and viable career path for them. If it isn’t obvious to people where they would go next after becoming a PO, or worse yet if becoming a PO is seen as a career dead end, then why would anyone choose to step into this role? One option for POs is to become product managers, if a product management function exists in your organization. Another career path is for POs to move into a senior business or IT leadership position. Being a PO gives people a deeper understanding of how IT fits into the larger organization and how it works in practice – key skills for anyone in senior management these days.

 

Stable Teams Over Project Teams

One of the interesting trends that we’re seeing within organizations taking a disciplined agile approach to solution delivery is the preference for stable teams. Stable teams, also called stable product teams or simply long-term teams, are exactly as they sound – they remain (reasonably) stable over time, lasting longer than the life of a single project. This blog explores the differences between project teams and stable teams and then overviews the advantages and disadvantages of the stable team approach.  We also explore the issue of how stable teams evolve over time.

Stable Teams

As you can see in the following diagram, with a project team approach we say that we bring the team to the work. What we mean by that is that we first identify the need to run a project, perhaps to build the new release of an existing solution or to build the initial release of a new solution, we build a team to do the work.   Once the work is done, in this case the solution is successfully released into production, the team is disbanded and its team members move on to other things.

Stable teams vs project teams

The stable team approach is a bit different. In this case we first build an effective team then we continuously bring valuable work to the team to accomplish. In this situation the work never really ends, but instead we replenish the team’s work item list (or work item pool depending on the lifecycle being followed) regularly. The team stays together and continues to produce value for your organization over time.

Of course the term “stable team” is a bit of a misnomer as they do evolve over time. For example, many people like to stay on a team for a couple of years and then move on to another team to gain new skills and perspectives. This is good for them and good for your organization as it helps to keep your teams fresh. Sometimes you will want to grow or shrink a team. Sometimes you will discover that two people aren’t working well together and you need to split them up. The point is that there are very good reasons for your stable teams to evolve over time.

We wouldn’t be disciplined if we didn’t explore the trade-offs involved with stable teams.

The Advantages of Stable Teams

There are several advantages to stable teams:

  1. Lower management overhead. There is clearly less “resource management” to be done because you’re not constantly forming and disbanding project teams. In fact, this lower need for resource management activities is one of several factors why agile IT organizations need managers than non-agile IT organizations.
  2. Easier team budgeting. The annual budget for a stable team is incredibly straightforward to calculate: Multiply the number of people on the team by the fully burdened cost of an IT person for your organization. Once again, less management work required for this.
  3. You build better teams. When you build project teams you tend to take the people who are currently available (often referred to as sitting on the bench). With a stable team approach you’re motivated to build your teams with the right people, and very often its best for the team to build itself by inviting others who they believe will fit in well.
  4. There is greater opportunities to build trust within the team.  It takes time to build trust within a team.  Greater trust leads to greater willingness to work together in a more streamlined manner.  As Stephen Covey insightfully points out, trust enables speed.
  5. There’s a greater opportunity for safety.  It takes time to build an environment where people feel safe. In safe environments there is a much greater chance that they will share ideas and be willing to try new things because they don’t fear being thought less of or even punished.
  6. There is less overhead from team formation. You’re forming teams far less often with a stable approach compared to a project team approach, hence there is less overhead in total for your organization.
  7. Better team performance.  Consider the analogy of a train.  Just like it takes time to bring the train up to cruising speed it takes time for the team to jell.  Bringing work to a seasoned team that works together well is like jumping onto a train going at full speed: it’s faster in both cases because you don’t have to get going from a full stop.
  8. You have more efficient utilization of staff. With this approach it is far less likely that someone will be “sitting on the bench” because they will instead be an active member of a team. When someone is hired it is directly into a team. Throughout their career they will move from team to team as appropriate. The only time that they might not be utilized is when their on vacation, sabbatical, or if you purposefully disband a team. The first two reasons are something you still have with the project team approach, and the last reason should happen a lot less often.
  9. Your teams are more likely to improve. When a team knows that they will be working together for a long time, and particularly when they are responsible for the entire delivery lifecycle from beginning to end, they are more likely to streamline their work so as to make things better for themselves.

 

The Disadvantages of Stable Teams

There are several disadvantages to stable teams:

  1. Teams can become too stable. A real danger of stable teams is the potential for groupthink – everyone on the team starts to think and work in a common way, thereby being in danger to common blindspots. Luckily people still want to move to other teams for career management reasons, offering the opportunity to bring new viewpoints into other teams. In the Disciplined Agile (DA) framework we have the continuous improvement process blade which supports sharing of ideas across teams so that can also lessen the chance of groupthink. And, as mentioned earlier, some people may need to be motivated to move on to another team for interpersonal reasons.
  2. You still may need to do projects. Sometimes your business team makes promises to their customers. For example, in a software company a sales person makes a big sale and promises that by a certain date your solution will have additional features that the customer needs (in immature organizations they’ll even make such promises without first negotiating this with the delivery team). Another example would be a financial institution that needs to fulfill new industry regulations that require changes to existing solutions. In both of these cases there is a large amount of work to be done that needs to be delivered before a certain date, and this may motivate you to treat this work as a project. You would still bring this work to the appropriate stable team(s) to accomplish as you normally would. However, you would also track the performance of the work to ensure that it is delivered in its entirety as appropriate. The implication is that projects may not completely go away

 

Evolving Stable Teams Over Time

Stable doesn’t mean stagnant.  Of course you still have basic people management issues such as people wanting to expand their skill set by working on something new by rotating to another team, people leaving the organization, and new people joining the organization.  So the team itself may go on for many years even though the membership of the team evolves over time.  Ideally these membership changes are not too disruptive: It’s not too bad adding a new person every month or so, or losing people at a similar rate, but gaining or losing several people in a short period of time can be painful.

 

Our Recommendation

Start experimenting with stable teams if you’re not already doing so. For most organizations the advantages clearly outweigh the disadvantages. In fact, you can see this in the Longevity decision point of the Form Initial Team goal diagram below.

Form the Initial Team

Update: Form Initial Team

Update

We’ve updated the goal diagram for Form Initial Team, an Inception Phase goal.  The new version of the diagram is follows, as does a summary of the changes that we made and the previous version of the diagram.

The New Version of the Goal Diagram

Form the Initial Team

We made one change to this diagram: We added the process factor Team Evolution Strategy to indicate that there are different ways to evolve a team once it’s been initiated.  One thing that we did not do to this diagram is to rename the process factors to begin with a verb.  In the case of this process goal most of the verbs would be “Identify” or “Select” so we felt this would add clutter more than it would clarify.

The Previous Version of the Goal Diagram

Form the Initial Team

So you want to become a Certified Disciplined Agile Practitioner (CDAP)?

Certified Disciplined Agile Practitioner (CDAP)

Knowledge + Experience

Certified Disciplined Agile Practitioner (CDAP) is the second of three certifications in Disciplined Agile.  Being a CDAP indicates to colleagues and employers that you understand the fundamentals of agile delivery and have experience in applying agile strategies in practice.

This blog posting addresses the following questions:

 

Why should I be interested in Disciplined Agile certification?

First and foremost, this is respectable certification for agile practitioners who respect themselves. The Disciplined Agile Consortium (DAC) promotes a principled, Shu-Ha-Ri strategy to certification.  These are certifications that must be earned through learning and experience – if you’re looking for a quick, easy agile certification then this isn’t the path for you.  However, if your goal is to learn about Disciplined Agile ways of working, if it is to gain a better understanding of how to apply agile strategies within your organization, if it is to show employers that you’ve worked hard to gain this knowledge, then Disciplined Agile certification may be for you.

Disciplined Agile certification is for agile professionals working in enterprise-class settings such as banks, insurance companies, retailers, and government agencies to name a few.  You’re not working in ideal situations – you have legacy cultures, legacy systems, and legacy processes to overcome – but that doesn’t mean you can’t make things better.  You take pride in your work and you want to create environments where you can be effective, and you can do that by adopting Disciplined Agile strategies.

 

Why should I become a CDAP?

To earn the CDAP you must pass a comprehensive test that requires you to have a fundamental understanding of how the agile delivery process from beginning to end.  You understand how testing, analysis, design, programming, architecture, management, governance, and many more activities fit together in a streamlined manner from the start of a software endeavour to deployment into production. You understand that you have choices in how you work, that these choices have tradeoffs and that you must follow a strategy that makes sense for the context you find yourself in.

The CDA tells employers that you have a broad understanding of how agile works in practice, how it works in a pragmatic way.  It indicates that you’ll fit into agile teams better because you have a holistic understanding of agile delivery.  Disciplined Agile certifications are something that employers can trust because they need to be earned.

 

How do I become a Certified Disciplined Agile Practitioner (CDAP?)?

There is a four-step process:

  1. Meet the qualifications.  First, you need to be a Certified Disciplined Agilist (CDA) in good standing.  Second, you must also have at least two years experience on agile team(s) and be able to prove it (you need two references, see step 3).  Third, you fulfill two or more of the optional requirements for CDAP (see the list posted here).
  2. Pass the CDAP test. This test is similar to the one that you needed to pass to earn your CDA but it is more comprehensive and a bit hard to pass.  You will want to brush up on you Disciplined Agile knowledge (see below).   Take the CDAP test.
  3. Apply to become a CDAP. The final, and easiest step, is to apply to become a CDAP at the Disciplined Agile Consortium (DAC).  Email DAC informing them that you have passed your test and the will send you a reference application to fill out and return. When your 2 references are received and reviewed, your membership will be upgraded to Certified Disciplined Agile Practitioner.
  4. Update your membership profile.  If you haven’t already done so, please update your membership profile to indicate your agile experience, references, and any other pertinent information.  Your profile information will be validated by us within a few days to determine whether you meet the criteria for Certified Disciplined Agile Practitioner.  Good luck!

 

What’s after CDAP?

To be clear, the CDAP is an indication that you have comprehensive knowledge of agile solution delivery, that you have some initial experience in agile, and that you might be ready to start coaching of others under the supervision of a Certified Disciplined Agile Coach (CDAC).   The next step is to earn your CDAC, which requires at least five years of experience plus proven give back to the community.  At some point you may even want to become a Certified Disciplined Agile Instructor (CDAI).

 

Recommended Resources

 

What is a Retrospective …. Who should attend?

Retrospective

What is the point of the retrospective?

The retrospective is one of the most important ceremonies in all of agile.  This is the time the team spends together to assess how they are working together and define steps to improve that process.  It needs to be a “safe place” where people are able to speak openly and honestly.  This is their opportunity to air their dirty laundry and work through their inter-personal issues.  This is a time of growth for the team and for the team to take ownership of improvement.  The team lead will facilitating the retrospective and should manage the interactions to keep the environment safe.

Define the Team

If the retrospective is a team ceremony, then what do we mean by team?   The team includes: the team lead, the architecture owner and all other members that actively contributed to meeting the deliverables for the iteration.  This includes: developers, testers, BAs, QAs, or other specialists such as technical writers, database engineers etc.

What about the Product Owner (PO)?

The PO is NOT a member of the team.  They certainly interact with the team but they do not contribute to meeting the deliverables for the iteration so they are not a member of the team.  They are not allowed to participate in the planning poker for the user stories for the same reason.  The team votes because they are on the hook for delivering based on the sizing and the estimates but the PO is not on the hook, so they don’t get a vote.

Should the Product Owner participate in the retrospective?

In general, I would start by including the PO in the retrospectives because the team does have to learn and adjust to working with the PO. Keep in mind though that the PO may come and go but the team should stay together so it is most important that the team works well together.  As a coach, I usually talk to the PO beforehand to say that they are an invited guest and that it is a privilege to be part of the meeting so they should act accordingly.   I have been in many situations where the PO was welcomed at the retrospective, and felt left out if not included.  I favor building trust between the business (the PO is their representative) and IT (the team).  Including the PO in the retrospective can help the PO assimilate with the team.

I have also had several situations where as the coach I had to ban the PO from the retrospective because they were too commanding and disruptive in the meeting for the team to have an effective retrospective.  I have also seen many situations where the PO is also the resource manager of members of the team (which in itself is not recommended).  Having managers in the room can definitely have a dampening effect on the member’s willingness to be open and honest about problems and solutions.

If the PO doesn’t participate, at least as an observer, the team runs the risk of having to “sell” the cost of their improvement actions (against other backlog items) after coming up with them. Hopefully the PO is engaged enough with the team to understand its weaknesses and support improvement in those areas whether then attend the meetings or not.

Team Decision

Retrospectives are about improving the process, and a non-trivial part of that is optimization of collaboration between the PO and the team.  I would suggest that the team should decide whether or not to include the Product owner.

What about the Stakeholders?

The retrospective should absolutely be a closed door session for the stakeholders since the retrospective must be a “safe space”.

There was a twitter debate lately that talked about a team being subjected to “a drive by criticism from 2 PM’s during a Retrospective”.  This is a good reminder why we constrain attendance.  The “safe place” is affected by the presence of people with positional authority, potential agendas or other implicit impact.  The team may decide to invite such people – usually to ensure that they are communicating improvements needed that are beyond their locus of control.  Having outsiders as guests at the retrospective will change the dynamics but at least it is a team decision to do so.

It is very important that the team own their process.  If they’re uncomfortable that someone is in the room then that person should be asked to either change their behavior or leave (perhaps to be invited back in the future).  The coach should always be thinking along the lines of “do we have the right people in the room” and then act accordingly

Isn’t agile all about transparency?

There was a twitter debate lately that centered on transparency.  I believe that transparency is a key element to making agile successful.   I’m all for transparency in everything about agile; EXCEPT the retrospective!  Sometimes you need to have a family meeting outside of the public eye and that is the retrospective. The retrospective is all about resolving your issues in private so that you can present a united front to the rest of the world. To use a sports analogy, an NHL coach doesn’t invite the business (fans) into the dressing room between periods.  There are lots of other places for transparency; the retrospective doesn’t have to be one of them.

The output of the Retrospective

While the actual retrospective meeting is closed to other observers, I would suggest that the action items coming out of the retrospective need to be made public and posted as an information radiator for everyone to see.  The changes are more likely to get implemented if the team sees them every day.  The team may also want to “radiate” their improvement actions on their dashboard.

The actions and results of the actions may also be shared with other teams through what is often called a Retrospective of Retrospectives. I encourage teams to only choose one or two areas for improvement at a time to provide focus and make meaningful progress.

So you want to become a Certified Disciplined Agilist (CDA)?

Certified Disciplined Agilist (CDA)

Knowledge

Certified Disciplined Agilist (CDA) is the first of three certifications in Disciplined Agile.  Being a CDA indicates to colleagues and employers that you understand the fundamentals of agile delivery and are eager to learn strategies that enable you to increase your skills and abilities as a software professional.

This blog posting addresses the following questions:

  1. Why should I be interested in Disciplined Agile certification?
  2. Why should I become a CDA?
  3. How do I become a CDA?
  4. What’s after CDA?

Why should I be interested in Disciplined Agile certification?

First and foremost, this is respectable certification for agile practitioners who respect themselves. The Disciplined Agile Consortium (DAC) promotes a principled, Shu-Ha-Ri strategy to certification.  These are certifications that must be earned through learning and experience – if you’re looking for a quick, easy agile certification then this isn’t the path for you.  However, if your goal is to learn about Disciplined Agile ways of working, if it is to gain a better understanding of how to apply agile strategies within your organization, if it is to show employers that you’ve worked hard to gain this knowledge, then Disciplined Agile certification may be for you.

Disciplined Agile certification is for agile professionals working in enterprise-class settings such as banks, insurance companies, retailers, and government agencies to name a few.  You’re not working in ideal situations – you have legacy cultures, legacy systems, and legacy processes to overcome – but that doesn’t mean you can’t make things better.  You take pride in your work and you want to create environments where you can be effective, and you can do that by adopting Disciplined Agile strategies.

Why should I become a CDA?

To earn the CDA you must pass a comprehensive test that requires you to have a fundamental understanding of how the agile delivery process from beginning to end.  You understand how testing, analysis, design, programming, architecture, management, governance, and many more activities fit together in a streamlined manner from the start of a software endeavour to deployment into production. You understand that you have choices in how you work, that these choices have tradeoffs and that you must follow a strategy that makes sense for the context you find yourself in.

The CDA tells employers that you have a broad understanding of how agile works in practice, how it works in a pragmatic way.  It indicates that you’ll fit into agile teams better because you have a holistic understanding of agile delivery.  Disciplined Agile certifications are something that employers can trust because they need to be earned.

How do I become a Certified Disciplined Agilist (CDA)?

There is a three step process:

  1. Learn about Disciplined Agile.  You need to have a comprehensive knowledge of how Disciplined Agile Delivery works from beginning to end.  You can do this by reading the Disciplined Agile Delivery book or by taking a Disciplined Agile workshop (in particular DA 101: The Disciplined Agile Experience, DA 104:Introduction to Disciplined Agile, or DA 105: Disciplined Agile in a Nutshell).  It is also possible for someone with deep experience in agile to read the articles and blog postings on this site to gain enough knowledge to pass the test, but there is far more information in the book and taught in the workshops.
  2. Pass the CDA test.  The CDA test is comprehensive and 10-15% of people fail it the first time (typically due to lack of preparation).  We suggest that you first read this advice on how to pass the CDA test.  Then, once you’re ready, take the CDA test.
  3. Apply for membership. The final, and easiest step, is to apply for membership at the Disciplined Agile Consortium (DAC).  This will get you publicly recognized as a CDA.

What’s after CDA?

To be clear, the CDA is an indication that you have comprehensive knowledge of agile solution delivery, it is not an indication that you have agile skills (yet).  Certified Disciplined Agile Practitioner (CDAP) and Certified Disciplined Agile Coach (CDAC) are better indicators of experience.  The CDAP requires you to have at least two years of experience in agile software development and the CDAC requires at least five years of experience plus proven give back to the community.  At some point you may even want to become a Certified Disciplined Agile Instructor (CDAI).

 

Recommended Resources

(In Agile) Where do all the managers go?

Business team

On February 23, 2016 I gave a webinar entitled (In Agile) Where do all the Managers go? A recording of the webinar is posted on Youtube and a PDF of the slides on Slideshare. This blog overviews the webinar and provides answers to the numerous questions that were asked during it.

Webinar Overview

The webinar began with a discussion of four trends that are reducing the need for people in management positions:

  1. Technical management tasks are performed by the team. As a result there is much less work for managers to do.
  2. Leadership is addressed by new roles. Team leadership responsibilities are in the hands of non-managers.
  3. Experienced organizations are moving towards stable teams. Important side effects of this are that much less “resource management” is required and team budgeting is greatly simplified.
  4. Status reporting is being automated away. Once again, less work for managers to do.

We then discussed the options that existing managers have in an agile environment. In Disciplined Agile there are four roles that existing managers are likely to transition to: Team Lead, Product Owner, Team Member, and Specialist. Specialist roles – such as Data Manager, Portfolio Manager, Program Manager, and Operations Manager – occur at scale and the corresponding positions are few and far between. Read the article Disciplined Agile Roles at Scale for more details.

We end with words of advice for existing managers: Observe what is actually happening; be flexible; and choose to evolve.

Questions and Answers

We’ve organized the questions into the following topics:

Evolving to New Roles

Will not the existing technical managers be disappointed with only people management work?

That depends on the person. Some will be very happy to do this, some will not.

How will managers fit into a leader role?

It depends on the person again. Some managers are very good leaders right now, some have the potential to be good leaders, and some don’t. They will need training and coaching to fit into their new role(s).

Addressing “Management Activities”

If there are no PMs in Agile, who handles communication with clients (meeting deadlines, priorities, etc.)

The Product Owner. 

How does individual performance to be taken up in Agile team? I think that is more crucial and challenging for Agile Leader / Manager.

It is always difficult to address performance-related activities. There are many lines of thought on how to do this. The most progressive is for the Team Lead to provide feedback to team members on a just-in-time basis. If the Team Lead seems behaviour, either desirable or undesirable, but a team member then they should comment on it right away so as to reinforce or dissuade it as soon as possible. Many organizations still have an annual review process, a strategy that many organizations have abandoned due to it’s ineffectiveness, where functional managers get involved with the review process.

I have seen that you have selected the Team Lead as the responsible of assess team members and budgeting the project. In Scrum the Product Owner is compare to a CEO that’s the reason I would say the Product Owner is responsible for bugdeting and about assessing I prefer a more democratic form which involve all the members. So what do you think about PO managing the budget and a democratic assessing vs one single vision assess?

Yes, I misspoke during the webinar. The Product Owner is often responsible for the team’s budget and is responsible for reporting the current financial information to the stakeholders. The Team Lead is often responsible for similar reporting to their management team.

Having multiple people involved with reviews/feedback is usually a pretty good idea. The People Management process blade captures several potential strategies. However, it is still a good idea for the Team Lead to provide feedback as well, see my earlier answer.

Potential Management Roles

I think there is still a need a bridge manager role between Finance, Teams, and PMO type orgs to ensure Product owners have budget… views. Thoughts?

In smaller organizations this likely isn’t an issue. In larger organizations there is often a Portfolio Management effort that is responsible for such issues.

What might be potential responsibilities of an Operations Manager, Data Manager, …?

Please read the article Disciplined Agile Roles at Scale for descriptions of these roles.

Okay, the data management team needs a team manager/leader. Are large organizations using various resource managers? (Although would be less necessary with stable teams I would think)

Exactly. Large organizations still tend to have people in resource manager roles, although sometimes they have different titles such as CoE Lead or HR Manager, but with stable teams they need far fewer of them.

If the team has a Team Lead/Scrum Master that is only the servant leader for 1-2 teams, is it suitable to have people managers?

What value would a “people manager” bring to the team? This is the fundamental dilemma for managers, for everyone for that matter, when an organization moves to agile ways of working. If they’re not bringing real value to the team then they either need to find ways to do so, which likely isn’t whatever management activities they’re trying to cling to, or they need to go elsewhere and try to add value there.

Do you intend to update the DA 2.0 interative pic on the DAD site to talk about “Potential Management Roles at Scale” as mentioned in page 18 of this presentation?

Yes. We actually have something in beta that we haven’t released yet. We’re just about to release an update to the main picture, which in turn requires an update to the role version of the interactive pic.

What is the most basic difference between Project/Program/Portfolio Managers in Agile?

Quick answer is that there isn’t Project Managers in Disciplined Agile nor in methods such as Scrum, XP, and so on. At the program level (a large team of teams) you likely need someone in a Program Manager (or more accurately Program Coordinator) role to coordinate activities (see the Program Management process blade for details). A Portfolio Manager is focused on the IT level and should be concerned about pre-development activities, development/delivery teams that are currently in flight, as well as operational activities.

Also, please read the article Disciplined Agile Roles at Scale for descriptions of these roles.

People Management

How does one manage the career path of the Team Leads? Is there career progression beyond a TL to be a specialist or does s/he continue being a TL throughout his career?

Everyone is different, so there isn’t one exact answer. It depends on what the person wants to do and what positions are available to them. If their desire is to move into management then there are fewer IT management positions available to them. If they want to become an AO or PO then they need to work towards getting the skills and experience to fulfill those sorts of roles. The People Management process blade includes career management strategies.

How do you evaluate what roles are/will be necessary?

It depends on the needs of the team in the situation that they face. The primary delivery roles typically exist on all delivery teams and the secondary roles start to appear at scale.

How do you see the role of a BA in agile?

Most existing BAs, like most existing project managers, will need to transition to other roles. However, at scale there is a need for some people in the specialist BA role. I recently has a user group presentation recorded on this very topic. See Disciplined Agile Business Analysis: Lessons from the Trenches.

Management Reporting

How do we approach a situation where management wants weekly status reports from a Program Manager who can combine both Team Lead & Product Owner roles, as well as manage multiple projects that may be similar in nature or not.

A few thoughts on this:

  1. It’s an incredibly bad idea to combine the TL and PO roles because it puts too much responsibility in the hands of one person. Furthermore, putting it into the hands of a former manager, someone who may have a command-and-control mindset instead of the collaborative mindset required of agile, can exacerbate the problem.
  2. You may need someone that Team Leads should work with to coordinate activities between teams (such as a Program Manager or Portfolio Manager) and someone that Product Owners should work with (a Chief Product Owner) to coordinate requirements activities. See The Product Owner Team.
  3. I do see stuff like this happen when organizations are transitioning to agile. They are still learning how to make agile work within their environment, they have a lot of people who haven’t yet made the transition, and they have a lot of middle management staff whom they want to treat fairly by finding them other work. Sadly that other work is often overhead that can be done away with given a bit of thinking.
  4. If you institute automated dashboards, what we originally referred to as Development Intelligence in Disciplined Agile, then a lot of your status reporting goes away.

 

In a typical organization, where to team lead(s) report into?

It depends. We’ve seen them report into a Program Manager or a Portfolio Manager. During the transition effort a Project Management Office (PMO) may still exist so Team Leads might report into there, although we often find that there’s a serious cultural and mindset difference that can be very frustrating for everyone involved.

During Your Agile Transformation

What about managers being responsible to support an agile transformation journey in a large organization?

Yes, they would very likely be working as part of an Agile Center of Excellence (CoE), although that would be mostly staffed by experienced agile coaches. There is a need for one or more senior execs to sponsor your agile transformation.

How to deal with “Project Manager” role renamed as “Agile Project Manager” but expected to do the same responsibilities as traditional PM?

We see this sort of stuff all the time unfortunately. First thing to do is to get these people educated in how agile actually works in practice, we’d suggest DA 101: The Disciplined Agile Experience or DA 104: Introduction to Disciplined Agile as your best option to get the whole picture. Next, work through with them how they would actually add real value on the team (see the discussions earlier). Very likely many of the activities that they think need to be are being handled by someone else or have been automated away. Third, get them some coaching to help them to truly transition to agile.

On my project, I am the Team Lead and there is a Project Manager. So far, I have observed that there are several conflicts in responsibilities. How do we come to an agreement of who handles which responsibilities? For my next project, would you suggest I work on a project with no project manager?

We often have to run facilitated workshops in organizations where we work through the roles and responsibilities that are needed in practice. We do this with a wide range of people and we do so in a collaborative and public manner. You need to come to an agreement as to who does what. Doesn’t sound like that’s happened in your case. When you work through this sort of an exercise you quickly discover that you don’t need a project manager, although there may be some project control officer (PCO) responsibilities that would be assigned to either the team lead or some sort of administrative role (such as PCO).

Do you have any advice on how to deal with the removal of the traditional hierarchy – in a flattening of responsibilities, ‘reporting-lines’ and salaries (or having a vast range of skills and pay-scales all with a job title of ‘team member’?)

This is what an agile transformation will accomplish for your organization. It takes time and investment in your people to implement. I highly suggest that you get some experienced coaches to help you do this.

Management is severely, negatively, personally affected by Agile, and will not look fondly upon it in many cases. Any tips to reduce this? Do you recommend mass management reduction, or multiple smaller rounds?

The first step is to recognize that your organization doesn’t exist to create jobs for managers, regardless of what the managers may think. Agile is about focusing on value, so why wouldn’t a good manager be interested in being actively involved with doing so? My recommendation is always to get training and coaching for everyone, including managers. As I described in the webinar there are many options for existing managers in the agile world if they’re willing to be flexible and evolve. Your organization should choose to help people make these transitions to new roles. However, if people are not willing to make the transition then they shouldn’t be surprised if the find themselves being asked to seek employment elsewhere.

It sounds like the person asking about “who’s responsible for delivery” might have used “responsible” when they meant “accountable” – many managers are the single wringable neck for something in their job description. Do you feel Agile draws the same distinction between the two like ITSM, for instance, does?

Agile is based on a collaborative, teamwork-based mindset. Having said that, it does make sense to have someone ultimately responsible for certain things. For example, the Product Owner is responsible for prioritizing the work on an agile team. Similarly, you may have someone in the Release Manager role who is responsible for overall Release Management within your organization. This is particularly important for regulatory environments where by law you need to have someone not involved with development who makes the final decision as to whether the solution is released or not.

From your observations and experience, what is the average timeframe for the managers number to decrease? How long does the process of the shift take?

It depends. We’ve seen this happen over timeframes as short as six months to several years.  With solid coaching this process will go a lot faster and smoother.

How to motivate and enable senior leaders to give up control?

In agile, particularly in Disciplined Agile, senior leaders have greater visibility and opportunities to steer than what they had in the traditional world. What they need to do is give up their false sense of control that traditional strategies provide. The real issue usually isn’t senior leaders but instead is middle management. They are the people who are currently performing many of the management tasks that are implemented in a more streamlined manner following agile approaches.

How can middle management start the agility journey when top leaders are not yet on board?

Agile typically begins following a stealth adoption strategy where senior leaders are unaware that it’s happening. The point is that anyone, including middle management, can start adopting agile strategies long before senior leadership gets involved. Strategies such as working collaboratively, enabling your team(s) to plan and organize their own work, adopting dashboard technology, and streamlining the bureaucracy whenever possible is very possible to accomplish on your own.

Thanks for being frank about the role(s) for managers in an evolving Agile culture: Agree, traditional project management organization’s aren’t highlighting these trends (and positive outcomes.)

You’re welcome. Traditional project management organizations often go at it from the point of view of how to continue justifying management activities. We go at it from the point of view of how to improve your overall organizational effectiveness and as a result come to a different conclusion.

Stable Teams

Will the idea for stable team become stale after some years? People tend to get frustrated doing same work. What’s the solution in that case?

Stable teams evolve over time. You’ll get people joining the team every so often and similarly leaving the team every so often. It’s natural for people to want to move on and try something new every few years. As a result your organization will still need People Management activities in place that motivate and enable people to manage their careers.

As far as stable teams go, commonly Valve, Inc. is referred to a place where teams are formed around projects that the team members find the most interesting. Project leaders try to sell their project to get developers. Your thoughts?

This is great technique that other organizations may be able to adopt. Allowing teams to form themselves is likely the most effective way to do so. However, like all strategies, there are some potential disadvantages. Team culture may become ingrained and they will not attract people with a different culture who would have the potential to add some real value to the team otherwise.

Is there a method to build the stable teams? Domain, Product, line of business?

There are several strategies for doing this. The most common is to form feature teams that do all of the work to implement a feature as a vertical slice through your entire infrastructure. Another approach is to form component teams that work on a technical or domain component/framework/LoB. A third approach is internal open source. We’ve discussed these strategies in greater detail at Strategies for Organizing Large Agile Teams.

Do you think stable teams concept will work in service-based organisation?

Yes. It’s a bit more difficult because you’d be bringing entire customer projects to the team at once instead of a flow of smaller features. Of course you can break each large project up into smaller features and feed them to teams in an interleaved manner, requiring a sophisticated approach to requirements management.

Training and Certification

What baseline training do you recommend for agile managers?

A good place to start is training on agile thinking, often referred to as how to be agile. Then I would recommend training that describes the full delivery lifecycle from end-to-end, something like DA 101: The Disciplined Agile Experience or DA 104: Introduction to Disciplined Agile. You want to understand all aspects of the agile delivery process, not just the management ones. Scrum training is popular but far too narrow. SAFe training isn’t for beginners.

I would like to participate in a certification workshop/further training. There doesn’t seem to be many offerings in the US. Are there plans to expand training opportunities in the states?

Yes. In fact we have training coming up in the Baltimore area in March and Philadelphia in April. We will have more open enrollment workshops scheduled soon.  Please visit the homepage of the Disciplined Agile Consortium for a listing of upcoming public workshops.

What should we be telling folks that have PMP’s – are they still valid? is PMP training moving toward Agile software development.

Yes, the PMI is moving towards agile but they have a very large ship to turn. Unfortunately the PMI training tends to suffer from the challenges that I described earlier – it seems to promote a rather unrealistic vision of how managers can potentially fit into agile.

Why should organizations be interested in Disciplined Agile certification?

Team

Disciplined Agile certification is for agile professionals working in enterprise-class settings such as banks, insurance companies, retailers, and government agencies. You’re not working in ideal situations – you have legacy cultures, legacy systems, and legacy processes to overcome – but that doesn’t mean you can’t make things better. You take pride in your work and you want to create environments where you can be effective, and you can do that by adopting Disciplined Agile strategies.

For organizations the primary value of disciplined agile certifications are that they indicate that people have gained a certain level of knowledge and in some cases expertise in Disciplined Agile methods.  Our principled approach to Disciplined Agile certification results in respected certifications that you can trust.  There are several benefits of Disciplined Agile certification for organizations:

  • It is meaningful. Disciplined Agile certification has to be earned. It is an indication that your people have a comprehensive understanding of enterprise-class development, and not just cargo cult agile.
  • It forms the basis of measurable skills assessment. Because the certifications build upon each other you can use them as a measure of how well agile skills and knowledge are spreading through your organization.
  • It’s trustworthy. Because Disciplined Agile certification is externally managed it is difficult for teams to game the numbers, unlike the self-assessment approach that is becoming all too common.

 

The Disciplined Agile Certification Program

The Disciplined Agile Certification program has three main certifications for practitioners – Certified Disciplined Agilist (CDA)Certified Disciplined Agile Practitioner (CDAP), and Certified Disciplined Agile Coach (CDAC) – that build upon each other. There is an additional designation, Disciplined Agilist (DA) and a fifth designation for trainers, Certified Disciplined Agile Instructor (CDAI).

Certified Disciplined Agilist (CDA): Shu (Beginner)

cdaInfoLarge

This certification indicates that the holder has comprehensive knowledge of how the Disciplined Agile solution delivery process works from beginning to end. To earn this Shu-level certification you need to pass a comprehensive test. It typically takes between 10 and 15 hours of classroom or reading time to prepare for the test. The primary benefits of this certification are that it:

  • Indicates that you have an understanding of how agile solution delivery works in enterprise-class settings;
  • Is a meaningful certification that sets you apart from the multitude of “certified masters”;
  • Shows that you have the desire to go beyond “cargo cult agile”;
  • Directs you down a path that reflects the realities faced by agile teams working in enterprise-class settings, enabling you to recognize and avoid the time consuming pitfalls common to Scrum teams.

Certified Disciplined Agile Practitioner (CDAP): Ha (Intermediate)

Certified Disciplined Agile Practitioner (CDAP)

This certification indicates that the holder has comprehensive knowledge of how the Disciplined Agile solution delivery process works from beginning to end and has experience applying agile strategies in practice. To earn this certification you must have earned the CDA first, have at least two years of agile work experience (you are required to provide references), and you have passed the CDAP test. The primary benefits of this certification are that it shows you’re:

  • Proficient at agile development and on the path towards mastery;
  • Ready to start helping others learn, potentially in a junior coaching role supervised by someone more experienced, such as a CDAC.

Certified Disciplined Agile Coach (CDAC): Ri (Expert)

Certified Disciplined Agile Coach (CDAC)

This certification indicates that the holder has comprehensive knowledge of how the Disciplined Agile solution delivery process works from beginning to end, has experience applying it in practice, and has proven giveback to the community. To earn this certification you must have earned the CDAP first, have at least five years of agile work experience (you are required to provide references), and have gone through a board-level interview. The primary benefit of this certification is that it shows you’re qualified to coach agile delivery teams. Effective coaches must have deep knowledge in what they are coaching people in, and that requires proven experience.

 

Retention

To retain your certification you should be dedicated to continuous learning of agile strategies in general, and in Disciplined Agile (DA) strategies in particular. Once someone is certified there are no direct membership dues. For CDA’s to retain their certification level they must take and pass the CDA test every two years. Having said that, at the two year point a practicing CDA is eligible to apply to become a CDAP anyway. Anyone with a CDAP will need to either pass the CDAP test every two years, or if they are qualified to apply for and become a CDAC. CDACs must provide proof of continuing give back to the DA community.

Further Reading

Why should you become certified in Disciplined Agile?

Certified

Are you tired of being embarrassed when you tell people what agile certifications you have? Are you tired of dancing around what little you had to do to “earn” your certification or what little knowledge about agile that effort actually imparted? Are you tired of explaining that you got certified only because it looks good on your resume, when in fact it only looks good to organizations that really don’t know what they’re asking for?  If you answered yes to any of those questions, it’s time to up your game.

Disciplined Agile certification takes a principled approach that provides real value to practitioners. Disciplined Agile certifications are respected because they are earned. There are several benefits of Disciplined Agile certification for practitioners:

  • Increase your knowledge.  Disciplined Agile certification requires you to have a comprehensive understanding of Disciplined Agile Delivery, which in turn describes how all aspects of agile principles and practices fit together in an enterprise-class environment.
  • Improve your employability.  Disciplined Agile certification indicates to employers that you’re dedicated to improving your knowledge and skills, a clear sign of professionalism.
  • Improve your career options.  Disciplined Agile certification can help you gain that new position or role as the result of your increased knowledge base and desire to improve.

Disciplined Agile Certification is for agile professionals working in enterprise-class settings such as banks, insurance companies, retailers, and government agencies. You’re not working in ideal situations – you have legacy cultures, legacy systems, and legacy processes to overcome – but that doesn’t mean you can’t make things better. You take pride in your work and you want to create environments where you can be effective, and you can do that by adopting Disciplined Agile strategies.

 

The Disciplined Agile Certification Program

The Disciplined Agile Certification program has three main certifications for practitioners – Certified Disciplined Agilist (CDA), Certified Disciplined Agile Practitioner (CDAP), and Certified Disciplined Agile Coach (CDAC) – that build upon each other. There is an additional designation, Disciplined Agilist (DA) and a fifth designation for trainers, Certified Disciplined Agile Instructor (CDAI).

 

Certified Disciplined Agilist (CDA): Shu (Beginner)

cdaInfoLarge

This certification indicates that the holder has comprehensive knowledge of how the Disciplined Agile solution delivery process works from beginning to end. To earn this Shu-level certification you need to pass a comprehensive test. It typically takes between 10 and 15 hours of classroom or reading time to prepare for the test. The primary benefits of this certification are that it:

  • Shows that you have an understanding of how agile solution delivery works in enterprise-class settings;
  • Is a meaningful certification that sets you apart from the multitude of “certified masters”;
  • Indicates that you have the desire to go beyond “cargo cult agile”;
  • Directs you down a path that reflects the realities faced by agile teams working in enterprise-class settings, enabling you to recognize and avoid the time consuming pitfalls common to Scrum teams.

 

Certified Disciplined Agile Practitioner (CDAP): Ha (Intermediate)

Certified Disciplined Agile Practitioner (CDAP)

This certification indicates that the holder has comprehensive knowledge of how the Disciplined Agile solution delivery process works from beginning to end and has experience applying agile strategies in practice. To earn this certification you must have earned the CDA first, have at least two years of agile work experience (you are required to provide references), and you have passed the CDAP test. The primary benefits of this certification are that it shows you’re:

  • Proficient at agile development and on the path towards mastery;
  • Ready to start helping others learn, potentially in a junior coaching role supervised by someone more experienced, such as a CDAC.

 

Certified Disciplined Agile Coach (CDAC): Ri (Expert)

Certified Disciplined Agile Coach (CDAC)

This certification indicates that the holder has comprehensive knowledge of how the Disciplined Agile solution delivery process works from beginning to end, has experience applying it in practice, and has proven giveback to the community. To earn this certification you must have earned the CDAP first, have at least five years of agile work experience (you are required to provide references), and have gone through a board-level interview. The primary benefit of this certification is that it shows you’re qualified to coach agile delivery teams. Effective coaches must have deep knowledge in what they are coaching people in, and that requires proven experience.

 

Retention

To retain your certification you should be dedicated to continuous learning of agile strategies in general, and in Disciplined Agile (DA) strategies in particular. Once someone is certified there are no direct membership dues. For CDA’s to retain their certification level they must take and pass the CDA test every two years. Having said that, at the two year point a practicing CDA is eligible to apply to become a CDAP anyway. Anyone with a CDAP will need to either pass the CDAP test every two years, or if they are qualified to apply for and become a CDAC. CDACs must provide proof of continuing give back to the DA community.

 

Further Reading