The 2018 PMI-ACP® Exam Changes

The 2018 PMI-ACP® Exam Changes

Daniel Tousignant

The Project Management Institute (PMI®) has proceeded down the path of embracing Agile. On March 26, 2018 both the PMP® and PMI-ACP® exams with be updated to reflect PMI's new Agile Practice Guide and the PMBOK® 6th edition. You can read about the changes here.

My Observations

PMI stated there were not any changes to the overall course outline for the PMI-ACP exam, but changes were made to "harmonize with terminology" used in the practice guide. After scouring the guide, I made a number of updates to my practice exam questions, training content and my self-study training.

Here are my takeaways after reviewing the guide in detail:

  • Ultimately their goal is to become framework neutral so there is an attempt to create some common terminology and practices.
  • There are now 3 generic Agile roles, taken primarily from Scrum:
    • Team Facilitator
    • Cross Functional Team Members
    • Product Owner
  • There was recognition that there is no PM role in Agile but the PM can play the role of Team Facilitator
  • They have stated the need for PMOs in an Agile environment
  • There are now 2 generic Agile approaches:
    • Iteration-based Agile (essentially Scrum)
    • Flow-based Agile (essentially Kanban)
  • Transparency, Inspection and Adaptation (from Scrum) are now considered to be generally Agile principles
  • Stories (for Agile requirements) now seem to be accepted terminology. I don't think they were even referred to in the initial version of the exam
  • I like how they now have a Venn diagram for Lean and Agile and how Kanban bridges both. That will become a popular training graphic
  • Hybrid and scaling were now acknowledged, though minimally. I don't expect to see many more questions on this area yet- too much inconsistency in the marketplace.
  • I think they have embraced the following pure Agile concepts even though they are the very opposite of traditional PM:
    • Servant leadership
    • Generalizing specialists
    • Burndown charts and Kanban boards instead of Gantt charts
  • Even though there was a lot alignment with Scrum, there were still some contradictions:
    • "The Product Owner sees the demonstration and accepts or declines the stories" - that is a big faux-pas in formal Scrum. The Product Owner should be signing off throughout the iteration and showing the final product to stakeholders at the demonstration.
    • Iterations are usually 2 weeks - that is another false reality. I trained hundreds if not thousands of people over the years and the length of a Sprint is anywhere from a week to a month. If anything, three weeks seems to be as popular as two weeks.
    • The Product Owner asks a "triad"; a developer, tester and analyst, to get together to write a story as a way to refine the backlog. Hmmm that sounds dysfunctional to so many ways...

Summary

In addition to those terminology changes I mentioned, the guide provided a little more detail into some of the definitions of terms that were already in the exam outline. Though it is by no means perfect, it is a big step in developing a common terminology and set of practices called "Agile."  The exam is difficult to study for and difficult to train because there was, and still is, so many contradictory terms in the Agile community. Even within PMI's recommended reading list the authors contradict each other. The best part is that the Agile Practice Guide is a little more than 100 pages, as opposed to the nearly 1000 pages in the latest PMBOK. Let's hope it stays that way!

Remember, if you are studying for the exam I have the most popular FREE PMI-ACP study guide and other great resources for studying for the exam.

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...

How Agile are you? Free Agile Maturity Assessment

NEW! Become a Certified Agile ProfessionalWhen 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...

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...

The 2018 PMI-ACP® Exam Changes

  The Project Management Institute (PMI®) has proceeded down the path of embracing Agile. On March 26, 2018 both the PMP® and PMI-ACP® exams with be updated to reflect PMI's new Agile Practice Guide and the PMBOK® 6th edition. You can read about the changes here....

What’s next on your Agile journey?

Hello Agile Adventurer: My son Zach and I hiking in Maine. As an avid hiker, I tend to focus on the journey not so much the destination. The same is true with Agile. All of you are in a different place on your Agile journey. Some of you are well into your Agile...

An Agile software development approach could have prevented this – just saying.

UPDATE: January 30, 2018 The Washington Post published an article with more details: https://www.washingtonpost.com/news/the-switch/wp/2018/01/30/heres-what-went-wrong-with-that-hawaii-missile-alert-the-fcc-says/?utm_term=.84e766af06c6 It is interesting that one of...

The Practical Agile Blog

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...
Please follow and like us:
What’s next on your Agile journey?

What’s next on your Agile journey?

Hello Agile Adventurer:

My son Zach and I hiking in Maine.

As an avid hiker, I tend to focus on the journey not so much the destination. The same is true with Agile. All of you are in a different place on your Agile journey. Some of you are well into your Agile implementation while others of you are still getting started. I would like to offer you some tips and tools for your journey:

