Capricious Scrum. A shortlist of conditions for Scrum to be able to bring something useful

What is Scrum framework? It’s the framework which can be used to achieve business goals via implementing a solution by a team, in a case when one doesn’t have a fixed plan of how to achieve it. Supposedly, this plan should be discovered via the test-and-feedback approach during the implementation. This is a powerful framework with great results if it’s used in a proper manner, in a proper team, in the right company. 

This article is describing the points which should be considered as critical must-have, from business, team and personal sides, for being able to use Scrum framework effectively. These points are not related to Scrum framework itself and can be applied to any management framework, which requires business results and relying on the implementation team to find a way of how to do it. The focus of this article is mostly about restrictions which should be removed or adjusted for Scrum team, to function effectively and being able to find the way to achieve the goal implementation in the best way. 

A. Company environment

It’s the most critical and underrated point. Scrum way of doing things can’t exist in a company that is implementing chaotic, encouraging micromanagement practices, or not suitable for self-organisation on a team level. The list of requirements that must-have been implemented and accepted on a company level for Scrum approach to existing includes:

1. The ability for team members to forecast their middle-term involvement in the project, without forcing them to change the focus and the project.

Why? Because each member of the team should be able to forecast their work, potential and sequential plan for the implementation of the solution. Inability to finish the started work is a point of frustration. Ticket-to-ticket based without ownership of the solution is better being implemented via other frameworks.

2. Ability to give a concrete, detailed and measurable business goal and task

Why? Because the work without a goal is useless to work and should be eliminated as a concept. The team’s reason for existing is to accomplish something business-valuable. It should be a particular description of how the stakeholders define if the goal is achieved or not. 

3. Ability to give detailed feedback over achieved goals, milestones or resolution of tasks. The feedback time shouldn’t be longer than the length of 2 sprints. 

Why? Because there is no defined way to achieve a mid-term goal. The concept of iterative development based on the assumptions the team is creating at the start of implementing the solution, and confirmation of those assumptions – either positive or negative. Business feedback, how we are naming it. If the team can’t get the feedback fast enough or can’t get it at all – the team can’t be sure that it’s doing the right thing. If the feedback cycle is longer than 2 sprints, it’s better to switch to other methods of work relying on detailed analysis and planning.

4. Ability to not to change the short-term goal.

Why? Because mostly the short-term goals are ‘in progress’ of resolution and not accomplished yet. And changing them makes no sense because it will not be confirmed yet if the already implemented steps are useful or useless. It’s better to release and collect feedback and use the collected data/experience in the next iteration.

5. Ability to choose the way to achieve the goal.

Why? Because otherwise, with external management, it will be longer, harder, and will require more effort from the team. If the way is already known, an old-school project-management approach to managing this project will be the best choice to use.

6. Ability to use the external experience and resources in the implementation.

Why? It will create external dependencies which are not a very good thing to have – for sure. But it will bring more benefits in the long term: the ability to work in a common environment, not be a black sheep in the company’s architecture. And the usage of external resources and experience will help to achieve the goal faster and reduce the potential errors of the solution.

7. Ability to share internal team resources for external requests.

Why? Because sharing is caring. It will help team members to understand how the external team works, know more about business processes in the company, and exchange experience. This experience will return back to the team and be shared across the team members, increasing the whole team experience. 

B. Team composition and experience

Scrum is about creativity and achieving business goals in the best and adaptive manner. The team should have a proper composition to be able to work together, and implement the solution in a proper way, and maintain it in the long term. Here is the list of traits the team should have to be able to do it:

1. At least one member of the development team should have a team lead experience, product or project manager.

Why? Because this experience will help to forecast potential problems with implementation, coordination, architecture and dependencies. Will help to solve problems before they happen. 

2. All team members should know the traits and experience of other team members.

Why? Because it will give the ability to distribute the tasks between the members of the group optimally. It will reduce the frustration, and friction, and will increase the speed of sharing the experience between team members. Experience is a part of dependencies list the team is dealing with, if the team doesn’t have suitable experience of implementing the goal, this dependency should be resolved on a management level.

3. The previous working environment of each team member should be a consideration for proper composition.

Why? Because of the difference of pace, maintainability requirements and dependencies resolution, the way of working can bring a strong desynchronisation between the members of the team. It can lead to an inability to work together and achieve something. Working in a startup and a bank could bring a misunderstanding of possible expectations of other members, way of implementation, directly undefined requirements and an implementation forecast time. 

4. Personal professional experience is not the main consideration if the team member has other traits.

Why? Because if the person wants to learn, and has an ability to work in a team, the experience will come quick enough to be useful. Using technical and sanity testing will help to fix implementation bugs, and personal feedback on a team level will help to keep the whole quality of solution.

5.  More than 1/2 of the development team should have experience of being a part of a development team with > 4 people. At least 2/3 of the dev team should have experience of implementing the same feature with someone else

Why? Because this experience will help to understand the pros and contras for each member better, show the ability to communicate with other team members and the ability to find a consensus for implementation and maintainability for the code. Communication and coordination are the keys to success.

