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.