Admit Weakness and Become Agile

Good teams help compensate
 for the weakness of its individual members.

Continuous improvement and changing organizations are difficult and time-consuming work.  I talk about it all the time because it is the vocation, I find myself.  I worked for years for bad bosses and exploitative people.  I swore to myself if I earned a position of authority, I was going to be different.  Your values and your principles are exposed when you are a servant leader.  You are vulnerable, and learning to forgive others, and yourself becomes critical. I want to talk about something which illustrated that point.

Being a software developer is hard.  It is a lucrative and satisfying career, but it is not easy.  You have to relearn your job every eighteen months.  Developers are surrounded by smart, capable people and expected to be intelligent and capable.  The time spent writing software is filled with false starts and dead ends.  It also contains unrealistic deadlines and pressure to excel.  I was an intermediate level software developer.  It explains why I am so protective of the developers under my leadership; I was one of them.

Since being a developer requires a tremendous amount of problem-solving skills, focus, and intelligence, it creates a culture where to admit misunderstanding or lack of knowledge is to admit weakness.  It is why stand-up meetings degenerate into a perfunctory status report or silent staring matches between the scrum master and the team.  No one wants to look weak, and in many technology companies, this weakness leads to unemployment.

A software demo went poorly this week.  The client was unhappy, and the CEO was frustrated.  What happened next changed the culture of the company and the career of the developer.  Instead of asking why the demo went poorly, the scrum master asked how the demo went badly.  It became apparent the developer was using an untested technology and was struggling for two weeks to meet a deadline.  Instead of speaking up, they suffered in silence.  No one knew there was a problem or that someone needed help.  It was apparent when the software demonstration failed, but by then, it was too late.

Instead of shaming the developer for not knowing the untested technology, the scrum master asked him what he would do differently.  In a heartbeat, the developer said next time they would ask for help.  By showing vulnerability and learning painful lessons, the developer grew as a professional.  The development team learned that they were only as successful as their weakest member.  The team discovered they would have to support each other.  Finally, they accepted failure was necessary if the team is going to succeed.  The scrum master used non-violent language and powerful questions to fix a problem and grow the organization.  I do not doubt that the team will have a successful demonstration in two weeks.  Together, they learned what it takes to be successful.

Admitting vulnerability and asking for help is essential for individuals to come together as a team.  Admitting weakness is a powerful professional strength.  Finally, understand those weaknesses and helping others overcome them is the key to good leadership.  I am glad I got a chance to witness it among my team.

Until next time.

Good Habits, Teamwork, and Grace Create Agility

Forgiveness is Agile

Being a business person is the ultimate endurance sport.  Each day we awaken and try to earn a living for ourselves and the people we love.  It is a grind.  It goes on for years, and if we are lucky, we will get a chance at the end of our lives to reflect and relax.  It is a precarious existence of striving and survival.  The business person confronts this reality each day.  We compete for the quick win and the big score but understand the long term nature of being a business person.  We need to take a look at the long term nature of the life of a business person and how agile can make the experience more sustainable. 

Building a business is a harrowing process.  For every entrepreneur who succeeds, there are more who fail.  Some of the best ideas fail because they can not find a market, while some of the most trivial can generate oceans of wealth.  The random nature of the success breeds arrogance, and these captains of an industry often ignore problems within their organizations until it is too late.  Only when threatened with extinction do organizations feel the need to change.  The scrum master steps into the world of organizational change when the stakes are highest.  It is the realm of failing fast and making corrections.  For some, it is like building the business from scratch all over again. 

The first step is building successful habits among the people doing the work.  It means meeting standards of quality, showing up to meetings prepared, and communicating correctly to make sure everyone understands what needs to happen.  The process of setting up the fundamental expectation of excellence is outlined by philosopher Will Durant who said, “We are what we repeatedly do.  Excellence, then, is not an act; it is a habit.”  Asking people to develop good habits and practice them is the first step to improvement.  Do not ask people to work extra hours and do not expect them to treat their work as a heroic struggle.  Work should be at a sustainable pace; heroic action is unnecessary. 

