The deceptive role description

The request

In some organizations, it is not uncommon for people to ask for a role description, i.e. some piece of text that describes what they or their colleagues are supposed to be doing. The reason for the request varies, but typically goes in one of four categories:

• The person asking is unsure of what he/she is supposed to be doing
• The person asking is building an argument towards a co-worker, that is believed to be doing the wrong things
• The person asking want it to argue for a raise with his/her boss.
• The person asking is recruiting for a specific role

The response

If you respond to the request by quickly emailing a document, chances are that you are doing the people involved a disservice. Here’s why: there is nothing wrong with role descriptions, except that they are deceptive. They give the illusion of clarifying mandate, responsibilities and tasks, but in reality no piece of paper will give you anything but perhaps a starting point for a discussion.

In my experience, no two people are alike, no two people will interpret a role the same, no matter if they both follow the same role description to the letter. And rarely, if ever, does a role description cover everything that you want a person to do, and you certainly never want a person to be limited what is in the role description.

(Sometimes, the person asking is just being difficult, because they do not like their new role. In this case, the response ”I’ll get you a role description, but only if you promise to do everything in it” gives interesting results.)

In all categories listed above, what the requester really need is support in their specific situation, not a document that was written by some consultant, years ago, for a different organization, in another context, with a different goal. If you, or somebody else, can give this support, then great. Otherwise, there is a trick outlined in the last paragraph.

The solution

Here’s the point: if you honestly want to know what you are supposed to be doing, ask! Ask your peers in the same role as you, your colleagues, your team members, your boss, your customer. They surely have an idea. Dare to ask for feedback on how you are doing, and have a discussion with people you trust about your priorities. And suddenly – and all without a role description – I’m sure you will find yourself doing things, good things, that will help both you and your organization to new heights.

The product owner – team gap

A fully functional, high-performing scrum team includes both a product owner, a scrum master and a development team. The product owner’s formal responsibilities are prioritization and funneling requests from the outside world into the product backlog, while the team and the scrum master grabs work from the backlog and turns it into potentially shippable increments.

However, this is not the full story. Many product owners struggles with the many responsibilities that comes with the role, and therefore – sometimes as a desperate measure to prioritize among their many business activities – delegate a lot of the responsibility to the team and to the scrum master. On the other hand, many teams expect all contacts with the outside world to occur through the product owner,  or that they do not need to worry about managing the product backlog (since that is the responsibility of the product owner).

When the product owner delegates too much to the team, it might leave the team feeling abandoned by the product owner. A good team might seize the opportunity to go ahead a prioritize the backlog themselves – which might work, but also might lead to suboptimal end results. A more challenged team might loose their agile practices altogether. After all, what point is there in having a demo, if nobody cares about the results?

Similarily, when the product owner is unable to fulfil the team’s expectations, the product owner might be frustrated by the teams inability to take the initiative. From the product owner’s point of view, it might seem that the team is waiting around to be spoon-fed ready-to-go-tasks.

I think of this as the product owner-team gap. That is, there is a gap between the decision level, where the product owner has the majority of the responsibility, and the operative level, where the teams technical expertise is required to refine and execute work.

This gap might seem superficial, because in no overview of Scrum there is such a gap. In reality, though, it almost always exists, at least at first.

One of the key ingredients in getting the entire scrum team to a higher level of performance, is to make sure that this gap is bridged. Either the product owner understands the importance of taking a step towards the operative level, and makes an effort not only to be present at refinement meetings, sprint planning meetings and so on, but also to truly understand the teams work environment and the teams needs and wants. Or, the team takes a step up to the decision level, and helps the product owner understand and prioritize the backlog. This means – among other things – that the team must make an effort to explain the contents of technical work on a level that the product owner can understand and relate to. The team must also explain why they need a product owner present in their day-to-day work.

For either of these solutions to work, it requires patience,  good understanding of agile values and preferrably the presence of an agile coach. Also, a key to success is interest in making it work. Without that, as usual, all approaches will fail.

 

