How To Study And Pass The PSD-I Assessment From

The Professional Scrum Developer I assessment is a 60 minute time boxed test where you answer 80 multiple choice type questions. It costs $200 to take and the passing score is 85%.

I took the test September 14, 2016 and passed. My Score was 71 points (or 88.8%) PSD-I Certificate

Here’s how I studied:

Install Recoll.

Create a directory  where you store any studied document. Setup an appropriate indexing strategy so that Recoll search is rebuilt every time you add a new document to your Scrum study folder.

Study the following documents:

Save the above documents into your study folder.

Read posts in the forum.

Once a day, for at least a few weeks, do the SCRUM OPEN, PRODUCT OWNER OPEN, and DEVELOPER OPEN assessments. When you finish an open assessment it will let you print a summary of your results. Save every summary in your study folder.

Keep doing the open assessments until you consistently get 100% every time

Keep doing the open assessments until you’ve seen every possible question.

The day before doing the test, take the time to create a single open assessments master document. Copy, paste (and study) all the information from all the open assessment summaries into the master document. When creating your master document avoid duplicate questions. Having to search through duplicates will slow you down.

Ignore any resource that doesn’t come from

When you’re ready, pay money to do the test, use your Recoll index to search for help when you don’t know an answer.

Good luck.

Free Online Scrum Training

These Scrum Training Series videos are my favourite. The site also offers a nice Scrum reference card. Choice quote:

Doing Scrum, or Pretending to Do Scrum? Scrum’s relentless reality checks expose dysfunctional constraints in individuals, teams, and organizations. Many people claiming to do Scrum modify the parts that require breaking through organizational impediments and end up robbing themselves of most of the benefits.

The Code Manifesto

We want to work in an ecosystem that empowers developers to reach their potential–one that encourages growth and effective collaboration. A space that is safe for all.

A space such as this benefits everyone that participates in it. It encourages new developers to enter our field. It is through discussion and collaboration that we grow, and through growth that we improve.

In the effort to create such a place, we hold to these values:

  1. Discrimination limits us. This includes discrimination on the basis of race, gender, sexual orientation, gender identity, age, nationality, technology and any other arbitrary exclusion of a group of people.
  2. Boundaries honor us. Your comfort levels are not everyone’s comfort levels. Remember that, and if brought to your attention, heed it.
  3. We are our biggest assets. None of us were born masters of our trade. Each of us has been helped along the way. Return that favor, when and where you can.
  4. We are resources for the future. As an extension of #3, share what you know. Make yourself a resource to help those that come after you.
  5. Respect defines us. Treat others as you wish to be treated. Make your discussions, criticisms and debates from a position of respectfulness. Ask yourself, is it true? Is it necessary? Is it constructive? Anything less is unacceptable.
  6. Reactions require grace. Angry responses are valid, but abusive language and vindictive actions are toxic. When something happens that offends you, handle it assertively, but be respectful. Escalate reasonably, and try to allow the offender an opportunity to explain themselves, and possibly correct the issue.
  7. Opinions are just that: opinions. Each and every one of us, due to our background and upbringing, have varying opinions. The fact of the matter, is that is perfectly acceptable. Remember this: if you respect your own opinions, you should respect the opinions of others.
  8. To err is human. You might not intend it, but mistakes do happen and contribute to build experience. Tolerate honest mistakes, and don’t hesitate to apologize if you make one yourself.


eXtreme Go Horse (XGH) Process

eXtreme Go Horse (XGH) Process

1. I think therefore it’s not XGH.

In XGH you don’t think, you do the first thing that comes to your mind. There is no second option as the first one is faster.

2. There are 3 ways of solving a problem: the right way, the wrong way, and the XGH way.

The XGH way is exactly like the first two but faster. XGH is faster than any development process you know (see Axiom 14).

3. You’ll always need to do more and more XGH.

For every solved problem using XGH seven more problems are created. And all of them will be solved using XGH. Therefore XGH tends to the infinite.

4. XGH is completely reactive.

