100% on Professional Scrum Master 1 (PSM 1) Certification Exam

I took the Professional Scrum Master 1 (PSM 1) certification exam today. I passed with a score of 100%. I will briefly share how I prepared for the test.

How I Prepared

I have experience using Scrum as a product manager. That proved to be helpful in understanding how to practically apply Scrum. I experienced many of the situations where a question includes a Product Manager.

I read through chapters 1 to 17 of Agile Project Management for Dummies on my Kindle. I found it helpful to understand broad concepts. It probably is more than what is needed for the certification test. Yet I felt very comfortable reading the Scrum guide and sample test questions after reading this book.

I read through some forum posts. This post (https://www.scrum.org/forum/scrum-forum/6156/psm-i-passed-100) was written by another person who passed with 100%. This post (https://www.scrum.org/forum/scrum-forum/7708/passed-psm-i-975-experiences) is more recent and the person passed with 97.5%.

I did the Scrum Open Assessment test about eight times. Several exam questions are similar to what I saw in other practice exams.

I did several practice exams on https://www.techagilist.com/practice-exams/psm-i-practice-test/psm-practice-exam-real-mode-questions/. These seem to be very popular and match what is in the Scrum Open Assessment test.

I spent US$9.99 for one week of access to  the Scrum Master Certification practice exam at https://www.capeprojectmanagement.com/agile-exams/. These are provided by Cape Project Management, Inc. I tried about eight sets of eighty question practice exams. The questions are similar to what I saw in other practice exams. There is similarity between questions in each practice exam. However, I liked the questions and I think that they helped me pass.

I read the Scrum Guide about 12 times. I would take one or two practice tests and then read through the Scrum Guide. This process helped me find the answers to practice questions that I got wrong. I kept doing this until I felt that I could answer correctly and explain why the other answers were wrong.

I read through the exam tips on https://www.volkerdon.com/pages/psm-1-exam-tips. I took the sample exam, too. I read through parts of the available course material. I thought that the course material was good; but I had a good understanding of the Scrum framework by the time I came to this website. It is probably a good idea to read through their course material if you have not read anything else but the Scrum Guide.

The Test

I had some concerns that the real exam would be more difficult than the practice exams. These concerns were based on some forum posts that I read. However, I thought that the actual exam was similar to what I had seen on practice exams; but not identical. I think that this is because I had worked through about 25 full practice exams. I also had experience, read a book on Agile, and read through the Scrum Guide many times.

I could answer most questions quickly. I returned to review a small number of questions. I changed answers on three questions after reading through them carefully again.


I agree with the forum posts that I read. However, I recommend that you take a couple of practice exams and then read the Scrum Guide. Repeat this process several times. Read a book on Scrum and/or Agile if you don’t have experience or knowledge.

Good luck when you take the PSM 1 test!

Agile Enterprise Architecture

I have spent the past few months thinking about why I would want to implement a complex and detailed enterprise architecture framework. I’ve always been an agile thinker. How can I rapidly implement a digital transformation using an enterprise architecture framework? Thus, I did some research and thinking. Below are my summarized thoughts. I include references and sources.

Good enterprise architecture takes a lot of work. The process, roles, and responsibilities are well-defined. There is a benefit to following a model that others use. But does the benefit outweigh the cost?

“The fundamental quality of Enterprise Architecture is its vision of the future.”

– Angelo Andreetto in Is Enterprise Architecture Completely Broken?

The TOGAF framework emphasizes vision definition as early as possible. However, fully defining the vision and creating an implementation plan can take a substantial effort. The actual implementation of the vision could be many months into the future. This approach provides little agility for businesses that are driving fast and deep transformations.

“Our architecture was changing faster than you can draw it. As a result, it wasn’t useful to try to draw it.”

– Adrian Cockcroft in Agile Enterprise Architecture Finally Crosses the Chasm

I can’t recommend using an enterprise architecture framework that essentially follows a waterfall approach while development teams are using Agile and DevOps. The two cannot coexist without creating tension. Only one can emerge victorious – or perhaps neither; but the organization may fail in achieving the vision in the end.

In 2010, the IBM Software Group reported on why enterprise architecture (EA) programs were cancelled. I am listing the top ten reasons below. EA failure was deemed to be due to “overpromising and under-delivering” or to “people issues”. These failures are very concerning to me. The success factors / strategies reported that “people issues” was the primary driver of success.

  1. Insufficient time provided
  2. Project teams didn’t take advantage of the EA
  3. Too difficult to measure benefits
  4. Enterprise architects perceived as “ivory tower”
  5. Development teams couldn’t wait for enterprise architects
  6. No perceived benefit of EA program
  7. No executive endorsement
  8. Enterprise architects weren’t sufficiently flexible
  9. Enterprise architects perceived as impediment to success
  10. Insufficient funding

The IBM Software Group report made the following recommendations.

  • You need to understand the business
    • Architecture must be based on requirements, otherwise you are hacking
    • There are two aspects to architecture, business and technical
  • Individuals and interactions
    • Supplying models and documents isn’t sufficient
    • Support project teams
    • Roll up your sleeves and work closely with the teams
    • Architecture comes from teams, not individuals

I found this report to be quite enlightening. The report recommended more communication and interaction. There should be less focus on models and documents with more focus on solutions that work immediately. For example, reduce the technical risk on a project by proving the architecture with code. This is a recommendation that the TOGAF framework does not seem to support. But you must do this in an agile environment. I often tell people that the benefit of a good diagram is that it explains an idea or concept to many different people. They all can have a common understanding and then continue to work. The value of the diagram is not to create it as part of a framework; the value is in the benefit it provides to others.

Furthermore, the goal is not to create many diagrams. This just means more maintenance work over time. Diagrams can be thrown out when they no longer serve their intended purpose. Thus, another goal is to “travel light” as work moves forward. Use a slim model that can be quickly updated or replaced as needed. It seems to me that the report is recommending moving to a much more agile approach to enterprise architecture.

Scott W. Ambler provided the following principles for capturing enterprise architecture in an agile manner:

  • Organizations are complex systems
  • Complex systems cannot be managed at a fine-grained level, but only at a meta level (management by rules)
  • Documentation for complex systems should be coarse (high level)
  • Describe how things work in principle
  • Predictions should be fuzzy and described as ranged probabilities
  • It is more important to strengthen a system’s resiliency than it is to document
  • Accept some disorder and ambiguity
  • Working examples are more valuable than documents

I think that these principles support agile development. This is probably the right time to mention the Manifesto for Agile Software Development.

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

Thus, in my opinion, the enterprise architecture framework must support successful agile software development. It should not be the reverse situation. That is, agile software development must not support successful enterprise architecture implementation. In the latter case, both would fail because they cannot coexist in harmony.

An agile enterprise architecture framework that supports agile software development would benefit an organization. This would allow an organization to rapidly implement digital transformations in response to market pressures.

Next Steps

Marc Lankhorst lists two new enterprise architecture frameworks that provide a more agile approach: Scaled Agile Framework (SAFe) and Disciplined Agile Delivery (DAD). He provides a comparison of TOGAF’s Implementation Governance (Phase G in the ADM) with SAFe. Marc states that “agile methods strongly rely on feedback loops, whereas TOGAF’s governance is rather feed-forward in nature”.

I think that I need to read more of Marc’s blogs and other resources. I want a better understanding of what an agile enterprise architect must do to support the enterprise organization and the agile software development teams. At least, I want validation that my current understanding is on the right path.


Link Title Author Published
https://www.slideshare.net/ScottWAmbler/agile-enterprise-architecture-62467855 Agile enterprise architecture Scott W. Ambler May 27, 2016
https://www.forbes.com/sites/jasonbloomberg/2014/07/23/agile-enterprise-architecture-finally-crosses-the-chasm/#65e4035852a5 Is Enterprise Architecture Completely Broken? Jason Bloomberg July 11, 2014
https://www.forbes.com/sites/jasonbloomberg/2014/07/23/agile-enterprise-architecture-finally-crosses-the-chasm/#65e4035852a5 Agile Enterprise Architecture Finally Crosses the Chasm Jason Bloomberg July 23, 2014
https://www.agilealliance.org/wp-content/uploads/2016/01/Agile-Enterprise-Architecture.pdf Agile Strategies for Enterprise


IBM Software Group 2010
https://bizzdesign.com/blog/enterprise-architecture-and-agile-development-opposites-attract/ Enterprise Architecture and Agile Development: Opposites Attract? Marc Lankhorst May 28, 2016