How Agile Are You? Free self-assessment.

How Agile Are You? Free self-assessment.

Take our Agile self-assessment by clicking on the button below:

When you receive the results of your self-assessment, you can identify our level of Agility on the above Agile maturity matrix.What is an Agile Maturity Model?

[list type="disc"]

  • A model that is designed to enhance and improve Agile practices by assessing the current state of your organization
  • A way to determine how closely you adhere to Agile principles
  • A model which shows your organization on an Agile maturity  continuum  from an initial or ad-hoc level to a continuously improving, self-sustaining level


How did we measure your Agility?

We based the assessment primarily on the use of Scrum since it is the most widely adopted Agile method. The scoring of the assessment is weighted based upon the overall importance of the answer and by applying our experience to the MocSCoW prioritization model as defined by the DSDM consortium, e.g. giving a higher value to those questions that are Agile "must haves" versus Agile "could haves."  No maturity model is perfect, but ours should provide insight into where you are today, reinforce where you have come from, and give you an idea where you are going.

The above maturity matrix is based upon the Maturity Index for Cultural Agility developed by Vodaphone UK and Hewlett Packard as presented in this paper to the UK's National Audit office.  The online Agile self-assessment was adapted from an original source developed by Henrik Kniberg and is licensed under a Creative Commons:

What next?

What you do with this information is up to you. This tool only presents one individual's point of view (you). If you want to have a number of people participate in this assessment and would like us to aggregate, summarize and make recommendations to help you on your Agile journey, please contact us.

About the author, Dan Tousignant, PMP, PMI-ACP, PSM I, PSPO I, PSD I, CSP

Dan is a lifelong project manager and trainer with extensive experience in managing software development projects. Based upon his experience, he has adopted both Agile as the primary method for developing and implementing software. He is passionate about the leadership emerging from self-organizing teams.

Dan has over 20 years of experience providing world class project management for strategic projects, direct P& L experience managing up to 50 million dollar software development project budgets, experience managing multi-million dollar outsourced software development efforts and strong, demonstrated, results-driven leadership skills including ability to communicate a clear vision, build strong teams, and drive necessary change within organizations.
Dan holds a Bachelor of Science majoring in Industrial Engineering from the University of Massachusetts, Amherst and is a Certified Project Management Professional, Professional Scrum Master, PMI Agile Certified Practitioner and Certified Scrum Professional and is the owner of Cape Project Management, Inc.
Cape Project Management, Inc.
Boston and Honolulu, USA


Who Owns Quality in Agile?

Who Owns Quality in Agile?

In Scrum, the expectation is that the entire Scrum Team owns quality, but what does that really mean? Isn’t the Product Owner only worried about value? Doesn’t the team own all the testing? Don’t they really own quality? Like many other concepts in Agile the answer to who owns quality is subtler than that, and as my first Agile mentor liked to say, “It depends.”

Before we define ownership, let’s define what we mean by quality in Agile. In terms of Agile software development, Jim Highsmith in Agile Project Management: Creating Innovative Products identifies quality as two points of the Agile Triangle: Intrinsic quality and Extrinsic quality.

This suggests that the definition of quality comes from two different sources, externally from the customer and internally from the development teams.

Defining Quality

Joseph Kelada, author of Integrating Reengineering with Total Quality defines these two aspects of quality:

Intrinsic Quality is all of the qualities that are built into the product: suitability, durability, reliability, uniformity, and maintainability. This type of quality can be measured quantitatively such as test coverage, bugs per line of code, escaped defects, cohesion, etc.

Extrinsic Quality is the buyer’s perception of quality and the value to the customer. This is a more qualitative measurement based upon sales, usage and customer feedback.

When most people think of quality, they think if intrinsic quality, which is why we have team members who are Quality Assurance specialists. They aren’t evaluating the customer’s perception of the product, they are performing verification and validation (V&V), e.g. Are we building the system right? Are we building the right system? The goal of V&V is to test the product against the written business and technical requirements.

On Agile projects, we build products with the premise that every requirement ties back to a customer-facing vision and value proposition. If a requirement doesn’t align with that vision, then it doesn’t matter how reliable it is, for it is of no value. With each iteration and release, the goal is to provide the highest value features balanced against the cost to develop those features. This the goal of each Sprint in Scrum.

