PMI-ACP Exam Prep (Part 1 of7): Agile Principles andMindset24 min readSam Vaghefi

Listen to this post:

This is part 1 of 7 posts on PMI-ACP Exam Prep. In this post, my focus will beon the agile mindset, its fundamental values and principles, the agilemethodologies, and agile leadership. In essence, this first post sets the stagefor understanding agile for the PMI-ACP exam.

Why Use Agile?

Well, different types of projects require different methods. in our everydaylives, we continually customize our approach depending on the situation,often in small and subtle ways. For example, we choose what information tocommunicate and how to present it based on our audience. We don’tapproach every issue we face in the exact same way, like a robot; instead, weadjust our methods to be most effective for each situation. This same conceptapplies to projects – and projects, especially knowledge work projects in afast-moving, complex environment, call for an agile approach.

Characteristics of Industrial Work vs Knowledge Work

Note that the development of agile methods took place over many years andwas done by different people. As a result, agile has multiple methods that use

different terminology. For example, Scrum calls its timeboxed developmentefforts “sprints”, while XP calls them “iterations”.

The Agile Mindset

“Being agile” isn’t simply a matter of using a set of tools or practices, orfollowing a specific methodology. Agility really involves adopting a newmindset – way of thinking – that is based on agile values and principles. Themost important statement of these values and principles is the agilemanifesto. But first, let’s look at some of the general characteristics of theagile mindset.

1. Increase return on investment by making continuous flow of valueour focus.

2. Deliver reliable results by engaging customers in frequentinteractions and shared ownership.

3. Expect uncertainty and manage for it through iterations,anticipations, and adaptation.

4. Unleash creativity and innovation by recognizing that individualsare the ultimate source of value, and creating an environment where theycan make a difference.

5. Boost performance through group accountability for results andshared responsibility for team effectiveness.

6. Improve effectiveness and reliability through situationally specificstrategies, processes, and practices.

Another way to summarize the core principles of agile:

Welcome changeWorking in small value-added increments

Using build and feedback loopsLearning through discovery

Value driven developmentFailing fast with learning

Continuous deliveryContinuous improvement

Applying agile values and principles to how we use agile methods changes notonly our approach, but also the effectiveness of the practices. This is thedifference between “being agile” and “doing agile”.

Being Agile vs. Doing Agile

Breaking down the above diagram:

The correct way to adopt agile is shown by the green arrow on the left.You need to start by internalizing the agile mindset (welcoming change,small increments, etc.), and then use those principles to guide yourselection and implementation of agile practices. Start with a goodunderstanding of why we you are using the practices, which in turn helpyou understand how to use them most effectively.The red arrow on the right represents a team that decides to adopt agile

practices (such as daily stand-up meetings and short iterations), withouttaking the time to understand what these practices are designed toaccomplish. In this case, they have jumped directly into the how of agilewithout understanding the why. This is a common problem in agileadoption.

The Agile Triangle

Another key difference between the agile mindset and traditional projectmanagement is the agile or “inverted” triangle of constraints.

Inverted Triangle Model – Agile vs Traditional Project Management

This reversal of the traditional triangle means that agile teams allow thescope to vary within the fixed parameters of cost and time. In other words, weaim to deliver the most value we can by X date with X budget. Although we’llbegin with a high-level vision of the end product, we can’t define up front howmuch we’ll be able to get done – that will emerge as we get close to the targetdate.

The Agile Manifesto

The agile manifesto is an important statement of 4 agile values and 12

principles.

The 4 Agile Values

1. Individuals and interactions over process and toolsThe message here is that while processes and tools will likely benecessary for our projects, we should try to focus on the team’sattention on the individuals and interactions involved. This isbecause projects are undertaken by people, not tools, and problemsget resolved by people, not processes.

2. Working software over comprehensive documentationThis value speaks to the need to deliver. It can be rephrased morebroadly as “working systems over comprehensive documentation”.Basically, this value reminds us to focus on the purpose or businessrather than the paperwork.

3. Customer collaboration over contract negotiationThis value reminds us to be flexible and accommodating, ratherthan fixed and uncooperative. Basically, you can build the productexactly as originally specified, but if the customer’s preferences orpriorities change, it would be better to be flexible and work towardthe new goal, as opposed to the goal that was originally stated.

4. Responding to change over following a planIn knowledge work projects, we know that our initial plans areinadequate since they are based on insufficient information aboutwhat it will take to complete the project. So instead of investingeffort in trying to bring the project back in line with our originalplan, you want to spend more effort and energy responding to thechanges that will inevitably arise. This doesn’t mean that weabandon the plan. It just means that we need to acknowledge thefact that at the beginning of the project we knew the least and astime has passed we gained more information and need to updateour plan.

