How Agile are you? Free Agile Maturity Assessment

How Agile are you? Free Agile Maturity Assessment

How Agile are you? Free Agile Maturity Assessment

NEW! Become a Certified Agile Professional

When you receive the score of your self-assessment, you can identify your level of Agility on the Agile maturity matrix. Contact us if you are looking for ways to improve your overall Agile Maturity.

  • 0 - 80 points: Ad-hoc Agile
  • 81-160 points: Doing Agile
  • 161-240 points: Being Agile
  • 241 - 320 points: Thinking Agile
  • > 320 points: Culturally Agile

Print a PDF of the maturity model and mark your score.

What is an Agile Maturity Model?

  • 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 MoSCoW 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: http://creativecommons.org/licenses/by-nc-nd/3.0/

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.

The Liberation of Remote Work: Why I’ll Never Go Back to the Office Full Time

Working from home has irreversibly changed me. The very thought of returning to the routine of a full-time office job feels antiquated, almost absurd. It’s been four continuous years of remote work for me, and I’ve embraced every second of it. While I occasionally...

The Overlooked Agile Topic: Psychological Safety

Psychological safety is an essential aspect of Agile teams that is often overlooked, despite its significant impact on team performance and collaboration. This concept involves creating an environment where team members feel comfortable sharing their ideas, asking...

Why Companies Struggle to Embrace the Lean Startup Approach (and How to Overcome It)

You've probably heard of Eric Ries' groundbreaking book, "The Lean Startup." The methodology has revolutionized the way many entrepreneurs and businesses approach product development and innovation. But, despite its proven success, some companies still struggle to...

Why Agile Implementations Fail

Have you ever wondered why some companies fail when trying to implement agile methodologies? Well, let me tell you, there are a few reasons. First of all, if management isn't fully on board with the cultural shift that agile requires, the teams are going to struggle....

Applying the Stacey Model: When is Agile the Right Fit for your Project?

The Stacey model is a framework developed by Ralph Stacey that categorizes complex problems into four domains: simple, complicated, complex, and chaotic. The model considers the degree of certainty of the problem and the level of agreement on what needs to be done....

Waterfall is not always bad

#agilecoachingtip Waterfall is not always bad! Some projects are inherently phased-based. One recent example was a vendor selection project that I was asked to assess. It was being mismanaged using Scrum. I could list a hundred different examples like that. Can you...

2020 Scrum Guide Changes and Observations

  The following video addresses my interpretation of the 2020 Scrum Guide changes and their impact both to those currently studying for the PSM I or PSPO I exams and for those who want to understand what these changes mean to their current implementation of...

The king is dead! Long live the king!

I watch every few years as someone tries to crown a new king. You know what? Agile is dead, but it is also alive and well.

Agile Consulting Manifesto

My Agile Consulting Manifesto. While delivering successful software development projects for over 20 years and seeing the profession that I am so passionate about become damaged by misinformation, framework saturation and a complete loss of credibility, I have come to...

I may be stating the obvious—you can’t be Agile without being Lean.

In the Agile Practice Guide published by PMI® and the Agile Alliance®, there is the Venn diagram shown above. It is a simple yet useful visual that most of us long-toothed Agile practitioners clearly understand.  Unfortunately, I am finding through my training...
Do you know where you are going with your Agile implementation?

Do you know where you are going with your Agile implementation?

What every executive needs to know!

Over the past decade, I've been involved in more than 20 Agile projects. Whether as a team member, Product Owner, Scrum Master, or Coach, I've had the opportunity to play a role in many successful projects. These days, however, I’m being brought in (more and more often) to prevent Agile failures. It isn't so much that the projects themselves are failing, but that organizational impediments are preventing success. Why? Version One’s most recent annual State of Agile Survey found that an “inability to change organizational culture” and “general resistance to change” are the most common reasons Agile projects fail.
.
I believe the bulk of these failures can be traced back to the initial implementation phases. For instance, were these organizations truly aware of what they were getting into? And did they realize the types of change that Agile requires? In my Scrum Master trainings, I emphasize the need for organizations to truly understand and embrace the change they are about to embark upon. We discuss what type of organizational change is needed for a successful Agile implementation. The three types of organizational change we look at include:
.
Developmental

  • Improvements on processes, methods, or performance standards
  • Done in order to stay competitive
  • Causes little stress to employees

Transitional

  • More intrusive because it introduces something completely new
  • Typically a planned change such as a reorganization, merger, acquisition, or implementation of a new technology
  • May cause instability and insecurity

Transformational

  • This leads to an organization that is very different to the organization that existed prior to the change
  • Since the change is radical, the organization and its employees need to drastically change their views, strategies, and assumptions
  • Such change can alter an organization’s culture, ethos, and systems

