THE FOLLOWING PMI-ACP® EXAM TOPICS ARE COVERED IN THIS CHAPTER:
Domain I: Agile Principles and Mindset
In this chapter, you will continue going through the first domain of the exam content outline about the mindset of Agile. Understanding different best practices and applying them (regardless of your choice of method) is a large part of absorbing Agile.
In Chapter 1, you covered the beginnings of Agile and the reasons it was necessary to find better ways to manage technology projects. In Chapter 2: Scrum and eXtreme Programming (XP), you covered Scrum and XP. In this chapter, you will finish moving through the final frameworks and mindsets that complete all nine tasks found on the exam content outline under the first domain.
Dynamic Systems Development Method (DSDM) is considered to be a framework, much like Scrum, rather than an Agile methodology. DSDM is based on best practices and lessons learned with a major focus of being on time and on budget, keeping a competitive advantage, and adhering to philosophies about getting to market first. DSDM is flexible enough to be implemented as a hybrid with Scrum, and it is compared with the Crystal family of methodologies of Agile development that you will cover later in this chapter.
The DSDM Consortium is a not-for-profit organization that was formed in the United Kingdom in 1994. One interesting fact is that it is based on the Pareto principle, or the 80/20 rule, and has roots in Waterfall and rapid application development (RAD). Further flexibility allows it to be utilized with ITIL and PRINCE2, which will be discussed shortly. Even though this framework was created earlier than the Agile Manifesto, you’ll see that it is tightly integrated with it based on its major principles.
Another comparison of DSDM with other frameworks like Scrum and XP reveals that the features are flexible, but the schedule is not.
There are eight principles of DSDM, and you’ll find that they are very much like Scrum and XP. The eight principles also reflect aspects of the Agile Manifesto. These eight principles of DSDM are represented graphically in Figure 3.1.
Focus on the Business Need: You’re probably starting to see a pattern between frameworks and methodologies like Scrum, XP, and now DSDM, because many are about focusing on the business needs and understanding the priorities necessary to meet requirements. For many projects, a valid business case must come before any official kickoff or planning of the project/iteration can begin.
Part of maintaining that business need is to ensure that there is continuous business sponsorship and commitment. Another aspect of this is guaranteeing delivery of a minimal usable subset or aspect of the whole that can be used and tested. Basically, like XP and Scrum, DSDM is a piece/part that is usable but not the finished product. To do that, the team must determine the most notable features and make sure that they are in the ultimate solution no matter what.
Deliver on Time: Timeboxing the work is a theme in Agile projects as is focusing on business priorities, always working to hit your deadlines, and building confidence through predictable delivery of usable increments. Therefore, all iterations in all methodologies are timeboxed in some way, shape, or form.
Collaborate: Another universal theme is stakeholder engagement, collaborative environments, and involving the right stakeholders at the right time throughout the project life cycle. The collaboration efforts are proactive across the board, and business representatives are not protected from the potential of being included in those collaborations. All teams are empowered to make decisions in order to best represent customer needs and to maintain a “one team” culture. This cultural philosophy creates buy-in. If everyone is on the same team, from business representatives to developers, then everyone owns the result.
Never Compromise Quality: No matter what types of project management methodologies you subscribe to, quality management is always important. Many notice a distinct overlap between Scope and Quality, and I’m often asked about the difference Scope is building the right thing, and Quality is building it right.
Never compromising on quality focuses on agreements on the level of quality that is necessary before any development begins. What are the tolerance levels that are acceptable if quality results fluctuate? How can you build quality into the plan so that you build quality into the increment? The focus here is to ensure that quality is not a variable that can come and go but rather that everyone agrees never to compromise on quality.
Quality is a pay me now or pay me later situation. If you pay now to build quality into the design, it costs less than fixing defects after the fact, not to mention an organization’s reputation can be damaged exponentially, which in most cases isn’t a quantifiable loss but one that is felt the most. Quality can be managed effectively by testing early, often, and appropriately with frequent reviews.
Build Incrementally from Firm Foundations: Much as you wouldn’t want your home built on a foundation that wasn’t solid, the DSDM framework is about building incrementally from firm foundations. What this really means is making sure that appropriate analysis is done and there’s “enough design up front,” or EDUF, to create as strong a foundation as possible. We do know that priorities change, and with that foundations change as well. Thus, you will need to reassess priorities formally and determine whether the project is still viable after the delivery of each increment.
Develop Iteratively: What makes Agile methodologies so different from Waterfall is the understanding that iterative developments and change are a fact of life in the Agile world. Not to say that Waterfall projects don’t experience progressive elaboration, changes, and even the dreaded scope creep! However, because Waterfall is more focused on a front-loaded plan with formal change control, making substantial change decisions on a regular basis is less likely to occur.
Waterfall methodologies plan first rather than going headfirst into a project knowing that most details will emerge later rather than sooner. Agile projects, on the other hand, focus on finding the right solution and proceed with the knowledge that the solution will not occur without embracing adaptability and change.
Part of iterative development is making room for business feedback and building it into each iteration while at the same time encouraging creativity, experimentation, learning, and even mistakes. Part of making mistakes is learning from them to help create the right solution.
Anyone who has never made a mistake has never tried anything new.
Albert Einstein
Communicate Continuously and Clearly: Communication is very important in all project methodologies and frameworks. Most project managers (Agile or not) spend about 90 percent of their time communicating. But what about the rest of the team?
One of the coolest things about Agile methodologies is that there’s total encouragement of informal face-to-face communication at all levels on a regular basis. There is also encouragement for many different forms of timeboxed communication, including daily stand-up meetings, facilitated workshops, modeling, and prototyping, all designed to help manage the expectations of stakeholders at all levels throughout the project.
Part of the importance of communicating continuously and clearly is that everyone understands the evolving solution, and it is demonstrated early and often enough to maintain that understanding. Notice that I didn’t say heavy documentation and massive amounts of status reports, because in this case, documentation is expected to be lean and timely. Face-to-face communication is the preferred method. The overarching philosophy of continuous and clear communication is making sure that we always aim to be honest and transparent in all communication.
Demonstrate Control: You can demonstrate control effectively by using DSDM by utilizing low-tech, high-touch information radiators that are visible to all. All Agile frameworks promote visual information radiators.
Demonstrating control is also a philosophy of proactive management and continuous reassessment and evaluation of the project viability based on the current objectives of the business. Finally, control is demonstrated by understanding what level and format is considered appropriate for formal tracking and reporting.
In the late 1940s, Toyota started studying US supermarkets after noticing that they were not storing a lot in warehouses or in the back rooms of their stores. They also noticed that customers generally retrieved what they needed at the time—no more, no less—because they knew they could always come back the next day and get what they needed again.
If you have ever been in a supermarket while they’re stocking the shelves, you might have noticed that they stock only what they expect to sell within a certain time frame and replace what they have already sold. Granted that much of that has to do with spoilage and expiration dates, but these observations by Toyota sparked a new way of perceiving inventory. Now, with the use of computer systems and inventory software, it is easier for a system to be lean and just in time (JIT). Toyota took the observation to its factory floors and created the Kanban system as a way to utilize it as an inventory control system.
Because Kanban means signboard or billboard in Japanese, the manufacturing system created the use of a card displaying the sequence of the process or events and instructions so everyone knew how to manage the process and what the instructions were to manage the just in time (JIT) model. It was sent all the way through the production line to communicate better through visual management and stay with the concept of using only what is needed.
The Kanban method emphasizes a focus on the customer and the work that services their needs rather than on the activities of individuals. Moreover, the principles of Kanban are quite simple, starting with change management and service delivery principles. The change management principle is all about understanding current processes and respecting roles, responsibilities, and job titles. There is a constant focus on pursuing improvements and evolving through change and encouraging every level to practice leadership no matter what their role is in the organization. Like the philosophy of cross-functional teams in many other Agile principles, Kanban mirrors adaptive leadership.
On the service delivery side, one key aspect is really understanding and focusing on what the customer needs and expects. One way to do this is to consistently evolve your policies organizationally to improve outcomes for both the customer and the business. The way this is done is quite simply to manage the work and let your team self-organize around it. Thus you have self-organized, self-managed, and cross-functional teams.
There are two aspects of Kanban that are a great introduction of the low-tech, high-touch tools that are used in Agile methodologies—the Kanban card and the Kanban board. The Kanban cards signal the need to move materials within the production facility or to get the materials from an external seller or supplier into the production facility. The primary technique, however, which is used most of all in many Agile methodologies, is the Kanban board.
The Kanban board is not only a visual representation of work that needs to be done, is being done, and is done, but it is one of the most popular ways to radiate information to multiple stakeholders at one time. The Kanban board is considered to be low-tech and high-touch, meaning no technology is used and everyone has a hands-on way of moving work through the process flow Figure 3.2 shows an example of a Kanban board.
What is so cool about the visual process that Kanban uses is that it represents a pull system. Work is pulled into the iteration when other work is completed. You know that a backlog is dynamic and ever changing. You also know that value changes based on the needs and wants of the customer. By using a pull system, the product owner can determine what backlog items should be done next. The team will select the work that they can accomplish in the sprint or iteration. Once the work is accomplished, it moves to acceptance and other work is pulled into progress. Once the work is considered done, it can be deployed. Many people who use this process use large white boards and Post-it notes to display backlog items, selected work, work in progress (WIP), and what’s been done and deployed.
The six principles of Kanban are as follows:
The six principles of Kanban review the cycle of understanding the workflow intellectually and allowing for consistent feedback and improvement as work progresses.
Visualize the Workflow: See the work and the policies that determine how the workflow is currently and will be executed. This does several things: It improves the overall process iteratively, helps to embrace necessary changes, and allows for learning from ineffective changes. This is why the Kanban boards are so useful, because they keep the workflow front and center, and they show a map of where you begin and where you end. Once workflow is understood then change for the better and optimized workflow can occur.
The Kanban board is always within eyesight, leaving very little question as to the work that needs to be done or what work has been completed or deployed. This low-tech, high-touch way of radiating information is more effective than status reports because it is so visual. The brain processes visual images 60,000 times faster than it processes text, and therefore Kanban/Scrum boards are highly valuable in a fast-paced Agile environment.
Manage Flow: Even though change is necessary to improve process or products, sometimes too much change can wreak havoc on process flow. A key aspect of managing the flow effectively is to only create changes in the process once the change is understood. This can be done by assessing all impacts on other areas of the project that could be a result of the change.
If you have ever attempted to make a change in one area of a project and then witnessed the domino effect after the change was implemented, you know why this is so important. For example, let’s say that you change the scope of work without consideration for time and money and now you are over budget and behind schedule. This is all due to not assessing the impact of the change and how it was implemented. Managing the flow and only implementing changes that are really necessary keep the things moving efficiently and remove waste from the process.
Implement Feedback Loops: Better understanding through feedback improves the process and the result. In a continuing trend of effective communication and colocated teams, it’s easy to see that everything under the Agile umbrella follows a similar theme. Visual workflow and self-directed and self-managed teams that are colocated are all considered important aspects of effective feedback loops.
Many of the Agile and quality management methodologies came from collaborations between Japan and the United States as organizations moved from the industrial age and entered the technical age. The knowledge transfer of Kanban still applies whether you are mass producing bicycles or creating cutting-edge software. Kanban is a deep concept with very simple ideals. Improve your process, use only what you need at the time until you pull more work in, organize around the work, and utilize visual workflow.
Many philosophies integrated into Agile methodologies come from the Japanese and more specifically from Toyota. It’s not unusual in both Waterfall projects and in Agile projects to see the term Lean. Many of you have probably heard of Lean Six Sigma, which is a quality approach that incorporates philosophies of Lean. Lean Six Sigma projects utilize the Lean philosophy of elimination of waste in the system, and Six Sigma focuses on reducing defects that can affect the overall quality of the result.
When you think of the word lean, you probably think thin, skinny, or without extra weight. That’s an excellent way to think about Lean product/software development as well. The history of Lean software development began as a translation of Lean manufacturing and IT principles and practices seen in the Toyota production system but were later translated and adapted to outline best practices in software projects.
The seven principles of Lean are as follows:
Lean complements Agile in four very distinctive ways, and it works to optimize flow efficiency across the entire value stream. The four ways are easily understood and necessary to keep the process flowing in the right direction.
Implementing Lean Software Development: From Concept to Cash (Poppendieck, 2006)
The goal in manufacturing is to keep things Lean, which is impossible if you’re producing the opposite of value. In any Lean project, waste is the opposite of value. The term waste started in the late 1940s at Toyota when they were looking to reduce manufacturing costs to keep the budget, you guessed it, lean. Because Toyota was mass-producing vehicles, the concepts of Lean manufacturing came well before Lean in Agile software development. While there is overlap in some concepts, there was a need to adapt it specifically to software development.
First, it’s important to understand where and how the original Lean framework began before jumping directly to software.
The original seven wastes of Lean manufacturing were identified in A Study of the Toyota Production System by Shigeo Shingo (Productivity Press, 1989):
To remove waste from the manufacturing process, it was important to identify what the causes were. After the wastes were identified effectively the organization could determine how to remove them from their value stream.
Extra processing: Additional steps in the process that aren’t really needed Extra processing is like the continuous integration practice in XP’s software development. If things get complicated or you are spending too much time on the process steps, it is necessary to implement process improvement and simplify the value stream.
Motion: Moving around within the process What is the shortest distance between two points? A straight line, of course. Too much motion or extra steps produce defects and wastes time.
The goal of Lean software development is to apply a framework around reducing the day-to-day items that create noise in the process. The goal is to determine relatively quickly what that noise is and continuously answer the questions of where are the time wasters, the extra steps, or the general problems in our process and our product. Figure 3.3 illustrates the seven wastes of Lean software development.
Since Lean software best practices were derived from Lean manufacturing, the framework involves a similar thought process. Remove waste from the system of software development and focus on continuous improvement.
Partially Done Work: Remember when your parents told you to eat all of your vegetables? Of course, you would take a small bite and hide the rest under your mashed potatoes or feed it to the family dog. Afterward, you would triumphantly announce that you were done and hope that nobody noticed. When your parents did notice, they reminded you that you only partially ate your vegetables and were in fact not done. Even worse, you were wasting food.
The same thing applies to partially done work. It does not meet the definition of done, it can’t be released or used in a demo, and the code is nowhere near deployable. What may have caused this is that you didn’t realize how complex the technology needed to be prior to the plan and have now wasted time and resources. Believe me when I say that it’s a similar feeling to getting busted by your parents when hiding your vegetables. Except in this case, it is your customer instead of your parents.
Extra Features: Goldplating in any project is considered a big no-no! Goldplating is, in its simplest form, giving the customer extra features or added functionality that they did not request. This shows that you did not understand the vision or understand the target end user and/or have incorrectly prioritized the value and produced to an incorrect spec. In a lot of organizations, this will result in mediocre quality and scope creep, which will in turn be a waste of time or money.
Relearning: You might be thinking, “What is wrong with learning?” Learning provides value, and it’s important to learn as much as possible. You are correct, but relearning something you already knew at some point is wasted time.
Think about a time when someone on your team asked you to do something again that you hadn’t done in years. You have a vague recollection of how to do it, but you still need to Google it on the sly. Yep, that’s relearning. Lack of documentation, poor coding practices, and consistent task switching between team members all create chaos as each one attempts to relearn something they moved on from in the past.
This can be managed effectively by using cross-functional teams, which is a major theme in all Agile projects. This means that one team contains all of the knowledge it needs to be effective across all functionalities.
In this scenario, you are a customer and the delay is keeping you from doing what you want to do. This form of waste is usually due to not having enough people to do the work, or overestimators and overachievers who select too much work than can be accomplished in an iteration. Oftentimes, delays can’t be helped because external dependencies get in the way, or there is a significant lack of estimation experience or simply generic estimating, which can result in major delays as well. Delays are the opposite of Lean.
The myth of multitasking is the perception that you are being super productive when in fact it is quite difficult. Task switching really muddies the waters and makes it impossible to have a shared vision when you’re expected to have visions about multiple projects. Task switching creates waste, and it does so because there are too many projects going on, which leads to poor estimation, poor analysis, and a lack of a shared vision. Having a cross-functional team will prevent many of the handoffs that create waste in the system due to switching tasks on a regular basis.
Several methods of continuous improvement can be found in Kanban, Lean, or other Agile environments. The main goal is to figure out (using the entire organization dynamic to do so) what is causing the waste or lack of improvement in the process and the results. Many times, as you saw in Lean, waste can happen in the process, the inventory, the team, and the product. To avoid that, you can look to philosophies that guide us in the right direction.
There are three very common philosophies that resonate with Agile frameworks.
The Theory of Constraints (TOC): The TOC study of bottlenecks in the process flow happens by identifying constraints and focusing on how to alleviate them by restructuring around them. Otherwise, organizations will be affected by a significant lack of meeting or achieving their goals. One bad apple can spoil the bunch, and because of that it is important to focus your efforts on ongoing process improvement to exploit the constraint(s) and remove them.
Much of what you just read is easier said than done, as are most philosophical approaches to project management. I call it “perfect world project management.” As organizations recognize the waste in their process flow, identify too many defects in their products, and recognize a faulty process system in general, the more necessary it is to attempt to attain a semblance of order. Lean and Kanban philosophies apply to both industrial and knowledge work, and they have been proven to work time and again in multiple industries and are flexible enough to converge with other frameworks. The theory of Kaizen, or continuous improvement, may be a moving target, but it is a target that all organizations should aim for. Being Agile is the goal.
Feature-Driven Development (FDD) isn’t the most widely known Agile methodology, but there are several best practices that can be gleaned from each methodology that you review. FDD has important aspects and influences that can be helpful on your Agile projects. FDD was created by Jeff De Luca to help larger teams implement Agile and improve their processes. Larger teams come with more communication channels and more challenges than smaller teams. Remember what Scrum recommends about nine team members. What if you have 30?
There are five processes attributed to FDD, of which the first three could be identified as part of Iteration Zero, or in FDD, initial project-wide activities. When you have a much larger team, it is important to get your ducks in a row and figure out how you are going to produce the expected result. Much like Initiation in a Waterfall project, Iteration Zero, or initial project-wide activities, helps to create a plan in advance and develop ways to prove the direction in which the project is headed. It also helps answer the question: Will the direction we want to head in work well before we actually begin heading in that direction?
Because tailoring is becoming so popular in project management, it might be relevant for your team to have an Iteration Zero on a large project, with multiple team members working on something totally unique and new. It’s a chance to plot your strategy and map out your way through the project before too much time and money is spent doing the wrong things.
The best practices of FDD are as follows:
Even though FDD isn’t the most talked about or popular Agile framework, I find it resonates with many of the Waterfall projects I have worked on in the IT sector. Knowing and determining what the features were in advance was commonplace, and then working to determine how to achieve those features involved owning the processes and achieving the goal. To me, FDD is really a simplified way of running a waterfall project in an Agile or software development environment that you can’t expect to be successful with the use a heavier framework.
Crystal methods are a family of methodologies (the Crystal family) developed by Alistair Cockburn in the mid-1990s. The methods come from years of study and interviews of teams by Cockburn. The Crystal family is Cockburn’s way of cataloguing what they did that made the projects successful. Crystal methods are considered and described as “lightweight methodologies.”
Crystal methods are a family of methodologies color-coded and customized by team size and the criticality of the project. Once that is determined, the project is placed based on the scale, and a method is chosen from a range of scalable models. The family of color codes is a lot like when you see a high terrorism alert from the government. They say it is code red, and everyone is on high alert.
In Crystal, it is a similar thought process. If I have a very heavy project with a lot of critical needs, then I need to scale my model to a weight that can work effectively for the outcome. The heavier the project, the heavier the need to scale up in process. The less critical the project, the greater the need to scale down. Crystal is a flexible model, and deciding which to use is based on the criticality of the project and what scale is needed to complete the work appropriately. The family of Crystal begins with Crystal Clear and ends with Crystal Sapphire:
The Crystal family uses “criticality” to determine what project goes in what color, from low to high, by using a point system based on categories like life, essential/discretionary money, and comfort. Based on the score, a determination can be made of how critical the project is. Then the selected family and their best practices will be utilized. A scalable model like Crystal is something of a one-stop shop for best practices in Agile. It is the most lightweight and adaptable Agile methodology.
The big focus outside of determining the color code are the core tenants of teamwork, communication, and simplicity. Reflection is used frequently to adjust and improve the process. Crystal also promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions.
This sounds like many of the frameworks and best practices you have read about already. The resounding themes across multiple Agile methods and frameworks are the focus on communication, delivery early and often, and adapting to changes as needed but keeping things as simple as possible.
As you have seen throughout, it makes sense that you would need to be flexible and adapt in the ever-changing waters of software development. In the book Adaptive Software Development: A Collaborative Approach to Managing Complex Systems by Jim Highsmith (Dorset House Publishing, 2000), Highsmith uses the analogy of mountain climbing to illustrate his points about needing effective teamwork, planning, and the ability to adapt to rapidly changing conditions. Adaptive software development replaces the traditional Waterfall cycle with a repeating series of speculate, collaborate, and learn cycles rather than the Deming/Shewhart cycle of Plan-Do-Check-Act. The planning, execution, monitoring and controlling, and closing process groups found in the PMBOK® Guide also reflect the need for continuous improvement and adaptation.
The characteristics of an ASD life cycle are mission-focused, feature-based, iterative, timeboxed, risk-driven, and change-tolerant.
Rules can be barriers to hide behind or guidelines for the wise to consider and break when the circumstances justify it.
Jim Highsmith
Rapidly changing conditions mandate the need to be adaptive and flexible. The adaptive software development (ASD) cycle very simply represents the continuous sequence of adaptation in software development. Figure 3.4 is a graphic depiction of the adaptive software development cycle.
The name adaptive software development cycle really describes its focus. Develop software, but be prepared to adapt by speculating, collaborating, and learning as you go. Even though the cycle sounds a bit vague, it is a good reminder to all of us working in Agile environments to be constantly checking ourselves, collaborating, communicating, and finally, learning from both our success and mistakes, using what we have learned in an effective and adaptive way.
Speculate: The project is launched and adaptive cycle planning is conducted using what was learned from project initiation information. For example, the customer creates a mission statement depicting what they want from the results. Typical project constraints like time, cost, scope, and quality are reviewed. The basic requirements are documented to define the set of release cycles or software increments that will be required for the project.
As the title suggests, this is all speculation at this point because nothing specific has been proven, and you know that customers always change their minds. Today’s mission statement could be tomorrow’s trash, but the act of speculation allows for a direction to be chosen and the ability to move forward while knowing that changes will occur and embracing them.
The servant leader is servant first. It begins with the natural feeling that one wants to serve, to serve first.
Robert K. Greenleaf
It seems relevant to end the chapter with everything that it takes to run any methodology successfully and to help you study for and answer questions on the PMI-ACP exam. It is also a good point to review the differences between management and leadership.
Management is focused on big picture items like best practices and whether they have been implemented correctly. It involves being efficient and task-oriented as well as maintaining a position of authority and formal power.
Leadership is much more focused on the human elements of communication, understanding people and your team of individuals, building and maintaining effective teams, and following a core set of principles. Most leadership on Agile projects promotes and encourages the team to be self-directed (and managed), and it stresses the ability to motivate and empower the team on the individual level as well as the collective “we.”
Having a good balance of both management and leadership are important and necessary skills for anyone running a team of people. Whether that is a team of salespeople or software developers, good leadership is necessary for effective team development. What you will see throughout most of the methodologies and the exam is the concept of servant leadership. Notice that the word management is missing.
The main aspects of leading an effective Agile team are to practice leadership and continuously aspire to learn innovative ways of leading. Servant leadership is a key mindset for Agile, and practicing the tasks of servant leadership is the icing on the cake of a highly effective Agile project manager.
The three aspects, or trifecta, of Agile Project success, is to be an Agile project manager who practices the three principles illustrated in Figure 3.5: leadership, servant leadership, and leadership tasks.
Leadership: This is the practice of emotional intelligence and being able to adapt and adjust to the needs of your team. A certain amount of extroversion is also a good practice, because without engaging with your team members, you won’t know what is going on with them day-to-day. Active listening, being open to new points of view, diversity of thought, and consistent learning are all active traits of good leaders.
I used to call project managers that stayed in their office all day, hovering over spreadsheets, “pod squatters,” because they just wouldn’t leave their offices to hang out with their team. I thought then (and still do) that they aren’t leaders at all—they are simply managers.
Servant Leadership: The servant leader is servant first and leader second. This may seem counterproductive, or as if their authority is somehow rapidly disappearing. I wouldn’t be surprised if this type of Agile project manager is foreign to a lot of managers today—maybe even your own manager!
Servant leadership is for sure, the key to effective Agile project management. To get into the mindset of a servant leader, you first should know what that entails. The servant leader should provide what the team needs. It’s as simple as that. Easier said than done you say? You would be correct! The only way to know what your team needs is to ask them. This requires the emotional intelligence to identify and understand an undercurrent not expressed yet; you’ll need to apply your active listening skills to truly understand what you are hearing without thinking about what you are going to say next.
Active listening is probably the biggest aspect of communication. My mother always said, “You have two ears and one mouth, use them accordingly.” I wasn’t listening at the time. It was only until I ran my first team that I understood what she meant. It’s not about me, it’s about them. Listening is the best way to know what the team needs and wants. If you are distracted by your own thoughts or words, you’ll never understand where the team is coming from.
It is also your job to remove any roadblocks the team is facing, including pesky stakeholders who are interrupting their work and meetings. Perhaps the biggest aspect of this that makes project managers everywhere scratch their heads in disbelief is helping maximize productivity by taking on administrative work if the team starts falling behind schedule. Me take on administrative work? Yep, you read correctly. I hear collective groans everywhere! Think of it this way: the more you help your team to be successful, the more successful they will be. This isn’t just fortune cookie rhetoric; it is part of carrying the food and water of servant leadership. Jump in there and get your hands dirty with your team. Also, keep in mind that excessive documentation is considered wasteful, so it won’t be that bad to take on administrative work in an Agile environment.
This chapter began with an overview of DSDM and the best practices associated with its framework, including the MoSCoW approach to brainstorming value.
Next I went over several other frameworks, including Lean, Kanban, and Feature-Driven Development (FDD), which all contribute to a full understanding of the principles to develop a shared mindset across the team. Much of the Lean and Kanban approaches are complementary to all Agile frameworks and help to trim the waste from your processes and products by embracing a visual pull system to manage your process flow with the use of Kanban/Scrum Boards.
Finally, I went over the essentials of embracing an Agile mindset by practicing servant leadership and some of the important things to keep in mind as you lead Agile projects as well as when you study for your exams.
Everything that we have covered in the first three chapters are incorporated into the tasks found in Domain I: Agile Principles and Mindset. Now you have a great foundation to move on to other domains and see how some of the best practices that we covered at the surface level can be implemented and utilized on your next project and on your exams.
Be able to understand DSDM and why the MoSCoW approach to determining value is important. Even though DSDM isn’t necessarily testable as a methodology or framework, it does contain the best practice of MoSCoW prioritization. Must, Should, Could, and Won’t aspects of MoSCoW help prioritize value.
Understand the Lean and Kanban methods. It is key that you understand why the Lean and Kanban methods influence Agile frameworks. You must especially appreciate the use of Kanban boards as a way to radiate information of what is in the backlog, what is in progress, and what has been deployed.
Understand the meaning of criticality and heavier weight methods. Even though Crystal methods aren’t mentioned too often on the PMI-ACP exam, the methods lend themselves to the understanding that higher-criticality projects need a heavier method. This is something you may see as a concept on the exam.
Be able to identify waste in a system. Even though this isn’t something that falls under Domain I on the exam specifically, eliminating waste from the value stream is a concept that you will see in Domain VII: Continuous Improvement (product, process and people). Understand that removing waste(s) from your Agile process is a continuing theme throughout, and the more waste removed from the system, the better the system works.
Be able to get into the mindset of servant leadership. The key to passing the PMI-ACP exam is to put yourself into servant leadership mode. Be able to understand the differences between leadership and management. Almost every question deals with the ability to understand this concept and apply it.
Be able to understand all Agile methodologies and frameworks. You have completed all of Domain I at this point, and you have reviewed at a high level all of the frameworks under the Agile umbrella. This is the foundation to understanding every other domain that we will cover in the rest of this guide. It’s always a good thing to review the first three chapters again before you take your exam so that you are really in the Agile mindset and understand the source of the concepts and best practices.
You can find the answers to the review questions in Appendix B.
Why is using the MoSCoW Approach in DSDM so important?
The Pareto principle is seen in many project management and quality methodologies. Why is the principle so important to use when determining cause and effect?
Which of the following is a correct statement?
Other than defects, which of the following is included in the seven wastes of Lean software development?
Using Kanban methodology, which of the following is the best way to show performance and WIP to the team and to the customer?
Why is a pull system so important in the practice of Kanban?
Why was Feature-Driven Development created?
Which of the following is the best way to complete the sentence: In Crystal methods,____________ increases with team size.
Mission focused, feature based, iterative, timeboxed, risk-driven, and ____________ are all characteristics of an ASD life cycle.
Your team is currently a bit behind schedule, and it is worried that it won’t complete the work before the iteration ends. If you are practicing good servant leadership, what should you do first?
One of your team members comes to you with a problem about something that they are experiencing with key stakeholders on the project. They seem upset and are looking for you to provide some feedback. If you are actively listening to your team member, what thoughts should be running through your mind?
If you are leading an Agile team and spend most your time focusing on inspiring and collaborating with your team, what kind of leadership are you practicing?
The team space is key in Agile projects. What is the one thing that is recommended above all others for Agile teams?
On a colocated team, what is one of the major benefits of everyone sitting together in the same work space?
Leadership tasks are designed to help your team be most successful and to remove roadblocks preventing the team’s success. Which of the following best describes this mindset?
What percentage of time should an Agile project manager spend communicating daily?
Lean was originally designed for which of the following?
Adaptive software development replaces ____________ with a repeating series of speculate, collaborate, and learn cycles:
One of your key stakeholders comes to you after a meeting and says, “I don’t see you doing a lot of normal paperwork associated with project management. Instead, I see you talking to your team a lot. Why aren’t you doing your management duties?” How would you respond to this statement?
A key stakeholder has asked for information on the team’s progress through the iteration. What would be the best way to present information about team progress?
What would be the reasoning behind having an Iteration Zero?