Soft Skills for an Excellent Product Owner

I want to improve the skills of Product Owners.  I introduced the topic and provided tips about backlog management and authoring user stories.  Today, I will discuss the soft skills a good Product Owner needs to cultivate.  

The Authority and Ability to Say No –

One of the tragedies of the contemporary business world is the number of people who are crushed with responsibility but have no authority over what they do.  Open offices and cubical farms contain many lonely souls who are accountable and responsible for the business's success but have no say in its operation.  Daily they are asked to sacrifice and be team players.  Bathed in toxic positivity, they stifle emotions and abilities for the business and their careers.  The unspoken rule is saying no to a request from leadership is career poison.  Business leaders need to break this cycle of abuse and mediocrity.  The first step is to give Product Owners the ability to set priorities and say no.  It means that they should be director or Vice President level in the organization and responsible for an individual portfolio of work.  

Listening Skills –

A Product Owner needs to learn how to listen.  A product owner will interact with customers, developers, and executives on any day.   Each interaction requires listening skills that account for what is said and intuiting what is left unsaid.  I continue to struggle with this skill because I feel I can continue to understand better the needs of the people I work with daily.  Not only do you have to understand stated and implied meaning in conversation but communicate it to others.  Having listening skills will separate the great product owner from the good.  It requires taking notes, being transparent, and spending plenty of time following up.  

Diplomacy –

Product Owners will find themselves in situations with a significant power imbalance.  These situations will include unhealthy levels of stress.  A key to survival is being diplomatic when everything goes sideways.  Diplomacy requires you to use "please" and "thank-you" when you want to say something else.  It is factually answering questions when being yelled at over a conference call and keeping your mouth shut.  At the same time, your manager attempts to steer a conversation into a more constructive place.  Finally, diplomacy requires you to let someone reveal they are a jerk instead of personally bestowing that title on them.  Being diplomatic does not mean you are a pushover; instead, you are advocating for your team and yourself in a manner that cultivates the respect of others. 

Product Ownership is a difficult job, but it also is an opportunity to deliver value to the organization in a conspicuous role.  The ability to say no, listen and diplomacy make it possible to be an excellent Product Owner.  

Next time we wrap up. 

Writing Good User Stories

The most important responsibility of a product owner is to write user stories.  It requires focus and skill.  The team members are responsible for completing work, but the product owner makes sure the team has work that delivers value to the business.  Today, we continue our series on healthy ownership by looking at some helpful guidelines on how to write better user stories.  

User stores are the bricks that construct your product and deliver value to your organization.  Together as an assemblage, they are the structure for all the agile team's conversations about the work they accomplish.  Good user stories have two principal characteristics: why the story needs execution and, finally, acceptance criteria that explain success.   

I wrote a blog three years ago which explains my technique of writing stories that I teach to others.  Please take a look at it here.  It features a sentence narrative that I then explain what needs to be done and why.  I do not tell the agile team how I want the work done.  It is because the team members are smart enough to develop solutions.  The team will appreciate the trust. 

Next, I encourage you to author acceptance criteria using the Gherkin syntax.  The simple use of the given, when, then narrative makes it easy for quality assurance people to confirm quality and for the developer to do the work.  Clear acceptance criteria in a given, when, then format avoid mistakes when people attempt to parse ambiguous requests.  Acceptance criteria allow the team to estimate more effectively and split stories.  

Finally, embrace the INVEST model of writing user stories.  INVEST stands for independent, negotiated, valuable, estimated, small, and testable.  These qualities make a user story a helpful nugget of information to help complete work.  

User stories are the bricks that make up the cathedral of your product.  If you create quality stories those bricks will be strong enough to make your product a success.  The architect Louis Kahn famously said, "Even a brick wants to be something."  

Next time the soft skills of a good product owner.  

Using the DEEP Model for Success

Agile has three primary roles, the development team, the scrum master, and the product owner.  Since the authoring of the agile manifesto, the reformation has done an excellent job encouraging the development of craft among software developers.  The reformation has also spent considerable time working on the professional development of scrum masters.  The weak link has been the development of product owners.  Understanding this, I have dedicated most of my career to helping product owners improve.  I call this “healthy ownership,” and today, I want to discuss a portion of what it takes to be a successful product owner; backlog management.   

