The goal of this article is to analyze common management pitfalls and offer possible solutions or approaches on how to best avoid them while providing the highest return of investment and value. First, there is a short description of the current state and the problem it is facing or trying to solve, after which follows a short management insight on how to approach it, managing the risks and providing action points and best practices.
The slipping deadline
Sometimes a deadline can start slipping through our hands due to not managing the risks properly. The highest probability and impact risk is always… people. Even if we put all the right processes and procedures in place, people are unpredictable and not managing them properly can wreak havoc on a time-sensitive product. Usually, if the team is small, the developers are not easily replaced or filled in in their absence, or there are simply not enough resources to cover for them. This risk is called “overlapping time off”. Another risk in managing a slipping deadline is how to balance between the time we have, the work that needs to be done, and the resources, without compromising the product quality. If we have a fixed deadline and we have planned our work accordingly yet we are falling behind, we need to balance this out.
We can always play with the triangle* (perhaps better depicted as a pyramid) of project management.
- The Project Manager can try to move the deadline
- The scope can be reduced (usually the preferred option)
- The quality should not be reduced because long-term this will cause many problems and will leave a lot of technical debt
- Some teams tend to skip writing unit tests, but again, this will just extend the fragility and rigidity of the application, as Robert Martin would argue in his book Clean Architecture*
Following the Project pyramid, we can play with Budget, Scope, and Time, some argue a Quality as the fourth corner or the central area between the tension of these three. I believe we are left with deploying an MVP solution that can satisfy the market needs at the beginning and continue developing the product by further prioritizing the needs of the end users.
- Work In Progress (WIP) - This is also a limitation, a constraint that the team needs to agree upon. Having too many items in the “WIP” state tends to defocus the sprint goal and disorient the team. Putting a hard limit can be done using the issue tracking system, but any mature team can know not to begin working on multiple items that have been committed to the sprint simultaneously
- Time In Progress (TIP) - This is an indicator of a slow or stuck ticket. These tickets should be our highest concern since they pose the highest risk. A ticket signaling this should be escalated and elevated to a blocker for the certain sprint, and sometimes more developers or even the whole team should stop what they are doing and address this issue
- Throughput - This is our completion rate, how much it goes in against how much it comes out, i.e., how much has been processed. This signal can detect and alarm us early on when we have a scope creep, or we deliver more than we committed. Sometimes this is not an indication of a creep, rather a lack of proper planning at the beginning of the sprint. Scrum allows us to start a sprint without having a complete picture of what it contains, granted that it always follows our sprint goal. Adding items that do follow the sprint goal, do not belong to the sprint, therefore are creeping our scope
The Guesstimate - noun /ˈɡɛstɪmət/ an estimate based on a mixture of guesswork and calculation
Is estimating necessary and if so, why do we estimate in story points? Why don’t we just go along with the requirements, designs, implementation, testing, and deployment and see how long it takes us, after all, rushing will not provide a high-quality solution. But management always insists on estimating, and since man-days was the anti-pattern of the 20th century, we now introduce the anti-pattern of the 21st, the trending story points. Is this really the case, and can we go by without estimations, or as the developers like to call them – guesstimations? Why don’t we just translate man-days into, more flexible, Fibonacci scaled numbering and be done with it. The managers will be happy, the client will be happy, and the developers will be relieved.
What about estimating niche cases that were previously unknown or we don’t have experience estimating? For example, documentation. How can we estimate how long it will take us to document something that we are not very familiar with, and we don’t know what type of documentation it will be needed? In that case, isn’t it better if we just timebox the task and say “you will get 5 story points of documentation” if that is what the time or budget allows?
Solution: The benefits story points offer as pure measure of size are compelling. The story points help promote cross-functional team behavior and that is a huge advantage. Shifting a team’s thinking from “my part will take three ideal days, and your part will take two ideal days, so the total is five ideal days” is very different from “overall, this story seems about the same size as that one, so let us call it five story points also.” Another benefit is that a story point to me can be the same as a story point to you, while the same may not be true of an ideal day. Two developers of different skill or experience can agree on the size of something while disagreeing about how long it will take to do. The shortcomings of story points are indeed short. Yes, it is easier to get started with ideal days. However, the discomfort of working with nebulous story points is short lived. Ideal days are easier to explain to those outside the team, but we probably should not choose based on how hard it will be to explain to outsiders.
Of course, we guess at some point or another, we must start with guesses, and as time goes on and we get a better product knowledge, the guessing game is moving into an actual estimation. We define a “baseline” that everyone is comfortable with, a task or a story that everyone agrees immediately that falls into the category of 2 story points. Of course, no two tasks are the same and even compared to this one, the one we are now trying to estimate is perhaps 2.2 relative. Okay, so what about if it is 2.5 or above, do we round it up or round it down? The main goal of working agile is to speed up, but naturally not forcefully. If we try to bloat up story points, we are only making a smokescreen and we are not actually going faster. So, the desirable approach is to round it down to free up capacity to take more work. Maybe in the beginning, the team will be skeptical and scared to do so, but it takes some courage to be continuously better. That’s why we are doing agile, it promotes this thinking and encourages it, so let’s exploit it. So now, not only are we trying to get a higher velocity each sprint, we are also maximizing the available capacity, as Jeff Sutherlands argues, twice the value for half the time*, but now even more daring, 4 times the value for half the time.
Estimating fringe cases should follow the same rules. Even if we are working on an issue rarely, having the experience and knowledge for such cases would benefit the team, and those can be obtained only through practice. One should never resort to estimation regression, or back to man-days estimations. Also, if the time budget allows, we should avoid “n story points worth of feature”. Once down this road it’s hard to get off from it. Next thing you know, we start to put “n story worth of effort” on every complex thing that we would like to avoid in any way possible. I tried my best. It is not a way that we write down our sprint goals, rather we reach milestones, finish epics, and deploy features that are a “usable increment” each sprint as defined by the Scrum guide.
As a finishing thought, estimations are a bridge between the development team and the product team. This is the language for communicating or translating requirements and designs to tasks, features, and epics, creating roadmaps and delivery plans, within a reasonable allotted time and budget (again the project pyramid creeps in). This is the way that both sides can commit to a joint effort, through transparency and trust, forming strong bonds of collaboration that can result in lengthy and worthy partnerships, for the endgame of a continuous raise of technological, ethical, and humanitarian standards.
[1*] https://en.wikipedia.org/wiki/Project_management_triangle [2*] https://www.goodreads.com/en/book/show/18043011-clean-architecture [3*] https://www.goodreads.com/en/book/show/19288230-scrum
About the author
Borjan Petreski is a Service Delivery Manager working in the engineering hub in Skopje.
Borjan is a versatile Service Delivery Manager and Scrum Master who has experience working within different agile frameworks, such as Scrum, Kanban, or "Scrumfall." Borjan managed multiple projects and products simultaneously with varying stakeholders and SMEs from various fields.
Read the second part of the of the project management pitfall series here.
-1.png&w=3840&q=50)