Given this, I would suggest that Jim Highsmith’s Agile triangle is visually inaccurate. It gives equal weight to intrinsic and extrinsic quality. The reality is that in order for organizations to compete, extrinsic quality, in most cases, is more important. Remember, the first principle in the Agile Manifesto, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

The Role of Product Owner in Quality

I recently encountered a simple yet telling example of how a Product Owner addressed intrinsic versus extrinsic quality while facilitating a Sprint planning meeting. A developer submitted a backlog item to refactor some previously written code that was causing a large increase in storage each time a report was run. This was an unexpected outcome of a customer-facing requirement. The assumption from a technical perspective was that the storage issue was egregious and the impact was large, but the effort to refactor the code was large as well. In a traditional software development environment it would be assumed that a defect like this would automatically be addressed in the next release. On this high-performing Scrum Team, the Product Owner questioned the value of addressing the defect in this release.

This involved an in-depth discussion of the issue and the options, and ultimately in came down to a quantifiable measurement. The technical debt of that storage issue could be measured in dollars and could easily be compared against the business value of other requirements.  Once the issue was quantified, the Product Owner removed the requirement as a candidate for this release. The Product Owner had more “valuable” items slated for this release. Not all issues of extrinsic quality versus intrinsic quality can be that easily quantified, but in mature Agile teams, the correct dialogue will occur and the decision that is most often made will balance the short-term customer facing goals with the long-term viability of the product.

Quality Ownership

So, back to the original question, who owns quality? When speaking of Agile roles, it is easiest to use the Scrum roles. In the most recent annual VersionOne Agile survey, 75% of companies practicing Agile are using Scrum or at least the Scrum terminology. The roles of Product Owner, Scrum Master, and Development Team have become ubiquitous terms in our industry.

In the Scrum Guide, it states, “As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.” “Scrum Teams” includes all three Scrum roles. So this would presume that the entire Scrum Team owns the intrinsic quality. However, the Guide also states that the Product Owner is responsible for “Optimizing the value of the work the Development Team performs.”  So, ultimately, the Product Owner owns extrinsic quality, and as we just discussed, this may supersede intrinsic quality.

The Reality

Though organizations understand this theoretically, this is seldom put fully into practice. For the Product Owner to truly own quality the following best practices would need to be in place:[list type="disc"]

  • Quality Assurance specialists would functionally report to the business
  • The Product Owner sign-off on design documents
  • Performance and non-functional requirements would be approved by the Product Owner
  • All defects would be approved by the Product Owner before being added to the backlog.
  • The scope of pre-production testing and readiness would be approved by the Product Owner[/list]

Those changes and many more would need to occur, both culturally and organizationally for an organization to truly align quality ownership with the Product Owner role.

At minimum, in order for the Product Owner to truly own value and quality, the Development Team needs to educate the Product Owner on the cost and effort of addressing intrinsic quality issues. The Product Owner needs to understand that well written code costs less to support and maintain. Technical debt eventually needs to be paid back and only an educated Product Owner can make the best decision as to when. This often creates conflicts within newly emerging Agile teams. In my experience, especially with large traditional organizations, this can shift the ownership of building the product away for the IT department and more to the business. This is intentional in Agile so that we ensure that delivering value to the customer is a primary goal.

Personally, I have seen too many well-built, highly reliable, stable products sit on a shelf because ultimately they missed customer’s expectations or were too late to market. Often a product that was not built half as well can dominate market share. There are exceptions to this of course, but for those companies at the forefront of their industries, they are adopting a Lean and Agile approach to software development that front-end loads value. They then add stability and reliability once the product achieves traction and validates the ROI for both the initial investment and continuing investment.

It is a team effort to understand how each requirement, whether technical or functional, will drive value to the customer. This type of understanding requires close collaboration between the Product Owner and the development team. It means truly embracing the “one team” concept and allowing full transparency into the decisions about which requirements make it into each release. Ultimately, it will be the Product Owner’s decision, but only in an environment that had truly embraced what it means to be Agile can this occur.


Joseph Kelada, Integrating Reengineering with Total Quality

Jim Highsmith, Agile Project Management: Creating Innovative Products

10th Annual VersionOne Survey

Jeff Sutherland, Ken Schwaber 2016 Scrum Guide

About the Author: Dan Tousignant

Dan has been managing software development projects for 20 years. He was first introduced to Agile via a Scrum Implementation in 2000 and has since adopted Agile as the primary method for managing software development projects.