How will they solve it?

I’m sure you have all been there. You know, that discussion that does not really solve anything. Perhaps you took part in it yourself, discussing that problem that your organization is having. All of you in that room agreed that it is a big problem for you, for your entire team, for the entire organization. You talk about how wonderful it would be if this problem could go away, you analyze all the terrible situations that will occur if it does not. You leave the meeting with a sense of having reached some profound conclusion, some deeper understanding of what is wrong with your organization, and you wish that they, the people really responsible for fixing what is wrong, could receive the same epiphany.

Here’s an unpleasant truth: unless you act on your new-found knowledge, what you just did constituted waste, and it should be eliminated.

”Come on”, you say, ”we must be allowed to have discussions about our problems. What about our retrospectives? Surely we can have those?”

Yes. Of course. But here’s an easy tell-tale sign if your discussions consititute waste:

• If you are talking about ”how we will solve the problem”, it is a valuable discussion.
• If you are talking about ”how they will solve the problem”, it is probably waste.

The difference in only one word, but it it makes all the difference in the world.

---

Please also see this  video from Jeff on this topic.

 

Story points and hours

A very common question from teams starting out with Scrum, is that about story points vs hours. How is estimation done? Can we use hours instead of points? Isn’t it the same thing? (Hint: it’s not.)

Before we proceed, I would like to make it clear that there is no definitive, general answer to how estimation should be performed, or whether you actually should be doing estimation at all. Every team must find its own answer. However, I find that the following is a good starting position.

And to get us going, we should start with the ”why?” before getting to the ”how?”.

Story points

Story points, or just points, are used in Scrum to estimate the complexity of an item in the product backlog. The estimation are typically done during refinement meetings or at the sprint planning meeting at the latest. Poker planning or swim lane sizing are common estimation methods. The purpose of the estimation is not only to get a complexity estimate – and therefore help the product owner in prioritizing – but also to check that the team has the same idea of the effort involved. The estimate is then used during sprint planning by the team to know how much work to commit to for the upcoming sprint, perhaps based on the number of points done during previous sprints.

Hours

Hours are used when estimating the tasks that needs to be done in order to reach the acceptance criteria specified in the product backlog item. If the remaining effort on each task is updated regularly during the sprint, it is possible to create a burndown chart that visualizes how much work remains to reach the sprint goal.

Comparison

	Story points	Hours
Estimate of…	Complexity	Work
Estimated at…	Refinement meetings	Sprint planning
Can be used to answer…	How much work can we manage in a sprint?	How much work remains in a sprint?
Are updated…	Never; or possibly at start of next sprint if not done.	Regularly.

There is no conversion factor between points and hours. Never. Ever. There is a correlation between the two, however. You would expect an item with small complexity to have tasks that sums up to a small amount of hours – but this does not always hold.

Misusing the estimates

It might be tempting to reuse the hours estimate for other purposes than the one stated above. For example, you might feel tempted to grab the number of hours from a number of tasks, multiply by some hourly rate to get a cost estimate. That is a bad idea, since that was not why the estimate was made. In fact, any idea to map the hours of the task estimates to any other measurements of hours, such as the team’s available hours, is probably a very bad idea. If you need such an estimate, ask the team explicitly for this.

Story points and hours

Do we need to do both story points and hours?

If you do not care about how many points you commit to, but instead use some other method (perhaps your gut feeling?) to know how much work to put into a sprint, then you do not need points. Beware, however, as it is quite likely that you will miss out on necessary discussions during refinement meetings.

If you do not plan to visualize the amount of remaining work, or use some other way of visualization, or if you are unable to regularly update the remaining effort, then you do not need hours.

Conclusion

Each agile team must find its own way in doing estimates (if at all), but to avoid the common pitfalls you should understand how Scrum has been implemented before. Story points and hours are used in different circumstances, and the estimation for product backlog items and tasks have different purposes. Be aware of this.

