Disciplined Agile

One of the great advantages of agile and lean software development is the wealth of practices, techniques and strategies available to you.  This is also one of its greatest challenges because without something like the DA toolkit it’s difficult to know what to choose and how to fit them together. The DA toolkit adopts practices and strategies from existing sources and provides advice for when and how to apply them together.  In one sense, methods such as Scrum, Extreme Programming (XP), Kanban, and Agile Modeling (AM) provide the process bricks and DA the mortar to fit the bricks together effectively.

Another strategy to process improvement is captured by the Capability Maturity Model Integrated (CMMI)-Development (CMMI-Dev) approach.  With this strategy organizations will organize their improvement efforts around the CMMI process areas, which has the effect of local optimization of each process area at the expense of the overall flow and efficiency within your software process. The fact that CMMI-Level 5, which few organizations achieve in practice, focuses on process optimization belies this point that overall flow tends to be an afterthought in CMMI environments.

It is possible to combine agile and CMMI approaches together, as a quick Internet search will reveal.  There appears to be a fair bit of evidence showing that applying agile within CMMI environments appears to improve the situation.  It is our opinion that applying CMMI to agile teams tends to decrease their effectiveness in practice.

A better strategy is to first apply the DA toolkit with the goal of streamlining your overall software process.  Then if, and only if, you need to be CMMI-compliant you should make changes to your process to become compliant.   As we show in Mapping CMMI-Dev to Disciplined Agile the DA toolkit can be fully CMMI-compliant. The DA framework in effect shows how to weave the various process areas together.   For example, the Produce a Potentially Consumable Solution process goal includes process factors such as Needs Exploration, Solution Exploration, and Planning which map to aspects of Requirements Development (RD), Technical Solution (TS), and Integrated Project Management (IPM) CMMI process areas respectively.  By starting with DA, you will tailor a light-weight software process to meet your actual needs while only requiring a few (hopefully) minor tweaks so that you can easily pass a SCAMPI assessment.  In short, get the process right and then make it CMMI compliant – focusing on CMMI-compliancy will almost assuredly guarantee you have a software process that is heavier than it needs to be.

Via the combination of supporting multiple lifecycles and lightweight process tailoring via application of process goals the DA toolkit provides a context-sensitive and scalable approach to the agile software process.   Furthermore, the DA toolkit presents time-oriented advice, e.g. at this point in time here’s what you need to do and here’s how it fits together, that is actionable by agile teams. In short, the toolkit takes the mystery out of how all of these agile and lean techniques work together in practice.

Our fundamental advice is to avoid CMMI if at all possible.  If you then your best bet is to take a Disciplined Agile approach to CMMI compliancy.

by Danial Schwartz

In Disciplined Agile Delivery (DAD), testing is so important we do it all the way through the lifecycle. One approach that your team will need to consider performing is recovery testing, which is used to see the ability of a system to handle faults. If a fault occurs, does the system keep working and does not stop? In case of a fault can the system recover within a specified period of time? In the event of a critical failure will damage such as physical, economical, health related, etc., result or not?

Recovery testing constitutes of making the system fail; then the results of system recovery are observed. The efficiency of the system to return to normal and the time it takes to do so are examined. The disturbances which can result in failure and need to be checked vary from product to product and from industry to industry.

Consider the healthcare industry and medical devices. When products are developed for the health care industry they have to be in strict accordance with FDA guidelines. They also have to adhere to the guidelines provided by the company for which the product is being made. When recovery tests are made they naturally have to comply with these strict rules. The tests require validation and so does the environment in which they are to be carried out.

The Defense Industry consists of complex systems embedded within one another. The interlink of the systems requires recovery testing which takes into account how different systems affect one another. Since the industry has to deal with harsh environmental variables, these have to be replicated for recovery testing. Doing so is no easy task.

Cloud applications are increasing in popularity. They are part of cloud systems. The cloud systems, in turn, are made up of commodity machines. This allows taking advantage of economies of scale. But this results in needing to use complex software which makes recovery testing quite a challenge.

Before a recovery test can be carried out, the software recovery tester has to make sure that recovery analysis has been undertaken. A fail over test is designed. The fail over test serves to determine that if a given threshold is reached, can the system allocate extra resources. It also serves to show if, in case of critical failure, a system can distribute resources and continue to operate or recover within a specified time.

