Ok, so how do Product Owners actually generate great User Stories? Are you tired of reading about how to deliver business value? Is creating big, upfront Business Requirements Documents (BRDs) not working? For those folks looking to create User Stories that are actually usable, please join me on July 29th for a full day workshop on Agile User Stories.
If you spend any time on the Internet at all you'll see something that goes like this-
Kanban vs. or Kanban Against or Kanban After…
I feel like all these are just variations of
“how does Kanban compare to what I do already?”
Okay so remember one of the principles is: Start with what you do now.
If you're doing Scrum right now that would work just fine.
If you're doing Waterfall that would work just fine.
If you're doing sAFE that would be just fine.
The idea isn't in the How, the idea is are we watching our work in such a way to cause us to improve? How many people have gone to a Sprint Retrospective and it's some variation on:
What went well?
What didn't go well?
What do we want to do differently?
Very very traditional approach, right? Now how many teams that you have you seen actually Implement those changes?
Scrum urges us to look for challenges and label them impediments. Stuff that would prevent us from getting our Sprint Goal done. Now the underlying idea here I think is that what we're supposed to be doing in the course of doing our work is to constantly be looking at the ways that our work is challenged or why we can't do something and it's interesting because a lot of times scrum talks about how to identify those Implement but not necessarily how to fix them. Kanban on the other hand says let's look at the work that we're doing and find the areas of opportunity that let us improve using whatever tools or approaches we want to.
One way I like to approach this uses an approach taken from Improv. “Yes, And”
“Yes, And” is a positive way to include in a conversation. In this frame we do Scrum...and. We do Waterfall...and. Kanban provides the model and the ability to predict the effects of change. It shows the areas of opportunity but leaves the type of change to the team.
So if you'd like to know more we have some upcoming training around Kanban and I'm sure we'll talk about scrum a little bit too check it out here.
Many say that the P.O. is the most difficult role in Scrum. There was a time when our team may have even agreed with that statement. As we guide clients changing the way they do work using Scrum and talk with graduates of our classes, we realize something. The Product Owner role isn’t the most difficult role in Scrum.
It is the most misunderstood role in Scrum.
This is a wonderful statement for any Scrum coach to hear. And over the past few years I have heard this or a version of this statement a lot. It’s the inevitable follow up question that has grabbed my attention over the last few years. ’How do we get the rest of the organization to start using Scrum?’
MINNEAPOLIS – October 4, 2018 – Collaborative Leadership Team (CoLead Team), an industry leader in providing Scrum and Agile coaching and training, hosted its sixth annual Scrum Day Minnesota on October 4, 2018 at the University of Minnesota – St. Paul campus. The sold-out not-for-profit event brought together more than 300 individuals from around the region to share their stories and network as a community.