And when someone asks you to estimate the entire backlog in hours, remember to ask ”why?”.

The Backlog Team Incompatibility

In theory it is simple. You form a cross-functional team, you set it up with a visual, prioritized backlog, and away you go on your journey towards agile.

In theory, your team can handle anything you throw into the backlog. The team is a software factory that churns out quality code with regular intervals and everybody in the team is happy with their new role as a team member.

Theory – meet Reality. Reality – this is Theory, that I’ve told you so much about.

In reality, all team members cannot – because of skill set or experience or role (or even, in some cases, their long term career plan) – handle (and not even contribute to the completion of) the work items that goes into the backlog. Regardless of the reason, I call this the Backlog-Team-Incompatibility (BTI).

There might be several causes for the BTI to occur – perhaps the team was originally formed for some other purpose, or the team has members with some competence that is no longer required – but it does not matter. Somehow, the BTI must be handled, and sooner rather than later.

The short time span

Depending on the team, it might be the scrum master or the team members themselves that becomes aware of the BTI. A team member suddenly has no more suitable tasks, and the new tasks on the board are simply not a good fit. Do not worry! This happens to all teams, all the time. Take this as an opportunity to pair program, learn new things, share knowledge, work on that system documentation, set up a build server or test routine or something else that the team will benefit from.

The average time span

If a team member consistenly is suffering from BTI, and the team feel that they have exhausted their possibilities of resolving this situation, the product owner must be notified. Perhaps there might be suitable tasks with currently a lower priority that could be worked on? It is in the best interest of both the team and the product owner to keep the team both intact and productive, and if that means that the team temporarily does not completely work on the highest priority items, the trade-off might be worth it.

The slightly longer time span

If the BTI persists over time, the issue must be brought to the team member’s manager. Remember, it is not because the team member lacks

competence he or she lacks suitable tasks – it is just a ”case of BTI”. Again, it is usually preferrably if a solution can be found without making changes to the team. Perhaps the team member can use training or coaching to find suitable tasks.

The longer time span

If the BTI still exists over a longer period of time, the team member’s manager must take action, and remove the team member from the team. Again, it is not anyone’s fault – it is just an incompatibility.

 A final word

It is important that the issue is discussed early with the product owner and the manager – exactly when depends on your situation, the severity of the BTI and the economy of the project (for how long can you afford to not utilize every team member?). The team or the scrum master can and should try to solve a BTI by themselves, but this might prove to be very difficult. And if the BTI is not resolved, the delivery, the team, and the team member will all suffer.

 

Agile for the non-development team: a practical guide

I have no idea what this has to do with the article, but they sure are cute!

Disclaimer: This article was intentionally written for an audience that do not know or care about the terminology of many of the agile methods. If you are a hard-core agilist, please look away.

Let’s say you have a group of people that want to try agile, but you are not sure where to start. If you have been working without any real method before, then Scrum might seem a bit heavy-handed, and Kanban scares you off with rules and an unfamiliar terminology you do not quite understand.

This is how you (might) do it.

1. Start off by taking any large piece of the wall (or a whiteboard), and create three columns: to-do, doing, done. Take all your current and upcoming tasks from all your group members and put them down on post-it notes. You don’t have to write an essay on every note, just enough to make it clear what each note represent. Put them up in the appropriate column.
2. Explain that each member of the group is responsible for updating their own notes, moving them along the board, and putting up new ones as new tasks appear.
3. Make an agreement with the group that they meet every other week for two hours and discuss how to improve the process.

Really, the only necessary and mandatory step is 3), the other ones are just there as a conversation starter.

Depending on your group size, the two hours might look different. The important thing is that you have a meaningful discussion, and that you walk away from the meeting with at least one action, change, or experiment that you want to try for the upcoming two weeks.

Issues and experiments that might solve them