Dan holds a BS in Industrial Engineering from UMASS, Amherst and is a Professional Scrum Master, Certified Product Owner, PMI Agile Certified Practitioner and Certified Scrum Professional.

Dan Tousignant, PMP, CSP, PMI-ACP.

President Cape Project Management, Inc.

Be Agile.®

Agile 2.0 – It’s about People and Connections! It’s not about Scaling.

Agile 2.0 – It’s about People and Connections! It’s not about Scaling.

Andrew Carnegie once said,

Teamwork is the ability to work together toward a common vision. The ability to direct individual accomplishments toward organizational objectives. It is the fuel that allows common people to attain uncommon results.

His observation is spot on, and yet, when discussing Agile Software Development, we find ourselves focused on frameworks instead of people and connections.

Over the past 15 years, Dan Tousignant and Todd Kamens, two Agile thought leaders, have collaborated on numerous projects.  Leveraging Traditional Project Management, Scrum, Lean and Kanban techniques to manage software projects they have now joined to share their thoughts.

Working together on and off over the years, Dan and Todd have discussed many issues with clients’ different implementations of Agile, and with each conversation, a pattern started to emerge.  It wasn’t clear at first, but they started to see how Agile’s success was more about the people and values than the prescribed process and framework.  Dan and Todd started to see how Agile was becoming a practice that was unique to each company and involved people and connections in making it succeed.

Interestingly, when Dan and Todd saw these connections in the workplace, they had both started to practice Mindfulness.  Mindfulness seems to be the new buzzword these days for the stressed out corporate executive, those going through a midlife crisis or those that are just searching for more meaning out of their day.  Though it is a new term, it is not a new concept and has existed for thousands of years.

We are not attempting to teach Mindfulness in this article, however, it is important to understand it at it’s core as defined by Jon Kabat-Zin as follows,

Mindfulness is paying attention, on purpose, in the present, and non-judgmentally, to the unfolding of the experience moment by moment.

In their conversations about Agile and Mindfulness, the patterns became clear as they started to see how Mindfulness aligned with the core values of Agile.  


Agile Mindfulness
Individuals and Interactions over processes and tools Mindfulness teaches us to be open to novelty, sensitive to different contexts and to be aware of multiple perspectives.
Working software over comprehensive documentation Mindfulness teaches us to accept change, to appreciate other viewpoints and to be able to focus on the present.
Customer collaboration over contract negotiation Mindfulness teaches us an awareness of multiple perspectives and listening to hear versus listening to reply.
Responding to change over following a plan Mindfulness teaches us to cherish trust, expertise and direct communication.


In summary, Agile 2.0 moves us beyond Frameworks and instead, focuses on people and connections.  We observe how the individual, the team and the organization work together to achieve amazing results.  We pay attention to one another, non-judgmentally, and work together to achieve great value for our customers.

Over the course of several collaborative articles, Dan and Todd will convey their vision of Agile 2.0 and explain how leveraging Mindfulness practices with your Agile software development adoption can create better people, teams and companies capable of achieving greatness.


Dan Tousignant

President, Cape Project Management, Inc.

Todd Kamens

President, Guidance Technology, Inc


Certifications, Integrity, Values: Where do you stand?

Certifications, Integrity, Values: Where do you stand?

Last week I passed the Product Owner Assessment (PSPO 1) from (you can check out my new PSPO 1 mock exam here).  As an Agile Coach and Trainer, I try to stay current with certifications. I don’t believe that these certifications necessarily make someone more effective, but for me, they are a structured way of staying current with industry best practices. As part of my long-term professional development plan, I have been thinking , “What’s next?” I had already achieved what I considered to be the core certifications for a project management consultant; PMP, PMI-ACP, PSM 1, PSPO 1, CSPO, CSP, so I wasn’t sure in which direction should I go? Should I go “big”, like SaFE or DAD (heaven forbid). Should I get certified as an Agile or PMI Trainer and pay thousands in licensing and application fees? As an independent consultant, these types of certifications become cost prohibitive.

