DOMAIN 3 STAKEHOLDER ENGAGEMENT
Frequently Asked Questions (FAQ)
Carilah jawaban sesuai pertanyaan dari sumber-sumber yang telah diinformasikan
Kumpulkan tugas yang sudah selesai selambat-lambatnya 1 jam sebelum Sesi study group
dimulai.
Jelaskan konsep dari hal-hal dibawah ini:
1. Agile project chartering
The team develops and maintains a high-level summary of the project’s key success factors, synthetic enough that it can be displayed on one wall of the team room as a flipchart-sized sheet of paper. This description includes at least the major objectives of the project, scope boundaries, and reciprocal agreements between the project’s implementation team and external stakeholders.
Agile project charters can contain many categories of information, but the primary purpose is to provide clarity so that technical and business resources are on the same page. This will result in greater alignments across the organization.
Start with a Collaborative Kickoff Meeting
Begin with a collaborative kickoff for the entire team. This should include the: executive sponsor, product owner or service manager, project manager, and a designated team lead along with as many members of the strategy, discovery, and development teams as are known. This kickoff meeting should accomplish the following high-level goals:
Align the teams with the business objectives for the project, so there is a firm foundation of understanding moving forward
Create team energy around the common goal and an understanding of how each team member fits
Discuss any issues or misunderstandings regarding the project
The kickoff meeting should also lay the groundwork for agile charter activities. It is a collaborative process that includes everyone involved in the success of the project and allows participants to decide what is important, what is useful, and how the team should interact throughout the lifecycle of the project. Agenda items of the kickoff meeting may include:
Project Vision: Why does the project exist?
Success Criteria: How will you know when the project is complete and the vision is realized?
Stakeholders: Who is involved and/or affected by this project?
Project Risks: What are the top risks of this project?
Responsibilities: What roles are needed, and who is doing what?
Project Size and Complexity: What is the size and degree of difficulty of this project?
Product Roadmap: What is the strategic view of where the product is headed?
Once the charter has been drafted, it goes to the Executive Sponsor for approval. Understand that the approved charter should not be filed away and forgotten about. In order for it to be effective, it must be easily accessible to all members of the team. This way, it can be referenced as needed and team members can see if and when updates to the charter are necessary as the project transitions into performing discovery.
Developing Project Charter
An agile charter will typically answer a subset (or all) of the following W5H questions:
» Who will be engaged?—Alist of theproject participants and involved stakeholders
» Whatis this project about?—A high-level description of the project s vision, mission, goals, and objectives
» Where will it occur?—Details of work sites, deployment requirements, etc.
» When will it start and end?—The project start and target end dates
» Why is it being undertaken?—The business rationale for theproject
» How will it be undertaken?—A description of the approach (This is particularly important if agile methods are new to the organization or changes from the standard approach, such as the increased involvement of the customer, need to be explained.)
MCG page 154
2. Agile modeling
To Capture the intent of the design in a barely sufficient way.
The term “agile modeling” refers to the various modeling techniques that are commonly used in agile.
Projects.
While models are important in agile methods, their main value often lies in the discussion and creation of the model, rather than the final output. As a reflection of this, agile models are often sketched on whiteboards and then photographed as a means of recording them. The value is in the creation, not the preservation of the modeling specialized modeling tool.
So agile models are typically lightweight, or “barely sufficient,” capturing the design without a need for further polish. We can create a model for predictive purposes to help clarify a design and identify the issues, risks, and elements that we need to test. We can also use modeling for reflective purposes to investigate problems and help find solutions.
Scott Ambler, an agile modeling expert, asserts that the value of modeling peaks earlier than traditional. The theory has led us to believe, as shown below. He recommends limiting modeling to the point where the model is “barely good enough,” and then moving on to the next task.
The types of agile models that can be created during agile modeling include:
» Use case diagrams (see figure 3.4)
» Data models (see figure 3.5)
» Screen designs (see figure 3.6)
Regardless of the type of model you create, remember that the goal is still to deliver value but not extraneous documentation. So keep it light, move on quickly, and remain adaptable for changes.
MCG page 158
3. Assessing and incorporating community and stakeholder values
Engaging the product owner in the prioritization of the backlog
Invite stakeholders to plan meetings and retrospectives
Seek for Consensus through Respecting on group participations
Speak Up uncompleted work to be reviewed to exhibit fear of criticism.
Incorporating Stakeholder Values
As we’ve seen, agile methods emphasize incorporating the sponsors’ and users’ priorities into the project s priorities and execution. In other words, they focus on bringing project priorities into alignment with stakeholder priorities. Incorporating stakeholder values means making sure we do not plan or initiate work that the stakeholders don’t support or value at this time.
The most important way that agile incorporates stakeholder values into a project is by engaging the product owner in the prioritization of the backlog. Executing the work according to the customer’s priorities (taking into account the necessary dependencies and risk mitigation work) allows the team to deliver the highest-priority items and deliver early value to the business.
Another way to incorporate stakeholder values and interests into the project activities is to invite stakeholders to planning meetings and retrospectives. At the end of the day, it is the customers and sponsors who will determine whether our project is a success or a failure, so it is smart to plan our work and actions according to their values.
Incorporating Community Values
In addition to reflecting the priorities of the project stakeholders, for any team to be effective its members must also share the values of their broader community—in this case, the community of agile practitioners.In addition to the fundamental values and principles set forth in the Agile Manifesto, the two most popular agile methods, Scrum and XP, each define their own set of core values. So let’s revisit the two values that are shared by both Scrum and XP—respect and courage—from the standpoint of community values.
Respect
Agile approaches seek consensus. They rely on group participation in estimating, decision making, and uncovering ideas for improvements during retrospectives. Respect is necessary to make these practices work; they need to be centered on the guiding principles “Don’t judge suggestions” and “There are no stupid ideas.” Agile methods depend upon shared respect for differing points of view, suggestions, and opinions.
Courage
Agile methods encourage early evaluations based on prototypes—and asking people to present uncompleted work for review requires them to exhibit courage against the fear of criticism. Pair programming also takes courage, as does asking a product owner to prioritize the company’s requirements. (It would be far easier but much less useful—to just insist that everything is important.) Other examples of courage in agile include focusing on transparency by openly posting our velocity data and defect rates and addressing the question “What did not go well?” during a retrospective.
MCG Page 151.
4. Brainstorming Communication management
Brainstorming is a collaborative technique in which a group tries to rapidly generate a lot of ideas about a problem or issue.
Brainstorming can be very useful on knowledge work projects. Agile teams can use this approach to help identify options, solve issues, and find ways to improve processes. For example, the team might brainstorm:
» Product roles to feature inpersonas
» Features to include in the minimal viable product for a release
» Potential risks that could impact theproject
» Solutions to a problem raised in a retrospective
Brainstorming Methods
Quiet Writing: With this method, the participants are given five to seven minutes to generate a list of ideas individually before the group gathers to share their ideas. This approach minimizes the effects of peer influence because the stakeholders generate their ideas in isolation before they share them.
Round-Robin: In this format, people take turns by passing a token around the group. When a participant receives the token, he or she will suggest an idea and then pass the token to the next person. This method has the advantage of allowing ideas to build on each other; however, people have to be comfortable sharing their ideas in front of each other for it to work.
Free-for-All: Another approach is the free-for-all format. With this method, people just shout out their ideas spontaneously. This method can be collaborative, as people build on each other’s suggestions through discussion—but it can only work in a supportive environment. And even with a supportive environment, the quieter team members may not be heard or may not feel as if they have an equal opportunity to participate.
MCG page 174.
5. Chartering
The process of chartering helps align stakeholders with the project. One way to help stakeholders explore and cement the basics of the project is to have them jointly develop a project elevator statement. Elevator statements are short descriptions of the project goals, benefits, and decision attributes that quickly describe the project or product. The following is a popular format for elevator statements:
6. Facilitation methods
Facilitation methods are management tools that can help your team achieve its desired objectives.
When facilitating following method mind:
» Goals: People often feel that meetings are a waste of their time, especially if the meeting discusses a wide range of topics and the participants don’t understand why they need to be there or what their contribution should be. Establishing a clear goal for each meeting or workshop session can help people get engaged in the discussion from the start. Plus, having a clear goal and keeping everyone focused on that goal, rather than allowing the session to be sidetracked, can shorten the session time, making the discussion feel more valuable to all involved.
» Rules: Establishing some basic ground rules is another important technique for holding effective sessions.For example, there might be rules regarding the use of cellphones, starting and ending the sessions on time, or respecting the views of all participants. It is not enough to simply set the rules, however. The rules must also be enforced during each session.
» Timing: Timing is always important when we are trying to get a group of people together, and it can be easy to lose track of time once the session is going. Therefore, the duration of the session should be established ahead of time, and someone should be designated as the timekeeper. It is also useful to determine in advance when the session breaks will take place.
» Assisting: The session facilitator needs to make sure the meeting is productive and that everyone has a chance to contribute. In addition to keeping the group focused on the session goal and enforcing the ground rules, this may include making sure junior or quieter members have the opportunity to express their thoughts, coping with dominant or aggressive participants, and otherwise keeping the session flowing smoothly.
Page 181
7. Active listening
Active listening is hearing what someone is really trying to convey, rather than just the meaning of the words they are speaking. The expression “Do whatImean, not what I say” speaks to this concept. On agile projects, we need to listen for the message, not just the string of words being spoken. Active listening is a skill that can be improved with practice. According to the authors of Co-Active Coaching: Changing Business) Transforming Lives, our listening skills progress through three levels, as shown below.
Page 180
8. Collaboration
Agile collaboration is the act of working together within that process to achieve a shared goal.
In Agile, we called collaboration game:
Page 174
9. Knowledge sharing/written communication
The concept of knowledge sharing on an agile project is best characterized as Central to many agile practices
To promote the idea of sharing knowledge, the organizational culture should instead encourage and reward the discovery, innovation, and transfer of information.
Kegiatan manajemen di perusahaan/organisasi yang bertujuan untuk menyebarkan ilmu dan informasi atau merupakan salah satu metode atau salah satu langkah dalam siklus Manajemen Pengetahuan yang digunakan untuk memberikan kesempatan kepada anggota suatu kelompok, organisasi, instansi atau perusahaan untuk berbagi pengetahuan yang mereka miliki kepada anggota lainnya.
Written communication adalah keterampilan yang diperlukan saat menyampaikan maksud secara tertulis. Berbeda dengan komunikasi pada umumnya yang mengandalkan lisan dan nada, komunikasi tertulis cenderung mengarah pada gaya kepenulisan.
Page 167
10. Collaboration games
Collaboration Games
Collaboration games, also known as innovation games, are facilitated workshop techniques that agile stakeholders can use to get a better understanding of complex or ambiguous issues and reach a consensus on options and solutions. Here are some examples of the collaborative games used on agile projects:
» Remember the Future: This is a vision-setting and requirements-elicitation exercise.
» Prune theProduct Tree: This exercise helps stakeholders gather and shape requirements.
» Speedboat (akaSailboat): The goal of this exercise is to identify threats and opportunities (risks) for The project.
» Buy a Feature: This is a prioritization exercise.
» Bang-for-the-Buck: This exercise looks at value versus cost rankings.
To get a feel for the games that agile teams use, we’ll examine the first three of these games in more detail, Looking at how they work and the theory behind them.
Page 174
11. Participatory decision models (convergent, shared collaboration)
Participative decision-making gives a voice to everyone on the team and allows team members to contribute to end results in a meaningful way.
Convergent
Participatory decision-making models aim for convergence or collective agreement on the best answer
Shared Collaboration
The second characteristic is that these approaches aim to share the decision-making process fairly.
12. Conflict resolution
Conflict resolution can be defined as the informal or formal process that two or more parties use to find a peaceful solution to their dispute.
Conflict is an inevitable part of project work. Whenever people come together to solve problems, there will be differences of opinion and competing interests. Some degree of conflict is healthy, to ensure that ideas are sufficiently tested before they are adopted.
Table Level of Conflict Resolution.
Page 182
13. Stakeholder management
“stakeholder management” is the process of managing the people who are involved in the project This starts with identifying the project stakeholders and continues with controlling and directing their participation in the project plan until they are released from the project.
The agile methodology is designed to improve upon the predictive approach to managing stakeholders. The approach has been designed with the weaknesses of the predictive approach in mind and tries to overcome these. The role of the Product Owner Is at its core – they are responsible for constantly consulting with stakeholders on project activity and ensuring that their views are reflected in the work of the project team.
Stakeholder management in the agile, from roadmap, to value approach:
Page 148.
14. Definition of done
DOD is Agreed upon by the team and the product owner
Therefore, a shared definition of done is necessary at every level of an agile project, including:
User stories: “For this story, done willmean developed, documented, and user acceptance tested.”
Releases: “The first release willbe deemed done whensystem Alphais replaced and there are no Priority1 defects or change requests.”
Final project deliverables: “Done for theproject will mean all high- and medium-priority features are implemented, there are two months of trouble-free operation, and the project receives satisfaction scores of greater than 70 percent from the user community.”
Page 157
15. Emotional intelligence
Emotional intelligence (otherwise known as emotional quotient or EQ) is the ability to understand, use, and manage your own emotions in positive ways to relieve stress, communicate effectively, empathize with others, overcome challenges and defuse conflict
Page 180
16. Information radiator
An information radiator is a big visual chart placed in a prominent location. It conveys key information and shows the health of a team. It is used to visualize the flow of work, shows where bottlenecks (or blockers) occur, and enables anyone to see what the team is working on at any time.
“Informationradiator” is agile’s umbrella term for highly visible displays of information, including large charts, graphs, and summaries of project data. These tools, sometimes referred to as “visual controls,” are usually displayed in high-traffic areas to maximize exposure, where they can quickly inform stakeholders about the project’s status. The term “informationradiator” was coined by Alistair Cockburn, who was in contrast to agile’s approach to the practice of locking project information away in an “information refrigerator,” where nobody knows what is going on. Instead, information radiators use highly visible charts or graphs that “radiate” information about the project quickly to anyone who is interested.
The sort of data that might be displayed on an information radiator includes:
» The features delivered to date versus the features remaining tobe delivered
» Whoisworkingonwhat
» The features selected for the current iteration
» Velocity and defect metrics
» Retrospective findings
» List of threats and issues
» Story maps
» Burn charts
Page 169
17. Wireframes
Wireframes are simple block diagrams that show the placement of elements in a user interface and demonstrate the intended layout and functionality of a solution
Which of the circumstances outlined below would be a good fit for the use of wireframes is when the conversation is centered on the high-level flow of a process.
Wireframes are a popular way of creating a quick mock-up of a product. For example, in software development, a wireframe depicts individual screens and the flows between the screens, as shown below. This diagram helps confirm that everyone has the same understanding of the product. If there are discrepancies in understanding, the wireframe serves as a useful visual tool for stakeholders to refer to and adjust until they achieve consensus.
Page 160
18. Negotiation
Negotiation is a strategic discussion that resolves an issue in a way that both parties find acceptable. In a negotiation, each party tries to persuade the other to agree with his or her point of view. By negotiating, all involved parties try to avoid arguing but agree to reach some form of compromise.
Negotiating on agile projects does not have to be—and typically should not be—a zero-sum game with a winner and a loser. Instead, healthy negotiations allow each party to investigate the options and trade¬ offs and present alternative perspectives.
Page 182
19. Personas
When the project calls for it – for instance when user experience is a major factor in project outcomes – the team crafts detailed, synthetic biographies of fictitious users of the future product: these are called “personas”. (In Alan Cooper’s concise terms: “make up pretend users and design for them”.)
Personas are concise and visual; a common layout is a single page including a photograph (from stock shots or magazine cutouts), a name, and social or professional details: “Amanda Jones, 34, press officer at a major food retailing organization, etc.”
Personas are quick guides or reminders of the key stakeholders on the project and their interests. So this tool would be a good fit when we are trying to better understand stakeholder demographics and general needs.
Personas are quick guides or reminders of the key stakeholders on the project and their interests. Software projects, for example, commonly create personas for the different types of people who will use the system that is being built.Personas may be based on profiles of real people or composites of multiple users. When they are used as a project tool, personas should:
» Provide an archetypal description of users
» Be grounded in reality
» Be goal-oriented, specific, and relevant
» Be tangible and actionable
» Generate focus
Personas are not a replacement for requirements but instead augment them. Personas help the team prioritize their work, stay focused on the users, and gain insight into who the users will be. These tools help team members empathize with users of the product or solution.
Page 161
20. Social media-based communication
Agile social media or Social media-based communication helps teams create attainable goals and repeatable processes so they can test, learn, and grow quicker.
Social media tools enable more team members to work remotely while still keeping up with project changes and developments. Near-instantaneous push notifications allow team members to collaborate and stay informed nearly as well as working in a common team room.
Page 171
21."Two-way communications (trustworthy, conversation-driven)"
In the collaborative, two-way communication style used on agile projects, hierarchies are flatter, and feedback from the receiver is expected—in fact, it is necessary for the project to reach its goals. Page 164
22. Workshops
Workshops are meetings in which the participants get work done. I use this definition to distinguish them from meetings where people are not engaged in work. Retrospectives are a form of a workshop, as are estimating sessions and planning sessions. Workshops should have clear goals and a schedule that is visible to everyone. There should be no confusion as to why we are here, what we are trying to do, or what steps we plan to follow. It should also be clear that input is both expected and encouraged from every participant.
In the Agile Team Workshop, your team gains a shared understanding of an Agile requirements model, starting with a vision and progressing all the way down to acceptance tests and testable examples. Leave with new ideas and a cohesive understanding of the Agile road ahead.
Page 172
Selamat mengerjakan !
No comments:
Post a Comment