While there is value in the items on the right, we value the items on theleft more. This isn’t as black and white as just saying “do A instead of B”.Instead it acknowledges that both A and B will be components of ourprojects, but that we should apply more focus, emphasis, and intention toA than to B.

The agile approach to documention is “just enough, just intime – and sometimes, just because.”

Agile documentation should be “barely sufficient” – just enough tocover our needs. This keeps most of our efforts focused on theemerging systems.Agile documentation is done “just in time” – also known as the “lasyresponsible moment” – so we don’t have to spend extra time to keepit updated as or requirments and design changes.Finally, just because reminds us that sometimes whendocumentation is required or requested, it’s easier and preferable tojust produce it than to face the consequenses of not doing so.Documentation by itself, or at the expense of working software, isnot useful.

The 12 Principles

In addition to the 4 agile values, the manifesto also includes 12 principles.They are as follows:

1. Our highest priority is to satisfy the customer through early andcontinuous delivery of valuable software.

3 points to underline: satisfy the customer, early and continuousdelivery, and delivery of valuable and working software (notcompleted work, documentation, etc.)

2. Welcome changing requirements, even late in development. Agileprocesses harness change for the customer’s competitive advantage.

Instead of creating a high-overhead mechanism for suppressing orprocessing changes, agile methods use a lightweight, high-visibilityapproach. Basically, by continuously updating and prioritizingchanges into the backlog of work to be done. Agile’s well-understood, high-visibility methods for handling changes keep theproject adaptive and flexible as long as possible. By welcoming thechanges that will inevitably happen and setting up an efficient wayto deal with them, we can spend more time developing the endproduct.

3. Deliver working software frequently, from a couple of weeks to a coupleof months, with a preference to the shorter timeline.

It’s better to get feedback early and often, to avoid going too fardown the wrong track.

4. Business people and developers must work together daily throughout theproject.

Written documents, email, and even telephone calls are lessefficient ways of transferring information than face-to-faceinteractions. Somewhat similar to the 6th principle.

5. Build projects around motivated individuals. Give them the environmentand support they need, and trust them to get the job done.

Having the best people is significantly more important for a projectthan having the best processes and tools.

6. The most efficient and effective method of conveying information to andwithin a development team is a face-to-face conversation.

7. Working software is the primary measure of progress.“How much of the solution is done and accepted?” is preferred over“Is the design complete?” – basically what gets measured getsdone. The measurement is “do you have sign-off by the customer”for a feature rather than the development is marked as completed.

8. Agile processes promote sustainable development. the sponsors,developers, and users should be able to maintain a constant paceindefinitely.

Instead of long and intense development periods, agile methodsrecognize the value of a sustainable pace that allows team membersto maintain a work-life balance.

9. Continuous attention to technical excellence and good design enhancesagility.

An agile team needs to balance its efforts to deliver high-endfeatures with continuous attention to the design of the solution.

10. Simplicity – the art of maximizing the amount of work not done – isessential.

Agile methods seek the “simplest thing that could possibly work”and recommend that this solution is built first. This approach notonly mitigates risk but also helps boost sponsor confidence.

11. The best architecture, requirements, and design emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective,then tunes and adjusts its behavior accordingly.

Don’t leave gathering lessons learned to the end of the project,rather do this constantly throughout the development andimplements actionable recommendations. Leaving this to the end ofthe project is too little too late.

Agile Methodologies

There are dozens of agile methodologies. The most common approaches areScrum, Extrem Programming (XP), Lean Product Development, Kanban,Feature Driven Development (FDD), Dynamic Systems Development Method(DSDM), and Crystal family of methods. Note that the PMI-ACP exam willmostly have questions around Scrum, XP, Lean, and Kanban.

Scrum

Scrum is a popular agile method that is lightweight and easy to understand.The theory behind Scrum is based on the 3 pillars of transparency,

inspection, and adaptation. These principles guide all aspects of theScrum methodology:

Transparency: This involves giving visibility to those responsible for theoutcome. For example: create a common definition of what “done”means, to ensure that all stakeholders are in agreement.Inspection: This involves doing timely checks of how well the project isprogressing toward its goals, looking for problematic deviations ordifferences from the goals.Adaptation: This involves adjusting the team’s process to minimizefurther issues if an inspection shows a problem or an undesirable trend.

In addition to the 3 pillars, Scrum also recognizes 5 fundamental values:focus, courage, openness, commitment, and respect.

Scrum Process

Sprints

A sprint is a timeboxed (time-limited) iteration of 1 to 4 weeks in which theteam builds a potentially releasable product. (a sprint and an iteration isbasically the same). Most sprints are 1 or 2 weeks long. During a sprint, nochanges are made that could affect the sprint goal. The scope might beclarified or renegotiated as new information becomes available but if forexample, a change has to be made to the members of the development team,that wouldn’t be done during a sprint.

A sprint can be canceled before the timebox is over if the sprint goal becomesobsolete due to a change in business direction or technology conditions. Keepin mind that only a product owner can cancel the sprint. Should this happen,any incomplete product backlog items are re-estimated and returned to theproduct backlog.

The sequence of activities within each sprint consists of a sprint planningmeeting, a development period that includes daily scrums, a sprintreview meeting, and a sprint retrospective meeting.

Scrum Team Roles

Development Team

The members of the development team are self-organizing – that is, they areempowered to manage their own work. Scrum teams are also cross-functional.

Product Owner

The product owner is responsible for maximizing the value of the product bymanaging the product backlog, or the list of work to be done. This includesensuring that the work items in the backlog are up to date and accuratelyprioritized based on business value. The product owner is also responsible formaking sure that the business and the team have a shared understanding ofthe project vision, the project goals, and the details of the work to be done, so

the team can plan and build the work items.

Scrum Master

The Scrum Master is responsible for ensuring that the Scrum methodology isunderstood and used effectively. This person is a servant leader to thedevelopment team, removing any impediments to their progress, facilitatingtheir events (meetings), and coaching the team members. The Scrum Masteralso helps the product owner with managing the backlog and communicatingthe project vision, project goals, and details of the backlog items to thedevelopment team. And lastly, the Scrum Master is an advocate for theadoption of Scrum throughout the organization on a wider scale.

Scrum Activities (Events and Ceremonies)

The Scrum methodology defines 5 activities/meetings: product backlogrefinement, sprint planning meeting, daily scrums, sprint review,and sprint retrospectives. The last 4 are the team’s planned opportunitiesfor inspection and adaptation (2 of the 3 pillars) in each sprint. (note that theterm “Scrum meetings” is the same as “Scrum events” and the same as“Scrum ceremonies”.)

Backlog Refinement

In this meeting “grooming the backlog” is done. Basically, everyone involvedin the project gathers to discuss and update the items in the backlog.

Sprint Planning Meeting

In this meeting, everyone gathers to determine what will be delivered in theupcoming sprint and how that work will be achieved. The product ownerpresents the updated backlog items and the group discusses them to ensurethey have a shared understanding. The development team forecasts what canbe delivered in the sprint, based on their estimates, projected capacity, and

past performance. With this forecast in mind, they define the sprint goal. Thedevelopment team then determines how that functionality will be built andhow they will organize themselves to deliver the sprint goal.

Note: Sprint planning is the responsibility of the development team, productowner, and the Scrum Master.

Daily Scrum

This is a 15-minute daily meeting that is held at the same time and placewhile the team is working toward the sprint goal. Each member of the teambriefly answers the following 3 questions:

1. What have I done since the last daily scrum?2. What do I plan to do today?3. Are there any impediments to my progress?

These questions help the team assess their progress towards the sprint goal.In answering questions, they address each other and any further questions orproblem-solving takes place offline.

Daily Scrum Meeting

As scrum projects get larger, multiple scrum teams might need to coordinatetheir work. To do this, they use an approach called “scrum of scrums”.

Basically, representatives of each team report their progress torepresentatives of other teams. Just like a daily scrum with an exception ofadding a 4th question: “Are you about to put something in another team’sway?”

Scrum of Scrums Meeting

Sprint Review

This meeting is held at the end of the sprint and includes the developmentteam, the product owner, and the Scrum Master (and could also include otherstakeholders if need be). The team should demo the work done during thesprint and the product owner should inspect and verify to decide if it can bemarked as “done” or explain what’s missing. The team and the product ownerdiscuss the increment and the remaining items in the product backlog.Together they make changes needed to the backlog and decide what to workon next.

Sprint Retrospective

After the sprint review but before the next sprint planning meeting, thedevelopment team holds their final “inspect and adapt” activity for the sprint.This meeting is called the sprint retrospective. This meeting primarily for thedevelopment team and they discuss the lessons learned and look foropportunities for improvement. The reflection that takes place during theretrospective might cover anything that occurred during the sprint, includingthe areas of people, process, and product. They look at what went well, whatcan be improved, and decide on changes to implement in the next sprint.