The value provided by consultants like me is that we offer services based upon real world experience at a reasonable cost. Not that long ago, I sat in a meeting with an external project management auditor from one of the Big Four. His rate was $475/hour. He was hired to audit my Scrum project to see if it was adhering to project management best practices. He started his initial findings meeting with, “I was reading about this Agile thing last night, and I think I have some recommendations.” Once my blood pressure dropped to reasonable levels, I realized that this interaction only reiterated that I needed to stay committed to my values:

  • Always provide value to my customer.
  • Stay current on best practices.
  • Keep my expenses low so I can offer reasonable rates.
  • Never sacrifice integrity for profitability.

I considered these same values when reviewing the available certifications. Can I meet those values with my current certifications? At this point, my answer is yes. What about you?

If you are interested, at my last count, there are 64 different Agile certifications! (I am sure I missed some). Can you imagine the signature line on my emails?

Agile Certification Institute

  • Accredited Agile Practitioner (AAP)
  • Accredited Scrum Master (ASM)
  • Accredited Product Owner (APO)
  • Accredited Scaled Agile Practitioner (ASAP)
  • Accredited Kanban Practitioner (AKP)
  • Accredited Lean Software Development Practitioner (ALSP)
  • Certified Agile Associate (CAA)
  • Certified Scrum Associate (CSA)

Scrum Alliance

  • Certified Scrum Coach (CSC)
  • Certified Scrum Trainer (CST)
  • Certified Scrum Developer (CSD)
  • Certified Scrum Master (CSM)
  • Certified Scrum Product Owner (CSPO)
  • Certified Scrum Professional (CSP)

Disciplined Agile Consortium

  • Disciplined Agilist-White Belt
  • Disciplined Agilist-Yellow Belt
  • Disciplined Agilist-Green Belt
  • Disciplined Agilist-Black Belt

DSDM Consortium

  • AgilePM certification
  • DSDM Atern Foundation Certificate
  • DSDM Advanced Practitioner Certificate
  • DSDM Foundation Certification
  • DSDM Consultant
  • DSDM Coach
  • DSDM Trainer
  • DSDM Advanced Practitioner

The International Consortium for Agile

  • ICAgile Certified Professional (ICP)
  • ICAgile Certified Professional in Business Value Analysis (ICP-BVA)
  • ICAgile Certified Professional in Agile Portfolio Management (ICP-PFM)
  • ICAgile Certified Professional in Agile Project Management (ICP-APM)
  • ICAgile Certified Professional in Adaptive Management (ICP-ADM)
  • ICAgile Certified Professional in Agile Team Facilitation (ICP-ATF)
  • ICAgile Certified Professional in Agile Coaching (ICP-ACC)
  • ICAgile Certified Professional in Agile Programming (ICP-PRG)
  • ICAgile Certified Professional in Agile Software Design (ICP-ASD)
  • ICAgile Certified Professional in Agile Testing (ICP-TST)
  • ICAgile Certified Professional in Agile Test Automation (ICP-ATA)
  • ICAgile Certified Professional in Enterprise Agile Coaching
  • ICAgile Certified Professional in Agile Leadership

International Scrum Institute

  • Scrum Master Accredited Certification (SMAC)
  • Scrum Product Owner Accredited Certification (SPOAC)
  • Scrum Team Member Accredited Certification (STMAC)
  • Scrum Certification for Java Developer (SC4JD)
  • Scrum Certification for Web Developer (SC4WD)
  • Scrum Certification for Mobile App Developer (SC4MD)

The LeSS Company

  • Certified LeSS Practitioner
  • Certified LeSS for Executives

Project Management Institute

  • PMI Agile Certified Practitioner (PMI-ACP)

Scaled Agile Inc.

  • SAFe Agilist (SA)
  • SAFe Practitioner (SP)
  • SAFe Program Consultant (SPC)
  • SAFe Program Consultant Trainer (SPCT)
  • SAFe Product Manager/Product Owner (SPMPO)

  • Professional Scrum Developer (PSD)
  • Professional Scrum Master I (PSM I)
  • Professional Scrum Master II (PSM II)
  • Professional Scrum Product Owner I(PSPO I)
  • Professional Scrum Product Owner II(PSPO II)
  • Scaled Professional Scrum (SPS)

  • Scrum Master Certified (SMC)
  • Scrum Developer Certified (SDC)
  • Scrum Product Owner Certified SPOC)
  • Agile Expert Certified (AEC)
  • Scrum Fundamentals Certified (SFC)

People have different reasons for certification. Some do it to advance their careers, others to learn new skills. Yes, there are also those that use certifications to artificially represent their expertise. I don't worry about them because the job will weed out those people. Ultimately, you need to decide, based upon your professional values. Will these certifications allow me to provide more value to my employer or my customer? Once you have that answer, the decision is easy.

