Como você pode ajudar sua equipe a gerenciar o tempo ao trabalhar em projetos com alta incerteza?

While working on Agile one should assess the type of uncertainty (technical, resource, time, requirement, financial etc.) and based on that following can help: - Make proper backlogs and prioritize the work. - Select best team members for quick execution. - Assess the progress very often - Provide proper & timely feedback - Share progress with team and motivate them - Bound time for tasks - Assess and manage risks

Currently, I am also working on a project which has high uncertainty. In my opinion, the best way to deal is to have; 1. Frequent collaboration between the Scrum team, Product Owner, and Stakeholders. 2. Be flexible with planning as priority will keep on changing. 3. Focus more on critical aspects first. 4. Schedule regular review meetings for fast feedback. 5. Incorporate buffer time into the project schedule to account for unexpected challenges or changes.

In projects with high uncertainty, embrace Agile methodologies like Scrum, XP, Kanban or DSDM. Break the project into short sprints, estimate the efforts, set achievable goals and regularly reassess priorities. Encourage open communication, frequent inspection, adaptability and quick feedback loops to enhance team responsiveness to changing circumstances.

Few strategies that help the team in high uncertainty projects are: Having a clear and regular communication and be flexible with planning. For product development having an iterative prototyping and receiving feedback are crucial.

Help your team manage time in projects with high uncertainty by emphasizing adaptability and flexibility. Encourage iterative planning and regular reassessment of priorities. Foster open communication to address uncertainties promptly and collaboratively. Implement timeboxing for tasks to maintain a sense of control and progress. Emphasize a mindset that views uncertainty as an opportunity for learning and improvement, promoting a proactive and resilient approach to time management.

One of the most powerful ways to prioritise your work is to limit work in progress (WIP). This is an enabling constraint as it ensures we have a focus on our most valuable work rather than trying to achieve many things at once. Juggling too much work will often limit the delivery of value. Limiting WIP can work well with time boxes (another enabling constraint) as time boxes give us an alternative perspective - if we commit to only do two things at one time as a team, and we commit to doing something valuable within X amount of time, what do we believe that we can complete? This approach to work still doesn’t guarantee value delivery, but it enables us to have conversations that generate clarity and alignment without undermining autonomy.

I recently encountered a challenging situation where we initiated a project without a deadline.However, when a high-priority project surfaced, we needed to establish a firm deadline for the initial project Prioritized backlogs, focusing on completing the essential happy path flow first. Assigned priorities (high to low) to each ticket under the epics of the project. Created a Confluence page to track the next two sprints, refining and pointing tickets to estimate capacity and time needed for completion.Had a weekly working sessions with the development team to address requirements and blockers.Ultimately, we set a hard deadline for QA and the sandbox environment, allowing for a two-week buffer to conduct thorough testing in the prod env.

→ Only focus on 1 task → Inspect and validate often → Tackle the most uncertain part first → Shorten feedback loop with stakeholders

Know how to escalate! I used to fear the concept, now it’s more gentle than a soothing embrace. Proper escalation helps. Learning when to leverage escalations, and how to do so while keeping your collaborators informed and comfortable, is an insane balancing act. Nonetheless, if you set and communicate clear boundaries, proactively, time comes to be the decision maker, not you.

Proper task priority before the sprint will help the team to stay focused and not deviate during a sprint. Proper synchronisation between QA and Dev plays an important role and helps the team to minimise the wasted time. Also the proper estimate of the task considering all the uncertainty in mind and QA effort also needs to be considered.

Minimum Viable Product offers flexibility to build and iterate or pivot the product vision as needed based on customer needs. Instead of Spending all of the resources ahead of time to build the best product, it is best to test the waters and check if the product is best serving the needs of the business and the customer.

MVP actually is not the best approach - a Minimum Viable Product is something that customers might not actually love. Aim for a product that will actually solve a PROBLEM and DELIVER VALUE rather than be only the 'bare minimum'. Pareto rule is actually something that usually (more or less) works - remember that not everything is important and usually only a small portion of work brings the most value. I like to explain it in terms of Sprint Goal where actually it's the highest value that we are delivering in each Sprint, but that doesn't mean that this goal should be 'complete all the items in the Sprint' (... for several reasons that's not a good goal and I have only 750 chars so I'm not gonna write why it's not :D) .

MVP- Most aVoided aPproach. I’ve never liked the MVP approach. Prototype to product, is much better. If you use this approach you will quickly learn the wins in your solution.

Instead of investing all resources upfront, the team can develop a basic version of the product, gather insights, and make necessary changes. This flexible method ensures that the product better meets the needs of both the business and its customers.

Scrum consists of events that provide a lot of communication and feedback loops - each and every event helps us to deal with uncertainty, risks, and problems. That's why it's super important to have them facilitated in an efficient way that will actually bring value. A great example will be daily scrum where we are synchronising between developers inside the team - do we see any risk in not delivering Sprint Goal? How should we react to that? Is there any team member that needs some help or support? Do we see some improvement that we can implement right away to make our life easier/improve the product? DO NOT avoid those events and DO NOT make them only for the sake of 'doing them'. Do them wisely and so that they will be valuable.

These might be helpful especially in this kind of project: 1. Ensure everyone in the team could read the latest information easily in a specific source (not scattered around). 2. The information is also documented in a way that is easy for everyone to read. 3. All questions have an owner to answer and the resolved question should clearly state the answer. 4. Code comments, test documents, even test case descriptions are clear.

Weekly status updates outlining Progress Made, Goals, Roadblocks, and team shout outs help keep everyone motivated and engaged. Clear project documentation through a dedicated chat channel, whiteboard, and wiki is also invaluable!

If you can't make more frequent meeting updates, make sure there is a system for keeping everyone on the loop: you do not want to leave a person behind, doing unnecessary work and adding to their personal uncertainty.

Dealing with uncertainty is best handled with everyone’s hand on 1 task. This technique is known as team swarming. → Team focuses on 1 problem. → Discoveries are accelerated. → Problem gets resolved quicker.

An unprotected environment is challenging for the team. It is good to have a buffer in the Sprint for unpredicted surprises. In other words, dedicate some capacity for unpredicted things. In an unprecedented environment, it is good to analyse and minimise surprises.

I am currently working on a project where our team is unfamiliar with the implementation, testing, deployment, and training, hence the many uncertainties. The following has helped keep the project on track: 1. Took a phased approach by implementing the features in phases, allowing us to improve our delivery continuously 2. Establish key milestones with timelines and owners, escalate when milestones are missed, and put actions to resolve it 3. Daily Stand-ups to keep track of the active sprint tasks 4. KT Sessions between our team and the consultants implementing to ensure we can support the new tool 5. Bi-weekly sessions to review priorities and opportunities to re-prioritize new item