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.