Sjoerdly's Bits -> new site @ sjoerdly.com

Viktor Grgic asked on linkedin about FIFO or LIFO backlog management. Which one of these options would lead to a better overall delivered product?

My thoughts on this: since you naturally spend more time looking at the top of the backlog, new stuff that is put at the top (LIFO) has to be dealt with quicker, leading to shorter lead times and a cleaner backlog. Stuff that comes in and gets discarded is cleaned up earlier. New work is split up for minimum testable hypothesis and validation of value earlier, etc.

The Definition of Done in Scrum is a super powerful artefact to create transparency around what needs to be delivered to consider a unit of work ‘done’. Meaning, no more work is needed on this item for it to potentially deliver value through a customer release. The concept helps with forecasting, increased transparency and fosters collaboration around the minimum amount of work needed to deliver value at high quality.

The concept I teach in training or when I am consulting is the following. It’s about overall quality, stuff that we have to do for each backlog item before it is releasable and not incurring technical debt, NFR’s might be candidates, documentation, verification, etc. Something we can actually put on paper as a sort of checklist to verify that stuff we started work on can actually be delivered. 

In practice however, there are often people using a DoD ‘field’ in their backlog tool or a concept as part of their user story. What I generally find people actually put in this field or consider to be part of this Definition of Done, comes down to either a list of tasks needed to be done which contains all specific tasks for this item, or a simple list of acceptance criteria (only verification).

To prevent confusion, I advise to call stuff like it is intended. When you intend to use Scrum as a framework for your situation, have a DoD that provides general transparency on what needs to be done to create a shippable increment for each backlog item. Something that ensures a common understanding of quality, that helps make transparent what the development team needs to deliver for the increment to create value. 

An additional win from this approach is that you reduce duplicate ‘documentation’ because you don’t have to include all the general stuff in each user story ‘document’ or tool-entry. 

I used to be like you. I was that Scrum Master who thought that a Definition of Ready was a nice add on to Scrum for starting teams. Teams struggling with clarity in their Backlog Items, teams constantly not making their Sprint Goals and being completely unpredictable in delivering the Sprint Backlog, teams working under heavy constraints from laws & regulations, etc. In all these cases, what is the harm in a checklist of stuff we need to do before we can plan and forecast it as part of the Sprint Backlog and Sprint Goal? The only reason not to use it was simply that experienced teams don't really need it, but what could be the harm in using it as a crutch for starting teams?

 These days, I've come to realize that this way of thinking poses a huge danger for delivering value with Scrum. And I believe I've come to understand why the Definition of Ready is not in the Scrum Guide, while the Definition of Done is. My journey to come to this insight goes all the way back to the origins of Scrum; the Toyota Way or Toyota Production System. In engaging with Lean thinking, the way Lean-Agile mindset is framed in SAFe, in discussions and observations with teams, clients and colleagues…

 So then, what did I realize? What is the reason I believe we should NEVER utilize a Definition of Ready? Why is this such a bad idea that you should really steer clear of it, even though it seems to be helpful? At least for new teams, teams struggling with readiness of their Backlog Items, Teams struggling with making reliable forecasts needed to build trust, deliver customer value and collect the right feedback to fuel their empirical process?

 Flow. The reason we should steer clear of Definition of Ready is that it has the potential to create a barrier for flow. I've seen the Definition of Ready lead to backlogs clogging up with non-ready high ordered items, leading to a loss in transparency for the Scrum Team & Stakeholders. I've seen teams becoming frustrated because the DoR prevented them from 'just' start working on items, while they had the experience that everything that is needed to get to "Done" always gets put in place before the end of Sprint. I've heard scary stories about 'Ready Teams' and two-phase Scrum, all the way up to Water-Scrum-Fall. And yes, with a Scrum Master who is awake, the continuous improvement process should surface these problems and more importantly fix them through retrospectives and solved impediments. But why set yourself up for failure? Why add stuff to the framework that you KNOW creates these problems. Or even worse, introduce a practice that gets embedded in the organizations' way of working until no-one remembers the exact reason why it's there, but no-one dares to suggest to remove this toxic practice 'because this is just the way it has always been'. So please. Do yourself a favour. STOP IT. Next time you hear someone mention the Definition of Ready, ask them what problem they hope to solve. Help them solve the problem with a practice that actually helps. Like the practice of 'Just Talk'. And by all means have a checklist of stuff that previously caused failure, to assist the practice of 'just talking' in refinement and sprint planning. But NEVER, EVER, let the checklist become an artefact that can be turned into a barrier. Don't formalize the checklist into a tool or process where items can only be pulled by the Development Team after reaching a certain state or filling out certain information. You will be contributing to killing one of the principles that the Scrum Framework was built on, and you will be setting the team up for failure. This WILL be on you.