Most assume that Agile is a developmental change. They see it as a process improvement and treat it as such. I would argue, however, that Agile implementation is actually closer to transformational change. Since most companies don't anticipate this transformation, care isn't taken to manage the impact of the change and the outcome is often failure. Those organizations that do see Agile as transformational are better prepared for the work needed to achieve long-term success.
.
What does it take to have a successful Agile implementation?
.
At the highest level, organizations need to outline their Agile goals and define expectations:
.

1. Is speed to market the main issue? Does the company need to deliver products more frequently?
2. Is the organization inefficient? Does it need to be “leaner” and more efficient with existing resources?
3. Is quality the issue? Does the company need to improve customer satisfaction with the software it delivers?
4. Is the organization new, or is it one that’s trying to reinvent itself and have a more empowered culture?

.
It’s critical to answer these questions before embarking on an Agile implementation.
.
With these answers, the choices become simple. If, for instance, your organization can answer YES to all four questions above, and if you're willing to do what it takes to implement the Agile approach verbatim, then you should consider implementing Scrum and XP (Extreme Programming). These are transformational approaches which focus on team empowerment and cross functional roles. They therefore require re-organization and a dramatic shift in management and leadership style.
.
I recommend using many XP practices when implementing Scrum. At an Agile New England meeting I attended a few months ago, Ken Schwaber, co-author of the Scrum Guide, stated that the merger of Scrum and XP into a single approach was originally intended. The reason for this is that Scrum doesn't dictate any specific engineering practices. XP addresses key development practices such as pair-programming and continuous integration. Its focus is on high-quality code. Technical Debt is minimized when you follow strict engineering practices. Many of the other Agile approaches make major assumptions about engineering practices already being in place. This is one of the major flaws of many current Agile implementations. If you don’t have a solid set of engineering practices and tools in place beforehand, your implementation will only have a short window of success.
.
On the other hand, if you answered NO to question number four, you should consider a more prescriptive Agile implementation. Approaches like Kanban, Scaled Agile Framework (SAFe), and Disciplined Agile Delivery (DAD) are more conservative and provide a clearer set of requirements and processes that need to be in place for the organization to be successful. I suggest that Kanban can be presented as a developmental change whereas I still consider SAFe and DAD to be transitional changes because they often require a reorganization to align with the approaches. Though I'm thoroughly familiar with Kanban, I only have passing knowledge of enterprise frameworks such as DAD and SAFe. At the enterprise level, my experience is with organizations that create their own Agile/Hybrid methodology, adopting Scrum terms but keeping many of their existing roles and processes in place. This generally creates confusion for the team members who get “certified” in Scrum but aren't actually allowed to implement Scrum as it was intended.
.
Here’s a matrix to help you choose your approach:

Goal

Scrum/XP

Kanban

SAFe/DAD

Improve project success
Be more efficient with resources
Increase IT quality
Have a more empowered culture

.
If you've read my other blog posts, you know that I’m totally onboard when it comes to adopting a full Agile implementation of Scrum and XP—even though it’s EXTREMELY difficult. The key thing to realize when implementing Agile’s most popular approaches (Scrum, XP, DAD, SAFe, etc.) is that you must embrace the entire approach. If you don’t, you’ll quickly become susceptible to confusion and implementation “fatigue” from team members and stakeholders. The implementation will become a struggle and it will probably fail. In Scott Ambler’s 2013 IT project survey, he finds that 64% of Agile projects are successful while only 49% of traditionally run projects manage to achieve the feat. To me, this isn't an overwhelming improvement given the amount of effort required to implement Agile. It’s hard to decipher whether or not these Agile implementations were well-executed. We only really know that organizations which call themselves Agile are still struggling with 36% of their projects.
.
Summary:
.
If you're not willing to embrace cultural change, DON’T DO SCRUM OR XP. Go with Kanban, SAFe, DAD, or an internally developed hybrid instead.

If you don't have engineering best practices and support tools, such as automated regression testing and continuous integration, then YOU'RE NOT READY FOR AGILE. Step back and institute these processes first before building a new project management approach on top of a flawed foundation.

Interested in learning more about my approach to selecting a project management approach? Check out my online training Implementing Kanban for Project Management in my Agile Training store: http://buyagile.com/Kanban1
.
References:

About the author, Dan Tousignant, PMP, PMI-ACP, PSM 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.

Dan Tousignant, President
Cape Project Management, Inc.
Contact: Dan@CapeProjectManagement.com
Does your organization need an Agile Coach?

Does your organization need an Agile Coach?

