Agile-ish is “Kind of…..not”

In my experience most middle managers are not interested in becoming servant leaders - command and control is what attracted them to the job in the first place.

Very true. Though to be fair, some middle managers appear to be "not interested" but in fact, they just need to be advised on what the real value of having a servant-leadership mindset is - some end-up being great servant-leaders after being coached and/or after realizing how it's beneficial.

I think that c&c is just a normal stage of a manager who is aiming to become a true leader one day. According to the Tribal Leadership study the most steady servant leader is the one who came to it through the epiphany after been c&c (wild wild west) for many years.

It's not just managers, though. People get used to C&C. I've seen companies where engineers have the Project Manager make technical decisions for them. Not because the PM has ordered that he will make that kind of decision, but because they lack the courage to do it themselves. I'm not convinced that managers just naturally evolve into micromanagement. We enable micromanagement when we ask Managers to make decisions that we should really be making ourselves.

It's a double-edged thing: Managers need to return control to the teams and Scrum Masters must coach the teams to have the courage to use that control.

The core intent of this article is great. However the diagram is a massive distraction with many issues.

Why are there tasks with hour estimates and assignments in the Sprint Planning event? Teams may choose to do this, but it certainly doesn't belong in a generalized diagram. What are all the other additional items on the board?

Why are the Scrum Master and Product Owner in the Daily Scrum event? "The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum."

"The heart of Scrum is a Sprint, a time-box of one month or less" does not equate to "2 - 4 weeks." Scrum Teams could be executing one week iterations (Sprints) or even other less common cadences.

There may be several releases during the Sprint. Yet another reason that simplified diagrams often lead to common misunderstandings.

Why aren't stakeholders, including users, in the Sprint Review event? Input from users at this point in time is the most important, yet it is completely missing.

Why is Process Improvement placed on the Product Backlog? "The Product Backlog is an ordered list of everything that might be needed in the product" and nothing about process improvement.

The C&C problem also shows it's ugly head when Scrum Masters stop being coaches and start taking C&C themselevs.

This part really got me thinking Alan:

Why is Process Improvement placed on the Product Backlog? "The Product Backlog is an ordered list of everything that might be needed in the product" and nothing about process improvement.

We actually use the product backlog to store process improvements also. The output from the retrospective is often tasks that fit well in the product backlog with a definition of done. Then it is easy to have it in the sprint backlog, convenient and works well.

The Scrum Guide also states:
"The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal"

So, if you read this, then process improvements can not be part of the sprint backlog either, since there are no Product Backlog items in the product backlog regarding process improvements. Then how to plan them? Or implement them spontaneous during the sprint?

How does one order, estimate, and value those process improvement items in the Product Backlog? What Definition of "Done" is used? Are you presenting these "Done" process improvement items at the Sprint Review? If they are not "Done" at the end of the Sprint, how is the "unfinished work" handled? Or do these different items have separate standards for each of these aspects? If they are truly separate with separate standards then they deserve, arguably even require, a separate method to track.

I agree that they also do not belong on the Sprint Backlog as you stated and for my previous statements. Additionally, not everything the Development Team does goes into the Sprint Backlog: email, mandated training, meals, bio, etc. Third, the process improvements probably apply and belong to the Scrum Team as a whole while the Sprint Backlog "belongs solely to the Development Team."

Ron Jeffries and Chet Hendrickson recently had some applicable (IMO) thoughts: https://youtu.be/UwYbSBUrot... (The entire video is great!)

Of course The Scrum Guide doesn't explicitly bar process improvement
items from the Product Backlog, but I still need to be convinced that
they belong there. Perhaps answers to my questions and some concrete examples will sway me. Even if they do not, I would like to thank you for your thoughtful response and a great conversation! It's a valuable rarity especially considering that most of the bloggers do not respond: publish and forget it seems.

Hi Alan!

Thank you for your reply and the video, it was interesting! And I agree that some bloggers publish and forget as you say, but I think many bloggers also reply to comments.

I will try to answer your questions to the best of my ability, with an example.

So, I do not know if these example is exactly a process improvement, however it certainly does not have anything to do with the backlog.

The team is using Ubuntu computers, however, there was a critical software that was needed by the team that was only available in Windows. We were the first team that encountered this problem. So, it was decided to try out Wine and if it worked document how to install the software and how to use it.

So it was something like:
"Install Wine on your Ubuntu computer. Run the wanted software with Wine and check the result.

Definition of Done: If the software runs successfully with Wine, document how to install Wine and how to run the software with Wine on the company wiki page. Have a team members try out the instructions to verify that it works. "

The wiki page was made available to all teams in the company. The PBI was also more detailed, however, I should not write those details here.

Order: High order since it was essential that we with Ubuntu computers could run the critical software

Estimate: We assumed one day for the team members to try it out and write the wiki page and also half a day for a team member to verify the instructions.

Value: High, as mentioned with the order.

We where presenting our result at the sprint review.

If it was not finished it would have been re-estimated and put back in the product backlog.

We like it to have it in the sprint backlog for transparency. Also, there is value in "Since last Daily Scrum I have written a wiki page with instructions that worked that you also can use" than "Since last Daily Scrum I emailed, had meals, etc."

So, I think there is a big difference here, some things I believe belong in the Product Backlog and the Sprint Backlog, even though it does not directly affect the product.

That said, if there is a better way to have this transparency and convey the value made since last Daily Scrum, then I say please by all means do that instead.

Thank you for the example. This type of activity is probably best described as a "spike" (research/prototype/proof of concept/safe-to-fail experiment). Whether or not spikes belong on the Product Backlog is also often debated. :)

It appears that you added a "DoD", more like acceptance criteria (with additional tasks?!?!?), to the PBI itself. Acceptance criteria belong to a story/feature; the DoD belongs to the product Increment.

To whom do you present the results at the Sprint Review event? Is it a collaborative event as described in The Scrum Guide or is it a demonstration and status update meeting?

Perhaps some questions affect to consider when determining whether or not something belongs on the Product Backlog. "Do the users want or need this information?" "Who benefits from the value?" The answer to those is contextual of course, depending on the the users. In your example, the value is enough to make me consider (though the original goalposts were moved from process improvement to spike) placing that item on the PB.

Interesting, if I interpret you correctly, you mean that some are adding "spike tasks" in the product backlog? I have so far only encountered organisations using "spike sprint" or "sprint 0"(even though of course, there is no such thing in the Scrum Guide), but no one adding "spike tasks".

It is true that we are using acceptance criteria for a story/feature, and DoD to the product increment. However, in my post I used DoD as you correctly pointed out for one reason only, there is no such thing as an acceptance criteria in the Scrum Guide.

I am always steering towards Sprint Reviews as a collaborative event, however, I can not say that I am always successful, for various reasons.

Good questions and summary of what should be put in the PB. Thanks for a great discussion, I will think more about what should be in the PB and what shouldn't :)

Yes; Spikes as items in the Product Backlog that move to the Sprint Backlog, or just tasks within a Sprint on the Sprint Backlog.

Collaboration in the Sprint Review is a common hurdle.

What should and should not be in the Product Backlog can be negotiable . . . the beauty of a framework.