The past half year I’ve been active making the podcast (with the help of the awesome Matthijs of the ProwarenessOndemand.nl platform). In that time, making the podcast I have learnt a lot and there are some things I would like to share about its lessons and developments.

Most important part: If you’re doing this solo (or almost solo, with the help of the awesome multimedia-wizard Matthijs) it goes slowly. That’s ok, but I’m still looking for active collaborators as well as pro-active Product Owners with lessons, stories and cool ideas to share.

Second: A unique name is a really nice thing to have. As I’ve learnt the past months there are a few other Product Owner Podcasts out there, and although none I’ve discovered so far has exactly this name, it is nice to have something distinguishable (is that even a word?). So here is is: The Product Owner Perspective. This also enables my other P.O. focused outings to fit nicely under that label. And by extending from podcasting it looks like I’m able to enroll some brilliant minds to collaborate on blog posts and other stuff. Exciting times. Let’s see what happens next. :)

Lastly, doing off the cuff audio recordings of about 30 mins (or more) talking about whatever comes up is nice for people who listen to podcasts. However, I’ve come to suspect that my target audience, Product Owners, might not be the kind to sit back and spend half an hour on listening to or even watching two people throw around ideas. So I’m planning to experiment with a slight change in format. Not sure where it will lead, but I’m looking to chop up the interviews in specific questions and smaller parts. This way listeners can more easily select and decide what they want to spend time on.

Een collega mailde de vraag; Hoe creëer je veiligheid in een groep. Specifieker:   

Veiligheid creëren in groepen doormiddel van concrete interventies/tools. 

Openheid creëren in groepen. 

Verschillende persoonlijkheden toch laten samenwerken in een groep en hoe dan.  

Een snelle reactie hierop die ik in het kader van ‘radicale transparantie’ wil delen:

Hi ...

Check vooral ook even de groepen binnen Prowareness die zich met Agile HR en High Performing teams bezighouden... 

Wat mij betreft: Openheid en veiligheid in Scrum zit vooral in het proces ingebakken in de daily scrum en de retrospective, waarbinnen met name de focus op TEAMdoelen ipv persoonlijke accountability een belangrijke tool is om af te komen van angst voor schuld e.d. Daarnaast natuurlijk de experimentele mindset; van angst voor fouten maken naar nieuwsgierigheid naar het onbekende door middel van kleine (veilige) experimenten.

 Verder moet ik denken aan deze linkedin post: https://www.linkedin.com/pulse/chipmunk-circles-soft-skills-serious-game-stanislava-potupchik Vertrouwen en veiligheid creeer je ook door simpelweg elkaar als team/personen beter te leren kennen… 😊

Succes!

Sjoerd

In this second episode of the Product Owner Podcast, we have the honour to chat with Patrick de Groot, Product Owner for Politie.nl and other online services. Politie.nl is one of the largest Government websites. Their continuous drive to deliver true value for the Dutch public has been rewarded two years in a row with the 'Website van het Jaar' award, a government first. Patrick shares his experience and insights in working with the Scrum Team and Stakeholders. Specifically about his collaboration with UX specialists, Project Managers & Program Managers; roles you might encounter in your organization.

Please enjoy this episode, and let us know what you think! If you have any comments, tips, input, questions… Please  contact us using one of the following: 

Feedback form: https://www.research.net/r/ZPWTCK6 

Follow us @po_podcast https://twitter.com/PO_Podcast 

Email: [email protected] 

 Links & resources from this episode 

Patrick on Linkedin: https://www.linkedin.com/in/patrickdegrootprr

Patrick on Twitter: http://twitter.com/paddylegrand

The award winning website: https://www.politie.nl

Mobile Media Lab on Twitter: https://twitter.com/MobileMediaLab

 Story Mapping / Walking Skeleton: http://jpattonassociates.com/user-story-mapping/

 Subscribe to the podcast 

Soundcloud: https://soundcloud.com/productownerpodcast/ 

iTunes Podcasts: https://itunes.apple.com/nl/podcast/product-owner-podcast-powered/id1183369330?l=en&mt=2 

TuneIn: http://tunein.com/radio/Product-Owner-Podcast-p941555/ 

Kai Stevens works for Enrise as a client Product Owner Coach.  Since Enrise builds software for various clients from different backgrounds, it is paramount that the value steering is done with the right business insights. However, the 'client' Product Owners are often new to Scrum and what their role entails, so even if they know all about what's valuable to their business, they often don’t know yet how to fulfill their new role. Which is where Kai comes in.