Scrum Artifacts

These are 3 tangible items that are used by the team during the sprint:Product Increment, Product Backlog, and Sprint Backlog.

Product Increment

During each sprint, the development team builds and increment of thesolution (the end product of the project). They demo the latest increment toget feedback from the product owner and find out if the item is “done”.

Product Backlog

The product backlog is a prioritized list of all the work that needs to be doneto build the product. It serves as the single source for all the productrequirements. This is a living and dynamic list and needs to be continuallyupdated. The items are prioritized by the product owner and the highest-priority items are at the top of the list. The lowest-priority items may not getdeveloped as they may get deferred in favor of the higher priority items.Teams provide estimates for each item on the list and the product ownerprioritizes them.

Sprint Backlog

The sprint backlog is the subset of items in the product backlog that have

been selected as the goal of a specific sprint. The sprint backlog serves as ahighly visible view of the work being undertaken and may only be updated bythe development team.

Note: The definition of “done” is created and accepted by the developmentteam, product owner, and the Scrum Master.

A Typical Sprint, Play-By-Play

https://www.scrum.org/resources/blog/typical-sprint-play-play

Extreme Programming (XP)

XP is an agile method that focuses on software development. While Scrumfocuses at the project management level, prioritizing work and gettingfeedback, XP focuses on software development best practices.

XP Core Values

The core values of XP are:

Simplicity: This value focuses on reducing complexity, extra featuresand waste. XP focus on finding the simplest thing that could possiblywork and build a solution first.Communication: This value focuses on making sure all team membersknow what is expected of them and what other people are working on.For example, the daily standup is key.Feedback: The team should get impressions of stability early. Failingfast and getting feedback early on can be useful as the team would havetime to fix issues.Courage: It takes courage to allow our work to be entirely visible toothers. Developers need to have the confidence to make importantchanges.Respect: Team members need to recognize that people work differently

and respect those differences.

Iterations in XP are typically 2 weeks long. Developers work in pairs duringthe iteration and all software developed is subjected to rigorous and frequenttesting. Then upon, approval by the on-site customer, the software isdelivered as small releases.

“Spikes” are periods of work undertaken to reduce threats and issues, and“architectural spikes” are iterations used to prove a technical approach. Thespikes are blended into the release planning process.

XP Team Roles

XP defines roles a bit different from Scrum. XP roles are customer,programmer, coach, and tester.

Coach: Acts as a mentor to the team, guiding process and helping teammembers stay on track. Think of the coach as a facilitator. This roleshares many responsibilities with Scrum Master.Customer: The role is similar to a product owner in Scrum. Basically, abusiness person that provides requirements, priorities, and businessdirection.Programmer: AKA the developers who write code and implementcustomer/user stories.Tester: Testers do quality assurance and help customer define and writeacceptance tests for the user stories. This can be done by programmers ifthey have the right skill set.

XP Core Practices

13 simple yet powerful practices:

13 XP Core Practices

1. Whole Team: The whole team practices the idea that all the contributorsto an XP project sit together in the same location, as members of a singleteam.

2. Planning Games: XP has 2 primary planning activities: release planningand iteration planning.

A release is a push of new functionality all the way to the productionuser. Typically a project would have 1 or more releases with no morethan 2 releases in a year.Iterations are short development cycles within a release that Scrumcalls sprints. Iteration planning is done at the start of everyiteration.

3. Small Releases: frequent and small releases are encouraged in XP. Bothat iteration and release levels to demonstrate progress and visibility to

the customer.4. Customer Tests5. Collective Code Ownership: This means multiple people will work on all

the code, which results in increased visibility and broader knowledge ofthe code base. This leads to a higher level of quality. Also, this willmitigate the impact of a developer leaving in the mid of the project as theknowledge is shared.

6. Code Standards: Important to follow a coding standard so that all thecode looks as if it was written by a single, knowledgeable programmer.

7. Sustainable Pace: Productivity is achieved by a team operating at asustainable pace.

8. Metaphor: Using metaphors to explain the shared vision and technicaldetails.

9. Continuous Integration: Integration involves bringing the code togetherand making sure it all compiles and works together. Integration testshould run automatically every time a programmer checks in code to therepository.

10. Test-Driven Development11. Refactoring: Refactoring is the process of improving the design f existing

