sjoerdly

[sjoerdly]

Moving over to sjoerdly.com

adding posts & articles slowly but surely but prioritizing a home for the Product Owner Perspective series.

[sjoerdly]

Putting new backlog items at the top by default for shorter lead time and earlier value validation

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.

So definitely go for LIFO backlog management IF you have to choose.  The reality might be somewhere in the middle, but I'm curious to hear your experiences and thoughts. This idea may help you to keep a healthier, less wasteful more transparent overview of the possible work ahead. So try it!

[sjoerdly]

The Scrum Definition of Done is not a User Story element

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. 

Next time you encounter a situation where people talk about, ‘oh thats in the DoD of story X’ or similar expressions, please help them learn what a Definition of Done is intended to do and how to prevent this duplication of information (and subsequent wasteful work and loss of transparency) that does the opposite of what the DoD is intended for. 

[sjoerdly]

If you believe in Flow then please stop using a Definition of Ready. Just stop it. Stop it now.

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.

 If you want to enable flow, don't use a Definition of Ready.

[sjoerdly]

Podcast development update: New name and a half year on

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.

Looking forward to another half year of Agile Product Owner knowledge sharing!

[sjoerdly]

First post of the Product Owner Perspective series is live! In this series I aim to put a P.O. Perspective on various Agile phenomena. Starting out with Scrum. So this post is all about the Definition of Scrum. 

Feedback is more than welcome, I’m looking to improve the articles over time to optimise their value for the people reading them. :) 

A P.O. Perspective on the Definition of Scrum

In this series I aim to put a Product Owner perspective to the elements of the Scrum Guide. Where else can we start then at the definition? We’ll discover the most important elements for a Product Owner and what they mean in practice.

Definition of Scrum according to scrumguides.org

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

What I believe to be essential to being a great Product Owner begins with understanding the bold parts in this definition, as well as their relation to the rest of the parts.

First off, we encounter address complex adaptive problems. As a Product Owner, your role starts with understanding the problem your product is trying to solve. You are not simply the owner of a Product for the products sake, no more than a shoe is made for standing on the shelves. Although the sheer amount of shoes in any city center’s shopping district might point to the contrary. Just like the sheer amount of seemingly useless software products in existence. By investigating and investing in knowing the problem you’re trying to solve, you automatically get a step closer to understanding the customer and a better grasp on the choices you need to make to improve the Product you manage. Scrum helps you employ an empirical process, working with the Agile mindset and principles in a complex problem space. For more on Complexity and how to know whether you are in a complex problem space, look at Cynefin and/or the Stacey Model. Scrum’s iterative and incremental nature helps you as a Product Owner to continuously adjust your solution for an adaptive problem, your moving target.  

Further along there’s products of the highest possible value. As a Product Owner, Scrum helps you focus on delivering value and minimizing risk. Scrum enables continuously reprioritizing according to new information, focusing  the Product Owner’s goals by placing the most valuable items on top of the backlog. Another way Scrum enables delivery of highest possible value is through time-boxed Sprints, where the Scrum Team’s assumptions and hypotheses are validated or discarded in short iterations. Having a limited amount of time and a lightweight plan prevents waste and spending too much effort and money moving your Product in the wrong direction.

Those two parts are in my opinion the most revealing and valuable parts of the definition from a product owner perspective. However, since Scrum is a lightweight framework, you’ll be hard pressed to find any non-relevant information in the guide.

Let’s look at A framework within which people can… Scrum is not a complete methodology. For a Product Owner it is important to notice that Scrum won’t tell you how to manage your product. How to create a vision. How to collaborate with your stakeholders. Scrum simply helps you by providing events, roles and artifacts to enable creative value delivery with minimal waste. This is also captured in the wording of while productively and creatively delivering. In a complex problem space, the Development team needs to be creative to address the problem. The development team needs to be able to self-organize to reach high productivity and fast delivery. All to enable you as a Product owner to focus on optimizing value and quickly validate assumptions and hypotheses. So although Scrum does not describe how to manage a Product, it does help you by providing a minimal structure for turning ideas into product (features/functionality) and the way you as a Product Owner collaborate with the other members of the Scrum Team and the product’s Stakeholders.