I cannot tell you what issues you might run into – that will be different from every group – but here are a number of issues that might come up and experiments that you could try to solve them:

”I cannot work on my tasks, because x is on vacation”.

Working in a group, or a team, requires each task to be the responsibility of the team, not a single individual. Try collaborating more, making sure that every task can potentially be done by at least two different people in the team (who do not go on vacation at the same time).

”It is unclear what ‘done’ means”.

Book a meeting where the team decides on what done means for different tasks. Create a short definition and put it up next to the board so that everybody can see it.

”Our to-do column is overflowing”.

Only put up tasks that you are planning on doing for the next two weeks (or whatever time span seems reasonable) in the to-do column. All other tasks can be in a longer list in a spread sheet or on a physical to-do-list.

”I do not know in which order I should be doing my tasks”.

You probably need to have someone help you prioritize your tasks. Who this person is, depends on your business. Preferably, it should be someone from the receiving end of whatever your produce.

”My tasks are too big, and just get stuck in the ‘doing’ column forever”.

You probably need to break down your large task into smaller ones. It is a good idea to do so before the task end up on the to-do-column, but not too early either – the prioritization might change. Gathering the team to discuss upcoming tasks regularly will help.

”My tasks have a good size, but they still seem to get stuck in the ‘doing’ column”.

You are doing too many things at once. Try to prioritize and get one task finished before starting a new one. You could try to set a reasonable limit on the number of notes in the ‘doing’ column. This means that instead of just choosing a new task when you get stuck with the current one, you must ask for help in order to get it to ‘done’.

”I do not know what others are working on”.

Perhaps a short meeting everyday can help? Focus on this meeting is to update everybody, but also to be able to ask for and offer help to the other group members.

”I can see that a lot of tasks are in ‘doing’ column, but not who is responsible”.

Simple: if you are responsible for a task, write your name the note.

”What we are doing are being questioned by outside stakeholders”.

Set up a meeting, perhaps every two weeks, where you show what you have done, are doing and why.

”There are too many external disturbances”.

Explain to the outside world that you are now a team, with a prioritized workflow. Any additional work should ideally go through that workflow. Invite people to your meetings, so that they can see how you work.

This is agile

Wait! you say. Is this all there is to it? Is this agile?

Well, yes, it’s a perfectly valid start. Communicate. Be creative. Dare to try. Improve. Go for it.

Introducing: Agile

Will it work with…?

Since a while back, I have a new assignment: introducing agile methodology in a major organization. I’ve also recently been in contact with other organizations, interested in replacing their current methods with agile. Now, these aforementioned organizations do not have that much in common, but they all voice concerns about making the transition to agile: ”will it work?” is an obvious question, while another – but just as common – is the extension ”will it work with our existing methods, roles and processes?”

Now, I find the latter question more interesting, because somewhere in there is a bigger issue. It indicates a conservative desire to keep everything as it is, while benefitting from the new. Perhaps that is human nature. But more serious is that it, when probing with follow-up questions, indicates an organization where several such method initiatives have come and gone over the years. Each such initiative have been preceeded by discussions on effectiveness, communication, structure, tools, etc. From many co-workers point-of-view, there is no difference between ”introducing RUP” or ”introducing agile”. It is just another one of a long line of changes supposed to improve their process, driven by consultants (such as me), after a while being replaced by another intiative when the results did not live up to the hype.

Methodology inheritance

The question ”will it work with…” thus also implies, that the employees have to live with a large flora of more or less related methods, roles and processes, sometimes being forced to perform tasks that belongs to a role long since obsolete. They still do them, because they always have done them, or sometimes, put bluntly, it might be a bit unclear as to what their current role actually are supposed to do.

You might by now see where this is going, but here it is spelled out: there is no point in blaming your existing methodology for its supposed short-comings, when you are actually not doing what the methodology tells you to. The same is true for agile. You could with some effort apply Scrum, do it by the book, and still not be very happy with the result. You could with much more effort apply SAFe – or some other agile scaling framework – after which you would throw your hands up in frustration since nothing has improved. The only thing you achieved was more confusion.

