When it all goes wrong, keep it together.

Bad things happen to good
Scrum Masters

A software developer is an odd creature.  We see ourselves as artists and professionals.  At the same time we can be childish, lack an internal filter and be less than professional.  This week I wanted to talk about what to do when it all goes wrong.  I have a lot of experience in this area.

Software is a creative process.  You receive some vague guidelines from a business person and then you have to transform it into a website or app which makes that business person happy.  Often it becomes a farce, as the business person says that what was created is not what they wanted and to try again without telling the software developer what they want.  This is one of the reasons software developers get so prickly.  They work very hard for people who don’t understand what they want.  Add to this mix time pressures and individuals who don’t understand what it means to develop software and you get a toxic stew of dysfunction.

As a scrum master, you are going to be in situations where it is all going to go wrong.  It has only taken me two years being a scrum master but I am beginning to understand that when everything goes wrong you need to be the focus of stability when everything goes wrong.  The reason why is that in a chaotic situation, the person who has his act together is going to be the person giving orders when people are in need of direction.  If you panic you can bet that the people you are leading are going to start panicking.

This is not an easy thing for me because I am ball of neurotic energy.  I get angry easily and I don’t tolerate foolishness very well.  I also have difficultly being diplomatic when I am dealing with people who are untrustworthy.  That said learning to work with your emotions is an important thing and the best that you can do is control and channel them the better.

Is it easy? No, this is one of the hardest parts of my job.  I have to work on it every day and if I slip for just an instant I become a puddle of rage.  The good news is that it is getting better and my scrum teams are grateful as a result.  So if you are scrum master when everything goes wrong, try to keep it together.  The team and the project are counting on you.

Until next time.

More than the Man in the Taupe Blazer

I am a guy from a state school with a
taupe blazer.  I am going to help you
get your software written on time.

I have had a lot on my mind the two weeks.  My day job is getting more challenging and my home business is puttering along as it always has.  The most interesting thing about working in technology is the pace of change.  If you don’t like something it is bound to change in the span of a week.  This week I wanted to devote more attention to the fine article in Bloomberg Business Week, entitled “What is code?”  For the beginner in technology it is a fine read, but it does get a few things wrong and in particular they get wrong the role of the “scrum master.”

In the first chapter of the rather long article they describe a “scrum master” as “The Man in the Taupe Blazer.”  According to the article:

“This man makes a third less than you, and his education ended with a B.S. from a large perfectly fine state university.  But he has 500+ connections on Linked In.  That plus sign after the “500” bothers you.  How many more than 500 people does he know? Five? Five thousand?”

In short, a Scrum master is an eccentric person who understands software development along with project management and if a project goes south they will be able to get on with their lives while the executive who hires them will be forced into early retirement.  At first glance this is not an unfair impression.

What the article missed is that a scrum master is just as invested as the executive who hires him.  One of first things a scrum master learns is the difference between involvement and commitment.  To be committed, is to put your career at risk if you don’t succeed.  To be involved, is to be a participant in a project with no repercussions should it fail.  This gets to the classic metaphor about the breakfast shop and pigs and chickens.  In my darker moments, I joke about being a pig because I live on a steady diet of garbage, live in the excrement of other pigs, am treated with contempt by the other farm animals, and when necessary butchered for someone else’s breakfast.

I am not far from the truth.  I don’t know how many times I have had a member of my business organization look at me like I am some kind of insect because I am not as; cool, professional, good looking, or credentialed as they are.  I also spend many moments of my day slopping through the mud of my company bureaucracy and infrastructure to get things done.  I have had people lie to me and get insulted when I point out they are lying to me.  I also remember the week before Christmas 2008 when I was slaughtered because I made a mistake after 14 hours of non-stop coding.

So to be clear my executive friends, many of the scrum masters you face have seen failure first hand and they do not wish to experience it again.  They also know that their success is dependent on the same things that make you a success which is getting the project finished on time and on budget.  We are not some empty shell in taupe blazers.  We are just as invested as you are.

Where we excel is that we understand software and the people who write it.  It is not a pretty job but for every skyscraper built it requires hundreds of people who understand, engineering, construction, and motivating construction workers to get the job done.  The tower may have “Trump” on its marque but it took an anonymous engineer with decades of experience to make it rise.

Unfortunately, software development is not construction in the conventional sense.  While buildings are constructed with steel, glass, and concrete, software is built using languages and systems that often do not play nice together.  We also have differing levels of training and experience which is not taught in schools but rather learned on the job so asking a developer to do something that seems routine can be a huge suck of time and money.  Also software developers, the good ones at least, see themselves as artists.  Which means they cannot be led around like construction workers.  They have to be treated like the smart professionals they are.  Instead, they are treated like expensive pigs ready to be sacrificed when a project goes bad.