As we love to say when answering many questions pertaining to Agile, “It depends.” Not the answer you want to hear, but let me elaborate. Extreme Programming (XP) introduced the term coach into the Agile community. The role was intended to both be a mentor on XP practices and a hands-on developer when needed. Scrum created the role of the Scrum Master with similar expectations but without the emphasis of being a hands-on developer.
The term, Agile coach, has become ubiquitous; however, it hasn't been used as XP intended. Quite often, the term refers to an external consultant and very seldom will you see it applied to an internal position.
I have played the role of Agile coach on and off over the last decade, and I didn’t always use the term coach. I was a coach when I was a program manager of a large Agile initiative; I was a coach when I was a functional development manager; and I was an Agile coach consultant hired to serve multiple Scrum teams. What was common for each of those roles was that I was the most experienced person in the room on Agile practices and I had a passion for passing on that knowledge to the teams I was working with.
In the first two instances, though I wasn’t formally named a coach, it was clear based upon my experience and willingness to share, that people felt comfortable approaching me for advice and discussion. Recently as an Agile Coach consultant, the same dynamic was true, but my role was more formal.

Do I need to be called an Agile coach to be an Agile coach?

Anybody with a passion for learning and sharing Agile best practices can be a coach. Becoming a coach is like becoming a leader. As with leaders, coaches can emerge from within a team.

What skills do I need to be an Agile coach?

  • Active listening
  • The ability to influence without authority
  • Experience – with both success and failure
  • Patience
  • The right attitude!

If they don’t work for me, how can I tell them what to do?

Here is a real situation I faced while coaching a Scrum Master. I had just sat through a very painful Sprint Retrospective:

Coach: “How did you feel that Retrospective went?”
Scrum Master: “It went fine, but the team is bored with them so I try to get them over with as quickly as possible.”
Coach: “Are you open to working with me to prepare something more fun and engaging for the next Sprint Retrospective?”
Scrum Master: “Definitely!”

In this situation, I didn't  immediately tell her what I would do differently, I gave her an opportunity to choose whether she wanted help or not.

How can I be an Agile coach for people that work for me?

I find this situation to be the easiest in many ways. My management style is very much in line with a typical coaching style. I work with the individual on their career goals and set a specific Agile maturity path based upon their experience and role. Some of these goals are around Agile best practices and engineering principles, and most often, it is about soft skills like listening, being self-organizing, and peer influencing.

So, back to the original question, does my organization need an Agile coach?

Every organization that is in the beginning or in the midst of implementing Agile needs someone who can be an Agile Coach. The question really should be, “Who should be playing the role of Agile Coach?”
If the Scrum Master is experienced and has the soft skills necessary, then the Scrum Master is often the coach. If there is a development manager or practice lead with the necessary background and desire, then they can be the coach. A team member can emerge as the coach if he or she has the passion and emerges from within the team.
If none of these internal candidates exist, you may need to look outside the organization—at least on a temporary basis—to fill this role. The ultimate goal is for everyone on the team to have a high level knowledge of Agile principles and practices, so that they can self-organize and continue to improve; resolve impediments; be productive; and truly enjoy their jobs. Then . . . there will no longer be the need for one individual to be a coach.

About the author, Dan Tousignant
Dan is a lifelong project manager and trainer with extensive experience in managing software development projects. Based upon this 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 president of Cape Project Management, Inc.

email: dan@capeprojectmanagement.com

Why Scrum “Master”? What about Scrum Apprentice? Maybe we need a Scrum Jedi?

Why Scrum “Master”? What about Scrum Apprentice? Maybe we need a Scrum Jedi?

I learned the term Scrum Master back at the turn of the century (I like how that sounds). I first heard it from Ken Schwaber himself. At that point in my career, I was a true and tried project manager that had recently earned his PMP. I was a self-taught project manager, and looking back, my instincts and style were better suited for Agile, but I happened to go down the formal PM path first. After 10 years of experience, I had come to the conclusion that project management was a “craft”.  I believed it then and I believe it even more now, which is why I struggle with the term “Master.”

What does it take to be a "Master" of Scrum?

I was a carpenter before I was a project manager. I was the only honors student taking wood-working classes in high school and I worked as a carpenter’s apprentice during the summer while I was in college. I had tremendous respect and even awe for the master craftsmen I worked with. In carpentry, the term Master is reserved for the likes of Norm Abram. Also, to be a union carpenter, you have to go through a rigorous apprentice and journeyman program before you can get paid as a true master carpenter.

In history, you had to earn the term “Master” to be seen as the top of your craft. Wikipedia has a good definition:

“An aspiring master would have to pass through the career chain from apprentice to journeyman before he could be elected to become a master craftsman. He would then have to produce a sum of money and a masterpiece before he could actually join the guild. If the masterpiece was not accepted by the masters, he was not allowed to join the guild, possibly remaining a journeyman for the rest of his life.”