Inspect and adapt

Here is the catch: you do not ”apply” agile. You are agile. There is no agile ”method”. You inspect and adapt. And this is the difference between ”introducing agile” and all those other, previous initiatives: agile is all about attitude and mentality, and really very little (or nothing) about a preset number of documents and rituals.

Since nothing is a very tough starting point, there are a number of methods or frameworks that previously have proven to be successful that you can start off with. But they are not intended to be used as-is, and they are certainly not intended to be the ultimate agile goal. ”Introducing agile” is thus, in itself, a large exercise in inspect and adapt.

Thinking agile

When done correctly, the people in the organization will start to think agile, which in turn might lead to it actually making the necessary changes in order to achieve the desired effects. By inspecting and adapting, we can make agile working with just about any other method (if truly necessary, otherwise our agility allows us to remove the obsolete obstacles).

Now, the road to agile is not easy. It requires quite a lot of work, inspiration, education and perseverance. I know a consultant that might help you with that. 🙂

Keeping track of things

This is a post about how to manage yourself and being a better Scrum Master. In short, this means that you:

• always keep an up-to-date, personal todo-list
• follow up on that todo-list.

Read on, for the slightly longer version…

The other tasks

An appreciated quality in a Scrum Master (or project manager or really any responsible leader) is the ability to keep track of things that needs to be done, and make sure that they happen. Now, I am not talking about things that should go on the teams Kanban board, but rather other stuff for which the Scrum Master typically is responsible: talk to people in the project, discuss with stake holders outside the project, book meetings, arrange team activities, negotiate with resource owners, etc.

(It does not have to be the Scrum Master that performs these tasks, but with a team of developers, there is a non-negligble risk that nobody else is interested in doing this work.)

These tasks originates from a number of sources, but common for all of them is that somebody relies on you, as a Scrum Master, to see to it that they get done. If you do, chances are the work will run more smoothly, and it also comes with the personal benefit that people will see you as a responsible person. If you don’t… well, the really important stuff will be remembered anyway, but you just missed an opportunity to help the team with one of the things they really need you for.

Keeping track of it

One of the things that I practice, is to keep a notebook with me to every meeting. You should too. It should be a nice notebook that you feel comfortable carrying around. It is also important that you do not loose it, and just use whatever you have lying around on your desk (you will see why in a moment). And it should be with you always, even if it is just a stand-up meeting or a brief chat with a colleague. Writing stuff down helps your memory, so write at least a few lines every meeting. Now, things that you are responsible for, mark them clearly in the notebook with an arrow in the margin.

Back from the meeting, or at the very latest at the end of the day, transfer all your yet unresolved arrows from the notebook to your todo-list software. You could use any todo-list, but I tend to use Outlook, mostly because its always there and its also, automatically, on my phone. I can also flag emails directly – in Outlook or on the phone – and make them show up in the todo-list.

This transfer into the todo-list might not always be that simple, since there might be information in the notebook that needs to go with the todo item, or the todo item might need to be broken down into multiple tasks. But here’s the thing: it does not need to be perfect. As long as it is on the list, you can always go back and find the note – or the email, or the contact information, or the special circumstance surrounding the item – fairly easy.

Forgetting it

With your responsibility now on the list, and synced with your phone, you can now forget it. Don’t worry, chances are you won’t, now that you have written it down, but its okay if you do. And if you do, it is still there the next day you open Outlook or your todo-list on your phone.

Sorting it

The todo-list might need some attention, once a while, when you categorize the items, set end dates, or do whatever your todo-list software allows you to do. I have found that it helps to add information, such as phone numbers or due dates, directly to the title of the item – but really, I’m sure that you will find a way to suits your own needs.