Yes, I have a taupe blazer.  Instead of a Bachelor of Science, I have earned a Master’s in Management and I have earned numerous credentials in my field to prove to executives that I know what I am doing.  I also have over 17 years writing software and learning how to adopt to the new technologies.  I am your ally.  I am just as invested in the success of the project as you are.  Finally, if you give me what I need to succeed, I will.  So have a little respect for the scrum master’s in your life executives, we are the steady hands which make software work for your business.

Until next time.

Lead, Follow or Get Out of the Way!

Leadership is about change.

It has been a week of confusion and wildly changing situations at my day job.  I have been using this time reflect on my leadership style.  I have also been using this period to do some thinking of the changing role of a leader in the agile.  It is funny how scraps of wisdom bubble up during times of chaos and uncertainty.

When I was in high school, I belonged to the Marine Corp Junior Reserve Officer Training Corps.  I joined as a freshman because I wanted to improve my grades and develop some self-discipline.  In the four years since I made that decision, I rose from a lowly recruit to the executive officer of the company of cadets.  Thanks to the guidance of two Vietnam Veterans named David Ogle and Richard Weidner, I learned how to be a leader.

One of the inspirational signs which hung in the drill room said, “Lead, Follow, or Get the Hell out of the Way.”  That boring vinyl sign is stuck in my mind.  Marines are the definition of commitment, it is their job to go anywhere, at any time to act as the long arm of American Military policy.  This is why they are often rescuing American’s from embassies or showing up at short notice when shots begin to fly.  The sign alludes to this because you are either leading fellow marines, part of the unit doing the work, or staying out of their way because when you give marines a job they are going to do it even if they have to pulverize something into dust.

So what does this mean for a scrum master? Situations are going to change over the course of your career.  This means you are going to have to adapt to the different people.  I am learning to get out of the way of team with a strong technical lead.  It is clear they know what they are doing.  It is also clear they do not want my technical guidance on anything.  This means that I have had to learn to step back and let the team succeed and fail on its own because nothing I am going to say is going to change its mind.  In another situation, I see a scrum team which delivers code in a timely manner and appears to be running correctly, but it is hiding some dysfunction.  It is not delivering features wanted by the business. For that team, I wanted to get out of the way but it seems that I must take a more leadership role.

So a scrum master must change based on the situation he or she finds herself.  We are not empty heads in taupe blazer looking to extort billable hours out of our companies.  The manifesto of agile says that we have to respond to change rather than follow a plan.  This tenant means that we need to lead, follow or get out of the way.  Not learning that lesson means we are in for some uncomfortable failures.

Until next time.

The Greatest Act of Project Management.

This intense young man conducted
the greatest act of project management
in the history of western civilization.

One of the few hobbies I have is collecting toy soldiers and learning about the military history surrounding those soldiers.  This is an important anniversary because it is the 71st anniversary of D-Day and the 70th anniversary of VE-Day.  I am afraid that we can learn a great deal from this period of history from the arrogance of Hermann Goering to the quite leadership of Omar Bradley.  This week I want to discuss the greatest piece of project management ever accomplished, the invasions of Normandy and what people in the Agile community can learn from it.

Looking back the Second World War was the largest catastrophe to occur in western civilization.  Over seventy million people died in the conflict and it spawned, suicide attacks, the deliberate targeting of civilians, and nuclear weapons.  It was the product of economic collapse and punitive treaties.  Its aftermath is still with us today.

Dwight David Eisenhower, was a mid-level officer at the start of World War Two holding the rank of Colonel at the beginning of 1941.  He had a reputation as a good politician and staff officer for more senior commanders including Douglas MacArthur.  From the outside looking in, Eisenhower was condemned to be a mid-level functionary with a minor role in the war.  What changed was that General George Marshal the top military officer during the Second World War, noticed that Eisenhower or Ike as he was nicknamed, had a knack for getting people to work together without having to give orders or invoke rank.  In 1942, he was spending a majority of his time coordinating efforts between British, Free French and other allies in London.  His reward for his efforts was command of the Allied Forces in North Africa fighting Rommel and the Afrika Corps.

The lessons learned in North Africa and the Ike’s efforts to get highly competitive commanders like Patton and Montgomery to work together sealed his fate.  In 1943, he was appointed to the command the Allied Expeditionary forces in Europe.  For good or ill, Eisenhower would be in charge of the planning and execution of the invasion of France to create a second front against Nazi Germany.  The planning included everything from how to deploy airborne troops to how to get millions of gallons fuel across the English Channel.  It had to be conducted with complete secrecy because if the German’s found out they would roll the invading army back into the sea.  It involved schmoozing Winston Churchill over cigars and brandy.  It meant appointing Omar Bradley over Patton because he was a more level headed commander.  It also meant putting up with Charles de Gaulle who when notified of the plan called the entire exercise folly.