When I discuss the principal role of a product owner, I say they are responsible for telling the development team what they need to work on next.  A product owner is also responsible for the business, ensuring the customer receives the value.  It is a demanding role that requires diplomacy, expert business knowledge, and a full-time commitment.  

Unfortunately, most organizations do not feel this way and often provide product owners who work part-time while doing other accounts receivable or shipping tasks.  A product owner should also have the authority to say “no” to others but often are subservient to executives.  The minimum requirements for a product owner are full-time commitment to the role, executive-level authority to set priorities and say no, and finally, the ability to work diplomatically with people inside and outside the development team.  It is not an easy job.  

The first order of business is to create a list of work that needs to be done by the development team.  It is called a product backlog.  Roman Pichler wrote a fantastic book on product ownership and scrum entitled “Agile Project Management with Scrum.”  In it, he outlines a helpful framework for organizing a product backlog.  It is called the DEEP model.  It is an acronym which stands for –

• Detailed
• Estimated
• Emergent
• Prioritized

I have discussed these backlog qualities in more detail in previous blogs.  I have included links to the original articles to review at your leisure.  

A detailed, estimated, emergent, and prioritized backlog is a recipe for success.  Estimated stories allow product owners to answer better the question of when work will get finished.  The correct level of detail in stories makes it possible to understand what needs to be done instead of doing it.  Just make sure you treat estimates like an educated guess instead of a quotation; otherwise, you are setting yourself up for unnecessary stress.  Backlogs are emergent because uncertainty around a project decreases when you get close to completion.  Prioritized because if nothing has a priority, then everything has a priority.  Lack of prioritization will transform any project into a carnival of chaos, so you must be sure you are doing things in a set order.  

Using Roman Pichler’s DEEP model is an excellent working guideline on managing work for your Agile team and giving you a leg up on other product owners.  

Next time a discussion on how to write user stories.  

Beginning a Journey Into Healthy Ownership.

We will remember the end of the COVID pandemic as a combination of science-fiction, fantasy, farce, and tragedy.  I was on a plane to have dinner with a client while tanks began rolling into Ukraine.  The contradictions between my life and the peril of others were oppressive.  

Still, the business world continued to turn, and clients were looking for ways to do business smarter and faster.  I am a minor player in the global business story, but my role is to make a difference.  Part of that difference is to help improve product ownership in the agile reformation.  I have authored numerous blog posts about product ownership, and I have advocated for something called "healthy ownership," which began at the 2018 Agile Coaching Retreat in London.  Today, I am starting a series of posts on being a better product owner and developing beneficial ownership on your team.   

Healthy ownership began when I had a jetlagged rant about the quality of the product owners at my organization.  I asked if I could instill good habits among product owners and respect the developers.  Then, I found a group of like-minded individuals, and we got to work.  An agile team requires trust and interdependence to be successful.  The team then takes collective responsibility for its outcomes to have healthy ownership.  It is a goal I think each team should strive to achieve. 

Product owners should begin by having an open dialog with team members.  It would help to ask the teams what works and what does not.  Take time and listen to what they are saying.  What are the team's frustrations, and what do they need to overcome those frustrations?  Assume good intentions unless proven otherwise.  Finally, collect data from the group and make it meaningful.  

As a coach, teach product owners the D.E.E.P  model of backlog management.  Let new product owners write user stories and then get them to critique their work.  Have developers push back on user stories that are unclear or incomplete.  The trial and error approach may be more clumsy, but it will help develop more skill and confidence in the long run.  

Product ownership requires more than writing user stories and gathering estimates.  It is not an easy job, but it can be a force multiplier if done well.  It takes clear communication with the team and understanding the social compact, which guides agile, and it takes interaction with business partners and saying "no" when necessary.  

We will talk about being a better product owner for the next few weeks.  We will have a blueprint to create healthy ownership in your organization by the end of our journey.  

Next week, the D.E.E.P model of managing a product backlog.  

Quality Goes in Before the Software Goes Out

Nothing is more aggravating on a software development project than quality issues.  Developers build software that works locally, but when promoted to a testing or production environment, it breaks in embarrassing ways.  Sometimes new features break existing functionality.  It is a special kind of horror and misfortune.  People who use software expect it to work and do not wish to struggle with quality.  As someone who has attempted to deliver software for over twenty years, I recognize this frustration and have a few suggestions on dealing with quality issues. 