But, and this is very important, remember to clean your list often, preferably at least once a week. Set aside time to do this, perhaps 15 minutes every Friday morning. Remove stuff that has already been done, or are no longer current. Prioritize the remaining items. If you do not, and keep adding stuff, you will soon stop using it because you just end up staring at stuff that are irrelevant.

Getting it done

Now, what do you do with your prioritized, cleaned todo list? Well, that is easy: you start from the top and work your way down.

But I can think of at least one other use for the list. Before going into a meeting – no matter what it is – scan your list of todo-items and see which ones are relevant to bring. Do you remember the notebook that comes with you into every meeting? Write the relevant items down into that notebook, and use that as a simple agenda.

Used right, the notebook-todo-list combo can function as a sort of collective memory for the team; put it into your notebook with an arrow, and that thing that you simply should not forget to bring up in the next meeting is there when you need it.

Reflecting on it

While your team mates are busy producing high quality software and are steadily moving things on your board into the ”done” column, the work you do as a Scrum Master is typically not that readily visible. Well, until you look at your own todo list, and unhide the amount of ”done” items. It is a good idea to now and then look at this list, just to get an idea of the amount of work you actually do – and it can be quite a lot, at least with a mature team that happily leaves managerial task to you.

---

I am sure there are other ways to keep track of things, but I have found that this combination of analogue and digital works excellent. It might be preferable to use a computer or a tablet instead of a notebook, but I have found that the notebook disturbs a meeting less than the alternatives. I have also tried personal Kanban boards, but I have found that I do not need the extra complexity – a list suits me fine.

What is your experience with todo lists from your work as a Scrum Master/project manager?

Celebrate your victories!

A complaint that is sometimes heard about agile techniques such as Scrum and Kanban is that there is no relief for the developers – they are always sprinting, or there is always some task with top priority. Compared to a more traditional technique, this is true – we prefer to have a steady flow of things to do instead of increasing heaps of unfinished work when the deadline approaches.

But with continuous delivery in place and having a steady sustainable pace, you might miss something: the sense of accomplishment that comes from just making the deadline and the relief that follows, knowing that for a time, you will have the time to do all those tasks that you put off. If all goes well, you might even have cake. Or champagne. Or both.

There is no reason why you should not have a sense of accomplishment or cake (or champagne. or both.) when using an agile method! The problem might be to see when there proper occasion is for this. It is too easy to forget what you actually did two months back – sometimes you cannot even remember what happened a week ago.

My suggestion, and also how we implemented it in the Project, is to have it in association with the sprint review or demonstration meetings. Depending on your sprint length, it might also be a good idea to attach it to a special accomplishment meeting, where you review the accomplishments made (both developments in practices and in code). As a scrum master, this meeting is your responsibility. Set aside half-an-hour for this, and then have cake (or champagne. or both). Invite the Customer and/or the Product Owner to join!

If you, or anybody else, have trouble motivating this towards the Customer or the Product Owner or whoever pays for the time and the cake, mention that the cake is no cost compared to the improvement in morale the team will experience.

Is the Scrum Master a full time job?

This is a discussion I hear a lot. The Scrum Guide has a list of duties that a Scrum Master performs, and while it is not clearly stated that it is a full time role, it is quite clear to me on reading it that it is intended to be. This is my least favourite motivation for why to do something ”Because Scrum says so”, so let’s look at this question a bit more in-depth and decide if you need a full time role?

What does a Scrum Master do?

The duties and activities of a Scrum Master are many and varied, they will take on different forms depending on what the organisation needs at that point in time. So, listing everything a Scrum Master does would be a very long list indeed. So, for the sake of simplification I am going to break it down to one central responsibility:

”A Scrum Master helps to facilitate change and improvement.”
People have a natural tendency to focus on the here and now, and things that need to be solved today, they focus on things that are urgent (time sensitive tasks) but not things that are important (not time sensitive but often more valuable). This is why we have the role of the Scrum Master in Scrum, their job is always to focus on the important, while the team is often occupied focusing on the urgent. While your team might be focusing on implementing new features, a Scrum Master focuses on how we improve our requirements handling to make sure they are easier to implement the next time. While each team member focuses on their own coding, a Scrum Master focuses on how we can help the work together as more of a team, so they can swarm problems rather than fix their own tasks.

