Forum Posts

Imon Rashid
Jul 06, 2020
In Agile Forum
Quarantine Scrum, leading remote teams We are faced with the reality that we can’t make use of our project “war” rooms and are forced to work from home. Well.. challenge accepted! Scrum actually provides a perfect framework for remote teams. If you’re not already working with such a framework, maybe you should. Set goals and ask for commitment Stop asking for estimations of time to complete a task and start explaining what goal you are trying to attain. When are you satisfied with the result? Describe what you want to accomplish or (preferably) what you want for your customer. This could also be another department within your company. Discuss thoroughly the context of the result and the criteria when your customer is satisfied. This gives your team member an insight of why something needs to be done and who it’s for. They are able, an capable, to determine the best course of action to accomplish this. Let them be the experts and you the leader. With a framework, such as scrum, you can define a goal for a set period of time. This period is called a sprint. A goal could be delivering something to you customer, but could also be testing an assumption or addressing some risks. A sprint usually consists of several thing that need to be done, that are part of the sprint goal. Explain these different parts and how they contribute to the goal. We call them backlog items. Tell your team when you would be satisfied if it’s delivered at the end of the sprint. If you can't use sprints, and sprint goals, at least use clear backlog items. Explain the goal, the context and who it's for, your team is capable enough to determine how this needs to be accomplished. When you explained what you want to accomplish, ask your team what would be feasible. Team members that are forced to work at home during this crisis also have some social obligations to attend to and limited in their time. They are the best judge of what is feasible. Research also shows that when you can determine to what extend you can give commitment, you are more likely to be committed and have more fun. In this way you are the person who determines what is most valuable. We call them the product owner within the scrum framework. You are not bogged down by discussing how your experts are going to do their job and can focus on prioritizing the goals you want to pursue. Keep in touch and review the result Working remotely can create isolation and that will result in a downturn in communication and lessened quality of results. To maintain the team spirit you need to make sure that everybody feels like a team. Start everyday with a quick get together. Not more then 15 minutes. It’s called a Daily Scrum. First of all it gives everybody the feeling they belong to a team, but you can also keep track of anything that impedes your team from reaching their goal. You discuss the progression towards the sprint goal; what they have been working on, what they are going to work on today and where they could use some help. This could result in some of your team member having some additional discussions afterwards to keep alignment. Keep the team spirit by coming together daily and check in on the progress and impediments of your team. After every part that you have described within the sprint, make sure you and the team members that worked on that part, get together to discuss the result. You can evaluate the result and see if the goal is reached within the criteria that you set. If not, discuss openly your concerns and let your team advice you for possible solutions. Naturally you'll have new ideas, so describe them as a part of your next sprint. At the end of the sprint, set up a meeting with your team and the customers that requested result. Your team has the chance to show what they have been working on and your customer can give them feedback. You'll see that there will be appreciation from the customer and empowerment of the team. The shared understanding will grow during the discussion and miscommunication will be quickly identified. All this information will lead to better alignment for upcoming sprints and new tasks that will be taken on. Fake face to face communication “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”, is one of the principles of the Manifesto for Agile Software Development. Well, that might not be possible in the coming weeks, but luckily there is a second best. Video conferencing! Use Microsoft Teams, Zoom, WhereBy, GoTo Meeting or some other tool. We're fan of Microsoft Teams, but there are lots of others out there (we like to hear your opinion). We like to have our meetings so we can see everybody and their screens. It ensures we pickup non-verbal communication. Working remote this makes it a little bit tricky, but you'll have more information if you can at least see the other person through a video stream. So make sure everybody's camera is on. Non-verbal communication is important when conveying information, so share your camera feed. If you have a meeting with a bigger group ensure that everybody respects the others in the group. Don't start talking while others are talking. Use the chat function in your conference call to raise your virtual hand, so that everybody knows you want to add to the story or ask a question. This way your meetings keep running smooth. Inspire others to collaborate! Are you managing a remote team and you have any tips and tricks, please feel free to send me a message or add them in the comments. Collaboration is key to working at home efficiently. Keep collaborating and stay healthy! https://www.linkedin.com/pulse/quarantine-scrum-leading-remote-teams-erik-poels/?articleId=6645785750447153152
0
0
1
Imon Rashid
May 18, 2020
In Agile Forum
Rafael Maranzato tells the story in this short video of a team who initially failed to adopt Scrum, but they tried again, successfully adopting it and moving to Scrum of Scrums within one year. Click here for the Video.
0
0
3
Imon Rashid
May 18, 2020
In Agile Forum
ahoo! is a large enterprise with a $32 billion market cap and has one of the largest Agile implementations in the world. The adoption of Scrum and Agile practices has been steadily growing over the past two years, and now encompasses more than 150 Yahoo! teams in the United States, Europe, and Asia-Pacific. The projects range from new product development for properties such as Yahoo! Autos to heavy-duty infrastructure work on Yahoo! Mail, which serves 250 million users each month around the globe. Read the complete article at the following link: http://static1.1.sqspcdn.com/static/f/447037/6486321/1270929190703/YahooAgileRollout.pdf?token=TEKsdddU%2FjH9HIMMDMZzjOTqMPc%3D
0
0
14
Imon Rashid
May 14, 2020
In Agile Forum
As the pace of business continues to accelerate, more and more organizations are turning to agile methodologies to keep up. And with top business priorities revolving around fulfilling customer needs, improving time to market, and reducing cycle time, the Scrum team structure has become the obvious answer for many organizations. Below we will cover what Scrum is and how can you build an effective Scrum team for agile development.  What is a Scrum team? Scrum is an iterative project management framework for implementing the agile methodology. The Scrum framework focuses on continuous improvement and learning to facilitate an agile mindset and allow teams to work together to develop projects. With only a few sets of rules, the Scrum framework provides a flexible guideline for teams to follow and adapt to their specific projects and development environments. This flexibility makes it an appealing structure across teams and organizations.  The basic Scrum Framework is composed of the following elements: 3 agile Scrum team roles: product owner, Scrum Master, and development team A prioritized backlog of user requirements Sprints Scrum events Scrum events include sprint planning meetings, daily Scrum meetings, sprint review meetings, and sprint retrospectives. Scrum team composition The typical Scrum team size is five to nine people (with seven being the ideal—one product owner, one scrum master, and five developers).  Unlike traditional development structures, Scrum teams don’t have a structural hierarchy. Instead, they are self-managing and cross-functional. All team members are equally important and together have all the skills and knowledge necessary to deliver a working product. While everyone has an equal voice, there are three distinct roles within the Scrum team structure. Product owner The product owner is the champion of the product and the foundation for its success. Their main responsibility is to understand the business and customer requirements and define and prioritize the work accordingly.  This role entails:  Building and managing the product backlog Communicating with the business and team to ensure everyone is on the same page Guide the team on which features to deliver next Decide when to ship the product In other words, the product owner acts as a guidepost for the team throughout the development process. While all team members will collaborate and discuss how to tackle the work, the product owner has the final say on what to prioritize and when.  Dive deeper into the seven key responsibilities of the product owner. Learn more Scrum Master The Scrum Master helps the team apply the Scrum framework successfully. They ensure the team functions smoothly by reigning in overbearing product owners, minimizing distractions, and coaching the team on best practices.  The Scrum Master also leads the daily Scrum meeting, which helps the team stay on task and on process.   Development team The developers are the foundation of the Scrum team. While the product owner outlines the priorities and the Scrum master monitors the process, the development team is responsible for determining how to get the work done.   They are essentially autonomous (one of the features that make Scrum unique from other methodologies). This feature makes Scrum teams highly collaborative and close-knit, often resulting in higher morale, satisfaction, and purpose.  Benefits of an agile team structure The Scrum team structure is a popular approach for many teams—and for good reason. Scrum has several advantages:  1. Shorter feedback cycle Due to their incremental approach to development, Scrum teams can receive and act on feedback faster.  For example, instead of spending six months developing and then releasing a product based on the original requirements, Scrum teams shorten the development cycle with multiple, shorter releases (often within a few weeks).  This structure allows them to get feedback earlier in the development process and adapt the product based on their learnings and user feedback.  2. Greater ability to adapt to change Scrum teams are designed to expect and adapt to change. Agile frameworks like Scrum make it easy for teams to pivot based on user feedback and changing requirements as they arise—instead of letting these changes disrupt or derail the development process. 3. Higher quality products Because Scrum teams are agile, they can deliver higher quality products with greater consistency. In addition to receiving and adapting to incremental feedback, Scrum teams also test the product at every sprint, ensuring issues are identified and handled as they occur.  4. Transparency Transparency and communication are key principles of the Scrum framework. The product owner and stakeholder(s) take active roles in the development process.   Therefore, transparency is critical for both internal team collaboration and external client (or user) communication so that the work always aligns with the product goals and requirements.     5. Higher user satisfaction With higher-quality outcomes, responsive feedback loops, clear communication, and managed scopes, it is no wonder Scrum teams so frequently experience higher user satisfaction.    6. Shared team purpose The culture of Scrum is one of collaboration. The heart of the Scrum team is the developers. Because there isn’t a traditional hierarchy with a team boss, and the work itself is structured collaboratively, members have a shared sense of ownership for the product.  This sense of ownership improves morale, gives the team purpose, and helps everyone work more productively.  When to use a Scrum team structure Scrum teams can work on all types of software development projects, including full software packages, client or internal work. While Scrum is a flexible and valuable approach for many types of projects, there are a few ways to recognize when it is best applied.  When requirements are not clearly defined Sometimes clients have a general vision for their product but lack clear requirements. This can make it difficult to estimate the scope of time and costs—which are necessary for fixed cost projects or more traditional methodologies.  The Scrum framework is built to adapt to evolving requirements, making it the natural choice for projects with undefined scopes. When changes are expected during development Similarly, Scrum works especially well for projects that anticipate changes during development. This can happen even when requirements are clearly defined from the outset.  For example, changes in the business environment or evolving technologies can affect product requirements mid-project. Scrum’s agile structure makes it easy to pivot to accommodate changes throughout the development process. When the project is complex Complex problems are difficult to address effectively and efficiently in traditional development methodologies. The more complex the project, the more issues that can arise as you go.  Scrum is well equipped to handle complex projects because it breaks them down iteratively and incrementally. Rather than trying to anticipate all the requirements in one plan at the beginning of the project, Scrum teams work on it piece by piece, adapting as they learn.  Picking the right people for your Scrum team To build a successful Scrum team, you need to bring together the right people. But what do you look for?  A good Scrum team is: Collectively accountable for the work  Autonomous and self-organizing Cross-functional and balanced Colocated and everyone works full-time together Additionally, look for a product owner who is fully available for the project. They must be fully involved to ensure the team has the right priorities and guiding requirements along the way.  When you have determined the key competencies required for a given project, consider using a visual workspace to highlight employees with the necessary strengths and skill sets. In Lucidchart, you can generate an org chart from employee data, add conditional formatting, and group employees by various factors. Though Scrum is not difficult to implement, consistently delivering real value is never easy. Teams that want to succeed in an Agile environment must commit to the process and their own personal and collective growth. Those that do are the ones who will stay ahead of the curve. This article first appeared on this link.
How to Build a Scrum Team Structure for Agile Development content media
0
0
9
Imon Rashid
May 11, 2020
In Agile Discussions
The work of a Scrum Development Team is pretty complex. People with a wide range of technical skills need to organise themselves to bring multiple work-streams together and produce production-grade code in as little as 1-2 weeks. While the tasks involved are carefully planned with detailed implementation steps, the novel nature of the work means that plans need to be revised on the fly as new information comes to light. By the end of the sprint, the broad objectives and goals may have been met in ways that were not foreseen at the start. As a result, a daily synchronisation event is absolutely essential to keep focus, share information, and allow time to re-plan. The trouble is that in the real world, there is an awful lot that can get in the way of this self-organised utopia. We regularly work with teams that see the daily scrum as irrelevant, disruptive, and boring. They are often right. Here are three common anti-patterns and three potential solutions. 1. The team is all working on separate things Scenario: A team works together in the same functional area of IT, perhaps maintaining the same software product, but the pattern of work is such that each individual works on their own task for a few days or weeks at a time, such as: Small client projects Business-as-usual minor enhancements Configuration changes Of course, the team members help each other out when needed and there’s the monthly curry-night to keep up morale, but people find very little value in getting daily updates on the meetings their colleagues attended. Potential Solution: Change the Process Scrum is optimised for complex work, originally in the software product development space. Teams work closely together towards regular incremental goals, that form part of a long-term product strategy. If this is not what your team are doing, then maybe there are other modern, productive delivery processes that might be a better fit. Kanban is the obvious mainstream example, and adopting this methodology would allow your team to: Define the service your team is providing Visualise your process and populate it with work Design a series of events that is optimised for the work you are actually doing This might lead you to conclude that a Daily Scrum is not a good fit, and perhaps a weekly catchup might serve you better. 2. ‘Mini-waterfall’ syndrome There is a multi-disciplinary team of analysts, designers, software engineers, testers, etc. The team forms into distinct sub-teams, where groups of specialists work in batches, handing work over throughout the Sprint. During the Daily Scrum, the following comments may be overheard: “I can’t start on that until you’ve deployed it to the QA environment” “I haven’t finished the specs for that, but maybe you can pick it up tomorrow” “Hmmm, I wonder if we should start having a separate testing sprint after we’re code-complete…” The value of meeting face to face to figure out how to creatively meet shared goals is beaten into submission by rigid “waterfall” handover procedures. Potential Solution: Change the work Some teams really are doing complex work that is a good fit for Scrum, but they are still organising this work in a batch-based or individual-focused way. For a daily scrum to make sense, the somewhat superficial act of batching work together into 2-week chunks is not enough. Fundamental changes to the way the work is done are also required: Find technical solutions enabling non-sequential work, rather than following a mini-waterfall. For example: Implementing automated tests while others write the software Effective use of continuous integration and a well thought-through source control strategy Building (or re-building) the product using modern architectures that allow many developers to work on the system without the need for complicated merge and integration issues Establish a common purpose, such as a Sprint Goal. Creating a high-level business objective at the start of the Sprint gives teams something to focus on during the daily scrum, and if all team members are playing a part in meeting this goal then one of the main barriers to creative whole-team collaboration has been cleared. Reduce the amount of parallel work by helping team mates work together on a single feature. This might be done by pair-programming, especially by people with different specialisms. A database programmer pairing with a UI developer will increase the flexibility and skill levels of the team. 3. Self-organisation is a buzz word that has little practical meaning for the team The team is not engaged in their plan for theSsprint and has no idea how much will be done by the end. The Sprint Backlog is just a dumping ground for tasks, with work routinely carried over from one sprint to the next. Tools like burn-down charts are a Scrum Master thing and the team don’t pay much attention to them. A typical “update” at the daily scrum follows the same well-trodden path: “Yesterday I did task 342 and went to a meeting. Today I will go to another meeting and start task 471. I have no impediments. Very little ever changes. The sole outcome of the daily scrum is that each individual takes 2-3 minutes to make their own plan for the day, with an audience of their peers (probably taking a sneaky look at their mobile phones). Worse still, it becomes a reporting session where developers feel that they have to justify their work over the past day, and be assigned new tasks. Potential Solution: Change the Culture People have a natural instinct to organise themselves in groups, but it takes skill and experience to apply this to building software. This is especially true if people are accustomed to being assigned tasks and do not see the benefit of self-organisation. Even skilled people will struggle if operating within unnecessary constraints. This situation may be improved by: Training the team at the start so that everyone understands this style of working, either informally by the scrum master or by attending a course Establishing clear accountabilities, so the team understand that they are collectively responsible for maximising the value delivered by the end of the Sprint Coaching the team to actively manage their work, keeping track of their forecast and escalating to the product owner if they foresee a need to adjust the scope of the Sprint Working with the leaders of the organisation to establish a culture of autonomy for technical teams, where constraints are limited, and those present are based on genuine IT strategy The Daily Scrum is highly revealing of team dynamics During my time as a Scrum Master I found that this event was highly revealing of the dynamics at play within the teams I worked with. In most cases, problems observed during the daily scrum pointed to deeper problems and were a starting point to help teams improve. In these cases, tackling the symptom directly was ineffective until the root cause had been addressed: Routine lateness for a team in London was not solved by moving the time of the event, but by addressing the unhappiness at a change in technical strategy Technical problems for a distributed team across Europe and Asia were not solved with new video conferencing facilities, but by ensuring that the whole team were included in product strategy meetings A genuinely self-organising team is as powerful as it is rare. Daily Scrums become focused but unstructured as the group takes control and explores the possibilities of the day ahead. Getting there takes time, skill, and commitment on the part of the team; and attention to the things that might be holding them back on the part of their Scrum Master. This article was first published at Agility in Mind.
0
0
1
Imon Rashid
May 02, 2020
In Business Analysis Forum
Business Analysis is simple! Almost anyone can do it. Just kidding 😊. Actually, as we all know, SDLC is a team work. Since the BA is in between the various stake holders, BA does play a central role. A good BA is a great listener, drills down to details, stays sharp on the basics, resourceful, and gets along with everybody! Let me indulge to elaborate, 1) Listening is so underrated: Listening is how we understand what others or stakeholder/s are saying or not saying. This helps to find out what someone said or didn’t say. It is your job to pet Only after carefully listening we find out what follow up questions to ask and what other factors to consider in the project. Project is served best when all relevant information is considered and collected in the initial stages. 2) The devil is in the detail: Take any topic or part of a project to drill down to the minute detail relating to the project relying on your experience to sift through the details. Attention to detail can make or break your project. 3) Need to know the basics: You seriously need to know the basics of Business Analysis. The complexities of the Software systems are enormous, especially the ERP type systems. Therefore, it is important to know the basics of software development to understand how the developers work and think. How a front end typically interacts with the back end, the Database. Process flow diagrams are critical to visualize the flow of information. Use cases shows the user interaction with the system. These are the basics any good BA worth his or her salt should know. 4) Resourceful: I cannot say enough about this. If You don’t have an answer, go find the person in the organization who has it, search for it on the web. If you decide to approach someone outside the organization be discreet so as not to reveal sensitive information. The BA being in a central position can smooth tensions between teammates or between departments as tension often seem to flare up but do not make a bad situation worse! Never forget the point that you as a facilitator wear multiple hats at the same time! 5) Interpersonal skills: IMHO you catch more flies with honey. Well a BA is not exactly out there to catch flies, but gather information to put together a document. When you put people at ease by your friendly demeanor you are more likely to get the proper information to fulfill your responsibilities.
0
0
2
Imon Rashid
Jul 04, 2019
In Current Topics
SDLC stands for Software development life cycle. It is a process that describes how to develop, design and maintain the software project ensuring that all the functional & user requirement, goals and objective are met. This methodology improves the quality of the software project and over all process of software development.
0
0
3
Imon Rashid
Jul 04, 2019
In Current Topics
Is it ever enough ? That is the question ! If you like to take a lot of pictures aka selfies and also download lots of music then you need something like 32 GB storage.
0
0
2
Imon Rashid
Jul 04, 2019
In Agile Discussions
Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum itself is a simple framework for effective team collaboration on complex products.  Scrum co-creators Ken Schwaber and Jeff Sutherland have written The Scrum Guide to explain Scrum clearly and succinctly.  This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together.  Scrum is: Lightweight Simple to understand Difficult to master Read more, https://www.scrum.org/resources/what-is-scrum
0
0
3
Imon Rashid
Jul 04, 2019
In Agile Discussions
MIT Sloan professor Steven Eppinger makes the case that agile applies not just to software development, but to large-scale systems engineering too. Nearly 20 years into the agile revolution, it’s a given that software development has been inextricably altered by the avid embrace of agile practices. Are large-scale systems engineering initiatives next? Steven Eppinger, professor of management science at MIT Sloan, recently laid out a case for applying agile to development realms outside of software. “Every company is trying to be more agile — it’s become part of the regular engineering management lexicon,” he said. “It's shocking how quickly it’s being adopted.” Agile replaces the traditional, linear “waterfall” development model, in which projects are preplanned and fully built out before they are tested, with an iterative process where small parts of projects are being built and tested simultaneously.Companies have embraced agile for a variety of reasons — to boost product innovation, more quickly meet customer demands, accelerate delivery cycles, reduce risk, and improve productivity. But while agile has a proven track record in software development, it hasn’t been put to the test or used extensively in other types of development, such as  manufacturing or engineering, said Eppinger, faculty co-director of the MIT System Design and Management program. In a recent webinar, Eppinger outlined agile practices that, with some minor adjustments, can deliver benefits to other engineering practices and industries. A major telecommunications company, for example, used agile to facilitate the design of hardware and cloud-based connected services Read more , https://mitsloan.mit.edu/ideas-made-to-matter/10-agile-ideas-worth-sharing
0
0
0
Imon Rashid
Jul 04, 2019
In Agile Discussions
Scrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland, the originators of Scrum.  The Scrum Guide is maintained independently of any company or vendor and therefore lives on a brand neutral site.  The Scrum Guide is translated and available in over 30 languages.  You can read and download the Scrum Guide here.
0
0
2
Imon Rashid
Jul 04, 2019
In Agile Discussions
From Scrum.org The 2019 Scrum Master Trends Report is based on a 2018 survey of over 2100 participants, with a focus on trends useful to both new and experienced Scrum Masters. The survey results reveal salary trends and agile adoption patterns, while also exploring gender equality within the Scrum Master role. The participants represent 87 different countries and come from all levels of experience. Download Link, https://scrumorg-website-prod.s3.amazonaws.com/drupal/2019-02/2019%20Scrum%20Master%20Trends%20%282019-02-06%29.pdf
0
0
1
Imon Rashid
Jul 04, 2019
In Agile Discussions
Steve denning Senior Contributor forbes.com It’s ironic that the idea of Agile—a central concept of competitiveness in the 21stCentury economy—which began in manufacturing in the early 1990s, took hold in software, not manufacturing. While manufacturers continued to focus on process consistency and efficiency, it was software developers who picked up the ball on Agile and ran with it. It was software developers who showed us in detail. Read more, https://www.forbes.com/sites/stevedenning/2012/09/24/how-manufacturing-can-learn-from-software-to-become-agile/#3946dd5dbd6b
0
1
2
Imon Rashid
Jul 04, 2019
In Business Analysis Forum
The agile method, a project management process that was used primarily for software development, is being adopted by an increasing number of companies. For example, since 2017, organizations’ use of agile techniques has grown from 50 percent to 71 percent. This is because agile project management methodologies increase the speed at which companies are able to respond to changing market trends, which helps them deliver exceptional value to customers. Read more : https://www.iiba.org/iiba-analyst-catalyst-blogs/3-major-trends-transforming-the-agile-method-in-2019/
0
0
0
Imon Rashid
Jul 04, 2019
In Business Analysis Forum
The very nature of our job implies that we are faced with a massive amount of information to process within a short period of time. This can easily result in a situation where the BA does not know where to start or stop. Over-analyzing occurs when the BA: Asks questions repeatedly to get clarification Seeks to confirm requirements again and again Stretches the analysis phase instead of approaching it iteratively Develops more artifacts and models than required. Click here to read more ,
0
0
2
Imon Rashid
Jul 04, 2019
In Business Analysis Forum
Business Analysts often have to work in the twin worlds of business and technology. These are 2 vast fields with multiple areas that the BA is expected to keep a tab on. Focusing on one aspect will be to the detriment of another.How does the BA with a technical background attain an acceptable level of competency in the business domain? How does the BA with a business background attain some level of competency in the technical domain? How does the BA keep up with expected changes when moving from a structured systems analysis & design environment to one based on object-oriented analysis and design? How does the BA manage the transition from a Waterfall to an Agile/Iterative methodology?  Solution: BAs should continually strive from day one, to learn about the business, the industry and available technology. Certifications in specialist areas can also increase the BA’s knowledge and command of the domain area. It’s not an easy journey and there’s no one path to getting the knowledge and skills you need. The challenge is real but can be surmounted with time, training and experience. For hiring companies, finding the right BA can also be challenging. An employee should not be thrust into the BA role without the right tools or training. BAs should be provided with the opportunity to nurture their skills and a clearly defined career path they can aspire towards. Read more, https://businessanalystlearnings.com/blog/2013/4/29/common-problems-faced-by-business-analysts
0
0
1
Imon Rashid
Jul 04, 2019
In Business Analysis Forum
On the flip side of information overload is a situation where stakeholders clearly do not want to share information with the business analyst. The BA should not take this personal. A stakeholder can be uncooperative for a number of reasons as illustrated below: Solution: I once worked with an uncooperative stakeholder who clearly didn’t want to share any information concerning how she did her work. She kept shifting the goal post and would not schedule a firm date to meet. After several unsuccessful attempts at getting her to commit to a date, I asked her for the templates/documents she made use of. She didn't have any choice but to share these documents, which contained most of the information I needed. If a stakeholder is uncooperative, altering your technique or approach might help. If you are able to establish rapport with stakeholders by identifying a common area of interest, they’re more likely to be open to sharing information. Begin each meeting or workshop session with an icebreaker to ensure that everyone is completely relaxed and clear on the objectives and benefits of the project. As time goes on, share success stories and anticipated benefits of the project with stakeholders to gain their trust, confidence and support. As a last resort, if the stakeholder is still not forthcoming, consider escalating to a higher authority who might be able to encourage the desired behaviour. Courtesy of, https://businessanalystlearnings.com/blog/2013/4/29/common-problems-faced-by-business-analysts
Uncooperative Stakeholders
 content media