Errors only come to exist when they appear.

5. In XGH anything goes.

It solves the problem? It compiled? You commit and don’t think about it anymore.

6. Always commit what you code.

If things go wrong your part will always be correct… and your colleagues will be the ones dealing with the problems.

7. XGH never misses a deadline.

Schedules given to you by your clients are all but important. You will ALWAYS be able to implement EVERYTHING in time (even if that means accessing the DB through some crazy script, breaking other parts of the software, etc.)

8. Be ready to jump off when the boat starts sinking. Or blame someone else.

For people using XGH someday the boat sinks. As time passes the system grows into a bigger and bigger monster. You better have your resumé ready for when the thing comes down. Or have someone else to blame.

9. Be authentic. XGH doesn’t follow patterns.

Write code as you may want. If it solves the problem you must commit and forget about it.

10. There’s no refactoring just rework.

If things ever go wrong just use XGH to quickly solve the problem. Whenever the problem is too big and requires rewriting the whole software it’s time for you to jump off before the whole thing goes down. (see Axiom 8)

11. XGH is anarchic.

There’s no need for a project manager. There’s no owner and everyone does whatever they want when the problems and requirements appear.

12. Always believe in improvement promises.

Putting TODO comments in the code as a promise that the code will be improved later helps the XGH developer. He/She won’t feel guilt for the shit he/she did. Sure there won’t be no refactoring (see Axiom 10).

13. XGH is absolute.

Delivery dates and costs are absolute things. Quality is relative. Never think about quality but instead think about the minimum time required to implement a solution. Actually, don’t think. Do! (See Axiom 1)

14. XGH is not a fad.

XP, Scrum, Lean? Those are just trends. XGH developers don’t follow temporary trends. XGH will always be used by those who despise quality.

15. XGH is not always WOP (Workaround-oriented programming).

Many WOP require smart thinking. XGH requires no thinking (see Axiom 1).

16. Don’t try to row against the tide.

If your colleagues use XGH and you are the only sissy who wants to do things “the right way” then quit it! For any design pattern that you apply correctly your colleagues will generate ten times more rotten code using XGH.

17. XGH is not dangerous until you see some order in it.

This axiom is very complex but it says that an XGH project is always in chaos. Don’t try to put order into XGH (see Axiom 16). It’s useless and you’ll spend a lot of precious time. This will make things go down even faster. (see Axiom 8) Don’t try to manage XGH as it’s auto-sufficient (see Axiom 11) as it’s also chaos.

18. XGH is your bro. But it’s vengeful.

While you want it XGH will always be at your side. But be careful not to abandon him. If you start something using XGH and then turn to some trendy methodology you will be fucked up. XGH doesn’t allow refactoring (see Axiom 10) and your new sissy system will collapse. When that happens only XGH can save you.

19. If it’s working don’t bother.

Never ever change – or even think of questioning – working code. That’s a complete waste of time, even more so because refactoring doesn’t exist (see Axiom 10). Time is the engine behind XGH and quality is just a meaningless detail.

20. Tests are for wimps.

If you ever worked with XGH you better know what you’re doing. And if you know what you’re doing why test then? Tests are a waste of time. If it compiles it’s good.

21. Get used to that ‘living on the edge’ feeling.

Failure and success are the same thing. People normally think that a project can have greater chances of failing when using XGH but that’s just one way of seeing it. The project failed. You learned something with it? Then for you it was a success!

22. The problem is only yours when your name is in the code comments.

Never touch a class of code which you’re not the author. When a team member dies or stays away for too long the thing will go down. When that happens use Axiom 8.

File Under: Funny

SCRUM Open Assessments

“The way to make a million dollars is to start a religion software development methodology.”

What does it mean to be a SCRUM disciple when you are a lone freelancer working remotely? For me it means the knowledge you retain by practising SCRUM in an Agile work environment fades.

Doing these open exams once-in-a-while helps jog my memory:

…bet you can’t beat my scores!

Developer Open
100% of my SCRUM – up to you true star.