In my experience, quality issues have three root causes; insufficient software craftsperson skills, poor continuous integration and deployment, and a lack of quality culture in an organization.  Each of these is difficult to confront individually but can make a software project impossible in combination. 

Software craftspersonship is something we do not discuss often enough in this business.  It separates the amateurs from the professionals in this business.  Craft is taking pride in your work and holding it up as an example for others.  Some people never develop that mindset comfortable to muddle through their career.  It took me over ten years to build a sense of craft as a software developer.  I came to the software craft movement and continue to support it to improve quality in software projects worldwide.  Development organizations should encourage test-driven development, SOLID principles, design patterns, and code refactoring.  These practices improve quality, and it increases speed to market with better quality. 

The next cause of poor quality is the absence of continuous integration and deployment in organizations.  Software requires plenty of supporting structures to operate.  Configuration files store variables, configurable databases, and libraries help automate work.  On one machine, it is easy to maintain, but changes can quickly get out of control with multiple developers.  It is why having a source control took is a necessity.  Next, an automated build system should be in place, so when code returns o source control, it is compiled and deployed to a testing environment.   Finally, the same number of zeros and ones should move to other domains like copying and pasting a document.  The development team should alter database settings, libraries, and configuration files, but the compiled code should never change.  Approaching software deployments like this will save you numerous sleepless nights.  

The last thing hurting your quality is the culture of your organization.  Developers should be restless when looking at code, looking for ways to make it easier to read, debug, and maintain.  Refactoring should be a regular part of a developer's job, and the organization should understand refactoring code allows for better quality.  Developers should respectfully inspect each other's code to help others improve.  Each new piece of code should generate a unit test and every defect discovered.  Finally, developers need to treat quality assurance professionals with respect and like the first customer who views their software.  I believe this is the most laborious process in quality improvement, but you can move mountains with a healthy quality culture.  

Improving your organization's software quality is a matter of business survival because the release of buggy software undermines trust within your organization and, more importantly, with your customers.  Business partners will be more reluctant to purchase upgrades or use your automated systems because they do not trust them.  A few pennies more of software quality will save you pounds of frustration.  

Instill a sense of craft in your software development team, put continuous integration and deployment in place, finally breed a quality culture in your organization.  Otherwise, you have are doomed to live a life of aggravation.  

Until next time.  

When the Going Gets Tough Emotional Intelligence is a Force Multiplier

One of the most frustrating things I experience is business people making promises to customers and expecting technical professionals to keep those promises.  It is a clear violation of the social compact of agile.  Sadly, it is also a common occurrence.  In these high-pressure moments, it is clear that the people making the promises do not have the technical knowledge necessary to keep those promises.  If the situation becomes, egregious people can wind up in jail.  I have spent plenty of time working on these intense projects, and I want to try and provide a few tools to keep you from going insane.  

William H. Janeway is a founding silicon valley venture capitalist; his book “Doing Capitalism in the Innovation Economy” includes a great piece of wisdom about times of crisis in the investment world.  When situations deteriorate in a business, investors want cash and control.  The money is necessary in case of more economic hardship, and the control ensures work gets accomplished.  It is a harsh truism.  

With deadlines looming, executives are under intense pressure.  An executive often micromanages a team because it is the only way to look like they are in control.  It feels like playing a game of twenty questions with someone on amphetamines, pointing a gun at your head.  

Conversations resemble the following.

Executive #1 – “Those two bugs, when are they going to get fixed?”

Product Owner – “We wrote up the bugs five minutes ago when we were testing, so we are going to diagnose the problems and provide logs for the development team.“

Executive #2 – “We promised the client a release date on X.”

Product Owner – “I am aware, but releasing buggy code is going to undermine our relationship with the customer.”

Executive #2 – “We need that by X.”

Executive #1 –  “Can you give me an ETA on those defects so I can report them to my boss.”

Product Owner – “Yes, as soon as we trouble-shoot the problem and gather response object from the failed service.”

Executive #1 – “So when?”

Product Owner – “I am not sure.  Let us work the problem.”