We cannot afford a full time Scrum Master!

I think it is looking at the question completely backwards, the question we should be asking ourselves is ”What is the return on investment of having a full time Scrum Master?”

To demonstrate this, I will use some very simple back of the envelop math, nothing scientific just a quick calculation.
The maximum size of a Scrum team is 9 people. Add to this the Scrum Master and Product Owner makes 11.
For the purpose of this calculation we will assume everyone is paid the same.
In this calculation we will use the term ”Improvement” to indicate both efficiency and effectiveness gains.

So, the question is ”How much of a recurring improvement does a Scrum Master need to facilitate to have a justifiable ROI?”

Team time / team size = required improvement
100% / 11 = 9.09%

So, a Scrum Master needs to find and facilitate an improvement of 9.09% in order to break even week after week. Everything over and above that is money in the bank!

Now the question becomes, “Can this person truly find that much of an improvement?”

Some example improvements

As I do not always precisely track my work, these numbers will be fairly rough, but I think enough to show my point.

Refinement

One of the most normal situations I encounter are teams who are having long and unproductive sprint planning meetings. I find the simplest way to counter this is to have regular refinement meetings where we look at the product backlog and mould it in to usable shape. My previous team was having sprint planning meetings that went on for at least a whole day. After instituting a regular refinement meeting (1 hour every 2 weeks) we were able to shorten that to at the very most 2 hours (often much shorter).

So, we had saved the team 44 hours a month. Or a 2.5% improvement.
This doesn’t even count the less measurable benefits of higher quality output, better requirements, and a happier, more engaged customer.

Quality Cost

Poor quality is a huge source of waste in companies. Bugs are occurring in production, which require immediate attention. The team need to interrupt its ongoing work to focus on fixing the issue. The problem with this is, when an immediate fix is needed the natural human behaviour is to address the symptom instead of the underlying cause. So, we do nothing to prevent the bug from reoccurring the next time and eating more of our time. An experienced Scrum Master will catch this, and work to visualise these issues so that patterns can be found and the most costly issues can be addressed by the team.

Let’s say you get 10 bugs a week, and each disrupts your day for 1 hour (both pretty low estimates in most teams I encounter).
If we identify, and fix the root causes instead of the symptoms, we saved 40 hours a month. Or 2.27%.

Once again, this does not count the less measurable benefits like more satisfied customers, code bases which are easier to work with, preventing technical debt which comes with a maintenance cost, and less cost of task switching.

Helping the entire team pays back fast

These are some fairly simple examples but I think you are starting to get the idea: when you help the entire team, it starts to pay back very fast. And in my experience, the biggest improvements happen in those less tangible areas I mentioned. For an experienced and dedicated Scrum Master, 9.09% is easy!

Can’t this be done in a part time capacity?

So, we are able to demonstrate that a Scrum Master is able to pay for their role, but does this mean they NEED to be full time in order to achieve these results – could they not do the same work in a part time capacity?
Well, yes and no… Or, as they say in Sweden, Nja…

I am not saying you won’t get some value out of a part time Scrum Master, but, facilitating improvement is not work that can always be planned and actively executed. It often involves being around at the right time, or even if you are around, in the correct mental state to identify the opportunity and act on it. As mentioned earlier, someone needs to focus on the important, not just the urgent, because urgent is always treading water, important is where we move forward.

So, ”Can we do this in a part time capacity?” I think is the wrong way at looking at the question. Instead you should ask yourself:
”How much do we lose every time an improvement opportunity is missed?”

With this in mind, I think the central question is not ”Can we afford a full time Scrum Master?” but ”How can we afford NOT to have a full time Scrum Master?”