Exam tips for PMI ACP Certification from PMI Agile Certified Practitioner

Recently I have passed PMI-ACP exam :-) with highest band and yes I am now an PMI-ACP Certified Practitioner. This post is about my experience, preparation strategy and also I am trying to cover exam's prerequisites and requirements.  

I have noticed I found many follow forums or professional networking sites LinkedIn to find out if they want to be certified or not and it is always a hotly debated topic. With valid arguments on both sides, my personal decision was Yes, I wanted to get certified. Looking back, I have to say that I didn’t regret it. Not only it opened but some interesting ones too. In-fact I learned a lot (and started to actively use my knowledge) just by studying for the test and going through cases. 

According to PMI, The PMI-ACP recognizes knowledge of agile principles, practices and tools and techniques across agile methodologies. In order to be certified, you need to demonstrate the following and pass 3 hours exam by answering 120 questions.

My preparation strategy

First of all, the below reflects my personal experience only. Everybody’s story is different. You may already be an agile guru by experience or may be fairly new and need extra effort to prepare.

My first advise would be to join one of the PMI-ACP study groups on LinkedIn. In my case, I have been an Agile Coach for past 6 years but still the information I got from these groups was instrumental in my preparation. 

In order to satisfy the 21 educational PDU requirements, I opted for classroom training at simplilearn and also had access to there online course materials and exams. I wouldn't recommend just sticking to these notes of any tutorials rather read the main preparation book and it was Mike Griffin’s Exam Prep Book. I loved it! Really great summary at the right level of details. Overall for the exam I spent 4 weekends (i.e. 4x2=8 days) of studying because apart from weekends I was busy with my work with Red Hat. But this may vary from person to person and probably in my case since I have implemented agile practices across teams it was not extremely difficult to pass the exam. However, keep one thing in mind you need to cover the entire book and I recommend you to not skip any material. 

Take Mock tests for real exam

For final exam I have taken mock tests from quite a few sites. But mainly I have subscribed to agileexams.com for $49 which comes with 30 days membership and taken multiple short exams(25 questions in each exam) and two full exams (120 questions in exam). Fun with agileexams.com  you can take as many as exams you like and remember to review answers understanding why something is incorrect or even for that matter correct is very important because in real PMI-ACP exam you will be tested based on your understanding. Apart from that you may also take exams from following:

1. Free Full test 120 Q @ http://www.simplilearn.com/free-resources/pmi-acp-agile
2. Sample 20 Questions @ http://www.ucertify.com/exams/PMI/PMI-ACP.html
3. Free 30 Questions / exam simulator @ http://www.gr8pm.com
4. http://agiletraining.com/2011/09/24/pmi-acp-agile-certification-exam-study-tips/
5. http://pmiacptraining.com/
6. http://whitewaterprojects.com/pmi-acp-sample-exam/#
7. http://www.agiledream.com
8. http://www.proprofs.com/quiz-school/story.php?title=pmiacp
9. http://www.rmcproject.com/pmi-acp/pmi-acp-FreeContent.aspx

Exam experience

I took the exam at the Prometric center which was about 9kms from my home.

Overall my experience wasn’t very much different from what I have learned by reading other task takers comments. I had a balanced set of questions with most of them related to Scrum,XP, Lean,few risk management & Kanban questions, a good portion of situation questions, some questions on the manifesto / agile values, and some tricky ones on agile portfolio management, EVM, and costs.

I wouldn't call the test very difficult but it was challenging enough to keep me thinking very very carefully about my answers. It was more focused on testing the understanding and practical applications of the core agile values rather then on simply testing how well you remember the definitions. In other words, I encountered more “why”, “how”, and “when” then simple “what is ..” questions. Usually out of 4 answers 2 were obviously wrong but I had to choose carefully between the remaining 2. I managed to finish all 120 questions in 2 hours (120 minutes) and spent another hour reviewing my answers. The results are known immediately once you finish the test and you get a temporary certificate on the spot. Also you will be able to down the certificate from the PMI website. Few weeks later you’ll get the proper certificate by mail and waiting to receive it.

An overview of Test Driven Development (TDD)

It is also known as test-driven development (TDD) or test-first programming (TFD).

Test-first development, or test-driven development, is a rapid cycle of testing, coding, and refactoring. When adding a feature, a pair may perform dozens of these cycles, implementing and refining the software in baby steps until there is nothing left to add and nothing left to take away. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.

It is an evolutionary (iterative and incremental) approach to programming where Agile software developers must first write a test before they write new functional code. It is one of the Extreme Programming(XP) practices.

Steps:

1. Quickly add a test, basically just enough code so that the tests now fail.
2. Run the tests, often the complete test suite, although for sake of speed they may run only a subset to ensure that the new test does in fact fail.
3. Update the functional code so it passes the new test.
4. Run the tests again.
5. If the tests fail return to step 3.
6. Once the tests pass the next step is to start over (agilists may also want to refactor any duplication out of their design as needed).

Advantages of TDD:

• TDD forces developers to do detailed design just in time (JIT) before writing the code.
• It ensures that agile developers have testing code available to validate their work, ensuring that they test as often and early as possible.
• It gives developers the courage to refactor their code to keep it in the highest quality possible, because they know there is a test suite in place that will detect if they have “broken” anything as the result of refactoring.
• Research shows that TDD substantially reduces the incidence of defects.
• It also helps improve your design, documents your public interfaces, and guards against future mistakes.

I will write more into TDD practices in upcoming posts.

The road to Continuous Delivery

Continuous Delivery it's a software development practice where you make sure that your application is ready to be deployed to production at any time. You’re not only making sure that when a developer commits a change is, it is correctly integrated by building and unit testing your application (Continuous Integration). You’re also making sure that your application is always ready to be deployed by running automated and/or acceptance tests on it and testing the release process itself.

Practicing Continuous Delivery gives you several advantages:

+The time from idea to deployment to production (cycle time), is shortened.

+By shipping the product early you are encouraging early feedback. The faster you get your software to your end-user, the faster you get feedback.

+You’re always ready to deploy to production. You do not have to spend time making and testing a release.

+Because you’ve already tested the release process itself, deploying to production is simple and error-free.

+You are getting ahead of the competition and making your release process a business advantage.

How to implement ?

• Ensure both your developers and system administrators are responsible for deployment. Traditionally, the system administrator is responsible for deploying to production. By making your developers responsible too for deployment you are encouraging a culture of collaboration (DevOps) and lowers the chance of errors due to miscommunication.
• Find out what your release process looks like, make it reliable and repeatable and automate as much as possible. Make every step of the process reliable and repeatable. When your steps are reliable and repeatable, then they can also be automated. As our goal is to automate each step.
• Setup one single way of deployment to an environment. Make sure that you define a single way to deploy a release to an environment, whether is it the test environment or to production. If you do this, then you’re also testing your deployment process itself.
• Test on a production-like environment. If you test on a different environment than your production environment, then there is a risk that your deployment to production doesn’t work or worse: your end-users experience runtime problems due to different software versions of third-party software and libraries.
• Quality first Keeping your application deployable should get higher priority than adding new features. If an error in your release process occurs, fix it as soon as possible.

Where do I start ?

It takes effort to fully practice Continuous Delivery. But you may start slowly by:

• Let your developers and system administrators work together on deploying your application.
• Visualize your release process.
• Make steps of your release process reliable and repeatable

XP vs Lean vs FDD

Over the years I have noticed people getting confused about XP vs Lean vs FDD so thought to put together this article view

Extreme Programming (XP) What's that !

XP, originally described by Kent Beck, has emerged as one of the most popular and controversial agile methods. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.

The original XP recipe is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices:

1. Planning Game
2. Small Releases
3. Customer Acceptance Tests
4. Simple Design
5. Pair Programming
6. Test-Driven Development
7. Refactoring
8. Continuous Integration
9. Collective Code Ownership
10. Coding Standards
11. Metaphor
12. Sustainable Pace

 

In XP, the “Customer” works very closely with the development team to define and prioritize granular units of functionality referred to as "User Stories". The development team estimates, plans, and delivers the highest priority user stories in the form of working, tested software on an iteration by iteration basis.                                                                                                                           

In order to maximize productivity, the practices provide a supportive, lightweight framework to guide a team and ensure high-quality software.

The main aim of XP is to reduce the cost of change. In traditional system development methods the requirements for the system are determined at the beginning of the development project and often fixed from that point on. This means that the cost of changing the requirements at a later stage will be high. XP sets out to reduce the cost of change by introducing basic values, principles and practices. However, for applying XP, a system development project should be more flexible with respect to changes. Because of its nature as Experts suggests as maximum of 10 programmers can ideally work in an XP project this framework unlikely to work in slightly bigger projects. 

Guys: XP is one of those famous agile driven method which works those teams where the team is self organize. So use it or not is up to the team to decide but using it will definitely has all goods involve. 

Hope the Introduction helps you am open to your views so feel free to comment as much as you can!

How about Managing a People Oriented Process ?

People orientation manifests itself in a number of different ways in agile processes. It leads to different effects, not all of them are consistent.

One of the key elements is that of accepting the process rather than the imposition of a process. Often software processes are imposed by management figures. As such they are often resisted, particularly when the management figures have had a significant amount of time away from active development. Accepting a process requires commitment, and as such needs the active involvement of all the team.

This ends up with the interesting result that only the developers themselves can choose to follow an adaptive process. This is particularly true for XP, which requires a lot of discipline to execute. Crystal considers itself as a less disciplined approach that's appropriate for a wider audience.

Another point is that the developers must be able to make all technical decisions. XP gets to the heart of this where in its planning process it states that only developers may make estimates on how much time it will take to do some work.

Such technical leadership is a big shift for many people in management positions. Such an approach requires a sharing of responsibility where developers and management have an equal place in the leadership of the project. Notice that I say equal. Management still plays a role, but recognizes the expertise of developers.

An important reason for this is the rate of change of technology in our industry. After a few years technical knowledge becomes obsolete. This half life of technical skills is without parallel in any other industry. Even technical people have to recognize that entering management means their technical skills will wither rapidly. Ex-developers need to recognize that their technical skills will rapidly disappear and they need to trust and rely on current developers.