Where are you today? Assess your Agile Maturity: I have a free Agile assessment to help you see where you are. It includes 60 yes/no type questions that are weighted to give you an overall maturity score. In an effort to continuously improve, you should try to perform self-assessments at least once per year: https://www.capeprojectmanagement.com/agile-self-assessment/

If you would like an assessment of your whole team or company, contact me about my group assessment and full-day retrospective: https://www.capeprojectmanagement.com/advanced-agile-review-and-assessment/

Tools to help you on your journey:

  1. Be prepared! Take a refresher training or get new team members up to speed quickly: All of my core Agile courses are available in self-study narrated slide-based courses with module tests: https://capeprojectmanagement.learnupon.com/store
  2. Learn and share your experiences: Read my Practical Agile Blog. Provide your own comments or insights. If you have an article you want to share, I would be happy to post in on my blog as well: https://www.capeprojectmanagement.com/blog/
  3. Refine your skills, get certified: Though I am a firm believer that certification alone is not a measure of skill, it does show a commitment to improvement. I provide practice exams and online training for all the “open source” certifications, e.g. those that don’t require a specific licensed course or franchisee trainer. https://www.capeprojectmanagement.com/agile-exams/ Also, if you didn’t know the PMI-ACP exam is changing again on March 26, so if you have been studying, make sure you take it soon!
  4. Lastly, on a separate note, some of you are using Agile to start a new business or you are starting all over. For the last couple of years, in addition to coaching organizations, I have been providing personal coaching. This, along with my website hosting services, have been been fulfilling work because I am able to help individuals achieve their dreams and aspirations. Let me know if you would like some help to reach your destination.

Again, treat Agile as a journey. There is so much to experience along the way and so many opportunities for success. Good luck in your achieving all of your goals in 2018!

Dan

@scrumdan

dan@capeprojectmanagement.com

 

 

Please follow and like us:
An Agile software development approach could have prevented this – just saying.

An Agile software development approach could have prevented this – just saying.

UPDATE: January 30, 2018 The Washington Post published an article with more details: https://www.washingtonpost.com/news/the-switch/wp/2018/01/30/heres-what-went-wrong-with-that-hawaii-missile-alert-the-fcc-says/?utm_term=.84e766af06c6 It is interesting that one of the suggestions I mentioned to prevent this was actually in place, "They then must click 'yes' when the system asks 'Are you sure that you want to send this Alert?'" the article also stated that the application uses “the same language irrespective of whether the message [is] a test or actual alert.” Hmmm.

I live most of the year in Hawaii on the island of Oahu and was woken by this alert last week. Needless to say it was a distressing event that should not have happened. I don’t claim to have any inside information other than what I have read in the paper, but I have managed enough software development projects to know the root cause of this kind of error. I have been contemplating writing about this for the last week, and first of all I want to say, “Do not fire the person that sent this out!” This was user error but based upon a poorly designed system that is all too common in software development projects. For those of you who aren’t in the industry, let me walk you through how this happens:

“Traditional” Approach to Project Management:

Step 1 Business Requirements: A business person or customer decides what they want an application to do and they create a high-level requirement. e,g. “Create an application to allow a user to send out an alert to the phone and television emergency systems. This application should have a dual purpose for both testing the system and for sending actual alerts.”

Step 2 Analysis and Design: Analysts then create a set of system requirements based the business requirement. A designer designs screens to support the application. An architect designs how each piece will work together. They write everything down and get sign-off from their business stakeholder. They then hand it to a software developer to build. Sounds good so far?

Step 3 Development: (This is where it really break down) The developer builds it exactly the way it was written down!

Step 4 Testing: (Final failure point.) The developer hands-off the application to the tester, who tests it to make sure it meets the original business requirement and technical specifications. Once it passes the tests, it is ready to go live.

Again, for those of you who are not in this industry, the above steps probably seem completely reasonable, and many projects are still run this way. The problem is, this approach is why 50% of projects fail. I worked under this model for about 10 years until I experienced a couple of major project failures. Those project failures probably cost more than the above mentioned failure because they were expensive commercial software development projects that built a product “exactly the way it was written down.”

After those experiences, I became an Agile evangelist. For the last 10+ years I have focused on managing, consulting and training on Agile practices. We still have failures but there are far fewer, and if we fail, we fail fast. Also, Agile software development is a true collaboration between the users and the developers. So, for those of you who do not know much about Agile, let me tell you how we (the Agile community) would manage this project:

Agile Approach to Project Management: 

