I will not make the deadline. This is one of the hardest realities in project management. The deadline is approaching, and your chances of meeting it are low. What do you do in this situation? Hope for the best? Take the risk and go for it? Well, the answer is complex, but I keep the following in mind. β β Keep sustainable pace When working in an agile way, we want to keep a sustainable pace. We try to keep this pace by working with the concept that when something is fixed, other things are flexible. Let me give you an example: We have scope, time, and budget. Scope is the size of the work needed to finish a project. Time speaks for itself. I don't want to get into time relativity theory. Let's keep it simple π. The budget is the money we have. This can translate into the number of people working on the project, licensing, etc.
β β Fixed scope and time π«₯ What now? Now, this is the optimal state. But what do you do when scope and time are fixed? If you know this beforehand, you need to put in place a projection of the project's progress. Why, you ask? Well, it is fairly simple. It can indicate earlier if you will finish the amount of work by the deadline. This helps you anticipate this situation earlier and can ensure that you still have time to onboard new team members. I just mentioned onboarding new team members. But this is with a big BUT. Putting more people on a project does not mean they will go faster. There is a point of diminishing returns where it will even slow down the team. So be careful when taking this approach. β Let's take this example. Here, we have the progress from a six-week fictional project with a fixed scope and time. After the first week, we're off track. We can already raise this issue with our stakeholders by showing this chart. In week 2, the team worked hard and made better progress, but we are still not on track. In week 3, we are still not on track, and we raised the issue again with management. Now, the deadline and the scope cannot be altered, so we needed to use our last and most risky card in the deck. Add more people to the project. We freed up two experts from another team to jump in to reduce the risk of slowing down. As the experts were very familiar with the topic, they didn't need any onboarding and helped finish the project before the deadline. I hope you also noticed we used two experts from another team. So the other team lost two experts and probably slowed down in their speed. Not optimal. β β It happens every few months, Jelmar. Help me! If this happens every few months there is probably something wrong in the way of working. A good retrospective to find the root cause can be a good start. You can find my favorite templates in my blog. Looking for help from the outside could also be an option. Someone with a fresh perspective on the situation. If you want a free sparring session, you can book a call with me. β I hope I helped you today. Take care! β Jelmar β PS. If you have any feedback, feel free to reply to this email. It's highly appreciated β€οΈ. |
I write about my Agile learning journey. Writing about the challenges I face and how I navigate this uncertain world showing that work can be different.
Sprint Reviews are an essential part of the Agile development process, allowing teams to showcase their progress and gather valuable feedback from stakeholders. However, traditional Sprint Reviews can sometimes become repetitive and fail to capture the true essence of collaboration and innovation. Here are my 10 experiments you can try for your next Sprint Review! 1οΈβ£ Experiment number 1 - The raw and dirty. If you spend a lot of time preparing the slides, doing demos, and doing dry runs, Try...
How do you know if your meeting was impactful? My favorite way is to do a ROTI (Return On Time Invested) score. Here's how you can do a ROTI score: π Ask everyone to hold up their hand in a fist. Count down from 3οΈβ£2οΈβ£1οΈβ£. Everyone gives a score from πto π. π being the highest. π being the lowest. Here's what the result of a ROTI exercise could look like: π€ππβππ Then, do a round table to ask why they chose a particular score. π₯ BAM! π₯ You have feedback on your meeting you can take into...
Liked, Learned, Lacked, Longed for: Your guide to the 4L Retrospective. What is the 4 ls retrospective technique? The 4 Ls retrospective stands for Liked, Learned, Lacked, and Longed for. Itβs an easy-to-use template you can run with your agile teams. The goal is to gather feedback and make necessary adjustments as a team. The 4 sections of the retrospective prompts each team member to gather feedback. This conversation-focused retrospective helps you to bring the team on the same page to...