Executive #2 – “We could lose millions of dollars if we don’t release by X.”

As you can see, conversations like this resemble something out of a Kurt Vonnegut novel.  The stress levels increase, and no one benefits from the increased attention other than the executive. 

Often you are working with people inside your team and outside to address crises.  It requires plenty of emotional intelligence to do this correctly because many of the people around you begin to panic and are frazzled.  When confronted with situations like this, it is best to be the calmest person in the room.  State the facts and tell people what you are doing to work the problem.  Also, share with leadership the others working with you to fix the problem.

Next, let people know they are creating unnecessary stress.  If a manager is asking for updates each hour for a bug in testing, point out that their concern, while necessary, is not improving the situation.  

Finally, be kind to others and yourself.  Deadline pressure is never fun, but everyone is in the same difficult situation.  Being mean or showing a lack of kindness will create a feedback loop of reprisals on the team.  If the unit is fighting, they are not focusing on the deadline.  Kindness and grace are not easy during a deadline, but they are necessary to get the job done. 

High pressure and uncomfortable situations happen in software development.  As a coach or scrum master, you must show emotional intelligence when others are not.  

Until next time. 

Uncomfortable Truth Defeats Convenient Fiction in Agile

Working on a colossal software project is an endurance exercise.  Based on my experience in software development, no one agrees all the time during a project.  Coordination with thousands of people across continents to get something done is challenging when everyone agrees; it is next to impossible when there is a dispute.  The amount of money, time, and reputation wagered during each software project is tremendous, and this high-pressure environment arouses strong passions.  As a coach or scrum master, a person needs to adjust to those strong waves of emotional energy and find ways to move the work forward.  I want to discuss how to make this happen.  

Large projects are a Rube Goldberg contraption of competing interests, visions, and skills.  Systems which need to work together are often incompatible.  The people doing the work rarely understand the systems they are working with and how they are supposed to work.  Finally, no one person understands how the entire system operates.  What is not apparent is what the team must do and why it needs doing.  The only clear thing is that the project has funding and something needs to be delivered.  

Soon, skilled professionals will attempt to collapse the cone of uncertainty and figure out those two crucial questions.  By the time work begins, some understanding should be part of the project.  In reality, work is done blind, and the organization attempts to dig through the complexities of the task at hand.  

It also does not help that there are considerable gaps in power between the people commissioning the work, those leading the job, and the developers doing the work.  An executive vice president wants to know a completion date, and when they ask a developer who they can fire, the developer will create a comfortable fiction.  It ratchets the stress on the development team because the executive now treats the comfortable fiction as an actual deadline.  If the deadline is missed, the CIO becomes involved in the project, escalating the tension further.  

What happens is an awful cycle of failure which undermines trust up and down the chain of command.  It leads to micromanagement and arguments about service level agreements and contracts.  Sadly, I have experienced these situations more than I would mention.  

Clearly, as a coach and scrum master, we need to address this awfulness.  First, recognize a power imbalance and make it clear to everyone involved.  Let people know that someone will not return your calls or email without getting a director or vice president engaged in the conversation.  Next, state that you do not know what to say in a situation because you are not in a position of power.  For example, “ I want to provide an estimate for that feature, but I am understaffed and do not have the authority to hire.”  Finally, state the uncomfortable truth instead of a convenient fiction.  It is the hardest part of an agile professional’s job because it puts you at risk, especially contingent workers or consultants.  

Business is overflowing with convenient fiction, but if you want to get work done, you will have to point out uncomfortable truths and ambiguity in what is happening.  If you don’t, it will create the cycle of mistrust and escalation, which I outlined earlier.  Robert Sutton points out that corporate leaders often live in a “Fools Paradise,” where they only receive good news because subordinates are afraid they will be ostracised or fired for bringing bad news.  It is true in an organization with little psychological safety, but leadership will be grateful for the clear insight in an agile organization.  Thus, it is courageous to tell uncomfortable truths instead of a convenient fiction to leadership because if they are good leaders, they will act on these truths instead of burying them. 

Massive projects are challenging.  Working on one makes you feel small and futile.  What will help you and others get things done is admitting uncomfortable truths and working through them.  It requires courage and strength, but it will be better for everyone involved, and the project might get done sooner.  

Until next time.