Step 1 Business Requirements: This step is pretty much the same - a business person creates a high-level requirement. e,g. “Create an application to allow the user to send out an alert to the phone and television emergency systems. This application should have a dual purpose both for testing the system and for actual alerts.” We call this big requirement an Epic.

Step 2 Analysis and Design – Agile Discovery: (This is where everything changes) There is no analyst or middle-man between the developer and the business. Here is what we do:

  • The business person is part of the project and joins the development team.
  • At the start of the project we then have a workshop to break that big requirement into smaller requirements called user stories.
  • Included in the workshop are the people who will be developing and testing the software, business people, potential users and any interested stakeholders.
  • There is a facilitated session where we review the high level requirements and ask the following questions*:

What will the user likely do next?

What mistakes could they make?

What could confuse them?

What additional information might they need?

*Let me be clear, I did not come up with these questions in response that alert failure. It may look like I am using hindsight to fix the problem since asking those questions and addressing them would have obviously prevented the alert from being sent out. The reality is, I took those questions directly from an Agile training I have been delivering for years. I learned that technique from a leading Agile author, Mike Cohn, in his book User Stories Applied: For Agile Software DevelopmentThis is a common technique in Agile to ensure an application is well thought through.

  • The final difference in this step is that in that requirements meeting the developers are listening, asking questions, and writing notes that make up the specification. There is no second hand information, they design and build the application based upon their conversation with their customer.

Step 3 Agile Development: A key difference in Agile is that requirements are presented as a problem to solve not a specification to be built. It is the developers’ job to come up with a solution. The developers understand the business need since they reviewed the requirements with their customer. They are empowered to ask questions and clarify the design while they build it. They have a business owner or customer representative on the team who is available daily to answer questions. They are asking questions in real time, such as, “It seems like the requirement to test the system and execute a real alert are very different activities and should have a very different workflow and authentication model? Technically, there are many ways we can prevent errors from happening. Can I show you a couple of options?” Again, I am not using hindsight. I worked with systems that had a single critical field that if filled in incorrectly required a lot of work to fix. In those cases developers know the technical, and often simple, best practices to ensure quality of data entry. You may have seen these before even on a regular webpage:

  • Please enter your password again (replace the word password with “authorization for an alert”)
  • Please type YES if you want to close this screen without saving (replace the words without saving to “send the alert”)
  • A more advanced technique I have used in the past is called Double Key Data Entry.This a common technique for ensuring quality of high-risk data entry. Two different people have to enter the same information before the workflow can progress. I used it on a project for entering SSNs since an incorrectly typed SSN caused a new customer to be created instead of updating an existing customer. This prevented a lot of rework. Seems like this would be a great approach for this situation.

Step 4 Agile Testing: Testing is done very differently as well. We test as soon as we build a single functioning piece of software. We don’t wait until we build the entire application. That prevents the high cost of fixing errors. Also, another difference, and probably more critical in this situation, is we write all of our test cases, called acceptance criteria, before we develop anything. That ensures that the developer knows how the product is going to be tested and then used in the real world.

Again, don’t blame the end-user. This happens all the time our industry it’s just that the failures aren’t so public. This is why implementing Agile has become mission critical for many organizations. Implementing Agile to prevent these problems rather than assigning blame is the real lesson learned from this experience.

About the Author, Dan Tousignant

Dan is the president of Cape Project Management, Inc. and is a lifelong project manager. He has embraced Agile as the most effective way to manage software development projects. He has been managing mission critical projects and developing training for over twenty-years and is passionate about improving project team performance.

https://www.capeprojectmanagement.com/

Dan@CapeProjectManagement.com

Please follow and like us:
The Practical Agile Blog

The Practical Agile Blog

The Practical Agile Blog

Finding ways to be Agile in an un-Agile world.
Are you ready for Agile?

Are you ready for Agile?

Has your Agency or organization started moving to Agile? Do you hear the word Scrum, and wonder where the Rugby game is at?
Well, you may be part of the growing trend in IT organizations throughout the Federal Government.

read more

Please follow and like us:
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.  

AgileMindfulness
Individuals and Interactions over processes and toolsMindfulness teaches us to be open to novelty, sensitive to different contexts and to be aware of multiple perspectives.
Working software over comprehensive documentationMindfulness teaches us to accept change, to appreciate other viewpoints and to be able to focus on the present.
Customer collaboration over contract negotiationMindfulness teaches us an awareness of multiple perspectives and listening to hear versus listening to reply.
Responding to change over following a planMindfulness 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.

 

BE AGILE.®

Please follow and like us:
error

Enjoy this blog? Please spread the word :)