In this podcast Kai explains how he works with his client Product Owners to teach them the importance of Vision, how to get to a starting backlog using Story Mapping and more.  

Since this is the first podcast of a series, we highly value your feedback. If you have any comments, tips, input, questions… Please  contact us using one of the following:

Feedback form: https://www.research.net/r/ZPWTCK6

Follow us @po_podcast https://twitter.com/PO_Podcast

Email: [email protected]  

Links & resources from this episode

Kai on Linkedin: https://www.linkedin.com/in/kaistevens

Find Kai's blogs at Enrise: https://enrise.com/author/kai/

Roman Pichler's Product owner tools: http://www.romanpichler.com/tools/

Subscribe to the podcast

Soundcloud: https://soundcloud.com/productownerpodcast/

iTunes Podcasts: https://itunes.apple.com/nl/podcast/product-owner-podcast-powered/id1183369330?l=en&mt=2

TuneIn: http://tunein.com/radio/Product-Owner-Podcast-p941555/

Learn more about Product Ownership at the Prowareness Agile Academy

Product Owner training: https://www.agileacademy.nl/training/?eventtitle=professional-scrum-product-owner-training

Product Owner Advanced training: https://www.agileacademy.nl/training/?eventtitle=product-owner-advanced

Great coaching wisdom from Dennis Bergkamp (article from the guardian 2013). When you gloss over all the football (soccer) specifics, this paragraph stands out and we can all learn from the wisdom here. 

"There are times not to coach," he says. "You have to be balanced to know that. The urge is to step in and show how good you are as a coach and show you know everything and you can tell them. Sometimes it is better to let them make a mistake. Sometimes they learn more from that than being told what to do." 

In my current assignment as a Scrum Master, I try to be very conscious of when to step in and when to let the team make mistakes. It is a hard decision and as we are one of the first teams to ‘go agile’ and use Scrum as a process, we (as a Team) try to balance the line between educating, failing and showing success. 

Getting the balance is hard, but thanks to my network of colleagues at Prowareness I am supported and challenged to focus on the most important thing of all as a Scrum Master (or Agile Coach): 

Helping the team and organization by teaching the mindset of continuous improvement.

Today was a great leap forward in the product owner podcast development. I’m constantly juggling to find a balance between a lean start and having the minimal required structure to deliver the intended value to the ‘customer’; Product Owners looking for stories and experience of others to learn and improve.

I just got off the phone with Kai Stevens and am very thankful for his time to chat about stuff, and his offer to help me refine my questions a bit. 

I think it’s fun to compare my own current interview structure with the first podcast later on, so to share a bit of the process, here’s the current basic structure I thought up, along with all the previously brainstormed questions ranked by dotvotes (by a bunch of Prowareness colleagues). This has NOT yet been reviewed by Kai, but is loosely based on our conversation of today. 

Basic Interview Structure

Today I read the Happy Melly article on morning routines with much pleasure. I commented with my own routine, and would also like to share it here with you. 

If you have questions, recognize anything or want to give any response whatsoever, I’d be happy to read it! 

As a coach & consultant, I have to travel a lot before my day starts. When I visit a client that is farther away (> 60mins transit) then I adapt my morning routine to shift some stuff to happen in this time.

So my morning routine is flexible, but at a minimum I aim to do the following:

Start out with Feeding the cats, feeding myself (sometimes postponed to the car), get the household started. Do mindfulness exercise of at least 5 mins (pre-shower). I aim to take 20-30 mins (sometimes postponed to the car, while driving to clients). When arriving at work (no matter the location) I start out by making a bullet list in my journaling software (currently onenote) sketching out today’s stuff to do. This includes goals/tasks from my various kanban boards in trello, be it personal, company or project/client goals.

Most important step of the process: reflect on & prioritize this list to get focus on what’s most important to achieve this day.

During the day I check off each point as it is addressed. At the end of the day I review the list and put leftovers that still need addressing on next day’s list.

I currently have a ‘creative hour’ blocked in my agenda for reading/writing around lunchtime, but based on the awesome habits shared here, I’m going to experiment with putting that at the start of the day as well. Mainly because mid-day, there always seem to be other ‘priorities’ that overrule my creative hour.

Side note: I’m quite envious of those here successfully having adopted the zero inbox approach. I have not achieved this yet. Please tell me the secret to making it work, because it sounds quite heavenly.

Thanks all for sharing your day-start and inspiring new ideas!

