3 Quick Tips for Product Owners Dealing with Stress

Product Owner Stress

    A Product Owner’s job comes prepackaged with fun stress-filled responsibilities. Balancing business goals and team experience with finding time to refine your backlog, all while inspiring your team, can leave you overwhelmed in a puzzling mess. Worse, not settling your debt with stress can leave you paying the price with your health.  Here are three quick tips to put you back on track.

Step Back and Trust Your Team

    Once you’ve defined “What” needs to be built and in “What Order”, let go. Let your team handle the small details, the “How”. Self-organizing and ownership are at the heart of strong, effective Scrum teams. You’ll feel better giving your team autonomy with the extra benefit of your team loving you all the more for it.

Replace Schedule Driven Planning with Business Value Planning

    Focus your attention on requirements that give the business the most value first. Set realistic goals with your stakeholders and team.

Use Your ScrumMaster

    Refresh yourself on what a ScrumMaster does for his/her team. ScrumMasters can help you refine your backlog, remove distractions for you and your team, run meetings, and oh so much more. Don’t put everything on yourself, you have a team.

I want to see you, your team, and your projects succeed. If you feel overwhelmed and need help or guidance, please feel free to contact me via LinkedIn.


Tech Brief: Microsoft’s Visual Code, Google’s Collections, Tesla’s New Battery, and Microsoft Will Tell You How Old You Look

Scrum Blog Millionaire's Tech Brief

Microsoft Visual Code

    Nadella continued Microsoft’s face-lift this week launching a cross-platform, yes cross-platform, development environment: Visual Code. Developers can now choose from Windows, Linux, or Apple OS environments. It even comes with IntelliSense built-in. Ooh, so fancy!

Has Google Lost Their Ability to Innovate?

    *chirp, chirp* Google’s latest endeavor into the social media frontier leaves innovation absent as well as your friend’s recent updates. The search giant’s latest play, Collections, lacks wow-factor and blatantly copies existing site Pinterest, making me wonder if they’ll be leaving yet another digital ghost town behind. Don’t get me wrong, I love Google+ and use their social communities almost exclusively over Facebook, Twitter, and Reddit. In the meantime, Google’s recent experiments have me feeling a little Pindifferent.

Tesla is Rolling in his Grave

    Our very own 21st century da Vinci, Elon Musk, unveiled Tesla’s plans for selling home batteries, hoping Edison haters won’t be discouraged when they realize the battery uses DC power. Take that Tesla! The conference, held at night, ended when Musk informed the audience that the entire presentation had been powered by batteries charged from solar panels on the roof. Queue drop the mic, walk off stage backwards.

Microsoft’s Large Stones

    Didn’t your mother ever tell you to be nice? Microsoft showed off their creepy and possibly rude talents by developing a web application that guesses a person’s age after uploading their picture. Aptly named, how-old.net, the overall results are pretty amazing, although it thought my 4 month old son was 18. Get a job son!

May the 4th be with you ScrumMaster

Darth Vader's Retrospective

    Star Wars fans celebrate May the 4th as the film franchise’s holiday and while my favorite character, Master Yoda, lives “in a galaxy far, far away” it shouldn’t stop us from learning his infinite wisdom in our own. Here are 10 Yoda quotes every ScrumMaster should learn on their journey to becoming a Scrum Jedi:

10. “Truly wonderful, the mind of a child is.”

Freakonomics radio explored how kids problem-solve in their recent rebroadcast: Think Like a Child.

LEVITT: I think the beauty of thinking like a child … is that sometimes doing things differently and simply and with a kind of joy and triviality leads you to a really special place that as an adult you don’t get to go to very often.

9. “That is why you fail.”

After Luke’s lackluster attempt at using the force, Yoda shows the young punk how it’s done telling Luke his lack of faith in himself is the reason he fails. Have faith in your process, your team, and yourself.

8. “Judge me by my size, do you?”

Never underestimate the power of small teams. Like Yoda, smallness offers power through agility and swiftness. Read the Developers 101 post for more.