The invasion of D-Day was rehearsed twice and conducted in secret.  The launch of the invasion was even delayed thanks to bad weather.  In spite of all the planning, late nights, and countless packs of cigarettes that Eisenhower smoked, there was very little to guarantee the success of the operation.  When the word was given, 5,000 ships and over 150,000 people went into action.  Americans, British, Canadians, Free French, and numerous allies stormed the beach on June 6th.  Eisenhower said that once he had given the orders to launch the invasion, everything was out of his hands and he had to let the troops do their jobs.

I have a tremendous amount of respect for Eisenhower the General.  He was able to sweat the small stuff while not losing site of the big picture.  He was able to deal with difficult and insubordinate people and get them to do a job.  He was willing to take responsibility for failure as well as success.  He respected the people who served under him and never considered a solider expendable.  Finally, we was able to relate to people higher up the chain of command and have them understand how he was going to accomplish the mission.  All of these skills should be possessed by a competent scrum master.

Eisenhower’s story should also be an example of how even a mid-level manager or leader can be thrust into a position of serious visibility and they will have to succeed when the stakes are high.  I keep thinking about that when I grumble about the fact I have a desk in the office about the size of a desk blotter.  Someday, I am going to have to step up and I damn well better be ready for the opportunity.

So this week, I decided to give you a history lesson about Eisenhower and relate it to being a scrum master.  The success of the Normandy invasions are not solely because of his leadership.  Countless troops and support people contributed to the success, but Eisenhower knew the ultimate success or failure of the operation would be pinned on him.  Sound just like what it means to be a scrum master.  So when the pressure gets you down and it seems like you will not be able to succeed just think about Ike and his lonely moments in the spring of 1944 when the lives of hundreds of thousands of people depended on him.  He was able to rise above himself and so will you.

Until next time.

Great Failure Yields Great Wisdom

This guy can teach us about Agile

It is nice to take time off.  It feels slightly decadent to have nothing to do but enjoy time passing.  This week with the Memorial Day holiday behind me I wanted to talk about how agile professional can draw some inspiration from our armed forces to make our teams better.

The American Heroes Channel has be celebrating the end of the Second World War with the seventieth anniversary of VE day.  I think what was more informative was the more muted commemoration of the fortieth anniversary of the fall of Saigon.  That tragic period of history has a deep resonance with me.  Instead of “Peace with Honor” we had the collapse of a nation.  In my mind, the panic, chaos, and missed opportunities of the fall of Saigon seem like a fairly good metaphor for a failing IT project.  People scrambling for the exits, leaders trying to make the best of a bad situation, and stories of commitment and courage all come to the forefront when talking about how to deal with a desperate situation.

I think what sticks out in my mind most is the story of Richard Armitage.  Many people might remember him as the Deputy Secretary of State with Collin Powel during George W. Bush’s presidency.  But in 1975 he had served three tours in Vietnam with the Republic of Vietnam Navy.  He was also involved with the CIA gathering intelligence.  When the end come for South Vietnam, Armitage helped save 30,000 refugees crammed on ships escaping Saigon.  He did this against the wishes of the Philippine and American governments.

What can an agile specialist learn from this story?  First, when the chips are down doing what is “right” is more important than what your boss wants.  Armitage, was supposed to liberate a few officers from the Republic of Vietnam Navy and make sure the frigates and destroyers docked in Saigon did not fall into communist hands.  Instead, he defied orders and not only save the ships and officers but the sailors and their families.  Next, when confronted with an impossible situation make the impossible choice.  There was no way that Armitage was going to save everyone he could but he did the best that he could, given the circumstances.  Not everyone was saved from the communists but 30,000 people were able to breathe free thanks to the impossible choices Armitage made.  Finally, let the work and effort speak for itself.  When the war ended, Armitage’s career was over with the Navy but because of his reputation and experience he quickly found work with the Department of Defense.  Eventually, Armitage would work with a fellow Vietnam Vet named Collin Powel in the State Department.

It is easy to look at military victories and find lessons in them.  I find defeat and failure to be much more informative.  By looking at those tragic efforts we can see where we can improve and how we can do better the next time.  Many of the lessons of Vietnam informed the officers who fought their and guided their decision making steps when it came to future efforts in Iraq and Afghanistan.

So as an agile practitioner remember doing what is right is more important than what your boss wants, make impossible choices in impossible situations, and finally let your efforts speak for itself.

Until next time.