Dan Tousignant, PMP, CSP, PMI-ACP, etc., etc., etc.

President, Cape Project Management, Inc.


Using Kanban to run your start-up aka Stephen Covey was the first Agile Coach

Using Kanban to run your start-up aka Stephen Covey was the first Agile Coach

I presented on this topic last night at our monthly Agile Meetup in Honolulu  along with Chuck Liddell from the Agile development shop KapuHonu.

Honolulu has a thriving startup community. I decided to present on this topic after attending the kickoff of the extremely popular start-up event, Honolulu Startup Weekend. While listening to the pitches, I realized that these potential new companies were ripe for some Agile basics. Many of them were already very familiar with Lean Startup and customer driven business development, but very few were familiar with the Agile techniques designed to manage day-to-day projects or business.

I like to consider Stephen Covey as the first true Agile coach. His 7  Habits of Highly Effective People addressed key  effectiveness techniques that align nicely with Agile. My favorite one is First things First,  "To live a more balanced existence, you have to recognize that not doing everything that comes along is okay. There's no need to overextend yourself. All it takes is realizing that it's all right to say no when necessary and then focus on your highest priorities." This is perfectly aligned with the Agile Manifesto principle, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

One of the techniques he uses for First Things First is to get people to understand  the difference between urgent versus important work. He wasn't the first to make this distinction, Dwight D. Eisenhower is credited with this quote: "What is important is seldom urgent, and what is urgent is seldom important."  What Covey is responsible for is the creation of the following time management matrix to help people distinguish where they are spending their time:

  • Quadrant 1 is for important activities you could not have foreseen, and others that you left until it was almost too late. Plan for these.
  • Quadrant 2 is for important activities that help you achieve your personal and professional goals, and complete important work. Focus here.
  • Quadrant 3 is for time-sensitive distractions. They are not really important, but someone wants it now. Learn to say no.
  • Quadrant 4 is for activities that are just a distraction. Avoid them if possible.


The intent of this matrix is to get people to focus on daily activities and plan their time within Quadrant 2. At the time of publication (1989), the most common technique for managing your time spent on important activities was to capture them in your calendar book. This was before phone apps or even the use of Outlook calendars. They were documented in those heavy Daytimers that people carried everywhere. Covey's training courses suggested that you block time in your calendar to focus on important tasks and limit the time you spend on urgent tasks.

This fits nicely with Agile prioritization approaches and managing WIP. For the purpose of the audience last night, small business owners, I compared this approach of managing your important work in your calendar to the Kanban concept of prioritization using of classes of service and managing work in progress (WIP). I personally use this approach to manage my business every day. I have an online Kanban board (LeanKit) with swim lanes of important activities and I have WIP limit of a minimum of 6 hours of important work each day. I assume that at least 2 hours of my day will be taken up with unplanned urgent activities. I also use the Kanban Board to capture a backlog of ideas that may eventually become actual work. Here is an example of my business-oriented kanban board:


For those of you familiar with Agile techniques, it is easy to see how these techniques can be applied to many different situations other than software project management. I also believe that there are very few new ideas in Agile since these effective management techniques have been around for many decades and are just now being embraced within traditional project management. If Stephen Covey was a software developer, he would have made a great Agile coach.

For more information Kanban, check out my blog post or listen to my Introduction to Kanban self-study training.




About the author, Dan Tousignant, PMP, PMI-ACP, PSM I, CSP

Dan is a lifelong project manager and trainer with extensive experience in managing Agile software development projects. Though the role of the professional project manager is changing dramatically through these approaches, Dan coaches organizations on how to transition teams and organizations to Agile.

Dan has over 20 years of experience providing world class project management for strategic projects, direct P& L experience managing up to 50 million dollar software development project budgets, experience managing multi-million dollar outsourced software development efforts and strong, demonstrated, results-driven leadership skills including ability to communicate a clear vision, build strong teams, and drive necessary change within organizations.

Dan holds a Bachelor of Science majoring in Industrial Engineering from the University of Massachusetts, Amherst and is a Certified Project Management Professional, Professional Scrum Master, PMI Agile Certified Practitioner and Certified Scrum Professional.

Dan Tousignant, President
Cape Project Management, Inc.