Description
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.
Audience of this book
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.
Sample of the Ace the PMI-ACP exam Study pack: Compact PDF Version
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.
1.3.2.3 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.
l.
1.3.2.4 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:
https://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/
Here is what it states and its explanation:
- Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
The first principle is admittedly the most important one and hence worthy on spending some
time on it. Customers seek software to add value to their business – whether it is to secure market
share, increase their profit margins, stay in business, or even respond to regulatory laws. Such is
the importance, that Agile development prioritizes delivering to business over anything else like
processes, documentation and so on.
Figure 1-3. The effect of change on traditional projects versus Agile projects
Chapter 1 ■ Domain I: Agile Principles and Mindset
9
The word “early” is important. Agile aims at delivery to business as early as possible, even
if it is in the form of chunks of prioritized features that add value. The intent is to ratify the
requirements, receive feedback, incorporate them and also retrospect on internal processes.
The next significant word in this principle is “continuous.” Agile delivery maximizes flow;
ruthlessly removes waste; and, by following a continuous operating rhythm, ensures that valuable
software is with business and adequate provisions are there for instant feedback and, course
correction (let’s say reprioritization). So how does Agile achieve this? In contrast to traditional
software development life cycle, Agile does a little bit of analysis, development, testing, build,
integration and deployment at frequent timeboxed intervals called iterations. These iterations could
be anywhere between 2 to 4 weeks, although projects might want to choose a number that best
suits themselves. This means that customers get valuable software delivery continuously, that is,
at regular predictive intervals. Once in the hands of the customer, the software is likely to generate
revenue and if the circumstances change (e.g., due to economic, competitive, or regulatory reasons),
an immediate feedback and course – correction can be requested without going through lengthy
processes of change management as prevalent in traditional waterfall methodologies.
The final word to focus on this principle is “valuable.” Agile development does not require a
detailed specification of features and programs to be built. As we will see later on the book, it works
on a backlog that is maintained by a person whose job is to ensure that the maximum ROI (return on
investment) is realized for every iteration. This backlog is prioritized continuously and the ones that
are highest in value get picked by the team to deliver, bearing their capacity in mind. This means that
at any point in time, the features or components that are deemed most valuable are being worked
upon. There is also a latent upside in this. In the event that the project’s funding dries up, or the
sponsor considers the project not viable to proceed, it will still be left with a working version, albeit
with limited functions. If this were to happen in waterfall projects during the development phase, all
that we would be left with is a project plan (that is now obsolete), requirement specifications, highlevel and low-level design documents and half-cooked (read untested) code, with unrealized value. - Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage.
The second principle share one thing in common with the first one – the customer focus. And
it also ties back to the core value in the Agile Manifesto that favors “Responding to change over
following a plan.” As previously discussed, the onerous change management processes in waterfall
project management practices prohibit agility. It could, particularly, prove to be fatal where the
organization’s inability to make quick and important changes to their software leads to a loss to its
competitors at the marketplace.
Agile methodologies, on the other hand, accept and expect changes continuously, some
of which could be late breaking. Some of these changes could cause significant deviation from
the past and might need the architecture and design to evolve rather drastically. Agile project
management does not require comprehensive documentation of change controls, lengthy approval
processes and re-baselining of project plans. By virtue of the principle of continuous and frequent
delivery principle and the use of timeboxed iterations, it takes the changes in the stride. Note that
it doesn’t mean that Agile doesn’t analyze the functional and nonfunctional impact of the changes
adequately. It does it, but just that the process followed is lightweight and adaptive. - Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
The third principle seriously gets into numbers. Agile advocates short bursts of development
in contrast to thorough and detailed implementation that can span over months or years. The
realization is that change is inevitable during the course of large projects and without early and
continuous feedback we could be on the wrong track very soon, leading to sunk costs.
In this context, Agile follows a strategy called “Fail-fast.” The word “fail” obviously brings
about a negative connotation. But what it means is doing something (say a proof-of concept or
Reviews
There are no reviews yet.