Listen to this post:
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 agile for the PMI-ACP exam.
Why Use Agile?
Well, different types of projects require different methods. in our everyday lives, we continually customize our approach depending on the situation, often in small and subtle ways. For example, we choose what information to communicate and how to present it based on our audience. We don’t approach every issue we face in the exact same way, like a robot; instead, we adjust our methods to be most effective for each situation. This same concept applies to projects – and projects, especially knowledge work projects in a fast-moving, complex environment, call for an agile approach.
Note that the development of agile methods took place over many years and was done by different people. As a result, agile has multiple methods that use different terminology. For example, Scrum calls its timeboxed development efforts “sprints”, while XP calls them “iterations”.
The Agile Mindset
“Being agile” isn’t simply a matter of using a set of tools or practices, or following a specific methodology. Agility really involves adopting a new mindset – way of thinking – that is based on agile values and principles. The most important statement of these values and principles is the agile manifesto. But first, let’s look at some of the general characteristics of the agile mindset.
- Increase return on investment by making continuous flow of value our focus.
- Deliver reliable results by engaging customers in frequent interactions and shared ownership.
- Expect uncertainty and manage for it through iterations, anticipations, and adaptation.
- Unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
- Boost performance through group accountability for results and shared responsibility for team effectiveness.
- Improve effectiveness and reliability through situationally specific strategies, processes, and practices.
Another way to summarize the core principles of agile:
- Welcome change
- Working in small value-added increments
- Using build and feedback loops
- Learning through discovery
- Value driven development
- Failing fast with learning
- Continuous delivery
- Continuous improvement
Applying agile values and principles to how we use agile methods changes not only our approach, but also the effectiveness of the practices. This is the difference between “being agile” and “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 your selection and implementation of agile practices. Start with a good understanding of why we you are using the practices, which in turn help you 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), without taking the time to understand what these practices are designed to accomplish. In this case, they have jumped directly into the how of agile without understanding the why. This is a common problem in agile adoption.
The Agile Triangle
Another key difference between the agile mindset and traditional project management is the agile or “inverted” triangle of constraints.
This reversal of the traditional triangle means that agile teams allow the scope to vary within the fixed parameters of cost and time. In other words, we aim to deliver the most value we can by X date with X budget. Although we’ll begin with a high-level vision of the end product, we can’t define up front how much we’ll be able to get done – that will emerge as we get close to the target date.
The Agile Manifesto
The agile manifesto is an important statement of 4 agile values and 12 principles.
The 4 Agile Values
- Individuals and interactions over process and tools
- The message here is that while processes and tools will likely be necessary for our projects, we should try to focus on the team’s attention on the individuals and interactions involved. This is because projects are undertaken by people, not tools, and problems get resolved by people, not processes.
- Working software over comprehensive documentation
- This value speaks to the need to deliver. It can be rephrased more broadly as “working systems over comprehensive documentation”. Basically, this value reminds us to focus on the purpose or business rather than the paperwork.
- Customer collaboration over contract negotiation
- This value reminds us to be flexible and accommodating, rather than fixed and uncooperative. Basically, you can build the product exactly as originally specified, but if the customer’s preferences or priorities change, it would be better to be flexible and work toward the new goal, as opposed to the goal that was originally stated.
- Responding to change over following a plan
- In knowledge work projects, we know that our initial plans are inadequate since they are based on insufficient information about what it will take to complete the project. So instead of investing effort in trying to bring the project back in line with our original plan, you want to spend more effort and energy responding to the changes that will inevitably arise. This doesn’t mean that we abandon the plan. It just means that we need to acknowledge the fact that at the beginning of the project we knew the least and as time has passed we gained more information and need to update our plan.
While there is value in the items on the right, we value the items on the left 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 our projects, but that we should apply more focus, emphasis, and intention to A than to B.
The agile approach to documention is “just enough, just in time – and sometimes, just because.”
- Agile documentation should be “barely sufficient” – just enough to cover our needs. This keeps most of our efforts focused on the emerging systems.
- Agile documentation is done “just in time” – also known as the “lasy responsible moment” – so we don’t have to spend extra time to keep it updated as or requirments and design changes.
- Finally, just because reminds us that sometimes when documentation is required or requested, it’s easier and preferable to just produce it than to face the consequenses of not doing so.
- Documentation by itself, or at the expense of working software, is not useful.
The 12 Principles
In addition to the 4 agile values, the manifesto also includes 12 principles. They are as follows:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- 3 points to underline: satisfy the customer, early and continuous delivery, and delivery of valuable and working software (not completed work, documentation, etc.)
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Instead of creating a high-overhead mechanism for suppressing or processing changes, agile methods use a lightweight, high-visibility approach. Basically, by continuously updating and prioritizing changes into the backlog of work to be done. Agile’s well-understood, high-visibility methods for handling changes keep the project adaptive and flexible as long as possible. By welcoming the changes that will inevitably happen and setting up an efficient way to deal with them, we can spend more time developing the end product.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timeline.
- It’s better to get feedback early and often, to avoid going too far down the wrong track.
- Business people and developers must work together daily throughout the project.
- Written documents, email, and even telephone calls are less efficient ways of transferring information than face-to-face interactions. Somewhat similar to the 6th principle.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- Having the best people is significantly more important for a project than having the best processes and tools.
- The most efficient and effective method of conveying information to and within 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 gets done. 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 pace indefinitely.
- Instead of long and intense development periods, agile methods recognize the value of a sustainable pace that allows team members to maintain a work-life balance.
- Continuous attention to technical excellence and good design enhances agility.
- An agile team needs to balance its efforts to deliver high-end features with continuous attention to the design of the solution.
- Simplicity – the art of maximizing the amount of work not done – is essential.
- Agile methods seek the “simplest thing that could possibly work” and recommend that this solution is built first. This approach not only mitigates risk but also helps boost sponsor confidence.
- The best architecture, requirements, and design emerge from self-organizing 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 and implements actionable recommendations. Leaving this to the end of the project is too little too late.
There are dozens of agile methodologies. The most common approaches are Scrum, 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 will mostly have questions around Scrum, XP, Lean, and Kanban.
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 the Scrum methodology:
- Transparency: This involves giving visibility to those responsible for the outcome. 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 is progressing toward its goals, looking for problematic deviations or differences from the goals.
- Adaptation: This involves adjusting the team’s process to minimize further 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.
A sprint is a timeboxed (time-limited) iteration of 1 to 4 weeks in which the team builds a potentially releasable product. (a sprint and an iteration is basically the same). Most sprints are 1 or 2 weeks long. During a sprint, no changes are made that could affect the sprint goal. The scope might be clarified or renegotiated as new information becomes available but if for example, 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 becomes obsolete due to a change in business direction or technology conditions. Keep in mind that only a product owner can cancel the sprint. Should this happen, any incomplete product backlog items are re-estimated and returned to the product backlog.
The sequence of activities within each sprint consists of a sprint planning meeting, a development period that includes daily scrums, a sprint review meeting, and a sprint retrospective meeting.
Scrum Team Roles
The members of the development team are self-organizing – that is, they are empowered to manage their own work. Scrum teams are also cross-functional.
The product owner is responsible for maximizing the value of the product by managing the product backlog, or the list of work to be done. This includes ensuring that the work items in the backlog are up to date and accurately prioritized based on business value. The product owner is also responsible for making sure that the business and the team have a shared understanding of the project vision, the project goals, and the details of the work to be done, so the team can plan and build the work items.
The Scrum Master is responsible for ensuring that the Scrum methodology is understood and used effectively. This person is a servant leader to the development team, removing any impediments to their progress, facilitating their events (meetings), and coaching the team members. The Scrum Master also helps the product owner with managing the backlog and communicating the project vision, project goals, and details of the backlog items to the development team. And lastly, the Scrum Master is an advocate for the adoption of Scrum throughout the organization on a wider scale.
Scrum Activities (Events and Ceremonies)
The Scrum methodology defines 5 activities/meetings: product backlog refinement, sprint planning meeting, daily scrums, sprint review, and sprint retrospectives. The last 4 are the team’s planned opportunities for inspection and adaptation (2 of the 3 pillars) in each sprint. (note that the term “Scrum meetings” is the same as “Scrum events” and the same as “Scrum ceremonies”.)
In this meeting “grooming the backlog” is done. Basically, everyone involved in 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 the upcoming sprint and how that work will be achieved. The product owner presents the updated backlog items and the group discusses them to ensure they have a shared understanding. The development team forecasts what can be delivered in the sprint, based on their estimates, projected capacity, and past performance. With this forecast in mind, they define the sprint goal. The development team then determines how that functionality will be built and how they will organize themselves to deliver the sprint goal.
Note: Sprint planning is the responsibility of the development team, product owner, and the Scrum Master.
This is a 15-minute daily meeting that is held at the same time and place while the team is working toward the sprint goal. Each member of the team briefly answers the following 3 questions:
- What have I done since the last daily scrum?
- What do I plan to do today?
- 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 or problem-solving takes place offline.
As scrum projects get larger, multiple scrum teams might need to coordinate their work. To do this, they use an approach called “scrum of scrums”. Basically, representatives of each team report their progress to representatives of other teams. Just like a daily scrum with an exception of adding a 4th question: “Are you about to put something in another team’s way?”
This meeting is held at the end of the sprint and includes the development team, the product owner, and the Scrum Master (and could also include other stakeholders if need be). The team should demo the work done during the sprint and the product owner should inspect and verify to decide if it can be marked as “done” or explain what’s missing. The team and the product owner discuss the increment and the remaining items in the product backlog. Together they make changes needed to the backlog and decide what to work on next.
After the sprint review but before the next sprint planning meeting, the development team holds their final “inspect and adapt” activity for the sprint. This meeting is called the sprint retrospective. This meeting primarily for the development team and they discuss the lessons learned and look for opportunities for improvement. The reflection that takes place during the retrospective might cover anything that occurred during the sprint, including the areas of people, process, and product. They look at what went well, what can be improved, and decide on changes to implement in the next sprint.
These are 3 tangible items that are used by the team during the sprint: Product Increment, Product Backlog, and Sprint Backlog.
During each sprint, the development team builds and increment of the solution (the end product of the project). They demo the latest increment to get feedback from the product owner and find out if the item is “done”.
The product backlog is a prioritized list of all the work that needs to be done to build the product. It serves as the single source for all the product requirements. This is a living and dynamic list and needs to be continually updated. 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 get developed as they may get deferred in favor of the higher priority items. Teams provide estimates for each item on the list and the product owner prioritizes them.
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 a highly visible view of the work being undertaken and may only be updated by the development team.
Note: The definition of “done” is created and accepted by the development team, product owner, and the Scrum Master.
A Typical Sprint, Play-By-Play
Extreme Programming (XP)
XP is an agile method that focuses on software development. While Scrum focuses at the project management level, prioritizing work and getting feedback, XP focuses on software development best practices.
XP Core Values
The core values of XP are:
- Simplicity: This value focuses on reducing complexity, extra features and waste. XP focus on finding the simplest thing that could possibly work and build a solution first.
- Communication: This value focuses on making sure all team members know 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. Failing fast and getting feedback early on can be useful as the team would have time to fix issues.
- Courage: It takes courage to allow our work to be entirely visible to others. Developers need to have the confidence to make important changes.
- 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 during the iteration and all software developed is subjected to rigorous and frequent testing. Then upon, approval by the on-site customer, the software is delivered 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. The spikes 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 team members stay on track. Think of the coach as a facilitator. This role shares many responsibilities with Scrum Master.
- Customer: The role is similar to a product owner in Scrum. Basically, a business person that provides requirements, priorities, and business direction.
- Programmer: AKA the developers who write code and implement customer/user stories.
- Tester: Testers do quality assurance and help customer define and write acceptance tests for the user stories. This can be done by programmers if they have the right skill set.
XP Core Practices
13 simple yet powerful practices:
- Whole Team: The whole team practices the idea that all the contributors to an XP project sit together in the same location, as members of a single team.
- Planning Games: XP has 2 primary planning activities: release planning and iteration planning.
- A release is a push of new functionality all the way to the production user. Typically a project would have 1 or more releases with no more than 2 releases in a year.
- Iterations are short development cycles within a release that Scrum calls sprints. Iteration planning is done at the start of every iteration.
- Small Releases: frequent and small releases are encouraged in XP. Both at iteration and release levels to demonstrate progress and visibility to the customer.
- Customer Tests
- Collective Code Ownership: This means multiple people will work on all the code, which results in increased visibility and broader knowledge of the code base. This leads to a higher level of quality. Also, this will mitigate the impact of a developer leaving in the mid of the project as the knowledge is shared.
- Code Standards: Important to follow a coding standard so that all the code looks as if it was written by a single, knowledgeable programmer.
- Sustainable Pace: Productivity is achieved by a team operating at a sustainable pace.
- Metaphor: Using metaphors to explain the shared vision and technical details.
- Continuous Integration: Integration involves bringing the code together and making sure it all compiles and works together. Integration test should run automatically every time a programmer checks in code to the repository.
- Test-Driven Development
- 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 increasing cohesion.
- Simple Design: Design should be simple but adequate.
- Pair Programming: Production code is written by 2 developers working in a pair. While one person codes, the other reviews. The 2 would change roles frequently.
Lean Product Development
Strictly speaking, lean is not an agile methodology; however, the lean approach is closely aligned with agile. Lean product development deals with developing new and better products. The high-level principles of lean product development include:
- Using visual management tools
- Identifying customer-defined value
- Building 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 team members to make the required decisions to be productive and successful.
- Deliver fast: Maximize ROI by quickly producing valuable deliverables and iterating through designs.
- Optimize the whole: We aim to see the system as more than the sum of its parts.
- Build quality in: Don’t “test in” quality at the end. But continually assure quality throughout the development process using techniques like refactoring, continuous integration, and unit testing.
- Defer decisions: We balance early planning with making decisions and commitments as late as possible. e.g. reprioritizing backlog right up until it’s time to do the work.
- Amplify learning: It’s all about getting feedback early and as often as possible and building on what we learn.
Kanban means “signboard” in Japanese. The board shows the work items in each stage of the production process as defined by the team.
5 Principles of Kanban
- Visualize the workflow: Have some way to visualize the workflow. This is important for organizing, optimizing, and tracking.
- Limit WIP (Work In Progress): Restricting the amount of work in progress improves productivity, increase the visibility of issues and bottlenecks, and facilitates continuous improvement.
- Manage flow: By tracking the flow of work through a system, issues can be identified and changes can be measured for effectiveness.
- Make process policies explicit: It is important to clearly explain how things work so the team can have open discussions about improvements in an objective, rather than subjective way.
- Improve collaboratively: Through scientific measurement and experimentation, the team should collectively own and improve the processes 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, it triggers a “pull” to bring in the next item they will work on. Whenever there is an empty slot on the board, that signals the team to pull work from the previous stage. Here is a great video that talks about the pull system and how it differs from Scrum’s timebox.
WIP Limits in Kanban
This term refers to capping the number of items that can be in a given state of progress, as defined by the columns on the team’s Kanban board. Once the limit at the top of the column is reached no new item may be moved into that column until another item is moved out. With continuous pull model, iterations may not be required and therefore activities like creating estimates can be considered waste and reduced or eliminated.
Leadership Practices and Principles
Agile is more humanistic than mechanistic. To be effective leaders, we need to discover why team members want to do things, understand what motivates them 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|
|Doing things right||Doing the right things|
There are 4 primary duties of a leader performs in the role of serving the team:
- Shield the team from interruptions: protect the team members form diversions, interruptions, and requests for work that are not part of the project.
- Remove impediments to progress: These could include documentation or compliance activities.
- Communicate (and re-communicate) the project vision: A common vision helps keep people all pulling in the same direction.
- Carry food and water: Providing the essential resources a team needs to keep them nourished and productive.
12 Principles for Leading Agile Projects
- Learn the team members’ needs
- Learn the project’s requirements
- Act for the simultaneous welfare of the team and the project
- Create an environment of functional accountability
- Have a vision of the completed project
- Use project vision to drive your own behavior
- Serve as the central figure in successful project team development
- Recognize team conflict as a positive step
- Mange with an eye for ethics
- Remember that ethics is not an afterthought, but an integral part of our thinking
- Take time to reflect on the project.
- Develop the trick of thinking backwards
Hope you enjoyed this post and found it helpful! Here is a link to part 2 of 7.