Transcription
PMI-ACP Exam Prep (Part 1 of7): Agile Principles andMindset24 min readSam VaghefiListen 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 WorkNote 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 incrementsUsing build and feedback loopsLearning through discovery
Value driven developmentFailing fast with learningContinuous deliveryContinuous improvementApplying 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 AgileBreaking 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 TriangleAnother key difference between the agile mindset and traditional projectmanagement is the agile or “inverted” triangle of constraints.Inverted Triangle Model – Agile vs Traditional Project ManagementThis 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 ManifestoThe agile manifesto is an important statement of 4 agile values and 12
principles.The 4 Agile Values1. 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 PrinciplesIn 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.
3.4.5.6.7.8.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 wellunderstood, 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.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.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.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.The most efficient and effective method of conveying information to andwithin a development team is a face-to-face conversation.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.Agile processes promote sustainable development. the sponsors,developers, and users should be able to maintain a constant paceindefinitely.
9.10.11.12.Instead of long and intense development periods, agile methodsrecognize the value of a sustainable pace that allows team membersto maintain a work-life balance.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.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.The best architecture, requirements, and design emerge from selforganizing teams.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 MethodologiesThere 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.ScrumScrum 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 ProcessSprints
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 RolesDevelopment TeamThe members of the development team are self-organizing – that is, they areempowered to manage their own work. Scrum teams are also crossfunctional.Product OwnerThe 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 MasterThe 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 RefinementIn this meeting “grooming the backlog” is done. Basically, everyone involvedin the project gathers to discuss and update the items in the backlog.Sprint Planning MeetingIn 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 ScrumThis 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 MeetingAs 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 MeetingSprint ReviewThis 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 ArtifactsThese are 3 tangible items that are used by the team during the sprint:Product Increment, Product Backlog, and Sprint Backlog.Product IncrementDuring 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 BacklogThe 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 highestpriority 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 BacklogThe 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, ypical-sprint-play-playExtreme 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 ValuesThe 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 RolesXP 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 Practices13 simple yet powerful practices:
13 XP Core Practices1. 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
4.5.6.7.8.9.10.11.12.13.the customer.Customer TestsCollective Code Ownership: This means multiple people will work on allthe 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.Code Standards: Important to follow a coding standard so that all thecode looks as if it was written by a single, knowledgeable programmer.Sustainable Pace: Productivity is achieved by a team operating at asustainable pace.Metaphor: Using metaphors to explain the shared vision and technicaldetails.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.Test-Driven DevelopmentRefactoring: Refactoring is the process of improving the design f existingcode without altering its external behavior or adding new functionality.It focuses on removing duplicate code, lowering coupling, and increasingcohesion.Simple Design: Design should be simple but adequate.Pair Programming: Production code is written by 2 developers workingin a pair. While one person codes, the other reviews. The 2 would changeroles frequently.Lean Product DevelopmentStrictly 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 improvementsLean Core ConceptsLean 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.KanbanKanban means “signboard” in Japanese. The board shows the work items ineach stage of the production process as defined by the team.5 Principles of Kanban1. Visualize the workflow: Have some way to visualize the workflow. This is
2.3.4.5.important for organizing, optimizing, and tracking.Limit WIP (Work In Progress): Restricting the amount of work inprogress improves productivity, increase the visibility of issues andbottlenecks, and facilitates continuous improvement.Manage flow: By tracking the flow of work through a system, issues canbe identified and changes can be measured for effectiveness.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.Improve collaboratively: Through scientific measurement andexperimentation, the team should collectively own and improve theprocesses it uses.Kanban Pull SystemRather 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 KanbanThis 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 LimitLeadership Practices and PrinciplesAgile 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 LeadershipManagement 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 FocusLeadership yEffectivenessDoing things rightDoing the right unicationServant LeadershipThere 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 Projects1.2.3.4.5.Learn the team members’ needsLearn the project’s requirementsAct for the simultaneous welfare of the team and the projectCreate an environment of functional accountabilityHave a vision of the completed project
6.7.8.9.10.Use project vision to drive your own behaviorServe as the central figure in successful project team developmentRecognize team conflict as a positive stepMange with an eye for ethicsRemember that ethics is not an afterthought, but an integral part of ourthinking11. Take time to reflect on the project.12. Develop the trick of thinking backwardsHope you enjoyed this post and found it helpful! Here is a link to part 2 of 7.
This is part 1 of 7 posts on PMI-ACP Exam Prep. In this post, my focus will be on the agile mindset, its fundamental values and principles, the agile methodologies, and agile leadership. In essence, this first post sets the stage for understanding agil
