Friday, April 4, 2014

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 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  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 @
  2. Sample 20 Questions @
  3. Free 30 Questions / exam simulator @

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.

Thursday, February 27, 2014

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.

  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.

Thursday, January 23, 2014

Installing & configuring Git on Fedora

First thing first - Let's install git. There are two major ways we can install git 

  • install from an existing package
  • install it from source or
installing from an existing package: Easy, Open up Terminal and type the following command:

$ sudo yum install git-core ~/.ssh
$ sudo password for username: type your password here 

installing from source: It’s generally useful to install Git from source, because you’ll get the most recent version. Each version of Git tends to include useful UI enhancements, so getting the latest version is often the best route if you feel comfortable compiling software from source. It is also the case that many Linux distributions contain very old packages; so unless you’re on a very up-to-date distro or are using backports, installing from source may be the best bet.

To install Git, you need to have the following libraries that Git depends on: curl, zlib, openssl, expat, and libiconv. For example, if you’re on a system that has yum (such as Fedora), you can use the following command:
$ sudo yum install curl-devel expat-devel gettext-devel\

Once the installation is done you can do

$ git --version

this will show the version of Git you are using.

Now that you have Git on your system, you'll need to configure Git to use it. Following step you need to follow for configuring but before we start I am assuming that you already have a github account, if not please create an account in github.

Step 1: Check for SSH keys

First, we need to check for existing ssh keys on your computer. In the Terminal, type:
cd ~/.ssh
# Lists the files in your .ssh directory

Check the directory listing to see if you have a file named either or If you don't have either of those files go to step 2. Otherwise, you already have an existing keypair, and you can skip to step 3.

Step 2: Generate a new SSH key

To generate a new SSH key, enter the code below. We want the default settings so when asked to enter a file in which to save the key, just press enter.
ssh-keygen -t rsa -C ""
# Creates a new ssh key, using the provided email as a label
# Generating public/private rsa key pair.
# Enter file in which to save the key (/home/you/.ssh/id_rsa):
ssh-add id_rsa
Now you need to enter a passphrase.
Enter passphrase (empty for no passphrase): [Type a passphrase]
# Enter same passphrase again: [Type passphrase again]
Which should give you something like this:
# Your identification has been saved in /home/you/.ssh/id_rsa.
# Your public key has been saved in /home/you/.ssh/
# The key fingerprint is:
# 01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db

Step 3: Add your SSH key to GitHub

Run the following code to copy the key to your clipboard.
sudo yum install xclip
# Downloads and installs xclip. 

xclip -sel clip < ~/.ssh/
# Copies the contents of the file to your clipboard
Alternatively, using your favorite text editor, you can open the ~/.ssh/ file and copy the contents of the file manually.
Now you to open the Browser and perform the following steps 
  1. Go to Github Account Settings
  2. Click SSH Keys in the left sidebar
  3. Click Add SSH Key
  4. Paste your Key into the Key field
  5. Click Add Key
  6. Now Github will prompt you for your github password to Confirm the action.

Step 4: Test everything out

To make sure everything is working you'll now SSH to GitHub. When you do this, you will be asked to authenticate this action using your password, which for this purpose is the passphrase you created earlier. Don't change the part. That's supposed to be there.
ssh -T
# Attempts to ssh to github
You may see this warning:
# The authenticity of host ' (' can't be established.
# RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
# Are you sure you want to continue connecting (yes/no)?
Don't worry, this is supposed to happen. Verify that the fingerprint matches the one here and type "yes".
# Hi username! You've successfully authenticated, but GitHub does not
# provide shell access.
If that username is correct, you've successfully set up your SSH key. Don't worry about the shell access thing, you don't want that anyway.
Well we are done! Hope this helps.

Friday, January 10, 2014

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

Monday, August 5, 2013

Get Real

An introduction to Smaller, faster, better way to build software. Well then, it's time to skip all the unnecessary stuff and focus on build the real thing. Some of it I have listed here which you can stop doing and build the real thing.

Let's get rid of >>>>

Timelines that take months or even years

Pie-in-the-sky functional specs

Scalability debates

Interminable staff meetings

Useless paperwork E.g. charts, graphs, boxes, arrows, schematics etc.

The “need” to hire dozens of employees

Meaningless version numbers

Pristine roadmaps that predict the perfect future

Endless preference options

Outsourced support

Unrealistic user testing

Top-down hierarchy

Let me know if above these helped you anyway ever to build the real thing.

***Then how to build the real thing!

Do you remember Agile Manifesto(s) ? Read more

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer Collaboration over contract negotiation
  • Responding to change over following a plan

Interestingly if you follow what I have listed above and get rid of the ones I mentioned, you will see how quickly you be adapting to these new changes and start building the real thing early before your competitor builds it :-) Sounds easy ! Well then it's time to Be Agile and follow Scrum !

With the advent of Object Oriented Software development methods it became easy to break large software projects into very small components and therefore able to take advantage of the building incrementally during Sprint, build the MOST important feature first. Since each sprint outcome is working element of the product this ensures rapid feedback and adjustment to the changing needs to the marketplaces.

Let me provide you an quick introduction to Scrum Vocabulary (Note: this is probably the smallest introduction I have ever written :-) So feel free to read other relevant ones you will find in my blog)

What is it ? 
Scrum provides a language for this common sense way of organizing, performing, and managing work.

Product Backlog:
All work to be performed in the foreseeable future, both well-defined and requiring further definition.


A period of 30 days or less where a set of work will be performed to create a deliverable.

Sprint Backlog:
That work that is well enough defined that it can be worked on with relatively little change over a period of 30 days or less and will result in a tangible, incremental deliverable.

A daily meeting at which progress and impediments to progress is reviewed.

Do you agree with me with the benefits of Getting Real ?

Getting Real delivers better results because it forces you to deal with the actual problems you’re trying to solve instead of your ideas about those problems. It forces you to deal with reality.

Getting Real foregoes functional specs and other transitory documentation in favor of building real screens. A functional spec is make-believe, an illusion of agreement, while an actual web page is reality. That’s what your customers (whether internal or external) are going to see and use. That’s what matters. Getting Real gets you there faster. That means you’re making software decisions based on the real thing instead of abstract notions.

Finally, Getting Real is an approach ideally suited to web or mobile-based software. The old school model of shipping software in a box and then waiting a year or two to deliver an update is fading away. Unlike installed software, web apps can constantly evolve on a day-to-day basis. So far it I have taken advantage of this approach of Getting Real. Are you thinking ? I think it's worth a try!