6. More than 1/2 of the team should have some experience in QA and implementation of testing practices.

Why? Because no one wants to get an unmaintainable piece of… code in production as a result of teamwork. This experience will help members to understand the value of tests for the deliverable result, and use ‘testable’ as a part of acceptance criteria.

7. The team should use a typical approach of code review for PR with confirmation of 2 people.

Why? Because this will help to reduce technical debt in the long term and ability to share the way of implementation (experience) between team members.

8. Each of the development team members should have the ability to understand roughly the whole architecture of the solution. Which part is changing, what should be an input and output, and how it will possibly influence the other parts of the solution.

Why? This will help to understand the dependencies, increase the maintainability of the solution, and forecast potential issues beforehand.

9. Each team member should understand and value the short, middle and long term goals. Each team member should be able to understand and explain what business problem will be solved with each particular task and why it should be solved now and understand why the one has bigger priority over another.

Why? Because the ability to answer the ‘why’ and ‘why now’ questions is critical for using Scrum in the software development process. If the goal is not defined or known, that means that the result of work can be unpredictable and, often, unusable.

10. The team should understand that the operation of the team is the company’s costs. The team is a part of bigger business processes, which mostly gives an income, a reason and an ability for the team to exist. That ‘costs’ can be increased and reduced, as well.

Why? Firstly, to not feel themselves working in a vacuum environment, without any business outcome expectations. Secondly – the ability to understand that everything can be extended (team, resources, infrastructure) if the reason to do it is good enough. 

C. Personal experience and traits

These are the basic requirements to be a part of the Scrum team and work with other members of the team without being a drag:

1. Each team member should have a passion to create something new. 

Why? Because Scrum is a good framework to support people in invention and creation processes. If the person doesn’t want to invent or create – it’s better not to include this person as a member of the team.

2. Self-organisation and self-motivation.

Why? Because Scrum has strict iteration rules, which bring some kind of control. But the framework is not offering any way of stimulating or motivating the personal outcome, and don’t propose the way of achieving the goal outside the self-organisation on a personal level. Being a part of the scrum process is not for everyone. Scrum is not suited for every project and for every person.

3. Being able to use logic. The team member should have an ability to decompose the complex task to single stages. And each stage on primitive steps for implementation. 

Why? Because the ability to decompose tasks is crucial for understanding ‘where we are now’ and ‘what else is left to do’. This influences the ability of self-organisation and forecasting potential issues. NB: the consideration here is not a software design, but about the logic of the implementation.

4. Being able to understand, describe and demonstrate the potential bottlenecks of the implementation.

Why? This will demonstrate the professional quality of the implementation and a deep understanding of why the solution is implemented this way. This will help to maintain the solution, understand its limits, and extend the quality of testing

5. Understand the value of maintainability of the implementation.

Why? Because of the ROI concept. Sometimes, the speed of getting the results with the degradation of the ‘beauty’ of the solution, is more valuable than getting the best implementation but ‘sometimes later’. And vice versa, when the properly designed and tested architecture will bring the best value. The trait of not to suffer from ‘not invented here’ syndrome is the part of understanding the maintainability value.

The list is not full. Any bad implementation or useless results can be blamed by using the wrong framework. But its not always the framework’s fault. Any instrument requires some experience, education, the proper environment, and effort from everyone involved. This list can help to understand if the conditions are ok to consider if Scrum is a framework to use in this particular case, or better to look for another one.

Task prioritization based on business value

The time is limited for every person. Per 1 hour the employee can do a limited amount of work which leads to a limited number of the produced value. And in most situations, the number of tasks is much bigger than available time. 

That leads us to the idea that we need to have a plan and prioritisation for task flow: which tasks should be executed during a particular time frame and what should be the order for these tasks. This prioritisation should be based on the idea of optimizing business value outcome over the consumed time.

However, PM or developers are always struggling about giving priorities for the different tasks due to timeline limit, because it’s not always clear enough which task is more valuable and why. The simple table below should help to solve this problem:

Here, you can see the types of tasks and the groups of people which the resolution of this task is affected. On the crossing of rows and columns, you are seeing the number of points which represent this task.

I.e. if solving the technical bug will bring happiness for 1 person, it will give us 5 points, or if the new business-related solution was required for 1 team, its 30 points.

If you have a basic ETA in hours for the task, you can easily calculate the priority grade for the task, multiplying the number of hours by the number of points in the table:

I.e. if solving the technical bug will bring happiness for 1 person which will take 10 hours to resolve will give us the value of 1×10 = 10, and if the implementation for the new business-related solution for 1 team will take 0.5 hours, that will give 30 x 0.5 = 15 points, etc..

The resulting order is based on a basic principle: the task should be ordered by its points – the less is the number of points, the higher priority this task should get. The particular bond could be different, but as an example, this one can be used: for 0-49 is the top priority, 50-500 is the average priority, and > 500 points tasks will get the low priority

Business idea for this gradation is to speed up the value outcome per hour. As the bigger amount of people which are requiring the resolution for this task, and the lower effort it takes to resolve it – the bigger is the priority for the task.