Monday, April 22, 2019

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 it 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.

Monday, April 15, 2019

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.

Monday, April 8, 2019

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.

Monday, April 1, 2019

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.

Monday, March 25, 2019

Treat People Like People Instead of Resources

Treat others like people.
Being a scrum master is hard.  It is not a dirty job like being a trash collector.  It does not have the danger associated with being a firefighter or an electrical lineman.  It lacks the prestige and respect of being a member of the armed forces or the toughness of being a lumberjack.  Scrum masters make the world a little better one sprint at a time. 

Forbes magazine categorized four types of toxic professionals; the power hungry, the absent, the incompetent, and the micromanaging.  I have encountered these individuals throughout my career.  I have spoken about how those individuals can spoil an organization.  Each of these people are awful in their unique way, but I think one trait unites them; they see others as resources instead of people.

I blame this state of affairs on contemporary project training.  A modern corporation is deeply concerned about profit.  A company is so worried about profit they will do everything in their power to make sure each employee is running an efficiently as possible.  A software developer with downtime is wasting money.  It is why people expect them to perform multiple projects.  A business leader able to meet and mentor junior employees does not have enough to do or is not generating revenue.  Being busy is more important than being productive.  The agile community calls this putting outputs above outcomes. 

Treating the individuals doing the work like people requires downtime, training, and mentoring to provide value to customers.  If individuals are resources, they are office supplies which can be used up and discarded when they are no longer useful.  Treating people like resources is exploitive and antithetical to an agile mindset.  

I joined the agile reformation ten years ago because I felt there was a better way to deliver software.  People deserve to work in environments which are satisfying, sustainable and sane.  When you treat people as people instead of resources to be used and discarded this will not happen.  I have a simple vocation, and this is to help businesses manage people like people.  I suppose that is why it is so hard being a scrum master.

Until next time.

Monday, March 18, 2019

Your Job is to Work with Messy Emotions.

You get pulled in lots of directions.
An agile coach or scrum master is pulled in plenty of directions.  Servant leadership is difficult because you need to put the needs of the team ahead of your own.  It takes an emotional toll to do it properly.  It also requires practice and maturity.  Today on the blog, I would like to discuss the emotional work necessary to be successful.

I have spent the last three month at a new client.  It is refreshing, and it has taken me out of my comfort zone.  The experience has also opened my eyes to the emotional labor necessary to excel as a coach.  You must work with the emotions of the people you are coaching; everyone has good days and bad days.  A servant leader has to absorb those emotions and process them in ways which will benefit the team.  If this expectation sounds unreasonable Kim Scott the author of “Radical Candor,” says, “It is called management, and it is your job!”  A leader needs to put in the work emotionally to make the team successful.

The emotional labor expected of a leader comes in many forms.  A leader must listen to understand.  It is not enough to hear the words a leader must understand the context and emotions of those words.  Next, a leader needs not to take the ups and downs of the job personally.  For someone who takes pride in their work and has plenty of emotional investment in doing good work, this is challenging.  People are going to get angry with you and others are going to demand more from you than you can give.  The key is the anger and demands they are creating are usually their problems and not yours as Collin Powel said being responsible means pissing people off.  As a servant leader, this is inevitable.

Finally, to solve problems, you need to set aside your emotions and try to look at situations in a focused and rational way.  Again, emotional control like this is more natural said than done.  If you care about anything you are doing, you are going to have an emotional investment.  To succeed, a coach or scrum master has to set those emotions aside during periods of stress so that they can “work the problem,” instead of being an emotional wreck.

Human beings are emotional and messy.  Having some emotional control or awareness is tremendous work.  The product of that work will be the respect of the teams you serve and grace under pressure when things go wrong.  It will enhance your leadership and improve your standing in the organization.

Until next time.

Monday, March 11, 2019

Leadership and Eating the Elephant

Abrams as servant leader.
When I am not at the office, I relieve stress by pursuing several hobbies.  I am a big movie buff and love debating cinema of all types.  I also collect and play with toy soldiers.  I have been in the hobby for nearly forty years, and I am a member in good standing with the Historical Miniatures Gaming Society.  You pick up military history by process of osmosis when you collect soldiers.  Interestingly, some of the trivia I have picked up along the way have informed my agile practice.

