I have been working with / in / for agile in the field of web development for more than 10 years. Of these, most had to deal with the most popular agile framework - scrum ( according to VersionOne ). I want to share with you the accumulated observations and conclusions.
I will start with the metaphor, as sometimes I had to see the introduction of scrum in this scenario:
- Before scrum : “development” is like a baby - it is purposeful, but it does not know how to walk normally, but it really wants to learn how to get to the goal.
- Introduction : the teacher comes ( scrum trainings, courses, agile coach, etc. ) and shows how to walk. The kid is happy, he moves in steps! Top Top Top. We have sprints - we walk!
- After implementation : patient stakeholders say: “Okay, they drove to the goal,” what they get is “don’t put pressure on the team, we walk!”. Development writes interesting paths and enjoys the process, but the goal is forgotten.
- Scrum-no : further the truth pill from business, scrum “mutates” and allows business to get any product from development. And, unfortunately, the tick “we are working on scrum” is formally put, but the real potential of the development team has not been revealed, and the terms “scrum are not real”.
In my opinion, this is due to the fact that scrum is often implemented “mechanically”, without awareness of the essence of the framework and its elements. I want to try to reveal the symptoms of the "mechanical scrum"; to understand the disadvantages of this approach; understand what could be better with a “real scrum with agile”; and find ways to help fight scrum symptoms. I will dedicate this to a couple of articles here and I will be happy for your comments and questions.
To begin with, let's define what the “mechanical scrum” is. From my point of view, this is when all the roles, events and artifacts of the scrum are formally present, but values and goals are forgotten; when there is no agile culture ( ie, a high degree of awareness and acceptance of the agile manifesto and principles ). When there is no understanding or even an attempt to figure out what this or that artifact is for, or what purpose the scrum events have. It's like a robot in a video that can spin backflips, but who will call him a gymnast? When introducing a scrum, it is important to convey to the team its goals and values, not just the mechanics. Agile culture enhances scrum and makes it "real." Scrum is useful for regularly delivering value and receiving prompt feedback. Scrum is about speed and product development. Does the theory sound trite? Let's try to figure out how to work on scrum and not lose agile culture and values of scrum on the way.
When parsing the scrum elements in ScrumGuide, the roles are one of the first to be dealt with, we will do the same. Since material turned out a lot, then, to give him the opportunity to realize, it is divided into three parts ( Part 2 , Part 3 ). Let's start the analysis with the Product Owner.
Product Owner - Product Owner (PO):
The product owner is the person in charge of the product, he “owns” the product backlog. The main tool of PO is a vision of product development, and the main task is to maximize the value of the product produced by the team. It seems to be simple: “If you are brave, clever and skillful ...”, but there are nuances. We are not taught in PO, but they are taught in PM (project manager), and often PM become PO, considering that this is just a name change, and old approaches can be left as well. But that doesn't work in agile. So how should it be?
Interaction of PO and product, Backlog
Symptom : PO is not responsible for the composition of the backlog, it is simply working on stories received from other participants in the process. Or PO is not responsible for prioritizing backlog elements. He does not define his work to bring the backlog to the accepted standard in the team, and he does not define the content and priorities of what the team will do.
What is bad : If the PO does not have the courage or the ability to create a product ( form a backlog, set priorities, conduct experiments, etc. ), this is not a PO, but some other kind of activity. And without a scrum, no scrum. Without forming a backlog, PO cannot be responsible for the product. If the PO is not responsible for the backlog, then the adoption of product decisions requires additional communications - this is an extra time spent, which negatively affects the speed of the team.
How to treat : you need to give PO the sole right to make food decisions and responsibility for the composition of the backlog. If a non-decision making PO is an established order, then it is difficult to change the situation overnight. When PO is "proxy", then
- Or we remove it from the equation and make the PO really the one who is responsible for the composition and prioritization of the backlog. Helping PO work on the backlog can be done both by the development team and by the special Product Discovery Team , but the responsibility for the composition and quality of the backlog should remain with only one person - PO.
- Or gradually we teach / allow / force to take responsibility and make decisions (the composition of the backlog elements, the priority of the elements, etc. ) of the current PO. Important iterations: consolidation of success, getting feedback.
Symptom : PO has no vision for the development of a product, it does not have a global strategy, there is no goal, where to bring the product and why.
What is bad : The main strength of a PO is a product vision, an understanding of why and for whom it is created. With this vision, he can motivate and “infect” people around him. If there is no vision, it is unlikely that the product will turn out to be necessary and good. The team will not be "charged" on the result.
How to treat : PO it is important first of all to formulate a product vision. He should be able to tell in the elevator pitch format what a cool thing he does, for what and for whom. One of the agile values is transparency. Visualizing various artifacts of product development, we are working on transparency. PO can formulate his vision and post it in front of the team. It is better if the work on the formulation of the elevator pitch and the vision will be done with a certain frequency - like other scrum events ( planned new iteration - done - collected - feedback ).
Symptom : PO does not work on the elements of the backlog, does not bring them to the agreements adopted in the team, does not update the elements of the backlog, does not clean it, does not backlog the grooming .
What is bad : If the PO currently does not pay enough attention to the backlog on a regular basis, it will still have to do this ( sprints need to be collected ), but it will be more stressful and costly ( for example: collective restoring order in the backlog on planning a sprint ). Communication overhead will be offset from the development time. PO will start losing the trust of the team: it does not invest in the backlog - the team will not invest in increment. A bad / irrelevant backlog reduces transparency for all stakeholders. A scrum without transparency is not a scrum.
How to treat : Before PO you need to convey the importance of working on the backlog - articles, books, trainings, etc. It is necessary to develop rules / regulations for conducting a Product Backlog Refinement (PBR) so that these meetings are useful and effective, by conducting a mini-retrospective after PBR, in a few iterations, this event can be qualitatively improved. It is necessary to improve the mechanism of conducting PBR in teams, reaching the maximum synergy of the PO and the development team. Backlog needs regular cleaning. Receiving fresh information in addition to adding fresh stories to the backlog, you need to remember to remove stories that have lost their relevance. Backlog must contain clear to the team and elaborated ( within the framework of the arrangements of a specific team ) elements for 2-3 sprints, a deeper worked out backlog can lose its relevance. In general, the backlog should contain a Roadmap for at least a year, so that all interested parties feel that the product has a future. If you keep the backlog, beaten into approximate increments, it will help the team think ahead about the sprint goals .
Symptom : PO is working on several unrelated products or with several teams. Alternatively, in addition to the main PO, it also takes another role in the scrum process (or the developer, or SM).
What is bad : Being a PO is not an easy job that requires a lot of work. If the role of PO is combined with another activity, then it is very likely that this will have a bad effect on the quality of the result. Experienced and mature POs can simultaneously lead several products and work with several teams if these products are “related” or are similar in functionality to parts of one large product. Most likely, only very, very unique people can simultaneously make, say, a graphics editor for mobile devices and an army simulator. To be effective, you need to keep the focus on one goal before juggling several.
How we treat : PO should look critically at its products: how much is the vision worked out and formulated? How much do teams understand and accept this vision? How well designed is the backlog? Is it transparent to all interested parties? Is there a roadmap of the product, is it clear to everyone? The team understands what will be doing the next 2-3 sprints? How well known is the user and the market? What is the quality of interaction with the development team? If in some of these issues there is a place for qualitative improvements, you should keep one product for yourself and focus on it.
PO interaction and teams
Symptom : PO directively controls the team, actually working according to the classical PM scheme. PO makes all the decisions, even the most insignificant, the team runs to him on any issue.
What is bad : If PO is engaged in micromanagement within a team, takes an active part in development, then, on the one hand, it demotivates the team and does not allow it to develop ( there is no self-organization, because responsibility for local decisions remains on the PO ), on the other hand, this is bad for the product, because the PO efforts are directed inside the process, and the product can be left without his attention.
How to treat : PO you need to kill PM in yourself, try non-directive approaches in management and stop perceiving people as a resource. If a directive management scheme is built between the PO and the development team, it is worthwhile to involve an external or internal facilitator capable of correcting the interaction. It is necessary to clearly define the boundaries of responsibility between the PO and the development team - this is transparency. There must be trust between the PO and the team: the team mostly trusts the PO and its product solutions, and the PO trusts the team and the decisions that the team takes to implement the backlog elements. Everyone has an understanding that work is being done for a single purpose. One of the possible tools for a PO can be its “product” team, which includes analysts. When hypotheses are based on numbers and data, they are more credible. The main thing for PO is to remember to share this data with the development team. If the command is not independent, then PO must be learned to delegate. Then the team will be forced to take decision-making, as a consequence, responsibility, and gradually it will become a scrum team.
Symptom : PO and the development team regularly conflict, there is a constant confrontation, there is no understanding.
What is bad : the PO and the crew are sailing in the same boat, if effective communications are not established between them, then such a boat is unlikely to be able to sail far. A lot of energy will be spent on networking, not on product development. The goal of PO and the team is the same, which means there should be no regular conflicts.
How to treat : We need an experienced facilitator, able to identify the essence of the conflict, remove it and build a working relationship. If all efforts do not lead to mutual understanding, then perhaps it is worth changing tandems.
Symptom : PO almost does not communicate with the team. For example, it is available only in the framework of mandatory meetings (planning, sprint review).
What is bad : The team creates a new complex product ( Scrum is a framework for developing, delivering, and sustaining complex products. ), Therefore it works in conditions of great uncertainty. To deliver maximum value, they need information, which in most cases only PO has ( this is his job ). In the absence of information, incorrect assumptions and decisions may be made, as a result, valuable time will be lost in correcting them.
How to solve : PO should be available for the team, but the team should not be abused, otherwise the PO time will be spent only on ad hoc issues. It is necessary to develop a comfortable interaction format for all, in which the team receives in a timely manner the necessary information and decisions from the PO that the team really cannot take on its own. It is possible with a certain regularity to call on the PO retrospectives and discuss the issue of frequency, tools and the format of communications there.
Symptom : PO does not instill and does not encourage feedback culture in the team. Or, PO gives one-sided feedback, filtering praise or criticism.
What is bad : When the PO does not give regular honest feedback to the team, it demotivates the team. No synchronization on expectations and results. The team does not feel complicity, they are not actually the creators of the product, they just perform their function. “The team regularly supplies increment. The team regularly receives honest feedback on their work "- it seems to be a fair deal.
How we treat : PO, of course, does not have to charge the team with all that information with which, he works himself, all that he receives from users and analysts. He must aggregate and provide information that is already important and understandable to the team. It is good to come up with various formats for feedback, and not just on the basis of dry numbers ( for example: live tests, interviews, etc. ). The team itself should remind the PO of the need for feedback: ask questions, build a regular process for receiving feedback. If PO makes the “owner” of the sprint review event and perplexes him with the fact that the team needs feedback, this will at least remind the PO about working on the feedback, and may lead to a more creative approach in organizing it.
Interaction of PO and market users
Symptom : PO does not know "its" user; The product sees as a set of features. The PO ignores user requests and information from existing users. Does not communicate with "live" users.
What is bad : First of all, the product is created for the user who has ( perhaps he does not yet know this ) the need satisfied by the product. And if you do not know and do not understand the user, then it is impossible to “be responsible for achieving the maximum value of the product,” as required by the scrum guide.
How to treat : There are many different tools for conducting qualitative research, for example, in-depth interviews, a user's portrait, a customer journey map , tools for collecting qualitative (vs quantitative) analytics , etc. etc. You need to try different tools and leave useful / working for your product. Most of these tools have a result visualization of output; it is worthwhile to place them in front of the team in order to increase transparency. These artifacts are worth updating from time to time. You can organize a product discovery team to help conduct qualitative research. If PO is able to establish user interaction, he can use this contact, for example, on a sprint review: giving the user a fresh increment, and the team will investigate how the user will cope with the task, the help in solving which they laid in increment.
Symptom : PO does not study the market / competitors.
What is bad : The product lives as if in a vacuum, and divorced from reality; one must be a visionary in order to create a valuable product in such conditions.
How to treat : There are a number of practices for product owners, how to explore and create markets, it is worth trying different ones and leaving benefits. In this activity, the PO can be assisted by analysts or a team. It is useful from time to time to look for " blue oceans ". And of course, you should take inspiration from trainings, product meetings and conferences.
Conclusion
Parsing other roles will appear in the following sections. And now let's see what this information can do for you. We looked at some of the possible symptoms, saying that something was wrong in the scrum, and options for changing the situation. If you want, checklist at last:
- Reading almost each of the points, you recognized yourself ( your team / organization ), i.e. you have a scrum with non-canonical understanding. Then you should ask yourself: do you need a scrum at all? Why do you need a scrum? What tasks do you set for him? Is corporate culture ready for agile values and principles? If you have the answers and understanding of why you need a scrum, and you really bet on it, then go to the second option. If not, stop doing self-deception.
- Reading some of the points you thought it was not about you. Some points gave you reasoning and you remembered your situation. If so, select the items that may be applicable to your situation. Print them as cards. Discuss the symptoms with the team: are they fair to you? Discuss the risks, do you agree with them, or maybe you see more dangerous consequences from the symptoms. Then take the card that worries the team the most, the most dangerous symptom at the moment. Consider the proposed solution, does it suit you? Collectively think up how to improve the situation, how to remove a symptom. And act! Having dealt with one symptom, proceed to the next one, periodically returning to the general review, to be sure that you have not sunk through the results you have already achieved.
- If you read everything and did not recognize your realities in these situations, we are all right. Are there any such organizations? You are great fellows, be sure to share in the comments how you achieved this!
PS I hope that the article will give the scrum team a working tool for self-improvement.
PPS For illustrations, many thanks to Sai Kin
UPD. Part 2 and Part 3 .