99% of those dissatisfied with the results of their project are sure that they know who is to blame. Owners scold lazy contractors, programmers, stupid customers, etc. Who is right? All are mistaken. Each of us believes that only he knows how to react objectively to a situation, while the behavior of the others is only motivated by their personal characteristics.
Blame is generally silly. Do not look for bad people, look for harmful systems — systems that provoke the creation of bad processes and reward bad work. The scrum is the technique, where instead of looking for the guilty, it tries to investigate the system that has become the source of the error and fix it.
Scrum is based on a simple idea — whenever a project is started, nothing prevents you from regularly checking the progress of work and consistently finding out:
- Can your team handle the tasks;
- Are you moving in the right direction;
- Do your team create exactly what the customer actually wants.
The process described by Jeff Sutherland is called "check and adapt". In other words, at any suitable moment and as often as possible you should interrupt the work, review what has already been done, and find out whether everything is done correctly, what is needed, and how to do it better.
How to do it? The author of the scrum technique offers a list of 11 items.
1. Pick a Product Owner
Jeff Sutherland calls the owner of the product not the main investor, but a specialist, professional, who has the vision of what your team is going to do/create/achieve. He makes the final decisions, is always available for the team and ready to answer questions. It is he who takes into account the risks and benefits: what needs to be done, what can be done to maximize the benefits of the product and what will inspire the whole team. It is the product owner who is responsible for the OODA cycle (an abbreviation for observing, orienting, deciding, acting).
This concept was created by military pilot John Boyd. Sometime in the skies over North Korea, the work on OODA principles helped a wider F-86 review to gain superiority over the more advanced maneuverability and weapons of the MIG-15. The one who owns the OODA is able to get inside the opponent’s competitor’s decision-making cycle. So what is it about?
Observe — means to see the situation clearly as events unfold. And somehow covert these events into the data. Boyd recommends going beyond your own "I" to see the picture as a whole, and not only from your own point of view.
Orient — it is not only about the place where you are; it’s also a variety of situations that you can see — a menu of opportunities that you create for yourself. So, here you transform the findings from the first step, understand and analyze it.
Decide — here you are choosing the solution from the options based on the plan that was developed on the orient stage.
Act — speaks for itself.
Then the cycle repeats: you need to start watching again — the results of your own actions, the actions of your opponents, competitors or the market reaction. Then set a new plan or goal where you need to go and choose the way you will be reaching that goal and act by your plan.
The scrum methodology, with the addition of the notion "increment of work" or "sprint" to this model, allows the Product Owner to see how much value this increment creates and how clients react to it. Based on the information received, he can change the tasks or its priorities for the next sprint. In this way, a constant feedback loop is established, which speeds up the process of innovation and adaptation and allows the product owner to measure the amount of added value.
2. Build a team
Who are the people who have the job to do? Professionals in the team must have all the skills and knowledge necessary to bring the product owner’s idea to life. A gold standard of scrum is to have from 3 to 9 people in one cross-functional team. I think the ideal size is 6 people including the Scrum Master — large enough to ensure adequate skill sets, but small enough to collaborate easily.
The main attributes of the team:
- motivation to create a product;
- ability to create a product;
- autonomy, the freedom to do your job in the way that team consider the best;
- focusing on the customer and their needs;
3. Pick a Scrum Master
It is critical that someone ask difficult questions. You need a character like Shakespeare's wise jester. This is the person who follows the project, ensures that all daily scrum meetings are held and it helps the team to eliminate obstacles. Most often, the scrum master is a project manager. But it's always not a good idea to cope Scrum master with Product Owner, they have different responsibilities and conflicts of interest may arise.
4. Create a Product Backlog
Product backlog — this is a list of absolutely all requirements for the product placed by their priority. A backlog exists and evolves throughout the whole life of the product, which serves as a guide. The product backlog is the only and unambiguous concept of "everything that a team can, in principle, do in order of priority".
There can be only one product backlog. This means that the product owner must make priority decisions based on the full range of tasks. The product owner must talk with all interested people and the team to ensure full feedback and display all the requirements and wishes of the client in the backlog.
5. Specify and estimate the product backlog
It is very important that team members, who will perform tasks from the backlog, estimate how much effort this will take. In terms of Scrum, it called Grooming.
The team members should look at each task and determine:
- Whether it is feasible at all.
- Is there enough information to complete the task?
- Is it understandable enough to be evaluated?
- Is there a common understanding of what standards and criteria it must meet to be fulfilled?
- Does it create real value?
It must be possible to demonstrate the result of each task. Do not estimate backlog tasks in hours or money — people do poorly with this. Evaluate in relative sizes: "small", "medium", "large". It is better to use the Fibonacci sequence and assign the number of points to each task: 1, 2, 3, 5, 8, 13, 21. Of course, nothing will be exactly five, or eight, or thirteen, but by applying these numbers, you can collect opinions on the scale of the problem in conditions when everyone uses approximately one abstract measurement system — this way team will quickly reach an agreement. But it is also possible to measure a task in units of time: hours, days, weeks. Check out my post about how to estimate time properly. Thus, it turns out that a collective task assessment gives us much more accurate results than an individual one and may raise some important questions to the Product Owner.
6. Plan your sprint
Sprint is the time interval for which the team creates at least a minimally functioning part of the product. It then can be immediately shown to the client. Each sprint is preceded by a meeting where the team, scrum master and product owner plan tasks for the sprint.
Sprints always have a fixed duration, which must be less than a month. As a rule, choose sprints with a length of one or two weeks(questionable, but for me, it works best). The team looks to the top of the backlog and estimates the number of tasks that can be done for the next sprint. If the team has already done a couple of sprints, it should take into account the number of points that were in the last sprint. Scrum master and the team must try to increase the number of points taken in each sprint.
Sprint planning is another opportunity for the product owner and team to make sure that everyone understands exactly how the implementation of the tasks goes into the final product. At this meeting, everyone must agree on the goal of the sprint and determine what should be done for the sprint.
The main rule of scrum — if the team agreed on a certain number of tasks that need to be completed in one sprint, then new ones can no longer be added.
7. Make workflow transparent
It's all about building the right system. It is necessary to give people the freedom, respect and the right to do their own business on their own. Heads of organizations, where it is common to keep everything secret, do not want ordinary employees, leading experts, even managers close to the top of the hierarchy — know what is happening now, what has already been done and in what time frame. Any information and knowledge are not subject to share since hidden information is the only guarantee of their power(at least they think so). They pursue only their own interests, which most often do not help a product or company.
Here we are dealing with the type of thinking responsible for such a phenomenon as the management failure, which became widespread. Transparency of all actions and processes ensures the earliest achievement of the goal.
The most common way to achieve this is to have a scrum board with columns: "Todo or backlog", "In progress", "Done". Stickers are requirements that need to be implemented the command moves the stickers from one column to another as they are completed.
Another way to make the work transparent is to create a Burn down chart. On one axis place the number of points that the team took in this sprint, on the other — the number of days. Every day the Scrum master counts the number of points for the tasks performed and reflects this in the chart. Ideally, by the end of the sprint, this plot should meet zero. By the way, another plus of transparency lies in the fact that team members can see the number of tasks of each other and promptly help those who lag behind in order to achieve the goals set in the sprint.
8. Daily meeting or daily scrum
This is the pulse of the whole scrum process. Every day at the same time for no more than fifteen minutes the team and the Scrum master meet and give answers to three simple questions:
- What did you do yesterday to help the team finish the sprint?
- What will you do today to help the team finish the sprint?
- What obstacles and problems do you have that blocks you from the task completion?
That's all. All meeting. If it takes more than fifteen minutes, then you are doing something wrong. The essence of such meetings is that the whole team knows exactly what task at what stage is in the current sprint.
Will all tasks be completed on time? Is it possible to help other team members to overcome obstacles? Nobody gives tasks — the team is independent and decides everything itself. No one writes detailed reports to management, there is no point in this.
9. Demo to customer
It is an open meeting where the team demonstrates what was done during the sprint. The whole team with the product owner, scrum master, team and any interested parties: customer, management representatives, potential consumers are presented at this meeting. The team must demonstrate only what meets the definition of "Done"(it's criteria that determine the degree of readiness of an element from the user's wish log — this definition should be described and agreed by the team). What is completely and finally ready. It can be a completely completed product or its separate finished function.
Not everything can be done? This means that too many tasks were selected for this sprint.
10. Retrospective meeting
After the team has shown what it has done for the last sprint and what can be handed over to the client to receive feedback, everyone sits down and discusses the sprint. What went well? What could be done better? What was totally wrong? What improvement can the team implement immediately?
For the meeting to be effective, Scrum master and the team need to create an atmosphere of trust and show the necessary emotional maturity. The main thing that needs to remember is that you do not convict anyone, but discuss the work process. Why did this happen? Why did we miss it? What could speed up the progress of work?
It is especially important that people feel themselves a team and take responsibility for all processes and their results. Solutions are sought by the whole team. Group members should have a certain psychological exposure so that their discussions are directed at solving the problem, and not at finding guilty ones. It is absolutely unacceptable that even one member of the team was forced to take a defensive position — everyone in the group should hear and understand each other. By the end of the meeting, the team and the Scrum master must agree on improving the process, which will be put into effect in the next sprint.
11. Start the next sprint immediately.
The most important thing in this methodology is customer orientation. The customer must receive what he wants, on time and at a minimal cost. In contrast to the linear (waterfall) approach, when the project was originally planned "from" and "to", and the result is somewhere "at the end of the path", this method allows getting the finished product in a short time with minimal cost. Of course, it does not yet have all the required characteristics, but it can already be used. Further, in the course of the project, the contractor receives feedback from the client, on the basis of which the cyclic increase in functionality and product improvement is carried out.
Scrum's main characteristic is flexibility. This methodology allows you to quickly respond to changes in customer requirements and quickly adapt the product to them. There may be difficulties in implementing Scrum. Firstly, the active participation of the customer in the project is assumed, and secondly, well-coordinated teamwork is required.
What scrum is not
...a tool for controlling people(yeah, I heard it from developers). Of course, it is not true, it's more productive to work less. Agile in common is to control the risk, not each other.
...a complex framework. Go to http://agilemanifesto.org/ and read 4 values, just four points. That's it.
...unclear requirements because they may change along with product development. It means requirements need to be clear enough to be defined as user stories or items in the Product Backlog.
...only for software development. Many industries may benefit from this framework.
Daily dose of