This book helps in providing all the information and guidance required to prepare for the PMI-ACP® examination. The book augments a certification aspirant’s professional experience and skills with the knowledge of tools, techniques and practices that are required for the examination.
This resource is 100% quality checked!
Ace the PMI-ACP exam Study pack helps you prepare for the PMI-ACP Exam.
As observed from numerous surveys worldwide, the IT industry over the last decade has radically evolved in the way software is developed and provisioned to meet the changing requirements of the environment.
Agile methodologies are continuously gaining popularity over the traditional project management practices.
Organizations are naturally trying to accelerate their business by being flexible and responsive to change.
So whether it’s a company building a software product for internal or external markets, or are trying to sell IT services, we are seeing a trend of adoption of Agile practices. Such is the power of the iterative and incremental style of progress, Agile practices are also finding relevance in many other non-IT domains.
Hence knowledge of this subject has become much in demand these days.
Certifications boost the career of the exam takers, as it, in most cases, indicates knowledge, interest, proficiency and pursuit of excellence in the particular subject. One of the premier institutes of Project Management – PMI® has outlined the requirements of the Agile Certified Practitioner (PMI-ACP®) certification exam that was formally launched in 2011.
This book helps in providing all the information and guidance required to prepare for the PMI-ACP® examination. The book augments a certification aspirant’s professional experience and skills with the knowledge of tools, techniques and practices that are required for the examination. Beyond certification seekers, the content in this book are for all Agile practitioners on whom organizations rely to deliver projects effectively and efficiently for their customers.
The audience for this book primarily includes IT professionals who wish to prepare for and pass Agile Certified Professional (ACP®) exam from the Project Management Institute (PMI®). The contents can also
be referenced by those who would be pursuing the Certified Scrum Master Certification (CSM®) from Scrum
Alliance® and also a variety of other Agile certification courses in the market.
Apart from certification seekers, the book will also cover good ground for people using or learning to use various flavors of the Agile methodologies and its tools and techniques. As an author, I would expect this
book to become a popular asset in corporate and academic libraries.
If you are a PMI-ACP® aspirant, this book will augment your professional experience and skills with the knowledge of Agile tools and techniques that are required for the examination. The content covered in this book is necessary and sufficient to supplement your knowledge on Agile and aligned to the PMI-ACP® course outline.
This book contains the best of learnings from all the 12 reference books enlisted by PMI®, as well as documented and working knowledge from sound practitioners with whom I have been associated during my professional experience. This is invaluable for professionals like you who are extremely busy in their day to day work lives, but still want to devote enough attention to master the key concepts, practice hard and clear the PMI-ACP® exam.
Incidentally, even if you are not aspiring for the PMI-ACP® right away, this book will still serve as a ready reckoner for the key concepts in Agile and will, in a nutshell, expose you to the variants of Agile methodologies – namely Scrum, XP, Lean and Kanban. So, whether you are a beginner or a seasoned practitioner, this book will appeal to you, enrich your learning journey and add to your toolbox as an Agile professional.
Working Software over Comprehensive Documentation
This value reminds us that until the software is delivered to production, it adds no value to the
customer. The only measure of a usability of a product is feedback based on working code, as
Alistair Cockburn puts it, “Running code is ruthlessly honest.”
To understand this value, let us consider the example of a screen development for a web page.
In traditional methodologies the analysts will spend a lot of time specifying and designing the ‘look
and feel’ of the screens by trying to anticipate the needs of the end user. Writing such a detailed
document is tedious and is not cherished by most. But the underlying assumption here is that the
document, if sufficiently detailed, will provide all the necessary inputs that a developer will ever
require to build the web page. This has a few anticipated problems though, as mentioned below:
• It is almost impossible for a person to initially specify exactly how a screen should
look like or be perceived by an end user.
• In reality, end users can change their minds frequently, so keeping up-to-date
documentation is a challenging and costly affair.
• Considering the fact that significant effort is invested in creating a supposedly ‘rocksolid’ and elaborate document, this can give a false sense of progress. Projects are
initiated to deliver valuable software and until that is available, we have built up a
huge backlog of detailed specification documents (‘work-in-progress’ items) that
does not contribute tangible value.
• If more some reason the project is terminated in the middle of the project, what will
be left behind is a pile of documents that yields no value to the end user. Even if there
was a few working screens, they could have added some benefit.
In contrast, frequent delivery of working software gives more comfort at measuring progress
for the users and developers alike and provides an opportunity for inviting and incorporating realtime feedback, which is extremely valuable. Not a fraction of this value can be realized by showing
a document or even securing a sign-off on a document.
However, before we leave this point, we have to appreciate that to a fair extent, documentation
is required. For example people might move (e.g., get reallocated to other projects or leave a
company) and it is important that the knowledge of the system stick around so that the product can
be maintained, supported in production, or enhanced based on evolving needs. Or for that matter,
there are reports and documents that go out to regulators and used to fulfill legal and compliance
requirements. Agile teams, like others, should still invest effort behind producing these essential
documents and factor them in the list of deliverables on their backlog. Project documents that are
created solely to transfer information between various team members working on the same project
is not considered efficient and hence discouraged. In summary, this value recommends ‘barely
sufficient’ documentation for Agile teams.
18.104.22.168 Customer Collaboration over Contract Negotiation
This value focuses on building a relationship based on trust that spans across organization
boundaries between the customer and the vendor or service provider of the software. In traditional
projects, contracts are rigid, in the sense that both sides are coerced (or legally bound) to obey
the elements of scope, time and cost (also called The triple constraints). In the realistic event
of a change in any of these three parameters, a sophisticated change control process, takes
over. Approvals of such change controls take a long time and at times, could make the progress
frustratingly slow. A typical dialogue between a customer and a project manager, in the event of a
change is shown in Figure 1-2.
22.214.171.124 Responding to Change over Following a Plan
The final value embodies the fact that Agile acknowledges and embraces change and not treat that
as an exception.
Traditional projects invest a substantial effort in developing a detailed project plan, consisting
of detailed schedules, allocation and critical paths. The project team is supposed to follow this plan
from start to finish. And in the event of a change, re-planning and re-baselining needs to be done to
make sure that the plan is up to date and reflects the changes.
In the case of Agile projects, upfront detailed planning is considered counterproductive and
inefficient because of the uncertainties involved. A fair amount of planning happens just in time or at
the last responsible moment. This is also called Rolling Wave Planning. Development is timeboxed
into finite iterations (say one month) and it follows the principle of rolling wave planning. This
means that the work items for the upcoming iteration is well detailed out and the others are left
coarse-grained. Once the iteration is over, only then is the next iteration planned out. And this gives
an opportunity to look around and see if there are any changes in scope or prioritization that need to
be attended to. Figure 1-3 shows the effect of change between traditional and Agile projects.
Figure 1-2. H
The Twelve Agile Principles
The authors of the manifesto also came up with a set of twelve principles that supplement the
Agile Manifesto and explain agility. Like the core values in the manifesto, these principles are very
important to be understood and is helpful from the PMI-ACP®
exam perspective. There could be
tricky questions where one or more choices could appear to be correct, but by applying the core
values and these principles, you should choose the best answer or eliminate the wrong ones.
It is also important to realize that different Agile methodologies (we talk about them in
Chapter 2) are based on these values and principles. While the practices and characteristics could
be unique, the generic principles still hold up well.
The original text of principles (in bold-faced font below) are from the source:
Here is what it states and its explanation: