A Little Empathy Goes a Long Way

Empathy is a big deal.

As a scrum master, one of the most important qualities you can have is empathy.  It is a special quality where you can put yourself in someone else’s situation and understand the world from their perspective.  It means operating outside your comfort zone.  Today, I would like to discuss the importance of empathy for a scrum master.

Working for a large organization is hard.  Employees often feel alienated from their work and coworkers. I think a significant reason for this situation is many people in leadership roles do not understand what it takes to provide the goods and services their organization offers.  These leaders are good at managing budgets and capacity but little else. It is where empathy matters.  As a leader, you need to walk a mile in another person’s shoes.  If a leader cannot do that in reality, then they must attempt the thought experiment to see the world from the perspective of the employee.

When a leader sees the organization from the perspective of the people interacting with customers several changes take place.  First, they see the people doing the work as people instead of resources who are disposable.  Next, they understand the systems and equipment the employees are using might not be meeting the needs of the customers.  Another by-product of this exercise is leadership understands how long it takes actually to build something.  It gives leadership insight into which deadlines are real and which are fiction.  Finally, leaders discover which activities generate value and which ones do not.

Early in my career, a mentor I respect said I should never order a person to do something I would not do myself.  I still follow those directions today.  It is why I go to meetings, so my coders get a chance to write software.  It is why I fill out expense forms and project requests; so the people doing the work do not have to do it.  It is part of the servant leadership I try to practice each day. So have some empathy for the people who work for you.  You will be surprised by what you might discover.

Until next time.

The Strength of Technology Pros

No rest for technology

Technology is not for the meek.  A software developer is relearning their craft every 18 months.  Technology companies come and go with regularity.  Businesses rely on software to remain profitable and when the software does not work it costs lives.  The men and women who work in this business have to be tough.  Part of that toughness is the realization you have to deal with failure and frustration.  This week on the blog, I will discuss these central conditions of technology.

Many people have romantic notions about scientists, engineers, and software professionals.  The stereotype is that we are super smart and socially awkward individuals who spend their days making inventions and applications which change the world.  The reality of technology is less glamorous; it is hours, weeks, and months of frustration.  It is executives and financers demanding the work to be finished immediately.  It is cold coffee and stale pizza.  It is loneliness and frustration.  In the end, you might have a brief moment which feels like the creator is touching your shoulder but those moments are rare.  Often you will see a solution to a problem which has dominated your life and now you will have to make it work for others.

It means traditional methods cannot measure these workers.  Science is notoriously fickle when it comes to new advancements.  Computer software is a handmade and messy process prone to error and cost overruns.  Software is eating the world, but it depends on a small segment of the world population to build it.  Innovation and invention do not fit neatly into a project plan.  The realities and pressures of technology create unhealthy levels of stress.

The heavy intellectual lifting combined with the anxiety caused by deadline pressure creates a toxic stew of emotions which can lead to physical problems.  Obesity and heart disease are common among software professionals.  Self-medication with cannabis and alcohol are also common within the trade.  All of my contemporaries have recounted stores of insomnia and anxiousness caused by grappling with a severe challenge.  For those outside the profession, the levels of stress and frustration are extreme.  To a developer, it is just another day at the office.

Creativity and innovation are difficult.  The pressure we place on people leading innovation efforts is unhealthy.  The repercussions are professional burn out, defective products, and the risk of cascading failure within complex systems which maintain the global economy.  In many respects, we live in a magical age.  Today’s smartphones are more powerful than the computers which put people on the moon.  With a few swipes, we can order food and find a possible romantic partner to share it with us.  Information can swirl around the globe in seconds and we have millions of people using the internet to solve problems only a century ago would have had the attention of a small group of specialists.  It is a fantastic period to be alive, but the cost is that many people take for granted these advances and forget they are the product of the human mind rather than magic.

It is why I say technology is not for the meek. It requires intelligence, training, and the ability to tolerate frustration and failure.  The strength has helped build the global economy, and I have enjoyed a peripheral role in this process.  Technology people are different, but they have to be; otherwise, the magical world we live in would not exist.

Until next time.

A Scrum Master Demands Interpersonal Skills.

A scrum master must have a
moral compass and great interpersonal skills.

The role of a scrum master is a challenging one.  Any given day you are confronted with new challenges, and you always face the pressure to deliver software.  You are pulled from the top by the demands of business leadership.  From below, you are leading your team and helping them improve.  I have been reviewing plenty of career postings on the internet lately, and I have noticed an interesting trend.  Postings have mentioned in passing the need for interpersonal skills.  I want to argue interpersonal skills are the essential part of being a scrum master.

When you look at a job posting for a scrum master you often see references to project management systems, years of experience and relevant industry experience, usually there is a request for certifications from the various accrediting agencies involved with agile.  The final bullet point is the requirement is a request for excellent interpersonal skills.