Consider the example of a server which is reachable but it is not responding as one would expect it to. This is the fail-over cause. The result of this, known as the possible impact, could be a crash. The severity of the impact is medium to high. To simulate this one could initiate wrong responses on the server side.

Another example of a fail-over cause is a power supply failure. If the failure was in the auxiliary power source its possible impact could be a complete shutdown. This is critical. To simulate this the system could be subjected to a change in power strength or the power cord could simply be unplugged.

A low impact severity example includes a DB overload. This could result in slow response time. It could also result in information not being fetched from the DB leading to an error. Using appropriate tools a load test could be created to simulate this scenario.

At times a service might stop posing a low to high impact severity depending on the service which stopped. There might not be any possible impact or an application might stop working. To simulate this one could stop the service manually to see the possible impact.

The tester also has to ensure that the test plan and test environment are prepared, information is backed up, the recovery panel has been provided education and a record is kept of the techniques used for recovery.

Use of resources and having to deal with unpredictable possibilities makes recovery testing a daunting task, but its benefits are worth the trouble.  First, recovery testing improves the system quality. It removes risk since one knows that in case of a failure the system will continue to work.  Second, recovery testing results in a staff which is educated to perform recovery failure when need arise.  Third, recovery testing also fixes problems and mistakes in a system before it has to go live.  Finally, recovery testing shows how important recovery is and raises awareness of the fact that long term business continuity relies heavily on recovery management.

In conclusion, recovery testing is used to see how a system behaves when failure occurs. Recovery testing can be a tedious process but shows the efficiency of a recovery plan, educates the staff on how to deal with faults and failures which occur in systems, highlights the importance of recovery at times of crisis to members of the IT and business organizations, and shows how important it is to the long term success of a business to have a recovery strategy in case of a disaster.

About the Author

Danial Schwartz is a content strategist who sheds light on various engaging and informative topics related to the health IT and Q&A industry. His belief in technology, compliance and cost reduction have opened new horizons for people in the health care industry. He is passionate about topics such as Affordable Care Act, EHR,testing, test automation, and privacy and security of data.

Related Resources

• Process goal: Move Closer to a Deployable Release
• Agile Testing and Quality Assurance Strategies

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)

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)

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)

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

• Apply for certification
• Certification roadmap
• How to pass the certification test
• ShuHaRi
• The principles behind Disciplined  Agile certification
• The value and limits of certification

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)

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)

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)

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

• Apply for certification
• Certification roadmap
• How to pass the certification test
• ShuHaRi
• The principles behind Disciplined  Agile certification
• The value and limits of certification

One of the age-old debates in the software world is whether software architects need to write code.  We suspect that as an industry we’ll never reach consensus on this topic. Here are our thoughts on the subject.

Short Answer:

Hell yes!

Detailed Answer:

In the following table we list the advantages, disadvantages, and considerations (when does the strategy makes sense) to compare whether a software architect should write code or not.  You may recognize this approach from our book Disciplined Agile Delivery.

In the Disciplined Agile (DA) toolkit we’ve made it very clear that we expect Architecture Owners to be actively involved with the development of the solution.  On Disciplined Agile teams the Architecture Owner is effectively a team member with additional responsibilities around leading the team through architecture decisions, in coaching them on architecture skills, and in working closely with your Enterprise Architecture team (if any) to ensure their development team understands and is working towards your organization’s technical roadmap.

We’re often told that it isn’t realistic to expect architects to write code.  Invariably this is coming from people who are currently working in traditional IT organizations that have very well-defined roles, IT organizations that more often than not are struggling to be effective.  Our response is always the same – Really?  Are development teams following your architectural strategy?  Are they eager to work with you, or are they forced to work with you?  This generally leads to a discussion that reveals that things aren’t going so well for these architects in practice, and sometimes leads to a positive discussion as to how we can move towards a more effective approach for them.  They kind of approach described in the Disciplined Agile (DA) toolkit.

Additional Reading:

• In the mid-1990s James Coplien captured the organizational pattern Architect Also Implements.
• The Architects Don’t Code anti-pattern on Ward Cunningham’s C2 wiki is also a valuable read.