In summary, for the Product Owner, Scrum helps people (the Scrum Team and the Stakeholders) address complex adaptive problems, enabling the Development team to be productive and creative, while you focus on optimizing value through managing the Product Backlog.

[sjoerdly]

Korte gedachte over creëren van veiligheid

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

PS meer over Agile HR en andere Prowareness Proposities vind je op Prowareness.nl en bij onze Academy: www.agileacademy.nl/hr 

[sjoerdly]

Stakeholder collaboration for a large public website – P.O. Podcast #2 - Patrick de Groot

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: Productownerpodcast@prowareness.nl 

 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/ 

 Learn more about Product Ownership at the Prowareness Agile Academy 

[sjoerdly]

Coaching Product Owners when working as a contractor Scrum Team - P.O. Podcast #1 - Kai Stevens

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: Productownerpodcast@prowareness.nl  

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

SAFe Product Management/Product Owner training: https://www.agileacademy.nl/training/?eventtitle=safe-product-management-product-owner-training

[sjoerdly]

Becoming a better coach: resist the urge to step in

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.

Keeping this goal clear in my mind helps me make choices and explain them to the people I’m working with. And it is also why I love my job!

[sjoerdly]

Basic Interview Structure for the podcast

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

Introduction

Who are you?

What is your agile experience?

How did you become a product owner? Why?

What is your PO-’level’ (range BA to mini-ceo)?

The good stuff

Vision; what is your approach to conceive and communicate the Product Vision? How do you make the connection to Sprint Goals (if any)?

Refinement; What is your role and approach here? 

Business Value; How do you determine BV? If not, why? 

Stakeholder Management; How do you make sure the right Stakeholders are Involved and engaged? Where in the Sprint do you involve SH (Review, Refinement, collaborating directly with the team)?

Bonus: What is THE single most important thing for a product owner to know/do? What do you spend most time/energy on in your role as a PO

Closing/recap

Are you currently involved in ways to share knowledge/experience between Product Owners? Where/How?

Where can we find (more about) you? Blog/twitter/linkedin etc.

What do you think of this structure? Let me know!

As a bonus: We did the brainstorm of questions in dutch. Because we came up with MANY possible questions, I do not intend to translate them. But below you’ll find them nonetheless. The above set of ‘good stuff’ is compiled from the top questions in the list below.

5 Wat is het doel van je team? 5 Hoe bepaal je business value? 5 Hoe zorg je ervoor dat Stakeholders komen (en blijven komen) 4 Wat is het lastigste in jouw rol? 4 Hoe meet je geleverde Business Value? 4 Hoe krijg je feedback en wat doe je er mee? 3 Hoe bepaal je de volgorde van je Backlog? 3 Hoe heb je je product bepaald (en vertaald naar een backlog)? 3 Slicing: hoe doe jij dat? 1 Hoe breng je werk naar het team? 1 Hoeveel tijd besteed je aan Stakeholder mgt? 1 Hoe houd je Stakeholders Tevreden? 1 Hoe helpt de SM/AC jou? 1 Hoe doe je de refinement (en hoe vaak en met wie)? 1 Hoe ga je om met acceptatie criteria? 1 Hoeveel mandaat heb je? 1 Hoe ga je om met D.O.D.? 1 Hoe werk je samen met andere PO's? Hoe ziet jouw ideale review er uit? Wie schrijft de PBI's Hoe zorg je dat je betrokken blijft bij het team? Hoe (vaak) zeg je nee? Heb je een team backlog of product backlog? Wat voor soorten werk staan er op je Backlog? Heb je een Backlog item template, en zo ja, hoe dan? Hoe betrek je end users Wat doe je met klachten? Hoe vaak leveren jouw teams releasable software?

[sjoerdly]

My morning routine these days

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!

Check out all the great routines from the Happy Melly members and enthusiasts here: http://www.happymelly.com/how-to-spend-the-first-30-minutes-at-your-desk/

[sjoerdly]

Idea: Product Owner Podcast

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

Which media is your choice for consuming this?  Podcast (audio), Webpage (text), Vodcast (video), etc.?

[sjoerdly]

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!

Find the meetups here: https://www.meetup.com/agileholland/events/232426710/

[sjoerdly]

Sprint Goal in Scrum: Whose responsibility is it?

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? 

