How natural is the move from project manager to Scrum master role
While adopting Scrum, many organizations are facing difficulties to appoint the Scrum master. This role has a scope and mission that is disrupting the status quo of the hierarchical organizations, and one particular role: the project manager.
On the other side, Scrum is extremely often seen as a project management methodology, while it is clearly documented as a product development methodology.
From these situation, many organizations choose to appoint project managers as Scrum masters and believe their agile transformation is done. But is it a valid option? Let's have a look.
What is a project
There is no occurrence of the word project in the Scrum guide, so it sounds awkward to see the problem persist. If we can understand the confusion from non-agilist, it is a little more disturbing to hear it from Scrum coach and evangelists.
To give this question a rational answer, let’s review what is a project. No fancy definition here, let’s reuse the key elements of definition from the Project Management Institute. So a project:
- is temporary in that it has a defined beginning and end in time
- has a defined scope and associated resources
- is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal
- often involves people who don’t usually work together
Why Scrum is not a project management methodology
If the uniqueness of the work to perform is usually valid for Scrum, it is not the case for the others three statements.
- First statement: a project is temporary in that it has a defined beginning and end in time
No, Scrum is not temporary. It obviously has a start date, and can have an end date, but it is not necessarily the case. Moreover, it is by design indefinitely sustainable. This is already a pretty strong misalignment.
- Second statement: a project has a defined scope and associated resources
The scope of a Scrum product is meant to be aligned with user expectations with each iteration. Even if the team should start from an idea of scope or an initial problem to solve, there is no notion of fixing the scope. Once again Scrum differs largely from the definition of a project.
- Third statement: a project often involves people who don’t usually work together
Most Scrum experts agree to the fact that Scrum gains in predictability and quality when gaining in maturity. Mature Scrum teams are in essence productive teams. Even if at first it can group various skills, a good practice is to share knowledge as much as possible so that most team members are able to work on most items. In short, no, we cannot say that in Scrum people are not used to work together.
Scrum does not fit with most the key concepts that define a project. It could be the end of the story but from another perspective, you can very well setup a Scrum team in a context in which the items above are all true. It is actually pretty common.
When Scrum can be seen as a project management methodology
On principle, as defined above, Scrum is not a project management methodology.
However, if as a company you decide to fix a global scope or vision and a time-frame to try out a new idea, it is a project. And among the different methodologies you can choose from, Scrum is off course a valid option.
This creates confusion for many. I believe this is the source of many misunderstandings.
Why is it a problem
Well, is it only a wording question? After all, it does not matter much to decide if yes or no Scrum is this or that. As long as it helps to get value delivered, who cares?
While valid, this has a drawback: mindset.
Scrum is great but requires a deep change of mindset. It is the #1 failure of Scrum transformation: missing the mindset shift.
Back in the 90s and early 2000, projects were the way to go. Companies run projects for any kind of purpose. Consequently we have a large part of the workforce that believe projects are the way to innovate, and that the project manager is The head, the person who is accountable. If the whole organization expects the same from one person in the Scrum team, there will be disappointment. It will create issues like Scrum master seen as useless or all power. Product owners that can lack some skills as coming from the “project” team. Same applies to “one-year roadmap”, change control boards and all the structures and practices that arose from a project-oriented organization. If those may have had benefits, they will only create impediments on the adoption of Agile and Scrum.
It may as well suggest that project managers are best suited to become Scrum masters, which is not necessarily the best idea.
Project managers as Scrum masters
Now here is the main point. In an organization oriented towards projects, an easy take is to appoint all project managers as Scrum masters. It has the merit to be easy and fast, but that is all.
Obviously, some project managers can accommodate to the new role, but again this will be all about a change of mindset. Scrum is based on team self-organization and autonomy. It is about team and collaboration over one-head syndrome. That may not fit with the temper of some project managers, that have a habit to micro-manage and control all deliverables in their areas.
There are a number of qualities that makes a good Scrum master, and some that are explicitly important for project managers.
Key qualities to move from project manager to Scrum master role
- Belief in Scrum: this one seems obvious. By experience it is not. Many project managers do not easily accept agile transformation. An example is project managers that think Scrum comes with lack of transparency and predictability, like we discussed here;
- Involving the team with process definition: Project managers may have a tendency to decide how things are done. For a part Scrum masters has a strong role in in the process. In the end the team needs to like the Scrum process; An example is the Scrum branching model;
- Belief in self-organization: that is the point of Scrum, and its main value. A project manager needs to have faith in this model to avoid being himself an impediment to it;
- Recognizes and acts on team conflict: Pretty important and not always the work of project managers. Read our article on Scrum master role on conflict;
- Encouraging to take ownership: if the Project manager believes that being a Scrum master, he will still be owner of the product or the team, that should be a no-go;
- Sensitive to the question of sustainable tempo: A fundamental change between a standard project methodology and Scrum is the question of tempo that the Sprint brings. It is potentially difficult for a project manager to accept this change of temporality. That is how we come up with product increments sent to the users every three sprints and milestones in the roadmap…
- Facilitator: last but not least, Scrum master is about helping the team to produce value. The tasks that he has to do may be surprising to some project managers that precisely avoided this kind of low-level impediment to look at the global picture. Ask your project manager if that is really what he wants.
Scrum is not a project management methodology. Persistent teams should align to a product mode in which Scrum will be well seated to provide its best value. This ambiguity becomes a major issue when we try to transform project-oriented organization into the adoption of Scrum.
Project managers may be good candidates for the role of Scrum master, but the recruiter will need to verify the alignment with Scrum values before.
See what's next
Download our guide "How to grow your agile team"
Checkout our other Scrum hoaxes:
The role of Scrum master regarding team conflicts
Any activity done in group may create conflicts between individuals.
Scrum, by proposing self-organized teams synchronized by ceremonies and pair-reviews, may bring to the surface conflicts within the team and outside the team. A common thinking is that it relies on the Scrum master to solve these conflicts. In this article we will review where the role of Scrum master lies regarding conflict resolution.
Many people believe the Scrum master is useless. On the other side of the spectrum, some people believe that he is kind of a manager of the team. Where is the truth?
Last week, there was a conflict between two members in a team that I coach. Apparently the organization, including the team members, were expecting the Scrum master to take care of that conflict. He was not so sure about his role into it. So we discussed about that question: is it the responsability of the Scrum master to solve conflicts in Scrum?
It is common for organizations to miss the soft skills required by the job of the Scrum master. Conflict management is an opportunity to review this part of the role and to see if it is useless.
Conflicts within the team regarding the work to do
This first situation occurs when several people in the team cannot agree at all on a subject that relates to the work to be done.
It can occur on a very large set of topics, from trivial like code formating, to more in depth subject like architectural style, aesthetics, columns definition of the sprint board or branching strategies.
See our article on branching strategies in Scrum if you are in this case.
Under these circumstances, the conflict can block the team to progress. It is then an impediment. It is the role of the Scrum master to help fluidify collaboration and solve the conflict.
Many tools, not specific to Scrum by the way, can be used for this, depending on the situation.
Here are a few techniques, more or less sophisticated:
- - rediscussing roles and expectations. No, a senior developer should not assign work. Yes, a PO should write understandable, coherent and scoped stories...
- - getting back to the actual need. Many architecture discussions can be solved by reviewing non functional requirements or product vision with the PO
- - the technique of the three amigos to add a new perspective to the topic
- - one-to-one coaching session can be helpful
- - rationalize the conflict is as well a top priority. Easier said than done, but still required
- - the help of an expert can be interesting in some cases
In that area, the role of Scrum master as facilitator, oriented towards maximizing team collaboration, will play a key role. Not so useless indeed !
To establish mutual respect and active listening within the team may require sharp soft skills and emotional intelligence on the Scrum master side. It is crucial to get a happy and high performing team.
Scrum ceremonies speed up conflict emergence (and resolution)
As we mentionned, Scrum strongly relies on interpersonal communication to build a product. Many ceremonies are made to enable autoregulation within the team, with peer-to-peer discussions on a very regular basis. It is efficient but if not properly handled, it can lead to bad situations.
Take the example of a newcomer that is not motivated because he feels completly lost in the product. He is not working very efficiently so he does not progress much on what he is working on.
On a regular V-model project, he may have the opportunity to hide a bit the lack of progress. He may keep the problem to himself as he does not feel comfortable in sharing its difficulties. Result is that he will leave the team or that few weeks or months later, someone will realize that planning is at stake.
In Scrum, he will have to stand in front of the team and answer the question of what he did the day before. That again and again every day up to the end of the sprint, ie between 10 and 20 times! This will for sure catch his mates' attention as that situation endangers the team's objectives. And that is great if the setup is good: the team can quickly move to the resolution of the problem and improve the situation of that newcomer: let's work in pair on your story!
In that case, the conflict can be resolved by the team itself thanks to the framework.
When conflicts between team members become toxic
Helping to resolve conflicts that arise during the crafting of the product is one thing. But when toxicity steps in that is a totally different story.
Team members can have strong incompatibilities, far beyond a temporary divergence on the best solution.
This kind of conflict is not only a timebounded impediment of the team, it is a fundamental long term issue in the team and beyond.
In such a situation, the role of the Scrum master is typically to:
- Identify the situation as a conflict
- Try to solve with various conflict management techniques (see this good article for example)
- Diagnose that the problem goes beyond temporary impediments
- Hand-over the problem to a role in the organization that is typically fit for people management (People Manager, HR, ...)
- Follow-up the situation and mitigate the impact on the team
Hopefully by applying this simple method the Scrum master will manage to minimize the damages such a conflict may create in the team. Preserving team coherence under these circumstances is a real challenge.
Wrap-up: the Scrum master role facing conflicts
To summarize, we can say that no, the Scrum master does not have to handle all conflicts within the team.
As a facilitator, he has to take care of the potential difficulties team members have to collaborate in the day-to-day life of the team. For that, he has to demonstrate extensive soft skills and should continuously work to setup a good atmosphere.
When things goes beyond the resolution of temporary conflicts, the Scrum master should raise alarms within the organization that a recurring and potentially toxic situation is in progress and should be taken care of.
See what's next
Download our guide "How to grow your agile team"
Checkout our other Scrum hoaxes:
How to fight lack of transparency in your Scum implementation
Better transparency is one of the key value proposition of Scrum and one of its pillar. Several parts of the framework are designed to help it and make sure to keep stakeholders aware of the progress. More often than not, this does not work as expected and Scrum is blamed for that. It is a perfect opportunity to open this series of articles around the Scrum hoaxes. In today’s article we will discuss the black box syndrome some organizations encounter while implementing Scrum, and cover the possible causes and solutions.
Some times ago, I had a discussion with a senior product analyst about how Scrum impacted its organization. Like some people complaining here and there, he was not happy at all with the methodology. Bottom line, the issue was that since the implementation of Scrum, the teams around him were completely black boxes. No transparency at all, especially regarding what the team will work on. A common issue indeed, that may come at very different stages of Scrum adoption. It is very sad because it is usually due to a bad way to Scrum. This situation, like all the others of this series of article, is not due to Scrum but to how it is implemented.
So how a team, after implementing Scrum, can be perceived as less transparent than what it was before?
Obviously, it comes from the fact that some aspects of Scrum are missed, but it is not so trivial to see what is wrong.
I will share below the most common category of mistakes I have encountered.
Case 1: No (or ghost) Product Owner
Yes, I have met teams where the role of PO was simply not filled. The Product Owner being in charge of the product backlog, the issue is obvious and immediate.
A very similar flavor is the Product Owner is appointed but too busy to take care of the backlog, or not trained to or convinced by Scrum. At best there are a bunch of badly written stories, at worst nothing at all and the Product Owner sends an email to the Scrum master here and there to ask for things.
Without a proper and up-to-date backlog, no visibility on the product, either inside or outside of the team. You can obviously forget any notion of transparency.
To get out of this situation, the organization needs just to take the subject seriously: the role of PO is critical to a working Scrum team. He should be knowledgeable, accountable, available and invested in the product. You should have the proper skills, including technical skills.
I would love to say that this is the least frequent case, but sadly it is much more common than you think.
Case 2: No (public) demo
The sprint review meeting is the opportunity for the Scrum team to demo the proposed product increment to itself and potentially key stakeholders. It is as well the opportunity for the PO to decide to release this increment or not.
The first possibility is for this meeting not to be held or to be badly run. Relating to the previous case, if the Procut Owner does not attend this meeting it will be extremely hard to discuss with stakeholders what has arrived and what should come next.
In the situation where the PO is there, but if no stakeholders attend to this demo meeting and if there is no other way for them to see the increment and provide feedback, it naturally results in poor transparency on the Scrum team output.
Our advice here would be to invite key stakeholders to the review meetings to provide them the best visibility.
In addition, especially if the point above is not doable in your particular setup, you should put in place the means for the feedback loop to be available. It depends heavily on what comes next to “Product Increment is shippable”, i.e. the path to users after the sprint.
A solution can be a webinar (for very large audience), a platform to demo your new version, a recorded demo sent to stakeholders or even some canary testing on your production environment. We will cover more on these possibilities with articles on release management but in any case you need to put in place a feedback loop.
Case 3: Private backlog
If with the situation of secret project put aside (military or equivalent), this is astonishingly frequent: the team has a backlog that no one can see outside of the team.
You cannot expect the stakeholders to participate if they cannot see what the product owner has in mind and how their feedback is taken into account.
The solution is obviously to make sure the backlog is available to your stakeholders. The clearer the backlog is the best, so the tool selected should have a good navigability and it should be obvious how to find your backlog.
Case 4: No roadmap
With case 1, 2 and 3 covered, you have a reasonably well written backlog and a two-way communication is established between the stakeholders and the team about newly built product increments. The next source of issue is trickier: what comes beyond the current sprint.
Most organizations and actors in the field of software edition (and engineering in general) are expecting a form of roadmap. Yes, it is usually not reliable and not adaptable. It is not meant to be a commitment on the few next months, but it is valuable to give some visibility on what you hope to accomplish.
Case 5: No readability on what the stakeholders want
A backlog gets denser and denser as long as you are getting closer to the next sprint items, as you will detail more and more the content of the stories. From an external point of view, it may be very hard to find out how a suggestion or request has turned into a list of stories.
A good way to do it is to differentiate the stakeholders’ requests from the stories themselves. You can use epics, but it can get complicated for different requests fulfilled by the same stories.
The best option is to distinguish the requests from the stories of the backlog and make sure each request is updated based on the status of the stories implementing it.
Find out how this works in request management of Stenusys Scrumboard.
Case 6: Private Sprint Board
When some critical stories are under implementation, stakeholders may be interested to see if everything goes ok. It is not that they can do a lot about it in most cases but that sure means they may not appreciate to wait until the sprint demo to get news from you.
To make sure the information is available at any time, without a need to compute reports manually, it is a good idea to have a sprint board fully open and easily accessible. The best option is to have your backlog browsable in your Scrum tool: it will allow the best transparency possible.
Closing up, transparency is one the key value in a business relationship. It is required to setup the viable working environment you need to work efficiently, based on trust between the team and its stakeholders.
If well applied, Scrum is a great enabler of transparency. By following the suggestions proposed in this article you should get one brick to put in place a healthy product engineering team. More to come...
See what's next
Download our guide "How to grow your agile team"
Checkout our other Scrum hoaxes:
A branching strategy in adequacy with the Scrum model.
Scrum is a great framework. If you do not know it, you should check it out and then come back here ! Defining a branching strategy suitable for Scrum is not so simple, here is a proposal.
Scrum is designed to develop product among iterations (called sprints). The sprint backlog contains stories which represents the work to do in the scope of the sprint. At the end of the sprint the Product Owner will decide if the proposed product increment is accepted or not.
It is common for Scrum teams to have strong difficulties with the branching strategy to apply to the product they are building. As a matter of fact, the expected level of collaboration on each story, the need to propose a shippable product increment, the different stories that may or not be sent in the end, all these specificities of Scrum make it challenging to find the proper way to stay clean and consistent with the code repository. That’s the reason why the branching strategy must be in adequacy with the Scrum model.
In this article we will present a branching model for Scrum using Git, oriented towards team collaboration and continuous integration. If you doubt this is worth investing some time, you may be interested in why software engineering matters.
The master branch
The development will start from your reference branch. You call it the master branch, the develop branch or by any other name. It is the one that reflects the level of code approved by the Product Owner as being ready for the production. In the scope of this article we will call it master branch.
The sprint branch
The sprint branch aims at containing commits of completed stories, the ones that will be presented to the Product Owner during the sprint review. This branch can be seen as the “ready for demo” branch.
At the beginning of each new sprint, its sprint branch is created from the master branch (i.e.: sprint/S01). This operation can be managed by the Scrum Master for instance. It is also helpful to tag the branch at this point (you will understand why in ‘failed stories’).
The story branch (and the relevant-atomic-clean approach)
As soon as the sprint starts, a dedicated branch for each story will be created from the sprint, following a naming convention that has to be decided. It can be of the form story/S01S01, story/S01S02… Which would be read sprint 01/story 01, sprint 01/story 02, …
The important point here is that the story branch is fully part of the model. It can be seen as a reference branch for the development of a specific feature. Even if it is a short-lived branch (like described in the popular Trunk Based Development model), it should not be considered as a "garbage" branch. More precisely, commits that will be pushed to the remote story branch should be relevant, atomic and clean. For instance, the remote story branch should likely not contain commits description like ‘working on story 2, WIP’, or even ‘fixed typo in MyClass.java’.
The cleaner the commits are in the story branch, the better the code history will be.
Branching strategy for Scrum, the big picture
Commits and interactive rebase
Of course, in the day-to-day work, the developer working on a story wants to commit his ongoing work, like a checkpoint so he knows he can restart from this point if anything goes wrong after. While implementing the story, this can end up with several commits.
Before pushing the commit(s) to the remote story branch, he should ensure that these commits are atomic and relevant. Performing an interactive rebase ("rebase -i") will allow to squash relevant commits between them and write a meaningful commit message if needed. The dev team can agree on the commit message format, like : “Story 654 – Switching from log4j to logback”, where 654 would be the story id in the product backlog, followed by a meaningful description. Only when this operation is done, the commit(s) can be pushed.
In a story branch, a pushed commit is a commit ready for code-review.
Working together, and merge-request for code review
Once a commit has been pushed, the dev team member should create a pull-request (also called merge-request) to the sprint branch in order to ease with the code review. There is no need to wait for the story to be completed to perform the merge-request: the code-review may start before the other parts of the story are implemented. But of course the story will not be merged in the sprint branch before the implementation is complete (i.e. the story is put in the column DONE in the sprint backlog).
TIP: GitLab (for instance) will prevent the branch from being merged as long as the merge-request’s title starts with “WIP:”
The code-review phase can generate one or more additional commits that cannot be squashed to the code being reviewed. That’s an acceptable state.
If several developers are working on the very same topic that requires sharing portion of code being developed, it might not be a good idea to work directly on the story branch because it would break the relevant-atomic-clean approach. Instead, they can consider branching from the original story branch or even forking the project. That way others can contribute to this temporary branch which can be interactively rebased at the end, creating new nice and beautiful squashed commits. 🙂
When the story finally meets the done criteria and the code-review is completed, it can then be merged in the sprint branch. That means the story is “ready to be shipped” from the development team point of view. All tests (unit tests and integration tests) should be rerun at this stage.
The code level in the sprint branch is the one that will be presented to the product owner during the sprint review ceremony. Uncompleted stories should not be merged into the sprint branch.
It is important to keep in mind that stories in a sprint branch (i.e. in the “done” status) has the purpose of being accepted by the Product Owner. To maximize chances, it is essential to work as closely as possible with the Product Owner. The situation of a story seen as done by the dev team and finally failed at review time should be extremely rare.
The review during the demo
During the sprint review ceremony, the product owner will review all stories of the sprint backlog. He will decide whether each story passes or fails. If you are running Scrum in a strict mode, one failed story will fail the sprint! The consequence is that none of the stories will reach the master branch at this point. The reason is that the product owner acknowledges the stories being ready for production on the very code level being presented during the review. If a failed story is removed from the sprint branch afterwards, the resulting level of code has never been reviewed and thus should not be accepted.
If all stories have passed, the sprint can be merged back to the master branch. This operation is called the delivery.
The Git tree representation of the branching model for Scrum (general case)
If the Product Owner has rejected at least one story, the whole sprint is failed. The way to deal with failed stories may vary a lot depending of the failure type and the Product Owner’s point of view on this. There is actually no unique answer, but here is some global leads:
1st case: the failed stories can be fixed easily.
If the failed story can be fixed easily and quickly, the Product Owner can agree on keeping the story for the delivery. The dev team will fix the sprint branch and will rerun all tests. The Product Owner should accept the fix based on the evidence usually required (test results) or a short informal demo.
2nd case: the failed story has to be removed from the delivery.
That’s the touchy case that should be handled carefuly. Here are three different kinds of approaches:
1/ Commit(s) of failed stories are reverted in the sprint branch.
This is an easy operation if story’s commits are atomic. But if this kind of operation is often done, this will lead to a dirty code base.
2/ A new sprint branch is created from the original one (like ‘sprint/01-take2’), identified by the tag created at the beginning of the sprint. All story branches of approved stories are merged into this new branch.
This is a tedious operation but the code history will be cleaner. This is a safe operation as long as the sprint branch does not contains special commits (last minute fixes for instance). That’s easy to forget those commits, be careful!
3/ A new branch is created locally from the actual sprint branch (like ‘sprint/01-rebase1’) and interactively rebased upon the original sprint branch (identified by the tag created at the beginning of the sprint). That way, only accepted stories are picked and there is no chance to forget any relevant commit.
This is the safer method, but this will generate new commits due to the rebase nature, losing the merge information of the story branch.
In all cases, the strategy should be proposed to and accepted by the Product Owner. He can decide that this is too risky and reject the product increment as a whole. The stories will then be integrated into a new sprint.
Continuous integration: some keypoints
This branching strategy works well for continuous integration.
On story branches
- Every single commit pushed to the story branches triggers at least the run of the unit tests. That’s one of the reason behind the idea of not pushing partial/work-in-progress code to the story branch. If it can technically trigger more tests, it should. The earlier the tests are run, the better
- When the story development is complete, the integration tests should run. The trigger to this operation can be defined in several ways (a tag on the commit can be an option for instance).
On sprint branch
- Once the story is merged in the sprint branch, the whole pipeline should be run (including the integration tests). This will ensure that no story broke another one.
I have implemented this Scrum branching strategy successfully in several companies. Of course this is not the only possible solution, but from my point of view it takes a good compromise between respecting Scrum interactions and maintaining a clean code base. It can cope correctly with the different scenarios a Scrum team can encounter.
Implementing a good branching strategy takes time, and should probably require to convince your Product Owner of the benefits. I hope this article will help you and if not, take a look at why Product Owners should have technical skills.
That is however not the end of the story: not all code changes are necessarily done in the context of Scrum. Maintenance operations and urgent fixes may follow an alternative (and complementary) process. More on this in a future article. You can as well look into this post from Gitlab that provide insights regarding git branching strategies independently of Scrum.
See what's next
Download our guide "How to grow your agile team"
The difficulties of dealing with technical requirements in Scrum
In agile transformation projects, the position and scope of the Product Owner role is often source of confusion. Most agilists get that it is about translating user wishes into stories. Functionally it seems OK (thus it is not always easy to do). But a software product is more than a bunch of features.
If you have seen conflicts between the Product Owner and the development team about a technical change (refactoring, framework updates are common ones), you are at the right place. In this article we will propose a review of what the role of PO consists in with a focus on technical aspects. We discuss then how it impacts the staffing for this position.
All Scrum practitioners know that the PO is in charge of maintaining the product backlog. It includes defining the functional solutions to answer the customer needs. The Product Backlog Items (PBI), often called stories, are designed vertically so that each of them brings value. They are arranged by priorities in the product backlog.
When we describe the PO role, the first answer is that the PO has to understand the customer needs and drag from it the actual functionalities that the product team should develop. The PO incarnates here the customer and transform its needs into small chunks that brings each a piece of value.
This is absolutely correct yet incomplete. The tendency to see only this part of the role is the root of the issue faced with technical developments.
What is a product?
Scrum methodology makes an extensive use of the word “product”. It does not give any detail on what the word encompasses. In fact it will vastly depend on the context in which Scrum is used.
For the sake of defining the boundaries of the Product Owner role, it may however be of some help reviewing what a product can be.
Limiting ourselves to software, we can already have a wild variety of product size and complexity. Let’s present few examples:
- A mobile application executing basic functions like a hangman game
- A mobile application executing basic functions, and connected to several backends to ensure communication and data persistence like a messaging system
- A library executing a rather simple set of functions like a logger or a connector
- A library executing complex functions like facial recognition or a video game graphical engine
- A service of low functional complexity like a basic e-commerce site
- The same service but scaled to the extreme and running on thousands of nodes with failover
- A complex framework handling complex use cases like an application server
- A distributed system offering sophisticated services like a Global Distribution System
Obviously, if all these type of software systems answer functional needs, the technical complexity of each is hugely varying. The importance of technical knowledge at Product Owner level varies with it.
All in all, a product is not only a set of functionalities but a software artifact with many characteristics like performance, security, portability, extensibility, etc. This may or may not be a major concern for the PO depending on the very nature of the product itself, but it sure requires to be assessed.
Back to responsibilities in Scrum
The development team is responsible for proposing a product increment fulfilling predefined done criteria. It covers any aspects of the software, both functional and non-functional.
The PO has to express the needs, including non-functional aspects, and accepting the increments, i.e. to understand how the team addressed these points.
The technical aspects can come in two flavors: as acceptance criteria of stories or as standalone stories.
Non-functional acceptance criteria
A software artefact is more than a bunch functionality. Depending on the business environment you are in, the constraints will be different. But if a feature increases by 200% the memory consumption of Google search Engine, I doubt it will reach Google production servers.
The Product Owner is in charge of writing product backlog items. It includes writing technical acceptance criteria (response time, memory footprint, deployability..., the list is long). As with any criteria, this is a subject that can be discussed with all stakeholders, included the development team itself. But all in all the PO is accountable for it.
Back to the different type of products, it can clearly see that the frequency to which the PO has to work on these acceptance criteria will vary a lot.
This is the most common case of issues: the development team wants to rewrite a part of the product, independently of any functional stories. And the PO does not accept it. In some cases a story is written but never prioritize in a way to allow an implementation.
First, let's evacuate a common misunderstanding: a story is not necessarily functional. The backlog contains Product Backlog Items that can very well be technical. However, a PBI must have a business value, including the technical ones. An example of technical story is the setup of a branching model, hopefully compatible with Scrum. We discuss about this topic in this article.
And there is the difficult but necessary part: assessing the business value of a technical story. It means that the request of this story (usually the development team) must explain the proposed technical change by its justification (the WHY) and not by its content (the WHAT). By experience it is very difficult and may lead to challenge the fundamentals of developers's ways, yet it has to be done.
You propose to migrate from JBoss 7 to Wildfly 10? Why?
You propose to refactor the payment module? Why?
You propose to deploy via Docker containers? Why?
They are good reasons to do these three things. We could imagine discussions around continued support from the community, speed of integration of new payment providers or ease of deployment. But they have to be valued against features asked by the users.
Again collaboration is probable and wishable, but if the PO is fully hermetic to any form of technical discussions, it will be virtually impossible to get anything done.
Skills: who could become Product Owner
We see around many agile transformation with very different results. A usual source of issues is the appointment of the Product Owner in the newly formed organization.
As you might have guessed, there is no unique way to select a PO. It does depend a lot on the product but as well on the company context, the support the PO could get from its organization and how impacting it could be if he needs to answer team’ questions with a delay…
As far as the technical subjects are concerned, it is important that the technical skills of the PO are aligned with the technicality, complexity and ambition of the product. These three axes will define how much technical stories and non-functional acceptance criteria will show up.
In any case it can be difficult to get rid of the habits acquired in one position when taking a Product Owner role. And this is one of the reason to avoid “Scrum, but”: if a PO goes beyond or below the expected scope of its position, it can damage the organization a great deal.
The role of the Product Owner in Scrum is absolutely critical. If a member of the development team can be challenged rather quickly by its peers during ceremonies, the effects of a poorly chosen PO are not immediately visible and often extremely harmful.
And no, in most cases a good relationship with customers and management is not enough to be a good PO.