7. “Learn from the master, you must.”

Young Yoda

ScrumMasters teach their padawans, err I mean teams, to become masters of Scrum.

6. “You must unlearn what you have learned.”

Remember the not-so-wonderful project planning known as Waterfall? Yeah. Before your team can be successful at Scrum, you must unlearn what brought us here. Please, Don’t Go Chasing Waterfalls.

5. “If no mistake have you made, yet losing you are … a different game you should play.”

Scrum’s a descriptive framework, not prescriptive. Meaning it’s a guide, not law. If something isn’t working for your team it’s your responsibility to change it.

4. “Fear leads to anger. Anger leads to hate. Hate leads to suffering.”

Yoda  Rollin

    Don’t let the tiny Sigmund Freud fool you, this is deep. Fear, anger, and hate lay the foundation for many social problems. Phobia often leads to hate and suffering. Think Xenophobia. Don’t let your fear of failure or the unknown turn into resentment.

3. “Control, control, you must learn control.”

Scrum wields great power for you and your team, applying it requires complete control through understanding.

2. “Always in motion is the future.”

Scrum helps solve our ever evolving project requirements. Technology moves rapidly, so should your team.

1. “Do. Or do not. There is no try.”

Put up or shut up in Yoda-speak.  You can and will succeed, as long as you’re willing to give 100%.

Only Once You Live“Only Once You Live.”

Scrumptious Links from the Interwebs

Here are my favorite Agile and Scrum articles from the past week:

What’s the Deal with User Stories

    In the late 1970’s, the U.S. Government tested the effectiveness of group decision making within the military. Government researches asked 30 military experts to examine faux-enemy troops and anticipate the enemy’s next move. How’d these experts do? Initial tests proved, not very well.

Scrum Blog Millionaire - Map

    The average military expert correctly predicted the enemy’s movements 7 out of 100 times. Before giving out final scores, researches handed each expert the other 29 assessments and asked them to determine enemy movement once again. With no other new information added, the new average score improved to a remarkable 79 out of 100.  These same experts performed 10 times better as a group than at their individual level.

“The whole is greater than the sum of its parts.” ― Aristotle

    User Stories help teams collaborate in a similar way. They’re a quick and easy way for teams to establish a clear and concise definition for each requirement using a simple pattern: As a who, I want what, so that why. An example for a social media site might be: As a user, I want to upload a picture, so that I can share experiences with friends and family.

    In each Sprint Planning meeting, the entire team sees who the stakeholders are(the users), their request(uploading pictures), and the value(sharing experiences with friends and family). As a group, the team can then evaluate each story and estimate the time each task will take to complete.

    Another key issue User Stories address is to state a clear problem and its solution. Karen Rosengren, a senior technician at IBM, shared the following in A Practical Guide to Distributed Scrum:

A stakeholder requested a set of service routines to delete indices from a database and restore them. This was clearly a solution, rather than a problem. After exploring to understand why the customer wanted this specifically, the team determined the problem was an ever-shrinking window of opportunity to take the database offline for maintenance. Nonindexed databases take less time to backup. By deleting the indices, creating a backup, and rebuilding the indices, the backups were faster. The root problem was the shrinking window of opportunity to have the data unavailable. The team was able to look for solutions to back up data because they understood the business needs of their stakeholders.

    Like Karen says, often requirements come to teams in the form of proposed solutions rather than discussing the problem, leading to an inefficient or even wrong direction. Karen’s team could have easily identified a better solution if the entire story, problem and solution, had been stated: As a backup admin, I want indices deleted, so that backups take less time.

    User Stories promote group collaboration over individual solutions, they define clear and concise requirements, and they state both the problem and its solution upfront.