Being a good scrum master demands interpersonal skills.  You spend time coaching and educating others about agile and scrum.  A scrum master must be able to say no to others without sounding dismissive.  It requires solid interpersonal skills to have empathy for others.  A scrum master also must speak truth to power and have the integrity to back up those words.  All of this requires interpersonal skills, and a scrum master who does not have them is in trouble.  Earning a scrum master certification is straight forward, being able to do the job requires hard work and a growth mindset.  

You cannot check off boxes and have a scrum master arrive to make your team better.  It is a process of trial and error.  A team will take two steps forward and then fail in an embarrassing fashion.  It is not a traditional career path, but it is infinitely satisfying.  The foundation is excellent interpersonal skills.

Until next time.

The Development Team Must Be a Shark

The development team is like a shark.

As a boy, I thought sharks were the coolest creatures alive.  They were ultimate predators who created panic at beaches across the nation.  Steven Spielberg made one of the biggest movies of all time featuring a shark.  Sharks were a staple on public television, and today we can enjoy an entire week of shark programming on Discovery.  The more I have learned about sharks the more I respected and admired them.  As a scrum master, I have used sharks as a metaphor for the operation of a good scrum team.

A shark is a living fossil.  It has not evolved substantially in 200 million years.  When you are the top predator in the ocean natural selection is not a powerful influence.  It does give a shark several disadvantages.  The brain of a shark is smaller than the brain of a dog.  Sharks do not breed quickly, and the creatures plunge into irrational frenzies with the presence of blood and prey.

The biggest disadvantage sharks possess they have primitive gills.  Unless a shark is swimming with its mouth open, it cannot breathe.  It is a significant disadvantage because most fish today have gills which can filter oxygen out of the water without swimming.  Thus, a shark is doomed to swim from the moment of its birth.  A shark must swim, or it dies.

Software development teams should use the shark as a metaphor for how they should operate. Organizations need to keep swimming and moving forward.  A team needs to gain new knowledge and techniques continually.  A team has to deliver software regularly.  A team has to respond to a changing environment.  A team must keep swimming forward.

As a scrum master, it is up to you to keep the team swimming.  You need to ask compelling questions.  You must insist on delivering software into production at regular intervals.  Finally, a scrum master should encourage the team to pursue “Healthy Ownership,” with collective responsibility of outcomes.

If you cannot inspire the team in this fashion, you will have a drowning shark, and you will be dead in the water.

Until next time.

Don't be a Mad Hatter Agile Shop!

Delivery of software is not madness.

Becoming a scrum master is not hard. Professional certification takes two days of classroom training and a simple test makes sure you understood the information.  The real work happens when you are beginning your servant leadership of a software development project.  You wear multiple hats.  Somedays, a scrum master is a therapist.  On other days, they act as a cheerleader and on others they are a technical consultant.  It is a challenging career.  One of the things which get lost is the purpose of agile and scrum; is the team is responsible for delivering software.  Today, I want to discuss software delivery.

The Agile Manifesto is very clear about delivering software.  An agilest prefers working software over comprehensive documentation.  When the manifesto says “working software,” it means software in production used by customers.  Anything which does not meet this goal is not working software.

Over my career, I have had numerous conversations about when work is done.  Many of these conversations sound like sections of Lewis Caroll’s “Alice in Wonderland.”  I had a developer tell me with a straight face the code was finished, but the code did not compile.  I had another developer tell me they did not need to write unit tests before checking in code to source control.  The worst moment in software development is when a developer says, “It works on my machine, so it is done.”

None of these situations qualify as working software.  As a scrum master, you need to ensure that everyone understands what working software is.  In the agile community, we call what constitutes working software as a "definition of done."  In the medical community, successful treatment of illness is called the "standard of care."  I prefer to use the medical term standard of care when talking about working software.  It is a set of necessary and sufficient conditions.  Here is my formulation of what a good standard of care for web development is:

1. Does the software compile?
2. Does the software have a unit test to prove it is doing what it is supposed to do?
3. Does the software exist in a source control environment so that others can inspect and edit it?
4. Does the software work on a staging or test environment?
5. Does the business approve of the software delivered?
6. Does the software work in a production environment?
7. Are customers using the software?

We do not have working software if these conditions are missing.

I understand the standard of care seems extreme to some but think of all the steps you have to go through when you have surgery.  The nurses are required to count every piece of gauze, and surgical instrument used. The last thing a patient needs is a piece of gauze left in their body to be an environment for infection.  Likewise, in the software world, you do not want to deploy code which is not unit tested because it will be harder to debug and troubleshoot when something goes wrong.

Software not being used by the customer in production is not working software, and any good scrum master and product owner must make sure that happens.  If not, you are just pretending to be agile.

Until next time.