I think the intent with the term Scrum Master is that the title should be reserved for those that have earned the title of Master, but that is obviously not the case. There is no job requirement or career path to become a Scrum Master.  Most of us have had some type of career path as we developed our skills; e.g. in software engineering, there is a typical path of analyst, developer, designer, architect or in project management: project coordinator, project manager, senior project manager, program manager.

So, how does someone earn the designation of Scrum Master? Until recently, it was just take a 2-day class. Now, at least there are exams to test your knowledge of Scrum. It is surprising how we have come to a place where the term Master can be designated without any true effort or experience. Most of us have had to show both experience and knowledge to get the certifications we have. PMI, for example, requires the PMP and the PMI-ACP designation be based both upon experience and knowledge.
I am not sure if there is a way to backpedal to introduce qualifications for Scrum Master, so maybe we need a new term that actually requires that someone has proven themselves. How about Scrum Jedi? Just a thought… All I ask is that I get credit for the term when it goes viral…

Dan Tousignant, (long list of acronyms usually goes here, some hard earned, others...)

@ScrumDan

BE AGILE.®

The Agile Success Algorithm

The Agile Success Algorithm

al·go·rithm

algəˌriT͟Həm/

noun
1. a process or set of rules to be followed in calculations or other problem-solving operations
Those of you reading this are more than familiar that Agile is all the rage. Executives like to say that their organization is going "Agile". They throw out terms like Scrum and Kanban without truly understanding what they are getting involved in.
In order for Agile to be implemented successfully, I have created the following simple algorithm. Embrace Change + Learn from Mistakes = Agile Implementation Success.

Input 1 = Embrace Change

The primary risk with implementing Agile involves the ability your organization to embrace change. You need to answer the following questions about your organization's culture and your leadership team before you can successfully implement Agile:
How does your organization respond to change?

  • When was the last time your organization underwent any major changes?
  • Have they been through major layoffs? Have they introduced new leadership?
  • How long have they been in business? Have there been major new product introductions?
  • Have they been acquired or merged?

How did these changes go? In this case, past performance often dictates future performance. If your company struggles with change, then they will have trouble introducing Agile. Agile introduces change in so many ways:

  • Changes in roles, title and responsibilities. Just look at the roles in Scrum, since it is currently the most popular Agile method being implemented. How easy is it for your organization to adopt these roles?
    • A Scrum Master?   How many managers or project managers do you know who truly understand the concept of servant leadership? How many organizations allow for management positions that do not have direct reports? To truly be successful with Scrum, a Scrum Master role has to be created from scratch, not just assigned to an existing function.
    • A Product Owner??   Organizations that have a mature product manager function can transition easily to this, but many organizations manage product related decisions by committee with a team of business analysts. The role of a truly empowered Product Owner is difficult for many companies to swallow.
    • A Scrum Team??? A self-organizing team is the foundation of Scrum and of Agile in general. How many organizations actually foster this? How many middle manager's jobs would be eliminated if an organization becomes successful with this? How many under performers would be exposed in this model? This is the most difficult, yet most critical change required.
  • Changes to process.
    • No analysis or  business requirements phase? No Gantt charts? No 12 month project plan? Traditional project management was just formalized at many organization in the last decade. Formal PMOs have been rolled out, massive enterprise tracking tools implemented and teams of project managers hired to create and maintain documentation. Can your organization tolerate getting rid of all the processes you just implemented?

Input 2 = Learn from Mistakes

Only a company or leadership team that has experienced project failures can truly appreciate and support an Agile implementation. These failures may have come in many different ways:

  • The project came in too late to meet the market opportunity.
  • The budget changes were so excessive that the project was either terminated or deemed a total failure.
  • The customer rejected the product because it was "not what they were expecting."

The list goes on and on....The Agile Manifesto was not crafted by grad students developing a thesis. It was developed by people who were clear that the way we were working wasn't working. Many people, like myself, have become Agile evangelists only after suffering through one or more of the above project failures over which we had no control. One of the major downsides with introducing Agile to the "younger" workforce is that they don't truly appreciate how much more fun and enjoyable it is to work on an Agile project. Give them one month of using project time-sheets and hourly tracking in an ERP tool and they will start to see the light.

Output = Agile Implementation Success!

The benefits of Agile are self-evident for those who have lived through traditional project failures and are willing to change. There are hundreds of successful case studies and stories of successful Agile implementation, but implementation failures are becoming more and more common. Becoming "Agile" is not just using the term "Agile", it is a transformation that will effect your entire organization.

Dan Tousignant, PMI-ACP, PMP, PSM, CSPO, CSP
@scrumdan

error

Enjoy this blog? Please spread the word :)