Look Twice Before You Cross that Road

    A quick Google search or a read through the latest business book can turn up a myriad of ideas and promises for improving your team’s performance through work environment changes and tech snake-oil, Just turn-up office lights, no wait dim the office lights, or…setup half cubesno, wait open spaces are bad. In the short run, teams may show a more productive behavior making it tempting for business researchers to champion their latest work psychology fad. Yet, teams must be diligent in their research, empower their employees to find what works best,  and confirm the long-term effects through KPIs such as  team velocity.

    In the early 20th century, Hawthorne Works, a telephone factory just outside Chicago, ran a series of studies on its workers to determine if changes to work environments could increase production. In one study, they tested whether employees performed better in dim-lit or well-lit work environments. Researchers increased one group’s lighting while another, the control group, went unchanged. To management’s delight,  increasing factory’s floor-lighting increased worker’s productivity.

Arial View of Early 20th Century Chicago

Aerial View of Early 20th Century Chicago

    If improved lighting improved production then decreased lighting should decrease production, right? Not so. When researchers decreased worker’s light, they saw the same improvements. It didn’t matter if the group received slightly more or less illumination.  What mattered was that there was a change. Other environmental changes produced these same results. Hawthorne’s researchers experimented with break times, work hours, etc. and when a change was introduced, work improved. So, what gives? Well, the plant workers had become aware they were being observed. This behavior, to change one’s behavior simply because you’re aware of being observed, is now known as the Hawthorne Effect. 

    The brilliance is that the researchers continued without concluding that the results were simply driven by stimuli. Increasing floor-light would have seen a quick boost, but after a while workers would return to normal behavior.

Arial View of Hawthorne Works 1925

Aerial View of Hawthorne Works, 1925.

    Hawthorne Works, owned by Western Electric, continued their research to improve their employees’ efficiency and effectiveness and would later become the American Telephone and Telegraph company, better known today as AT&T.

Oh Node They Didn’t!

Node.JS and Microsoft

    In the past, Microsoft development stacks have lagged behind peer open source dev communities. Given the popularity of Ruby on Rails, Django/Python, and now Node.JS, Microsoft had in many ways lost out, not just in cutting-edge web development, but in well-established development patterns. Web forms were great in 1995 when web apps were small, but in 2015 where scalability and maintainability are crucial, they just can’t hang.

    Over the last few years, Microsoft has taken note and begun pushing their old ways out becoming more open to the development community. ASP.NET MVC was a great leap for Microsoft and came years after MVC had been well established as a solution to separate business logic. This week they’re showing off their latest example with Node.JS 1.0 Tools for Visual Studio.

    For those not familiar with Node.JS, this is the brainchild of Ryan Dahl. I won’t get too far in the weeds here, but what makes Node.JS so great is its use of JavaScript callbacks. So what, you may say, JavaScript has done that for years in the browser. While true, what makes Node.JS special is that it allows this same behavior to run server-side callbacks. Callbacks allow software to send a task to complete a job and then move onto the next job, not waiting for the job to be completed. This is known as asynchronous programming, while most languages are synchronous.  It’s the difference between ordering a coffee and waiting to the side while others order and your coffee is made(asynchronous) vs having to wait in line until each and every order of coffee is taken and then delivered to the customer, one at a time(synchronous) In the realm of computers, where some argue they do actually run on coffee,  a call to disk is 100,000 times slower than a call to memory. So imagine every request waiting for a response from a basic file read. Computers are fast, so one call might not be a big deal, but to scale when you start making millions of calls, then you begin to bottleneck.  Node.JS can pass these IO/Network calls off and move on to the next task via a single looping thread. It’s really impressive stuff.

    I’m impressed with Microsoft jumping into the game on this one. The tools are impressive and my personal preference is to code node in the VS IDE vs other IDEs, including Sublime. The IntelliSense features are helpful and the debugging will keep you from cursing at your code every 5 minutes. 😉

Update On My Son:

Harper is healthy and at home now. We are so blessed and thankful for all of your prayers.

An Update

My son was born at 6:04 AM on Saturday at 3lbs 9 oz. Since then he has been doing remarkably well. He’s breathing on his own and opening his eyes to look around quite a bit. He wanted to come a little early at 32 weeks, making the past several days a roller coaster of emotions for mom and I. Please keep us in your thoughts and prayers.