0
0
2
Imon Rashid
Jul 04, 2019
In Business Analysis Forum
Business Analysis Planning and Monitoring: Describes the tasks used to organize and coordinate business analysis efforts.  Elicitation and Collaboration: Describes the tasks used to prepare for and conduct elicitation activities and confirm the results.  Requirements Life Cycle Management: Describes the tasks used to manage and maintain requirements and design information from inception to retirement.  Strategy Analysis: Describes the tasks used to identify the business need, address that need, and align the change strategy within the enterprise.  Requirements Analysis and Design Definition: Describes the tasks used to organize requirements, specify and model requirements and designs, validate and verify information, identify solution options, and estimate the potential value that could be realized.  Solution Evaluation: Describes the tasks used to assess the performance of and value delivered by a solution and to recommend improvements on increasing values. 
0
0
3
Imon Rashid
Jul 04, 2019
In Agile Forum
The Agile concept has come a long way over the past several years, taking its place as a firmly established set of software development methodologies. Yet Agile continues to evolve and mature, as experience leads to improvements, refinements, and new uses. Looking forward to 2020, Scott Ambler, vice president and chief scientist of disciplined Agile at the Project Management Institute (PMI), a global nonprofit professional organization for project management, expects Agile to grow even more rapidly. "Agile isn’t just a trend; it's here to stay, especially as we better learn how to effectively yield its benefits," he said. Read more, https://www.informationweek.com/strategic-cio/enterprise-agility/the-most-important-agile-trends-to-follow-in-2020/a/d-id/1336550
0
0
3

Imon Rashid

Admin
More actions