Just added the page http://sjoerdly.com/productownerpodcast to this site. The podcast is an idea I’m working on to increase the amount of available stories, experience & knowledge for the Product Owner community (if any).

I noticed a while ago that while many excellent resources are available for Agile Coaches, Scrum Masters and various angles on Agile at large, there is no real Product Owner focused knowledge source, let alone a podcast.

Inspired by the Scrum Master Toolbox podcast among others, I’m now workding hard to launch a first episode, interviewing an awesome Product Owner with interesting stories. In the image you can see the results of a brainstorm session among Prowareness colleagues. We tried to come up with the best and most interesting questions to ask a Product Owner in this interview.

If you have any ideas to help, I’m open to suggestions. 

Stuff I’m looking for now are mainly: 

More input on what YOU’d like to learn from other Product Owners

Whether YOU as a Product Owner would like to share your stories

A DUTCH blog I wrote for Infi, about the Lean Agile Coffee Meetup I facilitate in collaboration with them. In this post I try to recall the topics discussed to give people an idea what such an Agile Coffee Meetup is like. I hope you will join me on one of the upcoming ones. You can do so EVERY third friday of the month!

The elusive Scrum Sprint Goal. One of those practices in Scrum that is often neglected or struggled with. Which is a shame since Scrum Teams can benefit greatly from the much needed Focus it provides, when used properly. Recently an aspiring Scrum Master asked me: “Who makes the sprint goal? In the training we discussed the PO makes it, while the guide states the Scrum Team makes it.” In this blog I’ll try to answer this question. If you’re looking for more insights on the Sprint Goal, try Barry’s excellent article 11 Advantages of using a Sprint Goal.

In any discussion about Scrum, especially in the case of prepping for an exam, I’d like to start by looking at the Scrum guide. So what does it say about this topic? 

Intro A while ago I stumbled upon a great initiative, called Action for Happiness. It is a movement of people committed to building a happier and more caring society. Their ideas are based on scientific research and the acronym GREAT DREAM is used to communicate their 10 keys for happier living. The 10 keys are: Giving, Relating, Excercising, Awareness, Trying Out, Direction, Resilience, Emotions, Acceptance & Meaning. Being a Scrum Master and Agile Coach, happiness is something I’m always curious about. I see Happiness as one of the key elements we as coaches should care about in our teams and  ourselves. so I was immediately interested in the movement and have now decided to investigate potential matches or clashes between The concepts in the GREAT DREAM and Agile way of working (and Scrum in particular). Hopefully learning more about improving Happiness & Agility in the process. Let’s start by looking at the first letter of the acronym: Giving. 

Agile & Giving as a key to Happier living

"We make a living by what we get, but we make a life by what we give."  - Winston Churchill The principle of giving in the GREAT DREAM stands for doing things for others. At face value, from the viewpoint of a Scrum Master (or Agile Coach), this is a straight up match. The Scrum Master role is all about facilitating, helping the team & organization. Doing things for others! Facilitating sessions, team growth, coaching people and the wider organization, etc. For the other roles involved, giving is also embedded in the way the Scrum roles are described: a Product Owner should satisfy Stakeholders’ needs (prioritize valuable items to be implemented). Scrum development team members are encouraged to help each other when surfacing impediments during any of the events: sharing knowledge and offering help during the Daily Scrum; collaborating in the other sessions looking for continuous improvement at team and personal level; helping the Product Owner to refine the backlog and manage Stakeholders; etc. In a Scrum team, giving acts an important ingredient in building social capital and growing as a team. "Kindness & caring seem to be contagious: when we see someone do something kind or thoughtful, or we are on the receiving end of kindness, it inspires us to be kinder ourselves." As a Scrum Master we have an important role here: leading by example. If you radiate kindness & thoughtfulness in everything you do, it may spread from one person to the next, ultimately even ‘infecting’ people you have never even met.

What does the research say?

Or: a quick note on using the right language in your app (site).

Today I used the online system of my doctor to ask for a medicine I had previously got prescribed. Very nice to not have to go to the doctor or wait a long time before I get through to the doctor’s assistent. A good example of eHealth in practice.

In a step in this process I got asked to which part of my medical file I would like to refer. I know the body part and layman term for what I need the medicine for. But not the medical term. So I had no way of figuring out which part of my own medical file I had to refer to.  Too bad, because I guess this would have been easier for my doctor to process my request.

What can we learn from this?  Don’t just write <medical term> when  this only makes sense to the doctor, make sure it can be understood by all the users of the system, in particularly (in this case) the patient. Keep it simple, don’t make me think, and especially don’t make me confused!