code without altering its external behavior or adding new functionality.It focuses on removing duplicate code, lowering coupling, and increasingcohesion.

12. Simple Design: Design should be simple but adequate.13. Pair Programming: Production code is written by 2 developers working

in a pair. While one person codes, the other reviews. The 2 would changeroles frequently.

Lean Product Development

Strictly speaking, lean is not an agile methodology; however, the leanapproach is closely aligned with agile. Lean product development deals withdeveloping new and better products. The high-level principles of lean productdevelopment include:

Using visual management toolsIdentifying customer-defined valueBuilding in learning and continuous improvements

Lean Core Concepts

Lean has 7 core concepts:

Eliminate waste: To maximize value we must minimize waste.7 wastes of lean: partially done work, extra process, extra features,task switching, waiting, motion, defects.

Empower the team: Don’t micromanage and instead empower teammembers to make the required decisions to be productive and successful.Deliver fast: Maximize ROI by quickly producing valuable deliverablesand iterating through designs.Optimize the whole: We aim to see the system as more than the sum ofits parts.Build quality in: Don’t “test in” quality at the end. But continually assurequality throughout the development process using techniques likerefactoring, continuous integration, and unit testing.Defer decisions: We balance early planning with making decisions andcommitments as late as possible. e.g. reprioritizing backlog right up untilit’s time to do the work.Amplify learning: It’s all about getting feedback early and as often aspossible and building on what we learn.

Kanban

Kanban means “signboard” in Japanese. The board shows the work items ineach stage of the production process as defined by the team.

5 Principles of Kanban

1. Visualize the workflow: Have some way to visualize the workflow. This is

important for organizing, optimizing, and tracking.2. Limit WIP (Work In Progress): Restricting the amount of work in

progress improves productivity, increase the visibility of issues andbottlenecks, and facilitates continuous improvement.

3. Manage flow: By tracking the flow of work through a system, issues canbe identified and changes can be measured for effectiveness.

4. Make process policies explicit: It is important to clearly explain howthings work so the team can have open discussions about improvementsin an objective, rather than subjective way.

5. Improve collaboratively: Through scientific measurement andexperimentation, the team should collectively own and improve theprocesses it uses.

Kanban Pull System

Rather than planning work in a timebox like in Scrum, in Kanban we use a“pull system”. Each time a Kanban team completes an item of work, ittriggers a “pull” to bring in the next item they will work on. Whenever there isan empty slot on the board, that signals the team to pull work from theprevious stage. Here is a great video that talks about the pull system and howit differs from Scrum’s timebox.

Scrum vs Kanban - What's the Difference? + FREE CHEAT SHEET

WIP Limits in Kanban

This term refers to capping the number of items that can be in a given state ofprogress, as defined by the columns on the team’s Kanban board. Once thelimit at the top of the column is reached no new item may be moved into thatcolumn until another item is moved out. With continuous pull model,iterations may not be required and therefore activities like creating estimatescan be considered waste and reduced or eliminated.

Kanban WIP Limit

Leadership Practices and Principles

Agile is more humanistic than mechanistic. To be effective leaders, we need todiscover why team members want to do things, understand what motivatesthem and the align their project tasks and goals accordingly.

Management vs Leadership

Management is getting people to do what needs to be done, while leadership

is getting people to want to do what needs to be done.

Management Focus Leadership Focus

Tasks/things PeopleControl Empowerment

Efficiency Effectiveness

Doing things right Doing the right thingsSpeed Direction

Practices Principles

Command Communication

Servant Leadership

There are 4 primary duties of a leader performs in the role of serving theteam:

1. Shield the team from interruptions: protect the team members formdiversions, interruptions, and requests for work that are not part of theproject.

2. Remove impediments to progress: These could include documentationor compliance activities.

3. Communicate (and re-communicate) the project vision: A commonvision helps keep people all pulling in the same direction.

4. Carry food and water: Providing the essential resources a team needs tokeep them nourished and productive.

12 Principles for Leading Agile Projects

1. Learn the team members’ needs2. Learn the project’s requirements3. Act for the simultaneous welfare of the team and the project4. Create an environment of functional accountability5. Have a vision of the completed project

6. Use project vision to drive your own behavior7. Serve as the central figure in successful project team development8. Recognize team conflict as a positive step9. Mange with an eye for ethics

10. Remember that ethics is not an afterthought, but an integral part of ourthinking

11. Take time to reflect on the project.12. Develop the trick of thinking backwards

Hope you enjoyed this post and found it helpful! Here is a link to part 2 of 7.