I have written about military history in the past.  I recognized Eisenhower performing the greatest act of project management in history with his preparations for the D-Day invasion.  I also pointed out Richard Armitage’s efforts to save South Vietnamese soldiers and civilians during the fall of Saigon.  Military history has plenty of stories of heroism and cowardice.  People are elevated to their highest ideals or reduced to animalistic squalor. You are changed forever when you experience it.

It is the ultimate nature of warfare which makes it such a bad metaphor for business.  War is wasteful and is never sustainable.  Many of the lessons of war are not relevant in today’s office because the worst thing that could happen is losing your job.  In combat, a person can be maimed or killed.  It is why when I talk about military history in my agile practice I avoid strategy, tactics, or logistics.  I spent most of my time talking about leadership.  It is the leadership of ordinary people in extraordinary situations which inspires me and which I use to encourage others.

One of the most inspiring leaders I know is Creighton Abrams.  He was a tank commander in World War Two and was part of Patton’s Third Army in Europe.  Abrams nicknamed his tank “Thunderball,” and he had the name emblazed on his tank in bold white letters.  Abrams survived the war in spite of the German’s destroying “Thunderball,” seven times.  He was lucky, brave, and he led his troops from the front.  He never asked a soldier to do something he would not do himself and inspired tremendous loyalty.

After the war, he continued to move through the ranks commanding tank units in Korea and Europe during the early 1960s.  Where his leadership ultimately expressed itself was his command of the U.S. Forces in Vietnam.  Abram’s took over for fellow West Point classmate William Westmorland after his promotion to Army Chief of Staff in 1968.  Abrams assumed command at a dangerous time.  American forces had defeated the North Vietnamese Army and the Viet Cong during the Tet Offensive.  It was an ugly and brutal victory which turned a majority of public opinion against the war in Southeast Asia.  The Communist Vietnamese were going to keep fighting no matter how many people died in the process.  Morale was low, and the mission of U.S. forces in Vietnam was in question.

Newspaper reports asked Abrams how he was going to preserve the South Vietnamese government, beat the communists, and keep U.S. casualties down.  He responded, “when eating an elephant you do it one bite at a time.”  The quotation would guide him the next four years as he led the U.S. withdrawal from Vietnam.

Unlike his predecessor, Abrams shunned the perks of leadership.  He replaced the ornate wood desk first used by the French provincial governors, with the standard steel desk used in the U.S. embassy.  The mission of U.S. combat forces was simplified, and Abrams implemented the Nixon plan of Vietnamization.  By the time he left Vietnam to become the Army Chief of Staff, U.S. forces had reduced from 576,000 to 24,200 troops.  The big test of Vietnamization and Abrams came in 1972 during the Easter Offensive.  With a fraction of the troops he had four years earlier, he stopped a significant assault on the country.

Abrams was the kind of leader who accepted responsibility for both victory and failure.  The My Lai massacre became public during his tenure.  The Khaki Mafia swindled the army out of millions of dollars.  Finally, the battle of Hamburger Hill further inflamed anti-war sentiment.  Despite these challenges and unreliable allies in the South Vietnamese government, Abrams stood as an example and ate the elephant one bite at a time.  The main battle tank in the U.S. Army was named after him; the M1A1 Abrams.

All of this history relates to agile because we should embrace the servant leadership of Abrams.  Instead of hunkering down in our offices or via conference calls, we should lead with our teams.  Instead of grand gestures of reform, we should pile up a stack of little victories which will lead the organization forward.  We should act as servants to our teams and shun the privileges of rank.  The flaws of our organization should be transparent.  Finally, when confronted with a threatening challenge we will be able to adapt and overcome.

Leading change in an organization is difficult.  The adoption of the agile mindset in business is going to be the most significant change in civilization since the protestant reformation.  I draw inspiration from figures like Abrams.  He inspires me to take plenty of small bites from the elephant which is my career.

Until next time.