It is after this process that you enter the second step.  Everyone should understand the business succeeds or fails together as a team.  It takes a team working together and complimenting each other’s strengths to be successful.  The success is constructed on positive habits and relying on others to do their part.  It is the salesperson respecting the administrative assistant for getting the presentation organized, and it is the developer understanding the quality assurance tester wants to ship quality code.  Everyone has a role to play, and it only happens when we work together. 

Habits of excellence and creating a team mentality in the organization are entry-level steps in creating agility.  It also requires what religious people call “grace.”  A pastor once told me the Christian definition of grace is, “…getting absolutely, positively something you do not deserve.”  It is having school canceled when you did not study for an important test.  It is the client rescheduling a meeting when you are stuck in traffic.  I also think grace is when you forgive yourself and someone else for a bad day.  It is the extra cup of coffee or bag of chips as you muddle through the day.  It is letting some go home early to look after a sick child or deal with the side effects of chemotherapy.  Grace means that you can trust others on the team to step up when you are not performing at your best. 

It is only by combining the habits of excellence, creating teams, and practicing grace do we create a more sustainable business environment.  It is a place where the day in day out grind becomes a day of learning, innovation, and forgiveness.  The victories are more regular, and the defeats are more educational.  It is a new way to look at work and one which I hope to pioneer. 

Until next time. 

Legacy Systems are Just as Dangerous as COVID-19

Creatures like this live in our legacy systems. 

The strongest test of leadership is adversity.  It is easy to look like a master of the university when everything is going well. Only when faced with failure and vulnerability, can we understand what kind of leaders we are.  Hardship and stress reveal the strengths of systems; it also points out glaring shortfalls.  One of the more interesting stories this week was a plea from the Governor of New Jersey to COBAL programmers to come out of retirement and fix the state’s antiquated unemployment system.  It is a story of benign neglect and poor leadership.

The computer languages COBOL, PASCAL, and Fortran were the first early languages used in computing.  From the 1950s to the early 1980s, these languages ran the large computer centers of business, government, and academia.  With the explosion of personal computing, these old languages fell out of favor.  With the arrival of a publicly accessible internet, the industry saw newer languages like Java and C# take over the professional world of programming.

The Y2K crisis was the last gasp of COBOL systems in banking and government.  These aging legacy systems had a glaring design flaw; they kept track of the year with two digits.  No one could answer with any confidence what would happen when the century ended, and the systems rolled over to the year “00.”  The Y2K bug created a frantic rush to patch and upgrade systems.  People paid COBOL developers ridiculous sums of money and government, business and academia were making the rush to avoid catastrophe.  Some of my first technology jobs were writing VB code to replace aging COBOL systems.

With the arrival of the millennium, the frantic rush paid off; no significant systems failed, and life proceeded as nothing had happened.  The COBOL developers and the technology pros saved the day.  The reward was unemployment for the tech pros in the dot.com crash of 2000.  COBOL programmers were no longer necessary, so they were laid off, and many of them were not hired again because organizations felt they were over the hill.  I remember being in a job club with many of these people, and I swore I would never let my technology skills become obsolete.

The hard lesson I discovered during the interim between the September 11 attacks and my return to the job market was something people in government chose to ignore.  Legacy systems become obsolete, and the people who knew how to maintain them retire. Schools do not educate people to work on these aging systems, so you are stuck with a difficult challenge.  Do you leave the system to become a ticking bomb, or do you go through the expensive and time-consuming process of upgrading?  Many people opted for the slogan of, “If it ain’t broke, don’t fix it.”  It was a great plan in the short term, but it sowed the seeds for a bitter harvest.

No one expected unemployment claims to be in the millions.  During our worst economic moments, the number of applications was barely over 500,000.  The COVID-19 outbreak changed that perception, and in New Jersey, the outdated unemployment system crashed, making it new to impossible to help people who needed it.  The schools were not teaching students how to program COBOL, and the only people who had experience were retired.  New Jersey has to patch its existing system and replace it with something more modern, and it is not going to be cheap.  The reactive approach is going to cost money and time when we have them in limited supply.

The moral of the story is simple; make sure all of your computer systems can be maintained.  If a college graduate can not update them, it is time to replace or upgrade the system.  Otherwise, you are going to wind up like the great state of New Jersey.

Until next time.

