“A good Scrum master can serve a few teams. A great Scrum Master will serve only one”.

rephrasing Michael James

 

There’s an ongoing debate on whether a team needs a full time Scrum master for the long run or not. Many teams feels that the duties of SM only fills a part of his day, and therefore he can do more than "just be a Scrum Master”.  In some cases the expectation from the SM was to pick up tasks like any team member, in other cases the SM was working with 2 or 3 teams in parallel, and in other teams spread the roles of the SM between various team members (and not having a dedicated person as the SM).  And there are of course many more options.

and honestly speaking, all are valid solutions that can be really effective. What I did learn over the years though, is that no matter how you approach this, you should always keep in mind the following when you decide on how to approach this:

Add a comment

Our_Logo_T_Shaped_People

Why we created Practical Agile?

Get your paper tissues ready, as this is a love story. Maybe we should make a Hollywood movie of it someday. Well, jokes aside, it really is, albeit not in the romantic sense.

Elad, Lior and I set Practical Agile in 2012. To be precise, the day the company was minted was the day of the first Agile Practitioners conference, and the two organizations go hand in hand. One is a commercial organization, the other non-profit.

But I am ahead of myself. A little bit of background first.

The three of us, Elad, Lior and I, had various experiences of working in organizations. By using two vignettes (Elad loves it when I use this word) I will divide these experiences into two major groups:

Add a comment

Not_SAFe

Yes. As the name of the post suggests, we at Practical Agile have chosen not to be involved in SAFe adoptions.

Some may ask: But you are practical Agile and your subtitle is “Agile in your context” isn't this kind of statement in conflict with your own brand? We think not, and this post will try to explain why.

Add a comment

manage_product_backlog

Disclaimer: If you haven't read my “Managing the product backlog for 8 teams“ post - I highly recommend you read it before continuing to read this blog

First thing is first: What the hell were you thinking when you decided that you need 50 teams for your product?! I hope you had a really good reason for it. 9 out of 10 times you have made a bad decision…

 

But here we are, having a product that has 50 teams, which means dealing with ~600 fine grained Product Backlog items at any given moment, i think we can all agree that this is definitely too much for one person to deal with (Disagree with that? Please do not stay silent and comment). So how would we go about and deal with such a big PBL?

Add a comment

How can we help?

Email:
Subject:
Message:
multiply one and three and get

Register to get notified about new blog posts