Let’s have a look at the Sprint Planning description, where the Sprint Goal is part of 'Topic One: What can be done this Sprint?’. In Topic One of the planning, the selection of Product Backlog Items to be included this Sprint is determined by the Development team in collaboration with the Product Owner, after which the Sprint Goal is crafted.

The guide states: 

“The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal.” 

Furthermore, the section closes with: 

“After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.”

So the Scrum guide is very clear about this. The Scrum Team crafts a Sprint Goal. The wording may be different, but to me that says: the Sprint Goal is a Scrum Team responsibility.

But what is the responsibility of the Product Owner in relation to the Scrum Goal? Yes, he’s part of the Scrum Team, so he is also responsible. But what is his specific contribution? The Product Owner’s main responsibility in Scrum is Value Maximizer. To maximize value, the Product Owner’s responsibility is to have a well-refined Product Backlog, to enable clear communication and deliberation in the Sprint Planning. The Product Owner should have a vision of the goals he/she wants to reach in the coming Sprint. This is reflected in the ordering of the Backlog, but can also be summarized in an initial Sprint Goal, which can be shared with the Development Team upon discussing the top of the Backlog in Topic One of the Sprint Planning. However, the ‘final’ Sprint Goal is clearly a Scrum Team responsibility: after discussing the Backlog Items that can be taken into the Sprint, the initial Goal can or must probably be refined to take into account new insights.

To summarize: As per the Scrum Guide, the responsibility for crafting a Sprint Goal is for the Scrum Team. It is however in large part of interest to the Product Owner to support this process by having clear business goals for the coming Sprint, which can also make ordering the Product Backlog a lot easier by providing Focus. 

[sjoerdly]

Agile Happiness pt.1: The role of Giving/Helping in Agile

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?

1. Impact on team collaboration

Helping increases happiness: "If people are altruistic, they are more likely to be liked and so build social connections and stronger and more supportive social networks, which leads to increased feelings of happiness and wellbeing.” High-performance (Scrum) teams are what we strive to help create as Agile Coaches & Scrum Masters. But for any situation where team-work is needed, this will apply and help improve the team collaboration by building stronger social bonds.

2. Impact on your mental state

"Giving literally feels good. ... Giving to others activates the reward centres of our brains which make us feel good and so encourage us to do more of the same.” Again, in High-Performance Teams, feeling good ties in to better ways of having constructive conflicts, creating a positive atmosphere and high energy.

3. Impact on your health

Giving does you good: "Giving may increase how long we live. … Volunteering also appeared to predict maintenance of cognitive functioning… it may be that volunteering is one intentional activity that people can engage in as a strategy to increase wellbeing and maintain optimal cognitive functioning in old age.” Note here that the last two sentences refer to studies about volunteering, so it may not be valid to expand their conclusions to ‘giving’ in a broader sense, like paid work.

Volunteering is key “If people are good only because they fear punishment, and hope for reward, then we are a sorry lot indeed.” - Albert Einstein In the previous research notes, the act of volunteering (doing unpaid work of your own volition) was linked to better cognitive functioning and increasing wellbeing, and I felt obliged to note that these findings may not extrapolate to giving in general. However, the word ‘volunteering’ does seem to be essential to reap the benefits of giving: when someone is helping or giving under pressure (because they have to, feel obliged to, etc), the benefits evaporate and may even be detrimental to wellbeing and happiness (i.e. leading to burn out in caregivers).

Takeaways “Every man must decide whether he will walk in the light of creative altruism or on the darkness of destructive selfishness.” - Martin Luther King, Jr. The act of Giving seems to have a fair bit of relation, or even impact, on our role as Scrum Master or Agile Coach. Not only in our own interactions with the teams & the wider organization, but also on our own mental and physical wellbeing, leading to our own better performance doing the work we love. But remember, work from intrinsic motivation, or else its effects can be reversed! So if you're like me, keep on giving from your personal motivation to make our workplaces a bit better and you're on the way to Agile Happiness.

Image taken from the “Giving” poster by Action For Happiness. Read more about the act of giving and its impact on Happiness & wellbeing at the Action For Happiness website.

[sjoerdly]

Please use the language of the end-user

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!

So please use the language of the end-user in your interface!