Create an Idea Driven Culture

Scrum Blog Millionaire - Create an Idea Driven Culture

    Great Britain’s Industrial Revolution brought an explosion of innovation to the world and was the aftermath of the Agricultural Revolution beginning in 1690.  Life expectancy and average incomes leaped forward in unfathomable ways, giving birth to the era of ideas where virtually every aspect of human life changed forever.

    Before the Industrial Revolution, most nation’s labor forces were made up of farmers. By 1820 in America, 72% of the working population were farmers and in 1900 the percentage had dropped to 38%. Today, farmers make up just 2% of the American population.  The initial dramatic drop was due to a new farming technique known as crop rotation. Crop production grew over 30%, lowering the labor costs of farming and allowing most of the population to move away from rural communities and into dense urban cities.

Scrum Blog Millionaire - American Gothic

    Urban cities became breeding grounds for many pioneers of modern thought.  Here, people could collaborate with a richly diverse population in completely new ways. People came to cities from all over the world with different backgrounds, different religions, and different solutions to problems. It was at Universities that modern science was born, it was in taverns that modern political science took shape, and it was in new coffeehouses springing up across Europe that old and new ideas came together to solve challenges by building on new and existing knowledge.

Scrum Blog Millionaire - American Gothic

    It’s tempting to believe that many of our great minds came to their ideas independently. Our Isaac Newtons, Adam Smiths, and Nikola Teslas were all geniuses no doubt, but their works were the collaboration and continuation of many people’s knowledge before them. It was books and urbanization that allowed them the good fortune of dedicating their lives to the pursuit of knowledge and allowed them to, seemingly overnight, change the world.

Scrum Blog Millionaire - Isaac Newton

    This pattern for cultivating ideas shows up everywhere. We can find this same process in biology where ecosystems thrive in richly diverse populations, while ecosystems where species diversity is lower are more prone to extinction. Everywhere we look, we see the same idea: diversity drives innovation. It even appears in business, but some seem to be running in the opposite direction, away from communicating and collaborating with one another.

    Within IT, we often balk at the idea of collaboration. Instead, we build our own information silos, safeguarding knowledge while thinking we are protecting ourselves. It’s unfortunate that in a field where technological progress is so vital to our success, we’ve become modern hunter-gatherers, protecting our own tribe from one another.

    We should model our teams and organizations after this same pattern and create an idea driven culture. Instead of working on projects alone in our cubicles, why not take the entire team for coffee or beers after work. Mix things up and socialize. Help foster ideas from everyone. Collaborate and communicate with your teams and within your organization.  Sir Isaac Newton’s own father after all was a farmer who couldn’t even write his own name. If the entire world could change in one generation in the 17th century, what are we capable of today?

What’s the Best Time for a Daily Scrum?

Before we dive into the “best time” for a Daily Scrum, note that the most important part of the Daily Scrum is that all team members can attend. The timing of the Daily Scrum is a group decision and shouldn’t be dictated to the team. It should be at a consistent time every day, so check with your team to make sure there are no scheduling conflicts, There will be some teams where certain times won’t be available for all team members.

So what’s better, should your team have a Daily Scrum first thing in the morning or should it be the last thing the team does?  It depends. Which is more important to the team: the work that has been done or the work that is going to be done?

The Daily Scrum covers three questions:

  1. What have I worked on since the last Daily Scrum?
  2. What will I be working on until our next Daily Scrum?
  3. What impediments are preventing progress?



  • Advantage: Immediately after the 15 minute stand-up meeting, you begin working on what you just committed to.
  • Disadvantage: Remembering what you worked on since the previous Daily Scrum.


  • Advantage: Discussing what you just worked on that day while it’s fresh on your mind.
  • Disadvantage: Remembering what you committed to do at the last Daily Scrum.

I  prefer to have the Daily Scrum in the morning. While what the team has worked on and completed is important to move forward,  keeping the team’s committed work fresh on our minds is far more important to me.