I was having a slice of pizza at a well-known restaurant at Neal’s Yard, I was sitting there with one of the owners of a startup in London I had invested in and wanted to know more about what pain points the owners were running into when executing projects with a very limited budget, my goal was to understand how could Agile Methodologies help them in executing better and with a constrained budget and a unstructured team, whilst achieving their goals. They have already raised some funds from small investors and they weren’t in a position to increase substantially their budget via fundraising in order to bring in senior professionals to execute projects, but without seniority they felt these initiatives were becoming too big to handle, but even before handling, they were becoming too big to structure which meant team members had a hard time understanding where to start and how to follow when something got blocked, they weren’t being able to dedicate time to support their teams and therefore the lack of guidance was affecting the timelines.
I started asking about these big projects and how big they were, after all, it was a very small startup, the problem wasn’t the projects being too big, but that the team lack the guidance on how to break the problem in smaller pieces and how to prioritize these pieces in order to start gaining momentum, this was due to the lack of experience in these kind of projects combined with a very busy management. I had seen this before, whenever I had seen the lack of guidance there was a risk of team members being procrastinating to no fault of their own, a risk of problems not being structured with a growth mentality where bigger problems are located at the beginning impeding the team to gain momentum. I then knew that one of my main goals in this book was to leverage this methodology to reduce procrastination, to help ourselves to order problems in a sequence that goes from low effort to high effort so that it becomes easier to start than to stop, since when you have gained momentum, when you are in it to a 100% is way difficult to leave things incomplete. This is also one of the roles a Scrum Master should assume beyond its traditional role, guiding the Product Owner in structuring the User Stories so that the team gains momentum quickly and the stories are easy to digest and complete, this way we will improve the way our people come to work.
How to make it harder to stop than to start?
- Assess Effort
- Assess Impact/Importance
- Assess Dependencies
- Assess Impact on Stakeholder Relations
- Assess Urgency
Using a point system and a matrixial approach we should be able to order the tasks from high priority to low priority, depending on the sum, but also based on the matrix evaluation, we will know what the immediate next step is. Ordering them from high to low will allow you to get a snapshot on your priorities and since this is not scientific, once you have been able to draft an initial approach you should feel free to promote or demote any task beyond their grade, this will only provide an initial structure subject to minor modifications, your gut is also an important variable, it is just one I cannot measure here.
Start by making a non-scientific assessment on these, you just need to rank them as high or low and then user these matrixes and their scoring system to not only prioritize but to take action.
Matrix 1: Effort-Impact
- If a task is Low Impact and High effort, you might want to break it into smaller pieces and check if any of those pieces can be deprioritized.
- If a task is Low Impact and Low Effort, you should evaluate if you can remove the task from the Product Backlog or slip at the end/bottom of a Sprint Plan but with less priority.
- If a task is High Impact and High Effort, you should break it into smaller pieces, evaluate different team members whose combined skills could allow to share the effort of these tasks.
- If a task is High Impact and Low Effort, just go for it!
Matrix 2: Dependency and Stakeholder Impact
- If a task is Low Impact on SH and High Dependency, you should push it backwards in the Sprint Planning or even in the Product Backlog, depending on other variables like the overall impact and not only impact on stakeholders.
- If a task is Low Impact on SH and Low Dependency, based on the overall impact you could move it forward or backward, since there is no dependency it allows the team to work on it.
- If a task is High Impact on SH and High Dependency, as Scrum Master you need to push for the necessary meetings to happen as soon as possible, guide the Product Owner on who to reach out and how to structure the meeting so that the team obtains what is needed on time. This is a Servant Leadership approach, which is becoming a crucial skill for leaders nowadays.
- If a task is High Impact on SH and Low Dependency, go for it there is nothing stopping you, it helps the brand of the team to collaborate with other stakeholders and allows the team to feel valued.
With all the above plus the actions generated by each matrix you should feel comfortable in playing around with tasks so that an effective configuration of User Stories allows your team to gain momentum and speed up the Sprint, making it hard to procrastinate and easy to move forward. The same way you are kind to your team you should be kind to yourself, do this in a personal project that you have been procrastinating for a while, break it into smaller pieces, allocate a few hours per week and create a smart configuration of tasks starting with those that require less effort and do have some impact, you might find out that you were procrastinating because of the structure and magnitude of the problems and not because you were being lazy. The Scrum Master can use this as a guide to take action whenever it feels right based on these guidelines, one of the main responsibilities of a Scrum Master is to remove any impediments that the team has but, by using this approach not only we are removing impediments but also dynamizing our relation between the Team, Product Owner and stakeholders.