LinkedIn : PMI ACP : Cert : PMI ACP Exam -Preparation
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Cert Prep: PMI Agile Certified Practitioner (PMI-ACP)®
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Welcome ::
Selecting transcript lines in this section will navigate to timestamp in the video
- You may have heard that agile is like the rule breaker's version of project management. At the same time, you know more and more companies are adopting these practices. So why is that? Well, agile has a much higher success rate than traditional methods, so many companies are trying it out. Since that's the world we project leaders live in, it only makes sense to learn more about this family of agile practices. Understanding them can help you hone your skills so you're a more valuable team member to your organization. I'm Kelley O'Connell. I have been a project manager for more than 20 years. I spent the first half of my career executing waterfall-style projects. But more recently, I've been practicing and coaching agile at the team and enterprise levels. In this course, we'll explore the world of agile and how you can apply these techniques in your environment. We'll start by talking about the principles behind agile and the mindset that makes it so successful. Next, we'll look at the essentials for all projects: Stakeholder management, planning, and team performance. Finally, we'll discuss troubleshooting and improving your agile practices. By the end of this course, you'll be well on your way to becoming a true agilist. So if you're ready, let's go.
What you should know ::
Selecting transcript lines in this section will navigate to timestamp in the video
- This course is intended to broaden and deepen your understanding of Agile project management. There are many ways to implement Agile, many specific methodologies. Each one can be useful depending on your situation. In Agile, you're also free to blend them into something that's ideal for you. Only by understanding the roots and philosophy behind Agile can you be completely successful. This course will start by giving you the why of Agile before we dive into the how. If you're new to Agile, I recommend taking my course on Transitioning from Waterfall to Agile Project Management, or the Agile at Work series. Once you're comfortable with the Agile mindset, we'll explore some tactics that apply across the whole family of Agile. We'll explore what value-driven delivery means and why it's so important. We'll also talk about managing your stakeholders. They can either be your champions or your adversaries. Working with them is going to be crucial for your projects. Every project depends on its team to achieve its objectives. Agile is no different on that front. In fact, Agile goes a bit further by saying that your team can't attain their potential without the right level of empowerment and autonomy. We'll explore both the rationale behind this statement and the tactics needed to guide your team there. Planning is a daily practice in Agile methodologies, so this course will also cover best practices and planning, and provide examples and templates you're free to use and modify to suit your needs. Finally, we'll spend some time talking about risk management and continuous improvement, and what that means for you and your teams. If you're ready for a deep dive into all things Agile, this is the course for you.
AGILE PRINCIPLES AND MINDSET ::
- Model Agile values
- Agile Methodologies
- Create a safe environment
- Transparency and information radiators
- Collaborations and self organized teams
- If you work in a factory or on an assembly line, your daily activities have very little variance. You can come in and repeat the same steps over and over with almost no difference in the result that you get. Most people worked in this kind of environment until the late 20th century. That's when the industrial revolution shifted to the knowledge or information revolution. When we shifted gears, the predictability of our work also changed. Traditional project management was based on the repeatability, what we call defined processes. Beginning in the 1980s and '90s, knowledge workers began to see that they work in a completely different environment, one that's unpredictable. You have to learn and adapt as you go. We call this the empirical process. When faced with the need to inspect and adapt all the time, project practices also needed to be transformed. This fundamental change required a shift in mindset. If repeatable practices were no longer driving our activities, something else was needed. There had to be a new way to look at work that allowed us the flexibility to discover the right answer while we're working. This called for a new way of thinking. That led us to the Agile mindset. Anyone can do Agile practices, but the full benefit of them can't be realized unless we adopt the Agile mindset. What does that mean? Well, it starts with an understanding of the principles and values behind Agile and you as a leader internalizing them, adapting your way of thinking to live, lead, and demonstrate those values to everyone around you. After the Agile Manifesto, the most important statement of the Agile mindset is reflected in the 2005 PM Declaration of Interdependence, or DOI. This was written by many of the same authors as the manifesto, but it adds details on how the manifesto is to be applied. It states, "We increase return on investment "by making continuous flow of value our focus. "We deliver reliable results by engaging customers "in frequent interactions and shared ownership. "We expect uncertainty and manage for it "through iterations, anticipation, and adaptation. "We unleash creativity and innovation by recognizing "that individuals are the ultimate source of value, "and creating an environment "where they can make a difference. "We boost performance through group accountability "for results and shared responsibility "for team effectiveness, "and we improve effectiveness and reliability "through situationally specific strategies, processes, "and practices." To sum these up, thinking Agile or having an Agile mindset means that you welcome change, you focus on short, value-driven delivery cycles, you learn through discovery, you continuous deliver so you can obtain feedback and improve your product and processes. You empower your customers and teams to maximize efficiency and quality. Finally, you encourage others to think and behave in the same way. While the Agile Manifesto is a great summary of what Agile is, the Declaration of Interdependence tells us more about how. This sets the stage for what it means to be Agile. Anyone can do Agile practices, but it's not enough unless you, as a leader, are demonstrating what it means to be Agile.
Agile methodologies ::
Selecting transcript lines in this section will navigate to timestamp in the video
- I come from a very large family. I have more than 60 first cousins. While we're all unique in our own way, we share certain characteristics that make us recognizable as a family; hair color, eye color, height, and so on. The same is true for Agile. It's a family of more than a dozen actively used practices. Some are more commonly used than others, so we'll spend most of our time talking about those, but it's incredibly useful to understand a little bit about several of them. Knowing something about these Agile family members, will enable you to flex and adapt your Agile practices when you need to based on whatever situation you face. Let's start with the most common practices, Scrum and Extreme Programming, XP for short. Scrum is probably the most commonly practiced methodology out there. It's based on three pillars. The pillars are: transparency, provide visibility to the people responsible for he outcome. An example of this is the Definition of Done for stories. Inspection, regularly assess how you're doing in relation to your stated goals. Adaptation, change the team's processes to minimize issues when you're trending in the wrong direction. One key element to Scrum, is that it's pretty much an out of the box methodology. There are key roles and activities that teams need to use until they have some experience. Scrum teams work in short, time-boxed iterations known as sprints. The roles every Scrum team needs are: the product owner, your business representative on the team, whose focus is to maximize the value delivered in each and every sprint. The Scrum master, your process owner whose responsible for ensuring that the Scrum methodology is followed and applied effectively. The development team, the group of professionals working together to meet the goal of the project. In practice, Scrum follows a repeatable set of activities, or ceremonies, every sprint. By doing so, it has guard rails that help teams effectively apply its practices. The essential activities for all Scrum teams include backlog refinement or grooming, meetings where everyone gathers to discuss new or changed items in the backlog. Sprint planning meetings where everyone gets together to discuss the work items that will be committed to for an upcoming sprint. Daily Scrum, or standup meeting where all the team members report on what they did the previous day, what they'll do today, and ask for help when they're stuck. Sprint review meeting where the development team, the PO, and Scrum master meet to demo what's been accomplished in the current sprint. Sprint retrospective meeting, where the team assesses themselves for the effectiveness and efficiency of their Scrum practices. They also decide here what can and should be changed to help them improve as a unit. All Scrum teams also produce the same set of tangible documents that are used to guide the team throughout the project. These are the product backlog, which is a defined set of the work items needed to be done to deliver the full valuable product, the Sprint backlog, which is a set of the work to be completed in a single Sprint and is therefore, a subset of the product backlog and represents the highest value items first whenever possible. Finally, a product increment is a portion of the overall product being developed and can be released on its own in order to deliver incremental value to customers. Scrum has a lot of structure around it so that teams can follow a predefined process with a known set of activities and artifacts. By following these guidelines, teams can achieve success earlier in the project, ensuring the overall success of their product.
Create a safe environment ::
Selecting transcript lines in this section will navigate to timestamp in the video
- Do you always have to be right in order for me to trust you? Think about that for a second. If the answer is yes, then it's impossible for children to trust their parents and parents to trust their children. It's also impossible for team members to trust each other. Trust isn't about being right all the time. It's about relying on the ability, integrity and honesty of someone else, be it a child or a team member. Creating a safe environment within a team is all about establishing and maintaining trust. You can order people to trust each other, but I can tell you that won't work. What does work is establishing that you, as a leader, see individuals as the ultimate source of all value that can be delivered. The best way to establish trust is to demonstrate it. People make mistakes; it's a given. It happens on my teams and it will happen on yours. As a leader, be generous in your assessment of mistakes. Always start with the belief that the person who made the mistake is capable, even if they're imperfect. Always jump to the best possible conclusion until the facts tell you something else. By trusting your team members, you're establishing that it's safe to make mistakes. In Agile, our focus is on failing and learning quickly. Failing is the essential first step. So you need to incorporate mistakes into your team culture. It's okay to err, that's only human. But the focus must remain on the lesson being learned, not embarrassing the individual. Even after you do this, there are further ground rules to maintain trust. When issues arise, you must also demonstrate your willingness and ability to address them directly. No conversations about others, especially when they're not present. Focus on the issues and deal with them head on, respectfully. Another key to creating trust is keeping your commitments. This is where integrity comes in. You need to keep every commitment you make and if you can't keep one, give the earliest possible notice that you can. By behaving in this way, you're leading your team by example. They see your expectation of them is the same as it is for yourself. When the playing field is level, trust can flow. Closely related to integrity is the expectation of sharing all information freely and transparently. Even when you don't know something, share that you don't know. This also demonstrates to the team that you're willing to be vulnerable. Your behaviors, as a leader, set the tone for the type of safe environment that's essential for successful agile teams. Trust is not a once and done thing. It requires ongoing focused intelligence. Trust is hard to earn and incredibly easy to lose. Be the example of trustworthy behavior for your team. Your project will reap huge rewards with trust as the foundation.
Transparency and information radiators ::
Selecting transcript lines in this section will navigate to timestamp in the video
- You're working hard to establish and model trust for your team. But what about your stakeholders? Well, you'll use the same principles and techniques with them that you've been using with your team. But Agile asks you to take these activities even further. Regular interactions with your customers are critical to maintaining alignment and building partnerships with them. Even when you can't meet with them face-to-face, Agile relies on information radiators to keep everyone that's interested aware of what you and your team are doing. Information radiators, also known as Big Visible Charts, take many forms. Some are intended for use within the team. Examples of this type of internal chart are the Team Norms or the Team Definition of Done. There's nothing secret about these that you wouldn't share, but they're really meant to guide and influence team behaviors and expectations. The ones your customers will care most about are the ones exhibiting the team's progress toward their commitments. First, you want to make sure your iteration, or sprint commitments, are displayed. Make sure your stakeholders know what you're promising to deliver. Then make sure you advertise how you're progressing toward those goals. Teams generally use a sprint burndown chart to show their progress toward their sprint commitment. Let's take a look at an example of each one of these. This is a sprint burndown chart. This tells your team, your PO, and your customers how your team is doing in accomplishing their current sprint commitment. In this case, we have 50 hours of committed work in this sprint. The dashed line represents an even spread of the work over the two-week, ten-day sprint timebox. The solid line shows what the team is accomplishing each day toward the commitment. In this case, the team is completing their work very well. In fact, they appear to be ahead of schedule. There's another common information radiator teams use to keep their stakeholders in tune with their progress. Let's take a look at a product burnup chart. This chart, instead of burning down to a finite commitment, remember, sprint scope is locked for the sprint, this is a burn up to a shifting goal. Remember, when we initially planned our project, we didn't know everything it would take to complete the work, so our backlog will fluctuate as we learn more and our PO makes decisions about what's most valuable. As we discover more, our top line moves up and down as we understand more fully what it takes to deliver this full product. The middle line tells us how much we need to do each sprint to complete the work. The bottom line, where it's solid, indicates what the team has finished and has been accepted by the customers while the dashed portion of the bottom line uses the team's historical velocity to predict when the product will fully be completed. In this case, at the end of iteration 11, the whole product should be completed if we continue on as we have so far. By openly sharing this information, both the team and your customers are aware of your progress. This level of openness and transparency builds trust within the team and among your stakeholders. When an issue arises, these charts will demonstrate the impact. By not hiding the bad news but sharing it equally, just like the good news, we're establishing our integrity and trustworthiness. This trust is the foundation for team and project success.
Collaboration and self-organized teams ::
Selecting transcript lines in this section will navigate to timestamp in the video
- I once attended a wedding that had the most delicious cake I've ever eaten. It was three layers, each with its own flavor: almond cake under lemon cake under strawberry cake. Absolutely fantastic. It made me think of my Agile team at the time. No, seriously, it did. They were a wonderful team and had just attained the level of maturity known as self-organizing. I thought about what it took for them to arrive at that place, and I recognized that it's like a layer cake. There are essential elements to helping a team become self-organizing. The first foundational layer to becoming self-organizing is trust. As a leader, your first and primary job as you launch your project with your team is to establish a safe environment based upon trust. Once you establish trust within the team, your job isn't done. Maintaining trust on the team is a full-time job. It requires you to continue facilitating open and honest communication. Doing this face to face is ideal, but video calling can meet the need when teams are distributed. Open and honest are big words to live up to. Open means you must model the vulnerability needed to be transparent about the successes, failures, and unknowns of the project and your organizational situations. You need to encourage others on your team to behave in the same way. Honest means you must act with integrity. Be capable, ask for help when you need it, keep your commitments, and tell the truth if you find you can't. As a leader, you must encourage your team to behave this way as well. With trust as your foundation, you and your team are able to collaborate, which is the next layer. Collaboration simply means the team works jointly, not independently, to complete the work. Agile pulls individuals onto a team from different backgrounds. The regular activities of Agile like sprint planning encourage open communication and highlight the need for all individuals to come together. In those meetings, everyone needs to share their knowledge, skills, abilities, and experience to organize and plan for the best possible product. This is collaboration. It means we're all in it together. We now realize that if we aren't all contributing, our product will suffer. It demands that people ask questions they may think are dumb without fear of ridicule. Once your team is collaborating well, you're in a position where self-organizing can begin, which is the third layer. Usually, a team has one or two emergent leaders. Those are individuals who are early experimenters. That means they're willing to identify and try new ways of doing things. These emergent leaders are helping to drive your team toward full self-organization. Self-organization doesn't mean the team decides on their own organizational design or what project they'll do. It simply means that leaders step back and allow the team the freedom to define the right solution to their challenges themselves. As leader, you still maintain the Agile boundaries, but the team is free to experiment with and problem solve within those boundaries. Here's an example of this self-organizing behavior. Let's say a team member has moved her current task to done. Having reviewed the pending tasks before the stand-up, she's collaborated with other team members. She knows, based on those conversations, which is the right task to pull. In the stand-up meeting, she pulls it and talks about what she'll do today for that task. Self-organization isn't mysterious. It's the freedom within the team to decide on the next right step together.
VALUE DRIVEN DELIVERY ::
- Define Valuable deliverables
- Tailor Agile to meet your needs
- The value of small increments
- Prioritize your backlog
Define valuable deliverables
Selecting transcript lines in this section will navigate to timestamp in the video
- Value-driven delivery is the defining principle of Agile. Pure and simple, if you're not focused and organized around this, you're not agile. So what does value-driven delivery really mean then? Well, all projects are started to add value to a business. Maybe it's a new product or an enhancement to an existing one. Value, then, is defined as the product or deliverable. Ultimately, the product will be observably more useful to your customer after you make that change. When we say that Agile is focused on value-driven delivery, we're really filtering every activity with the question what will result in the most value for our customer? The easiest way to do this is using a technique we call vertical slicing. Think of it this way. If you're building a website, you can build it horizontally or vertically. If you do it horizontally, you'll build the whole user interface first. Then you'd build the logic and services that make the website functional. If you do it vertically, you'll build a small bit of the user interface and the logic at the same time. In that way, you end up with incremental value. The additional benefit to vertical slicing is that you're itemizing each valuable deliverable in your backlog. When you deliver something, since you've already done this analysis, you'll know the final product is valuable to the customer. Another real benefit to defining value and focusing on it continuously is that you're driving consensus every time you slice your work. As you define a valuable piece of work, you also have to define success for it so everyone knows what they're trying to achieve. This is its Acceptance Criteria, or AC. Essentially, these are straightforward statements of the requirements that must be met for the value to be delivered. When you write your stories, agreeing up front on the AC is a great way to minimize waste. Here's an example of a user story and its AC. As a user, I want to receive a warning email when my bank balance is less than $25. The AC for this will incorporate three key aspects, input, process, and output. So for our story, the AC will include things like Email address is valid, which is input. Bank balance is less than $25, which is process. And a message sent to the customer email address, which is an output. You can approach AC definition in multiple ways. But at the core, all approaches will ensure all the requirements are covered by remaining focused on the value being delivered.
Acceptance Criteria (AC) : - Conditions that must be met for value to be delivered.
Tailor agile to meet your needs ::
Selecting transcript lines in this section will navigate to timestamp in the video
- Sometimes when I find great clothes on sale they're not quite the right size. I found a wonderful tailor though who can modify these clothes so they fit me perfectly. You might think of agile in the same way as a family of practices that allow you to tailor your processes to meet your specific needs. The most common adaptation is in sprint length. As you know iterations are meant to be anywhere from two to four weeks. This inherent ability to flex is the easiest way to tailor your agile practice. As an example I once worked on a team that was given a large initiative with a lot of risk and a tight timeline to bring the product to market. One of the adaptations we made to our scrum practice was to shift their iteration length from three weeks to two. Why? Well in the face of high risk and short time lines we needed to speed up our process of discovery. Essentially we needed to fail faster to meet the deadline while mitigating risk. Also it had a great psychological benefit for the team. It could be disheartening to hear the large scope of effort and knowing that we had four months, 16 weeks, to get it done. With a three week spring cadence we had only five iterations. With a two week cadence suddenly we had a generous-feeling eight. Don't underestimate how much of a benefit that feeling can be for your team. The best part is you can pick and choose practices from across the disciplines and different agile methodologies. So if you're using scrum you can still borrow practices from extreme programming or XP. In that same project we did a little borrowing from XP and this is what we did. We use paired programming on this team. Two developers would sit at the same computer taking turns coding and testing as code is being written. This has the benefit of having four eyes looking at the code and the result, as you can imagine, is greatly improved quality. Another thing we tried on this project for the first time was test-driven development, TDD for short. TDD first looks at the user story and acceptance criteria then immediately writes the tests that will pass the story. The developers have the advantage of an even smaller scale development process when using TDD. The tests are written, then you code, run the tests, and see which ones fail. Then you re-factor your code, run all the tests, and so forth. Until all the tests pass the story isn't complete. When we applied this practice it forced our developers to be outcome focused not code focused. The result was we ended up with much higher quality code. Another simple technique to tailor your agile is team size. Generally agile teams are five to nine people. This guideline however can be flexed. You can stretch your core team size up to about 12 by adding team members to meet your deadlines. At this number you'll have to be a bit more diligent in making sure sufficient collaboration is taking place. If you need to expand much beyond that you'll run into challenges with communication and team cohesiveness. What you can do at 13 and up is to build multiple dependent teams into a program. You can divide your valuable deliverables across the teams. You'll formalize the communication and integration activities of the teams by introducing the scrum of scrums. In scrum of scrums, the scrum master of each team meets two to three times a week to coordinate the work, provide updates, and identify dependencies. Finally another great way to flex your agile implementation to suit your project is by really assessing the timing of your demos. The higher the risk of the more frequently you should demo your work. Customer feedback is an essential ingredient to quality. For the team and project I've been talking about we opted to demo every week instead of at the end of the two week sprint. It was very informal. We asked our stakeholders to come to our collaboration space and check out what we were working on. The advantage is that we had continuous customer feedback and buy-in on our design decisions. When using agile practices take the time to really do an assessment of what the project is. Assess the practices you already have in place and then selectively tailor them to meet that specific project's need.
The value of small increments ::
Selecting transcript lines in this section will navigate to timestamp in the video
- There is a tendency for teams to think big. This is a good thing. We want them to remember the big picture, the final product they'll be delivering. But, when it comes to value, they need to be thinking more about elephants. You know, the elephant from the old adage, how do you eat an elephant? One bite at a time. Your Agile projects are the same way. Because of the vision, we know the big picture for our project, but we need to break that down into a series of deliverables that will get us to the product one bite at a time. As we plan our projects and the releases that we'll produce, we have to remember that every release needs to be valuable. In this context, valuable means that the release has to be useful to our customers. The term minimum viable product or MVP is the Agile shorthand for these small increments. Another common term is the minimum marketable feature or MMF. They mean the same thing and they refer to rolling out a set of features that's enough to meet early demand but not the whole product. So why do we want to deliver only part of our product? Well, there are some advantages to using this approach. First, by releasing a little bit early, we get fast feedback from our customers. That feedback will influence further design and development efforts. You get real world testing as well. Another great reason is that you're starting to get early return on your investment. Gaining early ROI essentially helps fund your project's future releases. Either by sales, if you're building a new product, or by stakeholder good will, if you're product is for internal use. Let's look at an example. If you're building an automated teller machine, ATM, you may have an initial MVP that includes dispense money, display balances, and protect user information. Maybe that's your first MVP and you receive feedback from users that they want an enhancement which is dispense more than one type of currency. This feedback becomes a new story for your team and will be prioritized in your backlog along with your existing stories. Maybe this story isn't as high a priority as your next MVP, which could be accepting deposits. As you define these MVPs, keep in mind that each needs to be complete in themselves. So, if you're working on the MVP to accept deposits at your ATM, you're going to need to include accept cash, accept check, update balances, print receipt, and so on. When working through your MVPs, you can also tailor your review cycle to match those releases. What I mean is that you'll still follow your normal demo cadence every sprint or two, but you may want to adapt them a little so your stakeholders stay in sync with your MVP. Using our ATM example, we'll continue to demo the individual stories we completed in each sprint, but we may add a segment at the end of the demo to show stories completed so far, which are all part of our MVP. Maybe we're about halfway through with our initial MVP of dispensing money. So we demo what we completed this sprint, say display balances. Then we take the stakeholders back to all the other work we've done and show how we're progressing toward the overall MVP. We show them PIN entry, account selection, and display balances together. As you add more functionality for your MVP, you can demo it all together each time. While thinking big is a great thing, make sure you take some time to think and plan in small increments with your team. It's a great way to deliver value throughout the project while funding your future efforts.
Prioritize your backlog ::
Selecting transcript lines in this section will navigate to timestamp in the video
- What happens if you have a jar that's full of sand and you've been given some river rocks you need to add to the jar? Will they fit? What will you do? For many projects using traditional methodologies, there was always a full list of requirements to be delivered, a full jar. Additional requests were known as scope creep. How do we address Agile's second principle, welcome changing requirements? The answer is very simple. It's to prioritize your backlog. Agile relies on the principle of customer value prioritization. Sounds fancy, but really all it means is that what the customers value the most are the highest priority. So, as your requirements change, the product owner works with the stakeholders to organize the backlog continuously with the highest value items at the top of the list. In this way, as new requirements come in, less valuable items are pushed to the bottom of the backlog. Remember the jar I mentioned earlier? Well the analogy is that the highest value items go into the jar first, the river rocks, and the less valuable items, the sand, can fit in when and if they can. So, tactically, how do we prioritize? Just like everything else Agile, prioritization is flexible, and you can tailor your approach to fit your needs. Some of the most common techniques are Kano and MoSCoW. Let's take a look at these. Kano is really a categorization tool that's used to help establish priorities. If your PO chooses to use this technique, she will assess all of your customer requirements or stories with the stakeholders in a meeting, and they'll categorize them into one of these four types. First is exciters, also known as delighters, are features that deliver new, very valuable functionality. Using an ATM example, the ability to withdraw cash in multiple currencies would be categorized as an exciter. Satisfiers, or basic features, are ones that the customers expect. They don't get too excited about them. They just expect them to be there. At the ATM, an example of this would be the ability to see all your bank accounts in the same session. Now, dissatisfiers are things that will cause your customer to dislike the product if they're not there. Back to the ATM. The ability to view your balances would probably fit in this category. And indifferent features are the ones that customers don't care about at all, and so will have little impact on their happiness with your product. These are features that would have a low priority. An ATM example of an indifferent feature could be the color of the ATM itself. While Kano is an effective technique for prioritzing your stories, you may run into issues when you have a large group of stakeholders. Their individual preferences will make coming to agreement more challenging. Similar to Kano is a prioritization model known as MoSCoW. That's an acronym for its categories: must have, should have, could have, and would like to have but not now. Again, your PO will host a meeting with the stakeholders and apply one of these categories. I've included a sample agenda in the exercise files for you to use when hosting a prioritization meeting. Now, let's change up our example and talk about building a pencil. For a pencil, a must would be it has lead. A should would be that it fits into one hand. A could requirement is that it has an eraser, while a would like to have is that it has a cushioned grip. MoSCoW is a bit easier to use because it couches everything in terms of what the essential functionalities for your product are. If you use this for your prioritization, your stakeholder conversations are very straightforward. There are many additional prioritization techniques, and I encourage you to do some research to find the ones that will work best for you. Remember, keeping your backlog prioritized is how Agile addresses its principle of welcoming changing requirements. Keeping your stakeholders in sync on your priorities will ensure you're building a well received product.
Kano and MoSCoW : Techniques you need to know.
STAKEHOLDER ENGAGEMENT ::
- Engage your stakeholders
- Collaborate across stakeholders
- Manage Stakeholders Expectation
- Ongoing status reporting
Selecting transcript lines in this section will navigate to timestamp in the video
- Why do we do projects? Job security? Well, yes, there is that, but beyond that? You might be thinking business value and you're right, partially. Really, projects are done for people and by people. Your stakeholders are people and groups of people, like departments, that are either working on your project or receiving your work product. In traditional project management, there's a whole segment of work around stakeholder management. Agile doesn't really subscribe to the concept of stakeholders as something you manage, as in you have to control it. Agile prefers to engage and collaborate with these individuals. The very first exercise you'll need to do is to identify all your stakeholders. This effort isn't really something you'd do in a big meeting, it's really the product owner, scrum master, sponsor, and the team sitting down for 30 minutes or so and brainstorming about who will be affected by the project. Some key questions for identification are, who or what is providing source information that could impact what you have to work with? Using our ATM example, this would be information on account holders at your bank. Who are the direct users of your product? This would include all customers using the ATM and internal departments validating withdrawals and deposits. Who or what will be using your product output? For an ATM, there will be systems that update bank balances in real-time. And are there secondary roles in the company that may care about what you deliver? Examples of this type of stakeholder are auditors or external assessors. Check out the Exercise Files for a template you can use during your brainstorming session. Once you know who your stakeholders are, you need to educate them about agile. Depending on who your stakeholders are, you'll want to tailor your message to them, especially if agile isn't fully adopted in your organization. As you craft your messages, be sure you address the most common fears of each stakeholder group. Sponsors and executives are most concerned about success rates for agile project. Be sure to have some statistics up your sleeve for them. Managers will be concerned about the self-organizing aspects and the potential erosion of their role in the organization. Be sure to share with them how critical their role as people manager is and remind them that that's not going away soon. The development team may be worried about being told exactly what to do, so reinforce for them the ability to tailor the process in ways that work best for the team. Finally, your broader user and stakeholder community will be concerned about the quality of work that's released so quickly. You can reassure them of their close involvement throughout design and testing. Those reassurances, however, will bring up another of their concerns, how much of my time will you take? This is where the short iterations of agile practices can help you. You'll need their time and focus every iteration, two to four weeks, but due to the frequency, the amount of time per iteration is actually pretty minimal. Additionally, it's much easier to maintain stakeholder engagement because the need for their input is more frequent. In traditional project management, they may have had months in between touch points and now it will be days or weeks. As you get things up and running, be sure to be specific about their involvement. Be as transparent as possible about what you'll need and how often. As you move through your project, be sure to acknowledge and thank your stakeholders for their ongoing input and involvement. Remember, in agile, we recognize that projects are done by people, for people. Successful, ongoing engagement and collaboration with your stakeholders will help you drive your project home.
Collaborate across stakeholders ::
Selecting transcript lines in this section will navigate to timestamp in the video
- As a parent, whenever I couldn't come up with a logical reason for something I wanted my son to do or not do, I always pulled out my standby, "Because I said so." I know I'm not the only parent to use that one and it would be really awesome if I could use it everywhere, but I can't, especially not with my Agile teams and stakeholders. At work, I need everyone to closely collaborate. In fact, the more involved people are in my project, the more engaged they need to be. There's a direct correlation between involvement and engagement. On Agile teams, we focus on making decisions quickly with no second guessing. With Agile projects, the goal is participatory decision making. That means everyone gets to chime in with their ideas, preferences, and votes. This type of approach ensures greater levels of satisfaction with the outcome. Greater satisfaction yields more support. There are many techniques you can use to drive your stakeholders towards convergence. That's just a fancy word for collective agreement. Convergence encourages discussion between people who don't agree. By discussing wide-ranging views, convergence occurs around a solution everyone can support. Also included in participatory decision making is the idea of shared collaboration. What that means is that you don't want one or two strong individuals influencing all of your team's decisions. Agile decision making requires that all voices be heard. Several techniques have been developed to make sure that happens. Let's look at a few. First, there's the ever present one person, one vote technique. While it wins in terms of simplicity, it doesn't by itself foster the discussion needed to reach convergence. This type of vote can always end up in a stalemate or entrenched positions. An improved version of this is the thumbs up, down, sideways approach. You pose the decision to be made and participants simultaneously place their hands thumbs up for supporters, thumbs down for dissenters, and sideways for the undecided. Unless everyone votes thumbs up, the group will discuss the topic until convergence can be attained. Finally, the one I use most frequently is the Fist of Five approach. There are some different takes on this which include going in the opposite order, but in general, the concepts are the same. The number of fingers a person votes with indicates their level of support for the idea. The proposal is reviewed, discussion takes place, and the participants vote simultaneously. If a participant shows zero fingers, a fist, it means, "No way, I won't go along with this." One finger means I have serious reservations. Two fingers says I would like to discuss some minor issues. Three fingers indicate I'm not convinced, but I'm comfortable enough to move forward without more conversation. Four fingers mean I think it's a good idea and I support it. Finally, five fingers indicate I think it's a great idea and I'd be happy to take the lead when we move forward. After you take your initial vote, those that voted zero, one, or two, are expected to share their reasons and concerns. This discussion will help you to arrive to convergence. Once everyone is aligned to the decision by voting three, four, or five, that's it. The decision is made and everyone now needs to follow through. With participatory decision making, everyone's voice and vote are heard. This ensures that you and your stakeholders have made your decisions collaboratively.
Manage stakeholder expectations ::
Selecting transcript lines in this section will navigate to timestamp in the video
- If you try to run your Agile project without a clear definition of where you're going and what success looks like, you'll end up with confused team members and unhappy stakeholders. Agile, for all its flexibility, understands this and has developed some tools to help maintain stakeholder expectations. In traditional project management, project charters have been used to establish success criteria for projects. The charter was used to define the project's finite scope. Agile charters, however, focus more on the goals of the project than what specifically will be built. This allows uncertainty to be acknowledged up front. While Agile doesn't propose using a specific template for the chartering activity, it does want teams to focus on the activity of having this discussion. At a minimum, when you establish your project charter, you'll define the W5H, the five whys and how of your project. Who will be engaged in your project, including team members and stakeholders? What will the project be about? This is your high level mission, vision, and goals. Where will the work happen? Details of work location and development environments. When will the work happen? Define your plan's start date and targeted end date. Why is the project needed? What's your business goal? How will you work? This is an outline of the approach you'll be using. In this case you'd identify which agile methodology you'll use, and your expected sprint cadence. Again, this is meant to be lightweight and flexible. It's also not intended to replace the formal visioning session or the definition of done. This is actually a precursor step to those activities. After you've completed your charter, vision, and definition of done, you'll need additional tools and techniques to keep everyone aligned throughout the rest of the project. Agile methods have some great tools for this. Let's talk about a couple of them. One group of techniques that you'll hear about most frequently is Agile modeling. In Agile, you use modeling to diagram use cases, model your data structures, or sketch out screen designs. These are very simple and lightweight. In many cases, they're drawn out on a whiteboard and a picture is taken to record the outcome. The value in this type of modeling happens early and quickly. The value isn't in the final model. The value comes from the discussion and direction it provides so you can start working. For instance, here's a model of an ATM screen to select an activity. Another Agile tool you can use is the wireframe. This is a very popular way of mocking up your product by showing the flow between the screens. The advantage of this is that it takes your sketched out screen designs and show how they flow together to ensure the overall experience is what you want. Back to our ATM screen. Here's the flow from view balance to the balance screen. This tool also enables ongoing discussion with the larger stakeholder group to ensure they're all in agreement about the final product as you flesh out more details. These are cheap and quick ways to get feedback. Finally, a commonly used tool is the creation of personas. Personas are used to describe a particular type of user for your final product. The goal of the activity is to really know and understand who your customers are and how they'll interact with your system. Personas are an archetype of your users. There are many techniques and tools you can use to keep your stakeholders in alignment throughout your project. They're all fast and light, and provide immediate value. Can you see yourself using one of these techniques each time your team starts work on new valuable deliverables? If you can, you'll be well on your way to maintaining stakeholder expectations throughout your project.
Ongoing status reporting ::
Selecting transcript lines in this section will navigate to timestamp in the video
- Status reports aren't Agile, right? Right. I'm not here to tell you how to craft a beautiful status report or build the perfect template for one. It's all about other ways to provide status updates that will engage your stakeholders. We've already talked about the information radiators or big visible charts you'll build, but that's a very passive method for sharing information. By passive, I mean your stakeholders have to seek it out or discover it on their own. The preferred method of communication is always going to be face to face communication. Why is talking in person so important? Well, with this type of conversation, you're receiving both verbal and non-verbal feedback. This gives you the best picture of how your message is heard. While many types of communication are needed throughout the life of your project, you need to tailor your style to the message being delivered. Design meetings, for example, will work best face to face or with video conferencing. Your information radiators are best served on paper, as are your risks and impediments. Documenting them on paper is necessary. Brainstorming solutions for them is best served with face to face formats. The focus with Agile is to establish repeatable best practices to foster collaborative or two-way communication. The sender provides the message. The receiver processes it and gives immediate feedback. Traditional project methods use the dispatching model where leaders tell people what to do and how. Feedback isn't desired or encouraged. Dispatching can lead to high levels of miscommunication or misunderstanding, where two-way communication goes to great lengths to avoid it. So what should you be communicating? Honestly, everything you can think of. This is transparency. Remember that in order to maintain our stakeholders' trust in us, we need to keep information flowing to them freely. At a minimum, we should communicate our charter, vision, sprint commitments, release plan, burn charts, project risks and issues, and of course our quality or defect steps. You're also going to be providing forecasts for your stakeholders. Usually these take the form of your road map and release plan. Remember, these are estimates, not commitments. So when you share them with your stakeholder group, help them keep this context in mind by also sharing your risks and issues. Your goal isn't to hedge your bets. It's simply to remind everyone that you don't know everything yet, so all plans are subject to change. We can forecast well in the near term but not very well the farther out we go on the time horizon. You can also branch out a bit from traditional face to face meetings in your communication planning. Don't hesitate to host workshops for story writing or design sessions where you can model your product and decide the best way to proceed. Some of my favorite engagement techniques are collaboration games. These are engaging ways to bring stakeholders together to get their input on priorities, design, and direction. Some of the most commonly used games are prune the product tree, where the stakeholders help gather and shape the final product. There's also the speedboat/sailboat exercise, where they identify threats and opportunities for the project, and buy a feature, which is a prioritization exercise. A quick internet search on collaboration games or any of these examples will yield millions of results. Seriously, millions. Ongoing status reporting in Agile is really focused on two-way communication and engagement. The more you communicate with your stakeholders, the more likely you are to deliver exactly what they expect.
PLANNING YOUR AGILE PROJECTS ::
- Plan at multiple levels
- Flex your agile
- Sizing and estimating technique
- One of the most common myths about Agile projects is that teams don't plan, they just take the vision and start building stuff. In reality, you'll spend more time planning with Agile than you did with traditional project processes. I know it sounds crazy but the basic philosophy of Agile planning is that we're planning to re-plan. Agile acknowledges that information work is inherently unpredictable. That being the case, it relies on adaptive planning. That means that we'll plan what we can upfront but know that we must adapt our plans throughout the project to meet the reality being faced by the team. In fact, if you think about it you're planning every day with Agile. At the start of the project you began with a vision for the project that's the strategic plan, what you're going to build and why it's valuable. Then you moved into planning your releases. Which MVPs do you plan to deliver when? Next, you broke those MVPs into smaller pieces and decided what you're going to deliver in each iteration of the release. Finally, every day of the iteration you're planning what to do today to meet the iteration objective. As you can see, Agile-ists plan every single day. Where the Agile approach differs from traditional PM is through the approach known as rolling wave planning. This is the strategy of planning at multiple points in time. Simply put, you're going to re-visit and adapt your plans throughout the life of the project. For me, I use the iterations and product releases as easy hallmarks to tell me when to re-plan. Every time you complete an iteration or release an MVP, you know more about your product than you did before each and every time you go back and re-visit your plans. Does what you learned in that iteration or release trigger a change in your original estimated plan? This is what we call rolling wave planning. You're simply aware that at times you're going to review your original plans and make new ones based on what you know now. You plan as a rolling wave between and within your execution cycles. Progressive elaboration is another key concept in Agile. While rolling wave planning is the acknowledgement that we don't know it all upfront so we'll continuously plan, progressive elaboration is how you apply it. You incorporate new information into your plans. You're taking feedback from demos and releases and re-prioritizing the backlog. As you go through your planning cycles you can't do this in a vacuum. Just like when you kicked off your project you were very careful about who to include in your visioning meeting. In that meeting your goal was to gain consensus on what the project is and what it does. You'll do the same thing as you re-plan your releases. In this way, you can share with the stakeholders what you've learned and how that's affected your road map. For me, I always hold a release kickoff meeting to share this information with my stakeholders. In the exercise files you'll find a template for the release kickoff meeting that you can use and adapt for your project. The benefits of rolling wave planning include the ability to keep diverse stakeholders in alignment on the plans. While you're continuously planning at many levels stakeholders require the most consistent visible communication.
2. Flex Your Agile ::
- All Agile teams work in timeboxed iterations. Most of the iterations team execute are development sprints. These are self-explanatory. You're building valuable increments of your product. Some, though, can have a special purpose to meet specific needs. For instance, there are two iteration types that are completely optional. They're up to you and your team to decide if you need them. They're iteration 0 and iteration H. In iteration 0, you're setting aside time to get the foundational elements set up completely so in iteration 1, your first development iteration starts, the team can immediately start building value without distractions. In iteration 0, you'll be identifying resources, setting up work spaces, setting up development and test environments, establishing the vision, and doing your normal early planning. This sprint can be as long or as short as you need it to be. For example, maybe you're setting up a brand new team to complete a product using a development language that's new to you. During iteration 0, you'll identify your team, do any hiring and training needed, and set up all the development tools they'll need to begin delivering value in iteration 1. A hardening iteration, iteration H, is a different optional iteration. In iteration H, you're hardening or finalizing your release contents. Your team is doing any final steps necessary to ensure your release is ready to move to production. Usually, this iteration has the same timebox as your development iterations, only your purpose is different. Many teams use this to complete extra testing, finalize user and system documentation, or whatever is needed to stabilize your code. At the end of iteration H, you're releasing this valuable increment of your product. There are additional iteration types you can use as well. These are focused on identifying risk and trying to mitigate them upfront. These fall into the category of spike iterations, and they come in two flavors: architectural spike and risk-based spike. Let's talk about them. The architectural spike is usually shorter than your normal iteration length, generally only a week but sometimes two if you have longer iterations. The purpose is to answer the question: Can we do this? Essentially, an architectural spike is a proof of concept build that will tell the team early on if the selected technology will work. For example, maybe it's cost-effective for your company to begin using an open source database for their web applications. You could do an architectural spike to prove that this free database will work. Next, let's talk about risk-based spikes. These are pretty self-explanatory, but in a nutshell these are shorter than your normal development sprints, and they test unfamiliar or new technologies early on. Let's look at an example of building an ATM machine. You have a requirement that a photograph check on a smartphone can be an acceptable form of deposit. One of the key risks is whether you can interface between a mobile device and your old system, so you execute a risk-based spike to make sure you can. If you can't, well, you need a new solution. If a new solution is needed, you may want to do an architectural spike to prove it will work. Sometimes, your proof of concept efforts aren't successful. That's okay. You've reached a state known as fast failure. It sounds bad, but it's really a good thing. You've learned early what won't work and now the resources can be directed to something that will work. The whole point of flexing your Agile is to customize it to your needs. You'll use different iteration types to prove early on what you're building will work. You're proving to your team and all your stakeholders that your project is on the right track.
Sizing and estimation techniques ::
Selecting transcript lines in this section will navigate to timestamp in the video
- Generally speaking, people aren't very good at making absolute estimations. It's really hard to estimate accurately exactly how long something will take to get done. In traditional project management, we knew this, so we cushioned our estimates by hours, days, or weeks in the hope that we'd be somewhat close. Agile addresses this fundamental human behavior by acknowledging that while people stink at absolute estimation, we're really good at comparing things to each other. This is known as relative estimation. Agile teams rely on this type of relative sizing to be faster and more accurate what their estimates. As an example, a soccer ball is roughly three times bigger than a cricket ball. Story points are the most commonly used measurement. They're based on the Fibonacci sequence of numbers, or some variation of it. This sequence is a naturally occurring numerical pattern that accurately reflects how things grow. It's really a simple math process. The next number is the addition of the two previous numbers, so the sequence is one, two, three, five, eight, 13, and so on. Using this sequence and knowing the pattern, we can start comparing things. If a golf ball is one, then I'd say a cricket ball is a two. What about a soccer ball? Well, since it's about three times bigger than a baseball, I'd say it's an eight. Relative sizing is the foundation of all estimation techniques used in Agile. Other techniques can be used just as successfully, so let's look at a couple. First, let's talk about affinity estimation. This technique involves grouping your stories into similar categories or affinities. There are many ways to do this, but the technique is very simple. At one end of the whiteboard or wall you'll place all your stories with a size of one, next to them the twos, then the threes, and so forth. As you continue to estimate the stories, they'll be placed on the wall in the right size affinity. As you add stories, you're comparing them to the ones already there. Does it fit? Does it seem bigger or smaller than the stories already there? If something doesn't seem to fit, the team will hold a discussion to make changes. In this way, we get a reality check to make sure our estimates are consistent. Another technique that can be used is known as Wideband Delphi. This is a group-based estimation technique where a panel of experts, your team, anonymously submit their estimates. The reason this is so valuable is that it avoids human biases. The common biases we're trying to avoid are the bandwagon effect, where people tend to go along with whichever opinion is gaining the most ground. There's also HPPO decision making. HPPO stands for highest paid person's opinion, and, as you can guess, people tend to defer to them as being experts as well as superiors. And group think, where people make decisions to keep harmony instead of voicing their true opinions. These behaviors will skew the accuracy of the estimates and impede the progress of the team. Few teams actually use Wideband Delphi for their estimates. Most teams use one of its related techniques. That technique is planning poker. It's the most commonly used Agile estimation technique. Check out this course for an in-depth explanation of planning poker. All of these techniques are designed to help teams produce fast, easy, accurate estimates for their work. Because they're simple to use and easy to adopt, you can use these techniques to help your team improve their accuracy too.
- Establish a Team foundation
- Generalize your team
- Collaboration and commitment
- How to get to a steady velocity
- Agile has always focused on people over process. As a leader, it's your job to ensure that the right people are lined up to work on your project, and that you're establishing the right processes to support them, not too much, not too little. All teams need the same key roles: the project sponsor, who's the project's main advocate and final decision maker. Since the sponsor is usually a member of the senior leadership team, the product owner is their direct representative and makes the day to day decisions regarding product vision and prioritization. The scrum master acts as a servant leader to coach and guide the team within the Agile process boundaries. They encourage the team to self-govern and makes the teams progress visible to the team and stakeholders. The team itself is responsible for the work to build your product. They're the essential element to the delivery of value for the sponsor, product owner, and stakeholders. As you select team members for your team, there are certain qualities and skills you'll need to look for. The scrum master, product owner, and sponsor will need to work together to determine the skills to execute the project. Focusing on the goal of the project, you'll determine which hard, technical skills are needed. For example, if you're building a website you'll need specialized skills like user experience designer. If you're building an ATM, you'll need people skilled in Java or C++, or something like that. On the softer side of things, you're going to need people that are willing to use Agile tools. They may be skeptical of them, that's okay, but they need to be willing to give them a try. Your team members need to be willing to learn new processes, work with new people, and be dedicated to collective accountability that's required for work on an Agile team. That means they need to be willing to share the glory as well as responsibilities for the failures of the team. One great method almost all Agile teams use is team norms. As the team forms, you need to lead your team through a norming session. Team norms are the ground rules that all team members agree to abide by throughout the course of the project. These are rules that they set for themselves about how they'll interact with each other. Every project and team should norm at the beginning. As new team members are added, the norms are reviewed and modified if necessary. In fact, team norms should be reviewed every couple of months so they adapt to what the team identifies as beneficial as they learn and grow together. A norming session is usually 30 to 60 minutes. You'll pull the team together with the product owner and scrum master and start identifying the ground rules. The norms can be very serious and govern how decisions are made. Here's an example. Silence means consent. This norm implies that if you disagree, you're expected to speak your mind. If you choose not to speak, you're still committed to the team decision. Some norms don't seem very serious at all, like no meetings before 9 a.m. on Mondays. These are simply boundaries where team members work with each other to define the best way to interact with each other and what rules they'll hold themselves and each other accountable for. Team norms are an essential way to set the team on the path to collaborative engagement. With guidance from the sponsor, product owner, and scrum master, they'll be set up with both the technical and interpersonal skills needed to succeed.
Generalize your team ::
Selecting transcript lines in this section will navigate to timestamp in the video
- I'm a huge multitasker. I read through the mail while cooking dinner and talking to my family. I'm sure you're the same way. We all are to a certain degree. It's the nature of our fast-paced, multidimensional world. On agile teams, we realize that multitasking is really inefficient. You should do one thing at a time until it's done, then move on to the next thing. But there's a big caveat to this on agile teams. The idea is that each team member should be able to play more than one role, but not at the same time. Let's work through this in a little more detail. For an ATM project, we need a business analyst who helps the PO quantify what our stakeholders need. Then we have a UI designer who figures out the most efficient and user-friendly screen design for our ATM. We need someone to write the code that meets the business needs and the UI design specs and finally, another person needs to perform all of the system testing. Can you have one person that's an expert in each of these functions? Yes, of course you can. That's how traditional project management has always worked. But do you remember the problems we run into with that structure? Yes, we always ran into bottlenecks. By the time the coder was building the product, the business analyst and UI designer were out of things to do. And the poor system tester usually twiddled his thumbs until the last minute, when all of the final code was dumped on him. The rest of the team had to wait on pins and needles to see if he'd get done. Agile is combating this inefficiency by saying, "Hey, we all have our specialties, "but that doesn't mean we can't help each other out." The term generalizing specialist is what we use for this. Sometimes it's referred to as a T-shaped resource. Generalizing specialist means that you have a specialty, say UI design, but you have additional skills you can apply to help out in other areas when needed, maybe business analyst or testing skills. As a result, we need to organize our teams around specialties while setting the expectation that team members generalize as well. I've seen coders and business analysts learn UI design or system testing and vice versa. There's no wrong way for people to select and learn a secondary or a generalist skill level. What's important is that you, as a leader, set the expectation early on that everyone will need to have more than one skill. Once everyone has more than one skill to apply, the team can all focus on the bottleneck to move the work through faster. This is known as swarming, which is when the team members' secondary skills are put to use to help accomplish the sprint goal. The value this provides to the team is incredible. When you're late in the sprint and focused on testing and refactoring, it's amazing to see everyone come together to cross the finish line. Not only does your product benefit, so do team cohesion and morale. You see, like a football team, when everyone faces the last-minute crisis and huddles together to make that last dash to victory, it builds team confidence and trust. These are the early hallmarks of self organization that can blossom into high performance for your agile team.
Collaboration and commitment ::
Selecting transcript lines in this section will navigate to timestamp in the video
- There's an old adage that if you want to go fast, go alone, but if you want to go far, go together. The vision and norms tell your team where they're going, why, and set the ground rules. These are great basics to get your team off to a collaborative start but they don't do much to reinforce the collective commitment to deliver the vision. However where they work can help. In an ideal world agile teams are co-located. It's not enough to be located in the same city or even on the same floor of the office building. Co-location means they're physically located in the same spot within 10 meters of each other with no walls or other barriers between them. You might be thinking that's really specific, what gives? Well, within that space, many beneficial things can help facilitate collaboration within the team and commitment to your team members. Let's talk a little about some of them. First there's the team space itself and the information it can provide. In your team space you'll usually have lots of great information posted. Your product vision, maybe your task board, a white board with some design models on it, team norms, your current burn down chart and the burn up chart that will tell you what's left to finish your product. These are more than just cool graphics they're reminders of the team's commitments to each other, their stake holders, and their product. Another benefit of co-location is what agilists call osmotic communication. This is another way to describe what you overhear of your teammates' conversations just by sitting close to them. This type of communication is free flowing and low cost. Let's say you're working in your team space and you hear a developer say, "She's going to refresh the database of customer data "to run a test on her code." Maybe you're in the middle of final testing and changing the data will skew your results. Based on osmotically hearing the developer's conversation you're able to avert a collision and negotiate better timing for everyone. I love working in this type of environment but truth be told there are times when I just need to be clear from distractions so I can really focus in on something. That's completely understandable. Lots of teams face this. Agile deals with this using the concepts of caves and commons. The team space is clearly the commons area. People work primarily in this environment. However knowing that sometimes everyone needs a little privacy for phone calls or heightened focus caves are small work rooms or cubicles where people can go to get away for a little while. Being co-located, while ideal, is pretty rare. Distributed teams are those with members more than 10 meters away and divided by walls or other barriers like time zones. So what do we do? Well we use communication planning and technology to replicate the experience of co-location. The first thing you'll need to do is formalize more frequent touch points throughout the work day. When you're co-located and communicating osmotically a single 15 minutes standup meeting is enough. When you're distributed it may not be. Maybe you need two, at the beginning, and end of each day. You'll also be sure to equip your team with the best technology you can get your hands on. Video cameras for the team space and computers. A conference phone and maybe a digital taskboard. Other great tools are instant messaging and electronic team spaces where people can check in online and be available on their schedule. Really team distribution doesn't have to be a huge hurdle for you and your team. There are many options available. I encourage you to do some research with your team to select the tools that will be ideal for you to collaborate and maintain your commitment.
How to get to a stable velocity ::
Selecting transcript lines in this section will navigate to timestamp in the video
- You're well on your way and your project is rolling right along. Now it's time to visualize your progress and measure your rate of delivery. Agile teams use a small number of low-tech, high-impact charts to track how they're doing. So let's talk about them. The first type of charts are known as burn charts. In this category, there are two basic types of charts, the burndown and the burnup. Let's start with the burndown chart. It's the most common agile chart out there. Most of the time the team uses this to measure progress toward the sprint commitment and calls it their sprint burndown. As work is completed, the progress line at the top of the chart will flow down to reflect the reduced amount of committed work to be completed. Take a look at two forms of the same chart. In the first chart, the Y axis is measuring progress using hours of remaining effort. Many teams don't like to use a burndown that reflects hours. Most teams estimate in points, not effort, so they prefer to use a chart like this one where the Y axis reflects points. They believe this is a better reflection of their progress. Let's switch over and talk about burnup charts for a minute. Burnups reflects all the work that needs to be done to finish your project. Here's an example. There's a lot going on in this chart, but it's really quite simple. The top line is the changing scope of your project. As new work is requested or removed, this line moves around. That's normal in agile. The line with the diamond markers reflects the work completed and accepted to date. Finally, the dashed line reflects the ideal completion rate to hit your targeted completion milestone. The beauty of the burnup chart is that you can see the changes in scope in a very visible way. That means as your product owner adds stories, if they don't remove any, that top line will continue to climb. As a result, your X axis will naturally have to extend further over time, which means your project will last longer. The conversations triggered by such a simple chart are wonderful. It forces discussion about new requirements versus desired delivery dates. These are not always comfortable conversations, granted, but necessary and better to have them early. Another type of chart is the velocity tracking chart which tells you how many points you're completing in each sprint. Here's an example. In this chart, you can see your team's velocity over the past six sprints. What do you notice? This team was not hitting their commitments the first two sprints. Honestly, it takes three to four iterations for velocity to stabilize for newly-formed teams. This is because the team itself is still in the forming and norming stages of team development. One they've made it through those getting to know you and trust you stages, the norms have taken root. Agile's goal is for teams to attain stable velocity. That means the team is delivering about the same number of points every iteration plus or minus 10%. You can calculate stable velocity. Here's how it works. You add the total points delivered in each sprint. In this case, when you add up these numbers, you'd get a total of 291. Next, divide 291 by the number of sprints, six. This team's stable velocity is 48.5 points. Now that you know this number, you can project when your project will be done. If you have 140 points remaining in your backlog to complete your product, you simply divide that number by your stabilized velocity and now can confidently forecast the remaining work will be done in about three sprints. Measuring your team's progress helps keep them on track and focused on the goal. It also helps you communicate expectations for ideal delivery timelines and the impact of increased scope. Overall, attaining a stabilized velocity will help you predict the outcome of your project.
TROUBLESHOOTING YOUR AGILE PROJECT ::
- Risk Identification
- Risk Tracking
- Every project since the beginning of time has faced threats or risks to their success. Your project is no different. You, too, will have to face them. As you know, agile is very focused on creating a safe environment for your teams: safe for them to experiment, take risks, fail and succeed. The same, safe environment you've been cultivating will help your team identify and address threats. Doing risk analysis is not just a once and done exercise, though. As in traditional project management, agile also asks you and your team to keep an eye out for risks. Some risks can be a benefit to your project, but many can hurt you. There are some techniques you can use to identify threats, and there's no definite consensus on the best approach. Some are much more lightweight than others, so make sure you select one and modify it to suit your needs. One approach to risk identification that I use all the time is a simple brainstorming session. I've included a sample threat or risk assessment meeting agenda in the exercise files for you to use if you'd like. It's one that I've used with my teams for a long time. Quite simply, this is a brainstorming session that focuses on everything that could go wrong, and negatively impact your project. The goal is to identify those threats, quantify them and log them so you can keep track of them. As you go through your brainstorming session to identify risks, you're going to capture the nature of the risk, what it is that can go wrong. You're also going to quantify the risk in the same session. Specifically, you're going to assess how likely that risk is to occur and become an issue; that's its probability. The higher the probability, the more likely you're going to have to be ready to deal with it. You're also going to estimate how many days of work could be lost if that risk occurs and becomes an issue. This is really the team's best guess at how long it would take to recover. Next, you'll calculate the total exposure of the risk. What I mean by that is, if a risk is 50% likely to happen, and it's going to impact your project by 10 days if it does, the total risk exposure to your project is the loss of five days. In the exercise file, you'll also find a risk register to track and quantify your risks. You can modify it as you see fit. Risk management is nothing new for project management, and agile project management also sees the value in identifying and tracking risks. It's a very simple thing you can do to help keep your team and project on track.
Risk tracking ::
Selecting transcript lines in this section will navigate to timestamp in the video
- In many ways, simply using Agile practices is a form of risk mitigation in itself. The flexibility and short delivery cycles of Agile reduce risk because the team is fully focused on delivering value and clearing any obstacles that get in the way of that mission. Regular feedback from your stakeholders ensures that any expectations-based risks are automatically mitigated. Finally, since you're delivering value every iteration, the risk of a complete loss on the project investment is small. You could argue that low-risk Agile projects don't need to do any formal risk tracking at all. Many of these types of Agile projects don't, and that's fine. However, the larger the Agile project is, the more likely you'll need to be a bit more diligent in your approach to risk. Once you've held your risk identification meeting and created a risk register, monitoring your risks is something you simply blend into the other Agile processes you're following. For every sprint, there's a sprint planning meeting. All you need to do is modify the sprint planning meeting to assess your risk register. Within the planning meeting, you'll review your risks. You'll be confirming or modifying the following. Is this still a risk for your project? If it is, has the probability or impact changed? Do we need to do anything formal this sprint to manage or mitigate this risk? If we do, is there a story written, sized, and prioritized to address it? If not, add one or more so the work is visible. As you discuss your risks, you may choose to add information to your risk register. Sprint planning is really about ensuring all the task details are noted for the committed stories. You can follow this approach for your risk register too. Some of the items I've seen added to the risk register are the owner. Who owns this risk or is accountable for leading the mitigation efforts? There's also the mitigation plan. What is being done to prevent this risk from becoming an issue? Do those efforts need user stories? Bear in mind that if people outside the core development group are the owners, stories don't need to be added to the backlog. For example, if there's a risk that regulations will change, but the legal team owns that risk, you don't need a story for it. And the escalation path. Who will the owner go to for help if they need assistance in mitigating the risk? Many times, the product owner or the sponsor are the logical escalation paths, but it really can be unique for each risk. Your risks, like all of your Agile artifacts, should be transparent. One way some teams address this transparency is to create a risk burndown chart. Just like your sprint burndown, this chart will demonstrate how the project is faring in terms of risk exposure. I prefer to chart only the risks that have the highest exposure for the project. That makes the burndown more focused. I don't want to spend a lot of time worrying about or mitigating risks that have a low probability and a low impact. On the sample chart, note that the Y axis tracks the total exposure of the highest probability and impact risks and charts them across the iterations on the X axis. You also have the option to add an ideal burn line on the chart to help everyone understand that risks should burn down with the backlog. Risk naturally decreases over time. This is because the closer the project gets to done, the fewer the number of things that can go wrong. One of the benefits of agility is that you inherently mitigate some risks simply by using the process. When you need to be more direct in your risk management, be sure to use a risk register and burndown. These will demonstrate the team's focus on top notch project execution.
CONTINUES IMPROVEMENT ::
- Review and adapt your practices
- Demo your deliverable
- Develop team skills
- Access your efficiency
1. Review and adapt your practices ::
- One of the best things about agile is its focus on continuous improvement. It's based on the concept of kaizen, which is a Japanese word for change for the better. This was developed in the '50s as part of the manufacturing environment in Japan. Kaizen demands that the people doing the work frequently examine how they work and make incremental improvements. The expectation is that you can improve the quality of your work by making small adjustments to your processes over time. Agile didn't invent the continuous improvement model. It merely adapted these highly-successful practices. The most common agile practice for this is the agile retrospective that's held at the end of every iteration. In the retrospective, retro for short, the scrum master asks the team, "What went well in this iteration?", "What can be improved in future iterations?", and "What do we want to do differently to improve?" The simplicity of this format provides the team with feedback on what shouldn't change and what should. It also forces a dialogue and commitment about what the team will change going forward. Many times, teams want to change the processes they're using. This process tailoring is something that agile allows to help teams get the most out of their agile practices. As a leader, your role is to ensure that the processes you tailor are changes that add value, not risk, to your project. Consider for example one of the most common process adjustments that's requested. I would say that 90% of the teams I've worked with have asked to stop doing a stand-up every day. It's a simple request and easy to implement, but it's one that I've largely resisted as a scrum master and coach. You might be wondering why. So here's my thought process. I consider the value of the daily stand-up and what's happening in a healthy stand-up meeting. We're saying what we did yesterday, basically a readout of our commitment from the day before. Then we share what we're committing to doing today to help the team reach the sprint goal. Finally, we talk about what's getting in our way and how others can help. That seems like really valuable information to have every day. To me, not sharing these things daily seems like a big risk to the project. However, if a team has been together for a long time, and they're awesome collaborators, then the risk is lower and this adaptation can be considered. As you go through your retro and the team is making suggestions on things to improve, make sure you're taking a high-level view of the changes being proposed. For most teams, the agile practices themselves should be used out of the box until the team has long tenure together and is performing well. Under your watchful eye, your team can tailor processes in ways that benefit them and your project.
2. Demo your deliverable ::
- I absolutely dreaded math class in school. I just didn't get it most of the time; and, quite frankly, when I did get it, I hated having to show my work. I couldn't understand why it was necessary. I got the answer right. Now that I'm older, I understand why it matters to show your work. There needs to be proof that the work being done is happening in the right way. For similar reasons, Agile expects you to show your work. Every iteration, or at least as often as makes sense, you should be demonstrating your work to your stakeholders. This is an opportunity to keep them engaged in your project and get feedback on your deliverables as soon as possible. In Agile, there are two kinds of demonstrations, or demos, you'll be doing throughout your project. The most common one is the Sprint demo, but there's another one, the Product review or demo, that should be included too. Let's talk about the Sprint demo first. In the Sprint demo, you're showing your stakeholders the stories that were completed in the Sprint. Usually the product owner sets the stage by sharing the list of stories that were part of the Sprint commitment. He'll then identify which stories he accepted as complete and any that weren't accepted. The product owner or the team, whichever you prefer, will demonstrate the working product that came from the accepted stories. Then the stakeholders share their feedback and any requirements they have that weren't demonstrated. Many times these are stories that already exist further down in the backlog, but sometimes they're new requirements. You'll capture those and add them to the backlog. The other kind of demonstration is the product demonstration. In the product demo, you're showing the stakeholders the collective product as it's being built. This is intended to give the stakeholders an ongoing view to what the final product will look like. This is so important because they'll provide feedback that helps the team deliver precisely what they want. The product demo is usually held after each release so the evolving product can be viewed and assessed together. These meetings are intended to incrementally adapt the product vision that we began with. This gives our stakeholders and our project team the ability to pivot in response to changing business conditions. The agenda for a product demo doesn't vary much from your Sprint demo. Check out a sample in the exercise files. The big difference is that instead of limiting the demo to what you accomplished in the previous Sprint, this one is focused on how much of the product you've completed so far. That being the case, I generally host these sessions from a process perspective that shows the overall user experience from start to finish. If we're building an ATM, I would start the product review with the initial ATM log-in screen and demo all the subsequent steps that have been delivered and accepted. I would also close with a view of the major product features that are coming up next on the roadmap. This step helps the stakeholder see how much we've already done and where we are in the larger context of the product vision. Remember, showing your work is an essential element to Agile practices. They'll serve you and your team well in keeping your stakeholders on the journey with you.
Develop team skills ::
Selecting transcript lines in this section will navigate to timestamp in the video
- The basic assumption for all Agile teams is that they're made of people with the right set of specialized skills to get the job done. Then, Agile pushes those individuals further by asking them to learn how to gain skills in other areas that are also needed on the team. We call this asking them to generalize or build T skills. Both of these are essential to the success of your Agile team. Beyond that, people want to learn new things and grow their skills, both within their specialty and beyond into areas they may not have learned before. As a leader, you can help your team by encouraging them to branch out into new areas. There are a couple of ways you can do this. First, for each specialty skill on the team, you'll need one or more backups for that skill. Second, you may need specialized skills on your project once in a while. Both of these create opportunities for your team members to select new learning opportunities. As a scrum master, an Agile coach, I've used something known as a skill ball, or skill chart, to help my teams plan their continuous learning. On this project, we need a Business Analyst, a UI Designer, a Java Developer, and a Tester. We also need a Database Analyst specialist to help out once in a while, so she's not a dedicated member of the team. How this chart, or one like it, works is by helping the team self-organize around learning one or more new skills. You can have an expectation that each person needs to have one additional generalist skill and make adding a second skill for each person optional. You can also offer your team members the opportunity to learn from the off-team specialist by shadowing or pair programming. This will help your team members continuously learn and grow their own skills and abilities. Many companies also have implemented communities of practice, or CoPs. A CoP is where team members meet with others in their specialty across the organization. They get together each week for two to four hours and trade notes on skills and best practices. These are also great opportunities to get feedback and assistance when facing obstacles on projects. A quick internet search on CoPs will provide a lot of information on how to set these up for team members in your organization. Your project requires a set of specialists who are willing to generalize. As a leader, you need to help your team self-organize around continuous learning. These simple things can help boost your team's skills and their morale.
Assess your efficiency ::
Selecting transcript lines in this section will navigate to timestamp in the video
- Many of the concepts used by the founders of Agile of agile came from lean manufacturing. came from lean manufacturing. Simply called lean, it's a systematic approach to identify to identify and eliminate waste in a system and eliminate waste in a system without affecting productivity. As a result of Agile's reliance on lean concepts on lean concepts and processes, and processes, understanding lean is critical. understanding lean is critical so it's important for you to know It's important for you to know that lean identifies seven typical wastes in systems. The first is partially done work. If something isn't complete, it doesn't add value. Partial value doesn't count as value at all. Next, we have extra processes. Next, we have extra processes. If you do something no one needs, it doesn't add value. There are also extra features. Sometimes, this is known as gold plating, where you build more than what's been asked for. It might be cool, but it doesn't add value to what was actually asked for. to what was actually asked for. Task switching is considered a waste because you lose so much time stopping and restarting. Waiting is also considered waste, and this is why Agile focuses so much on doing just enough, on doing just enough just in time. just in time. Motion is waste because moving, in itself, doesn't add value. An example of this type of waste is the movement of your hand of your hand from the mouse to the keyboard and back. from the mouse to the keyboard and back. There is no innate value in this motion, so it's an example of the waste lean is thinking about. so it's an example of the waste lean is thinking about. Finally, defects are considered waste because you have to fix them, which is rework. This is where Agile encourages automated testing, building in small batches, and building quality into your processes from the beginning. It's to eliminate this type of waste. One of the primary methods lean uses in understanding where waste exists in a system is through the use of value stream mapping. through the use of value stream mapping. You don't have to be working in a manufacturing environment to find this exercise useful. Value stream mapping has you literally draw out the path the path something takes to get to your users something takes to get to your users and create value for them. This is called the value stream. Here's an example of a value stream map that you can also find in the exercise files. that you can also find in the Exercise Files. Let's go through this together. Let's go through this together. Starting on the left, the flow begins with the business unit where they add a requirement to the wishlist of things they want. This can be a new product or a new feature for an existing product. The up and down graphic at the bottom of the flow measures whether the step is VA, value add time. whether the step is VA, value add time. VA time is also known as touch time, and it's considered doing something that will directly impact value at the end of the flow. If something isn't VA, it's considered NVA, non-value add time. non-value add time. This is also known as cycle time. The step of adding something to the wishlist is counted as one day of value add work. as one day of value add work. The next step is the delay, or waiting, until funding chartering. As you can see, this is six months of non-value add time. Now you can continue to read across the flow Now you can continue to read across the flow to see where value is being added in your value stream and where waste exists in the process. and where waste exists in the process. Once you know all of this, you summarize your results. In this case, at the top is the summary of this process overall of this process overall, and it's represented as efficiency and throughput. Efficiency is calculated as the total number of VA days, in this case, 97, divided by the total number of NVA days, or 315. This process has a sorry 30% efficiency. Ideally, every day would be VA time and very little or none would be NVA. This tells you how easy it is to deliver value to your customers. The next calculation lean relies on is throughput. Throughput is simply a calculation of how much value is delivered over the course of the whole process. In this case, to deliver 100 points it takes 315 days. In this case, to deliver 100 points, it takes 315 days. As the leader of an Agile team, you can map any process you and your team believe creates a lot of waste for you. a lot of waste for you. For example, one of my teams once mapped the software deployment process in the company because they felt there was a lot of waste. In fact, their value stream map proved they were right. As an Agile team, you have an obligation to eliminate as much waste as possible from both your team processes and the processes of the larger organization of the larger organization in which you live. in which you live. Having an Agile mindset means that you believe in Agile and the concepts it relies on for success.
Next steps ::
Selecting transcript lines in this section will navigate to timestamp in the video
- Agile foundations are just the beginning on your journey of practicing the techniques needed to both do Agile and be agile. As you begin on this path, I recommend you select one item from this course and begin doing it. Now, that you have a solid foundation in why it's important, you'll transition to being agile. One easy area to begin with, is by defining valuable deliverables. Here's a book I recommend you check out to help you get started. Agile Estimating And Planning by Mike Cohn is a very practical guide on how to define you work, size your work, and determine your timelines. You can also watch my Scrum Basics and Scrum Advanced courses, to gain a deeper understanding of Agile's foundations. I hope that you value the strength of having guard rails around your practices and are starting to feel confident enough to flex your practices a bit and watch the results. Don't hesitate to share your successes with me. I'd love to hear your stories, or answer any questions. You can contact me on LinkedIn. Best of luck to you and your teams.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Exam Tips: PMI Agile Certified Practitioner (PMI-ACP)®
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Welcome ::
Selecting transcript lines in this section will navigate to timestamp in the video
- While the basics of Agile are simple and straightforward, there are many nuances to the practices. After you've been using Agile practices for a while, you may feel ready to take the next step to prove to your company, and potential employers, the depth of expertise you've gained. Understanding these and the other details of the Agile narrative will prepare you for the PMI-ACP exam. This exam provides you with proven validation of your Agile skills and can help you kick your career into high gear. I'm Kelley O'Connell, and I've been in project management for more than 20 years. I spent the first half of my career executing waterfall style projects, but more recently, I've been practicing and coaching Agile. In this course, we'll explore the topics you need to know in order to take the PMI-ACP Exam. We'll start by talking about eligibility for the exam, and going through the application process. Next, we'll explore the knowledge domains you'll be tested on. We'll talk about how you can best prepare to make sure you pass the test the first time. By the end of this course, you'll be well on your way to knowing what to do to prepare for this career-launching exam. So, let's get started!
What you should know ::
Selecting transcript lines in this section will navigate to timestamp in the video
- The PMI-ACP exam isn't for everyone. If you only practice Scrum and you don't think you'll ever branch out into any other agile practice, this exam probably isn't for you. On the other hand, if you think you'll continue to work agile projects and you want the ability to add some versatility to your practices, this exam is a good fit. This course is for anyone who's ready to take the PMI-ACP exam. At this point, you'll need at least six months experience working on agile projects. You should also have taken some formal agile training. I recommend the Agile at Work series to ensure you're well-grounded in agile topics. I also believe that checking out my courses on transitioning from waterfall to agile, the basics of Scrum, and Scrum: Advanced will help you set a solid foundation for what we'll cover here.
BEFORE YOU START STUDYING ::
- What is ACP Exam ?
- ACP exam eligibility ?
- Application Process ?
- ACP Audit process ?
- Schedule your exam ?
ACP exam eligibility ::
Selecting transcript lines in this section will navigate to timestamp in the video
- The ACP exam isn't just for project managers or scrum masters. It's designed so that all perspectives on an agile team are addressed, scrum masters, product owners, and team members. Individuals in any of those roles can take and benefit from the ACP exam. With this in mind, PMI designed the eligibility requirements to be broad so that the exam is inclusive for all agile professionals. It enables you to demonstrate to employers and stakeholders your level of professionalism in agile knowledge, skills, and abilities, and increase your versatility in tools and techniques. There are four prerequisites to taking the exam. They are a secondary degree or high school diploma and an associate's degree or equivalent. 2,000 hours of general project experience. 1,500 hours working on agile project teams or with agile methodologies. And 21 contact hours of training in agile practices. Let's look at each requirement in a little more detail. 2,000 hours of general project experience may seem like a lot, but it really isn't as steep as it sounds. There are about 2,000 working hours in a year. Really PMI is looking for you to demonstrate that you've spent one year out of the last five years working on project teams. It doesn't matter if your time was as a tester, business analyst, or project manager. It just means that you have at least a year working on project teams. It doesn't even need to be the same team. The only exception to this requirement is that if you currently have a PMP, Project Management Professional, or PgMP, Program Management Professional certification, in good standing with PMI, your experience is already proven and you don't need to verify it again for this exam. Next, you're required to demonstrate that you've had at least 1,500 hours, or roughly eight months, working on agile project teams. Again, it doesn't need to be the same team, but these hours must have occurred within the last three years. These projects must be separate and unique from the projects you listed to meet the general project experience requirement. That means that you need both the 2,000 general project hours, as well as the 1,500 agile project hours. Another key point to remember is this, gaps in experience won't count for you. For example, if you worked on a project in January and February, but then stopped and didn't work on any projects until May, the gap period of March and April won't count towards your eligibility. Similarly, if you worked on three projects at the same time in the month of June, you can only count it as one month of project experience, not three months of experience because of the number of projects you were on. Finally, you'll need 21 hours of training in agile practices. As a general rule, that's three days of in-person training. But you can also meet this requirement through online or blended in-person online courses. You can study any agile methodology you choose, or you can take a single ACP prep course to meet this requirement. By meeting these prerequisites, you'll demonstrate to PMI that your background and experience are strong enough to sit for the exam. Now you're ready to begin the application process and move closer to getting your ACP certification.
Application process ::
Selecting transcript lines in this section will navigate to timestamp in the video
- [Instructor] In order to take the PM-ACP exam, you need to submit an application. PMI primarily accepts online applications, but if you have unusual circumstances and you need to submit a paper application, all you need to do is contact PMI's customer care department. So, let's get started at cerfications.PMI.org. If you don't have a PMI account, you can sign up for a new one here. If you already have a PMI account, you can just sign in. You'll have the option of choosing which application to complete. We're going to select the PMI-ACP application. Since I've already started this process, I can continue to work on it. It's important to know that once you start the application process, you can't cancel it. The application will remain open for 90 days and then PMI will send you reminders to complete the process within that timeframe. Please remember that incomplete and faxed applications will never be accepted. So, let's look at the application. It asks you to share the basics like your address and contact information along with all the details of your eligibility. Here's a tip. Before you start the application, make sure you have all the details of your education, work experience, and project history or existing certifications with you. It will make the application process much simpler. Be aware though that you don't have to complete the application in one sitting. You can save it and return to it later like we did. You can add your education and then move on to the requirements. Much of this is self-explanatory, but let me go over some highlights with you so you know what to expect. The eligibility worksheet shows you the requirements and it's the launching point to add your experience. You can start by clicking on general project experience. Here you click the add button to open the worksheet where you will enter each non-Agile project individually. You'll follow the same steps for the Agile project experience as well. Remember, these projects can't be the same as your general projects. Next, let's look at the Agile education form. Again, this is pretty self-explanatory, but let's talk about hours versus qualifying hours. If you took a week-long project management seminar, that would be 40 hours of training. If only one day of it was on Agile, you'd have eight qualifying hours. Given the amount of prerequisites for this exam, be aware that the application process can be time-consuming. When you're ready to complete the application, set aside an hour or two to complete it. If you have everything organized and ready to go, it'll take less time, but it's a good idea to give yourself enough time. At the end of your application, you'll be asked to agree with the terms and conditions of the certification application renewal agreement. Then once you submit your application, PMI will process it and review it for completeness. This usually takes about 10 days, so don't panic if you don't hear back right away.
ACP audit process ::
Selecting transcript lines in this section will navigate to timestamp in the video
- You were probably thinking you're home free, nothing more to do but final preparations for the PMI-ACP exam. But then, you paid the testing fee and bam, received a notice that you've been randomly selected for an audit. The audit notification email will include instructions on how to download the audit package. You have 90 days to complete the audit and you'll be unable to schedule your exam until you've passed the audit. Audit responses are only accepted in hard copy, so your first step will be to print the contents of the package. In a nutshell, the process is meant to verify that all the experience and training you listed on the application is true and accurate. So long as you truthfully completed your application, it should be simple to pass the audit. That being said, it is time consuming and can be stressful. You'll be asked to provide supporting documentation for all aspects of the application. Education background, general project experience, agile project experience, and training certificates. Failure to comply with the audit will result in failure of the audit and you won't be able to schedule an ACP exam. So let's look at each item together. The educational requirement for the exam is a secondary or high school diploma and an associate's degree or equivalent. To meet this audit requirement, you'll be asked to submit copies of your diplomas or work experience. For both the general project and agile project experience, it's a little more complicated. Not difficult, just time consuming. For each project you listed on your application, you'll need to get a physical signature from your managers for each of them. For example, if you listed three general projects and two agile projects with five different managers, you'll need signatures from all of them. If you had the same manager during all five projects, that one person can sign five copies of the form, one for each project. After they sign the form, the manager needs to mail the form to you. Make sure they don't send it directly to PMI. It won't be accepted and you'll have to have them redo the form. When they send it to you, they also have to sign the back of the envelope across the sealed flap. Next, you'll copy or print the certificates you received when you completed your agile training. All of these items, including your education background, general project experience with signatures, agile project experience with signatures, and training certificates will go into an envelope and be mailed to PMI at this address. PMI will send you a notification email that your audit package is received, and your PMI account will also show this. Make sure you send everything in the same package. Once submitted, you cannot add anything to your audit package. If you forget to include something, you'll automatically fail the PMI-ACP audit and you'll have to wait a year before you can reapply. Once PMI reviews your audit materials, you'll receive another notification, letting you know whether you passed the audit. This usually takes five to 10 business days. Assuming you passed, you now have one year to schedule and pass your exam and the clock starts ticking on that day. If you receive notice that your application is being audited, don't worry. You can make it through this. Simply comply with the instructions and be sure you include all your information in the packet. If you do, you'll sail right through the audit
Comments
Post a Comment