A Hard Lesson in Agile Leadership from the U.S.S. Roosevelt

Agile leadership comes in all shapes and sizes.

The current pandemic and stay at home order continues to linger.  For those of us with careers which give us the privilege to work at home it has been a strange experience. I confess I feel like a grounded teenager stuck at home.  The reality is that many of us are stuck at home.  Plenty of others are less fortunate because they lack adequate shelter, or they are performing essential jobs risking increase exposure from the disease.  I have made a point of keeping informed but not wallowing in the 24-hour news cycle.  One news story did catch my attention, and that was the tale of the U.S.S Theodore Roosevelt.

Theodore Roosevelt is a Nimitz class aircraft carrier.  It is a floating airbase and city which can travel around the world.  It served in Desert Storm and provided continuous support for America’s ongoing efforts to fight the war on terror in the aftermath of the September 11th attacks.  It is a symbol of American power.  It also became an example of how that power is vulnerable.  The ship and its sailors had an outbreak of the COVID-19 virus.

Navy and Marine officers have two significant responsibilities; they accomplish their missions, and they look after the safety of the people under their command.  Everything else is a distraction to sailors and marines.  The commander of the ship Capt. Brett Crozier sent pleas for help and supplies via e-mail up the chain of command.  The navy did not answer those requests but they leaked to the press.  One hundred sailors contracted the disease, and the ship’s commander was asking for the evacuation of the sick to prevent more people from getting ill.

The chain of command exposed for its slow action began a medical evacuation of the ship.  It then relieved Captain Crozier of his command, effectively firing him.  The acting secretary of the navy said he had lost confidence in Crozier’s leadership.  As he left the ship, his sailors cheered and supported him.  We can gather plenty of lessons from this experience.  As an agile coach and scrum master, you should apply them to your practice.

First, look after the wellbeing of the people you lead and serve.  An aircraft carrier is a floating city powered by two nuclear reactors and has a fully functioning airport.  Over six-thousand people live in close quarters on the ship, and it operates night and day.  An outbreak of one-hundred sick people can quickly become a thousand in a matter of weeks.  If the carrier was going to remain combat effective, the sick had to relocate to a naval hospital.  The commander was acting in the best interest of his crew, the United States Navy, and America.  The thought of six thousand sailors sick and dying in the middle of the ocean is the stuff of nightmares—a plague ship that runs on nukes.

In the next lesson, do the right thing even if it is not popular.  Captain Crozier knew he would cause trouble if his messages became public.  He sent the messages anyway because the lives of his sailors and combat effectiveness of his ship were more important than his career.  When senior leadership relieved him of his command, Crozier accepted the decision and stepped aside rather than protest the injustice of his treatment.  He even took the time to make sure his second in command was ready to take over.

Finally, leadership means being with the people doing the work and making you successful.  Captain Crozier has COVID-19, so he had contact with the sailors and marines under his command.  Instead of sequestering himself on the bridge and giving orders, he met with the sick crew members and learned first hand from his ship’s doctor what was happening.  He put the health of his crew above his own.

I think the navy has made a grave mistake in relieving Captain Crozier of his command.  Acting Secretary of the Navy is showing poor leadership in his actions because it is more about keeping appearances to the commander and chief than looking after the safety of sailors and marines.  Being a leader means dealing with bad news, and it means accepting responsibility.  Thomas B. Modly, the current acting secretary of the navy, could have acknowledged the situation on the U.S.S. Roosevelt and admitted the navy was slow to act.  Instead, he fired Crozier sending a clear signal to other officers not to make the navy and the Commander-in-Chief look terrible.  It is a self-interested policy that will cost the lives of sailors and marines.

Being relieved of command effectively ends the career of an officer.  Crozier, if he survives his COVID-19 infection, will be passed over for a promotion and then asked to retire.  If you are a corporation, having someone like Captain Crozier on your leadership team will make your organization better because he will practice servant leadership and look after the people he serves.  He will do the right thing when circumstances require it.  Finally, he will get involved and get his hands dirty in times of crisis.  He may not be commanding an aircraft carrier, but to this agile coach and scrum master, he has shown exceptional leadership.  We need more leaders like Captain Crozier in our organizations.

Until next time.