Sunday, February 26, 2017

Debate and Playing Nice

At any company where small scrum teams operate, the typical buzzwords are teamwork, collaboration, commitment, cross-functional, and self-managed. (Bleh!, buzzwords.) But what about tension, disagreement, conflict, and debate?
"What we need is collaboration where tension, disagreement, and conflict improve the value of the ideas, expose the risks inherent in the plan, and lead to enhanced trust among the participants. It’s time to change your mindset about conflict. Let go of the idea that all conflict is destructive, and embrace the idea that productive conflict creates value. If you think beyond the trite clich├ęs, it’s obvious: Collaborating is unnecessary if you agree on everything. Building on one another’s ideas only gets you incremental thinking. If you avoid disagreeing, you leave faulty assumptions unexposed."
Remember when I wrote about asking "Why?" in a previous post? Well, that's why you ask why, to solve the right problems, build better products, and nurture stronger teams. Debate is important, healthy, needed. Bring it!
Now, I'm not saying that you should go into all your standups, grooming sessions, and retrospectives ready for battle, ready to pounce on the first thing you disagree with. There's still a grace to introducing disagreement and starting a healthy debate on a topic.
After years of intensive analysis, Google discovered the key to good teamwork: being nice! And that involves the concept of “psychological safety,” a model of teamwork in which members have a shared belief that it is safe to take risks and share a range of ideas without the fear of being humiliated.
"Google’s data-driven approach ended up highlighting what leaders in the business world have known for a while; the best teams respect one another’s emotions and are mindful that all members should contribute to the conversation equally. It has less to do with who is in a team, and more with how a team’s members interact with one another."
Wait, I have to be nice to everybody I work with? Yes, you need to be respectful, empathetic, and start with "the benefit of the doubt" in mind.
Luckily, my colleagues engage in healthy debate while everybody plays nice. Which is important because, 'The Rise of AI Makes Emotional Intelligence More Important.'

Friday, January 13, 2017

Why and No

by Wes Royer

If you have young kids, you probably have lost patience in the number of times you hear them tell you "No!" or ask you "Why?" But child development professionals will tell you that the use of those two words are positive signs of your child's cognitive, language, and social development.
So why is it as adults and professionals, we so often skip asking why or don't feel like we can say no? And, as parents, we are quick to say things our parents said to us, such as, "Don't you tell me no!" or, "Stop asking why!"
Whether you are a product manager, product owner, business analyst, account manager, etc., asking why and saying no should be embraced as the norm. Yes, within reason. But delivering value to your customers is a top priority. And asking why and knowing when it's appropriate to say no are pieces of the value puzzle.
MVP = minimum viable product. This term has been around since at least 2001 and is a commonly over-used buzzword. At my previous workplace, I used MLP (minimum loveable product). Minimum does not mean the product doesn’t provide value to the customer. It means highest value feature(s) first. Solve the immediate or top problems first and get that value in front of the customer ASAP.
You'll spend 20% of your project solving for 80% of your users, and then spend the remaining 80% of the project trying to solve for the remaining 20% of your users. MVP or MLP addresses the 80% of your users first.
But you cannot define a successful MVP without asking why. Ask a stakeholder, "Why do you need that feature?" Even better, "Why do you think your users need that feature?" What value will said feature bring to the bottom line? How often do you think this feature will be used? What user persona and problem are we solving for, and why is this more valuable than others?
And then, if asking why doesn't net a true benefit to stakeholders and/or customers, then why would we build that feature? This is where saying no comes into play. But how do I come right out and say, "No?"
In discussing this topic with a colleague, she offered, "There are benefits to the client in asking questions and saying no. We, as a partner, know the business of building software and many of us know the industry pretty well. Being direct, asking questions, and declining to do certain things develops our partnership and increases the value of what we are delivering. The added benefit is it creates a long-term relationship that requires less from us to maintain, equaling higher margins and profitability."
And if you feel the word “why” puts others on the defensive, another colleague offered, “Why questions can put many people on the defense, especially if they are coming from a person in a position of power like a leader or manager. A couple of suggestions to get at the same thing are, ‘Tell me more,’ ‘How did you get to this idea?,’ or ‘What are you trying to solve for?’”
Have you heard of the Bill Murray technique for saying “Yes?” You should read the humorous article, but here is the basic premise: Replace a hard “No!” with, “I have an idea that will solve a couple issues,” or, “I think there is more immediate value in focusing on X instead.” Replace your saying No with the client by instead saying Yes to something else more valuable. Not always easy, but a brilliant win/win scenario!
In our fast-paced digital world, it's not easy remembering to ask why, and can be even harder to say no, regardless of whether the request is coming from a coworker, a client, or friend and family. But when why and no become a regular part of your vocabulary, trust me, you'll feel liberated because you and those around you will be focusing on the things that offer the most value. Isn't that what everybody wants?
I ask why a lot and am willing to say no (it's still hard to do!). I expect my colleagues to ask me why often. And if they don't like my answer and tell me no, I will understand.