Scrum for small organisation with overlapping projects
Greetings community,
we recently decided to implement Scrum in our team and I can already see why the guide says it is easy to understand but difficult to master.
While this forum was already tremendously helpful, we are still struggling with a few decisions.
We are a small company / team of 5 full-stack developers, who are working on a web app, a chrome extension as well as one API. Theoretically, everybody has to knowledge to work on any of those projects. However, at the moment every developer has a focused one (usually a client) and adds features to our backend as they are needed.
This is something I would like to change in order to be more feature oriented and to facilitate common goals. I think otherwise Scrum will not work, since developers would still own backlog items and commitments as a team would be diluted.
Our first idea was to have 3 separate projects (web app, extension, api) with 3 different boards and one common PO & SM. However, this seems to be impractical. Not only do we need to split features over different projects (client / api), but it makes common goals impossible. Furthermore, developers would need to regularly switch between projects and PBIs from one backlog need to be adjusted according to changes from other projects. Therefore, this does not seem to be a good solution.
Another idea would be to have two projects / boards for the clients and split the team accordingly. This would lower one team size two 2 (not Scrum). Furthermore, e.g. bug tickets for the API would have to be put into one of the client boards, which I would like to avoid.
We came to the conclusion that it would make the most sense to see the clients/api as one project with only one backlog. This would make backlog refinements as well as a prioritisation much easier. However, it would not solve the problem of common sprint goals and I can see difficulties for scaling up. (The last point is less of an concern since we can change the setup in the future, as more people join)
I think the last approach still makes the most sense, even though we need to be creative with finding common sprint goals.
Is there anybody who could give us some feedback if we are on the right track and perhaps how to overcome the problem with common sprint goals?
Another problem I see in our organisation: We don’t have a product manager, yet. Thus, our boss is the one who would take the role as a PO. Since he regularly comes up with new ideas and we present our progress to him, he also acts as a client. I think this might lead to a conflict of interest as nobody is explicitly in change of filtering his ideas. Having another developer as PO would also lead to a conflict of interest and create overhead to our development resources, especially since our boss is willing to create and order the PBIs. This is only temporary until we get a product manager. But until this point, would it be a bad idea to have our boss as the PO?
Thanks for your advices,
Janis
One observation I would make is that you use the term "project" freely, and "product" somewhat more reticently.
So -- leaving aside for the moment how many projects there might be and how many teams might work on stuff -- how many products are there? Are the app, Chrome extension and API 3 products or 1? How many value streams are there to be optimized, given that value optimization is a core accountability describing what a Product Owner does?
To jump on @Ian's bandwagon, do a search on the current revision of the word "project" in the current revision of the Scrum Guide. It appears only once
Each Sprint may be considered a short project.
The previous revision uses the word "project" in context to a body of work twice.
Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
In order for your organization to realize the benefits of Scrum, you have to quit seeing it as a project management tool and see it as a framework for the solution of complex problems as they relate to a product. The following is only one part of the definition of Product from Merriam-Webster.
2a(1): something produced especially : COMMODITY sense 1
(2): something (such as a service) that is marketed or sold as a commodity
Define your product(s) first. Then define an "emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team." (definition of Product Backlog from the current Scrum Guide). Then "the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint" (definition of Developer from the current Scrum Guide) start to "compose the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how)." (definition of Sprint Backlog with slight modification for word tense).
You stated that all of your developers are capable of working on any project so they should be able to work together on a body of work that can span all "projects". Craft bodies of work that provide functionality across all "projects" as a complete increment. That way you are delivering the same value to all users at the same time regardless of how they access your product(s).
Transitioning to agile practices is more than changing the way the developers work. Often it means changing the way the entire company works and views the product that they sell.
Thanks for your feedback.
I think I get the idea:
We have 3 different code bases, but only one value stream. The same users will use our app and chrome extension and pay let's say a subscription. Our API handles the logic and supports the clients.
In order to maximise the value, we cannot look at the code bases, but have to decide what the most important features / changes are (independent from where they are implemented).
This leads to my conclusion, that we in fact only have one product.
Let’s say we create one common backlog and identify the most important PBIs. These are selected for a sprint, as long as they represent one piece of a potentially shippable functionality. This functionality would be our sprint goal. However, we would also add further high priority items (e.g. bug fixes / small features) that are not directly related to the sprint goal, as long as the team has the capacity to complete them and they are not jeopardising the sprint goal.
Would this approach make any sense?
Would you mind to also share some insight on how to tackle the problem with our boss/PO? I gave it some further though and realised that on the one hand, he is in face the project owner. He holds the responsibility and surely acts as a value maximiser. However, since he is the one that comes up with new ideas / that inspects the product at the end of a sprint, he also acts as our client and therefore has a conflict of interest (nobody is there to e. g. filter out unrealistic ideas). Am I putting too much though into it and is the PO role actually suitable for our boss, as long as he is familiar with the scrum rules and values?
Thanks again for your responses.
It does sound like you are getting the idea. I wish you luck in helping others to understand it also. I have a t-shirt that my kids bought me a few years ago with a phrase that has become something I tell myself often.
I can explain to you but I can't understand it for you
That is the life of a Scrum Master. You will explain this many, many times and eventually people will start to understand. You may have to let them misstep a few times until they start to feel and see the pain associated. Always gently and confidently remind them how Scrum could have helped them. Continuously explain Scrum Theory to them.
It also helps to review the Scrum Guide (https://scrumguides.org/scrum-guide.html) often. Everytime I reread it I start to understand a little more because of the situations that I have encountered since the last time I read it.
Now about the boss/PO thing. Remember that Scrum does not provide job descriptions, it provides roles. A role's responsibilities can be satisfied by many job descriptions but the key in Scrum is to have one person that is solely held accountable for ensuring that the responsibilities are satisfied. This is the section of the Scrum Guide (https://scrumguides.org/scrum-guide.html) that explains the Product Owner role. I have added emphasis to a few parts for my discussion.
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is also accountable for effective Product Backlog management, which includes:
Developing and explicitly communicating the Product Goal;
Creating and clearly communicating Product Backlog items;
Ordering Product Backlog items; and,
Ensuring that the Product Backlog is transparent, visible and understood.
The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.
For Product Owners to succeed, the entire organization must respect their decisions. These decisions are visible in the content and ordering of the Product Backlog, and through the inspectable Increment at the Sprint Review.
The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.
I do not think there is a problem with your boss fulfilling the Product Owner role as long as all of the text I bolded are being fulfilled. A Product Owner will often represent stakeholders when you are building a product for wide distribution and use. If your product is being used by 1000s of people is it difficult to include them all or even a representative sampling into a single review. However, there are other types of stakeholders. For example, if work being done during a Sprint is to introduce mechanism for measuring page views, you may want to include the sales and marketing organizations in the review to ensure that the means you are providing will work for them in their workflows. Or if a feature is one that Sales has told you is being asked for by a large number of potential users, include them as stakeholders in the review because of their need to have the feature in order to increase user base.
One caveat to my statement is that your boss will have to respect the developers to come up with the correct solution to the problems he presents. If they start to dictate the technical implementation, then they will be crossing into the responsibility of the Developers. Just as everyone has to respect that they are representing the needs of the stakeholders in the Product Backlog, everyone must respect that the Developers will deliver the best technical implementation to satisfy the need.
Hope this helps.
Your feedback far exceeded my expectations when I initially created this post. You really helped me to get a better understanding of Scrum. Now,I also feel more confined in applying the framework to our team.
Thanks for putting so much effort into your comments :)