Monday, September 11, 2017

Planning is Everything

This scrum master
wants to be more like Ike.
It takes plenty of emotional energy to be a scrum master or agile coach.  Developers need guidance, product owners need constant coaching, and upper management is always asking for status updates.  It is psychologically exhausting.  Along with day-to-day chores, you are planning and setting strategy.  This week I want to discuss how planning and responding to change are not mutually exclusive.

According to the Agile Manifesto, responding to change is more important than following a plan.  Situations in technology are changing at a rapid clip and an idea that seemed plausible an hour ago can be hopelessly out of date.  Agility depends so much on responding to change.  The unintended consequence of this is business leaders abandoning planning altogether because “We are doing agile we don’t need plans.” Let me try to add a little sanity to this discussion.

The manifesto states, “…while there is value in the items on the right, we value items on the left more.”  Planning has some value and should not be abandoned because we are responding to change.  It seems like a contradiction.

Planning is an integral part of agile.  A scrum team does sprint planning before the start of a sprint to decide what they are going to do.  The product owner does release planning to prioritize stories in the backlog.  A plan makes it possible for an agile team to understand the nature of the problems they are trying to solve.  It also allows them to learn how to respond to change when the inevitable happens.  It explains why Dwight David Eisenhower said, “Plans are worthless, but planning is everything.”  When a team plans they are going over possible scenarios which might happen during a sprint.  The team is also doing much of the analysis necessary to start writing unit tests and code.

To use a metaphor from music, Jazz and Blues musicians still rehearse even though much of their music is improvisational.  The players outline key progressions and cords they are going to play.  It is the plan they use for their performance.  Once the concert begins, situations may dictate a deviance from the scheme.  Thanks to the outlines figured out during the rehearsal, these musicians can respond to change.  The same thing happens to a development team during a sprint.

So responding to change is important but you cannot respond to change unless you have spent some time planning to understand what changes might happen.

Until next time.

Tuesday, September 5, 2017

When a team fails.

Failure Stinks!
I continue to assert that software development is one of the most misunderstood professions in the business world.  Numerous executives think what we do is magic or do not understand the creative nature of the activity.  It is not like working on an assembly line or collecting accounts payable.  There is plenty of uncertainty and opportunities for failure.  As a scrum master and coach, you have to deal with the failure of your agile team along with the personal failures that inevitably crop up in your career.

The saying in the agile community is that you should “fail early and fail often,” because failure is a brutal and efficient means of learning.  The notion of failure conflicts with the “cult of success” preached by motivational speakers.  It also contradicts notions of winning promoted in sports journalism.  I believe the failures in my life and career have made me a better person.  I also feel these failures were necessary milestones on the road to the success I have had in my life.  Failure is painful, but it does put into perspective the ups and downs each of us have in this life.  

Part of the educational process is owning up to and taking responsibility for those failures.  When your team fails to deliver software on time, you have failed.  It is incumbent on you understand what you did wrong and how to avoid the same mistake in the future.  There are situations where you do not have much control, and you still are confronted with failure.  It is unfair and unjust, but accepting that position and learning how to deal with it next time may lead to success in the future.

The acceptance of failure also does something else; it wins the respect of others who have been through the same experience you have.  You have endured the same hardship as others and have accepted responsibility for your shortfalls.  If you blame others or do not assume liability for failure, it will undermine your credibility as a leader and destroy teamwork.  I witnessed this first hand and could see collective eyes rolling as this individual began to speak.

So as a scrum master and agile coach, accept failure and take responsibility for it.

Until next time.

Monday, August 28, 2017

Admitting personal failure

I failed.  I will get over myself.
There is a saying in the medical profession, “When God puts his hand on the left shoulder of a patient, take yours off the right.”  The meaning being that patients die and even the best doctor will have to accept that they cannot heal everyone.  This week I am leaving the University of St. Francis business incubator, and I am shuttering much of my start-up.  I want to discuss this on the blog this week.

Seven years ago, in the aftermath of my failed second marriage, I founded E3 systems. The goal was to create an online inventory management system which other small and medium sized businesses could use to manage their organizations better.  I wrote software non-stop for weeks.  I would sequester myself to focus on setting up business structures which would scale.  I had numerous arguments with my product owner who also happened to be my father.

I would run into various business situations like people expecting me to give them my product for free.  One potential client loved my work until they realized they would have to pay me.  I even did a classic Silicon Valley “pivot” writing software which handled fleet and equipment maintenance.  I flooded social media with youtube videos, tweets, and Facebook posts and information on my product.  I did everything with scalable technologies and paid for everything out of my pocket.  Sadly, I could not do business development and close sales.  As my advisor told me, I was a dilettante.  The business world rejected me with harsh Darwinian indifference.

I toughed it out for seven years.  I kept my day job and hoped someday I would pack up my cubical and go full John Galt.  The last two years have been a denial of reality.  I did not have a market for my products, or a means to sell those products.  I failed.

I am disappointed, but I have learned some valuable lessons.  I understand that I am pretty good at operations and project management.  My software development skills have dramatically improved including my use of SOLID and test-driven development.  I have been jumping on the chest of a dead business.  Everyone knew this but me.  Now that I have a moment of clarity, I see that now is the time step aside and accept its demise.

I will still be open for consulting and will be happy to continue Agile coaching but my days of selling software as a service are over.  I have a relationship with the Will County Project Acclaim which I will continue to support.  I am shuttering my cloud based software on September 1st.  I will keep this blog open because I still have plenty to share about agile and software development.

In the agile movement, we say, fail early and fail often. Failure is the ultimate learning experience.  As a failed entrepreneur of a startup, I consider this something which makes me a better leader, agilest, and software developer.  Once the disappointment wears off, I will be ready for my next act.  I suspect it will be a command performance.

Until next time.

Monday, August 14, 2017

I would have fired him too!

Freedom of expression is not a license to be an asshole.
Plenty of pixels have been expended on the diversity memo from a Google engineer who argues that efforts to improve diversity were a waste of time.  I have been following the arguments and spoken with friends about the dust up.  It dawned on me that this is not a question about diversity versus political correctness.  The entire affair is really about teamwork and being a jerk to you colleagues.  The author of the memo is not free thinking but using pseudoscience to justify biased views.  As an agilest and leader, there is no room for these individuals in your organization.

Over the years, I have been critical of the “brogrammer” culture.  I have also been critical of engineers who think gender is a disqualifying factor to work in technology.  Last week, I further bemoaned the lack of women in the development profession.  I placed much of the blame on a feedback loop of men pursuing computer science careers and providing a leg up to other men in the industry.  It is also apparent to me that working in technology gives certain individuals the license to be an asshole to others.

One of my favorite business books is “The No Asshole Rule,” by Robert I. Sutton, Ph.D.  Sutton does a fantastic job providing a scholarly definition of what an asshole is and reasons why you do not want them in your business.  I think it should be required reading for any business person along with the “The Five Dysfunctions of a Team,” by Partick Lencioni.  

According to Sutton, an Asshole has two traits:
  • Test One: After talking to the alleged asshole, does the “target” feel oppressed, humiliated, de-energized, or belittled by the person?  In particular, does the target feel worse about him- or herself?
  • Test Two: Does the alleged asshole aim his or her venom at people who are less powerful rather those individuals who are more powerful.

Based on the above criteria, it is evident to me that the author of the Google memo is an asshole.  The author considers himself and those like him intellectually and morally superior.  Since they are superior, they should not have to debase themselves by having to educate, mentor, or collaborate with those people.  This"other" could be women, ethnic minorities, and people living different lives.

A modern office is not an environment for this kind of thinking.  Women make up a large percentage of the work force and are filling senior leadership positions.  There are also countless people of color working as professionals.  Finally, individuals who are gay, lesbian, bisexual or transgender are collaborating with those who are not.  Anyone who considers themselves superior to others not like them is going to create tension and undermine collaboration in the office.  Eventually, behavior like this is going to trickle down to the bottom line.  From an agile perspective, individuals who feel this sense of superiority are going to be resistant to continuous improvement.  It is not a surprise the author of the diversity memo wrote this after attending a workshop on the bias.

As a manager and agilest I would have fired the author of the Google memo.  He was a distraction to the firm and advocating for a direction that the company had openly rejected.  Finally, his attitude to co-workers different than him would undermine any project he was assigned.  Better to remove a polyp than deal with cancer which could kill your organization.

Until next time.

I am taking next week off to attend the Gen-Con game fair. 

Monday, August 7, 2017

Software Development needs Women

We need more women in Technology.
I take a great deal of pride in what I do.  Being a scrum master is difficult but it has plenty of intrinsic rewards.   As I have muddled through my career, I have noticed the technology business is diverse.  I have worked with Indian, Pakistani, Russian, and Latino developers.  I have worked with every possible religious group from atheists and pagans to evangelical fundamentalist Christians.  The only criteria in the technology business I have encountered is could a person write good code.  Race, creed or color never disqualified a person from being a software engineer.  Unfortunately, gender is not diverse in the technology business.  We need to do a better job having women represented in the ranks of coders and agile practitioners.   This week, I want to formally provide my support for efforts to get more young girls to join the profession I love.

In the early days of software development, women and men were equally involved in the trade.  These pioneering software developers were business people first who learned how to write software without a formal collegiate curriculum.  One of the best depictions of this period is the film “Hidden Figures” which shows women of color working for NASA.  The 1950’s and 1960’s were not a golden age of diversity in American Business, but in the early days of software development, there was less gender disparity.

I believe that this changed as colleges began accepting undergraduates for computer science course.  Men began to dominate in this academic major, and it created a feedback loop of men helping other men get into the profession.  As women retired from the occupation, men replaced them.  These individuals knew how to code but did not understand the businesses they were working. As the business of software development became more lucrative and prestigious, companies pushed more women out the activity.  With fewer women in the occupation, the “brogrammer” culture began to grow, and software development teams became hostile work environments.  With the rise of Silicon Valley software shops, this trend became more pronounced, and it has been severely parodied in popular culture thanks to the HBO series. 

I am glad to report that over the years, I have run into plenty of exceptional women who walk a lonely road and work in this profession.  It is also good to see the rise of organizations like Girl Scouts and Code Like a girl encourage young people to get into the profession.  There is plenty of toxic masculinity in this business, and only with the addition of more women, a means to discourage it.  Finally, it is important that men support women in this craft.

Software development is a diverse profession, but it could do better with gender equity.  It is up to all of us in the business to recognize that girls can code and they are welcome in the profession.

Until next time.

Monday, July 31, 2017

Learning to Manage time

Time should never be wasted
A software developer is a unique brand of employee.  The profession requires mental toughness and creativity.  The ability to create software also requires strong time management skills.  As a scrum master, you need to help your colleagues learn to manage time better.

If you work in technology, you confront a stark reality.  To keep the global economy moving there is a too much work chasing too few people.  Less than .05% of the world's population can build software and maintain the networks which run it.  Software engineers are under constant pressure to grind out code.  For those who do not understand, it feels like cramming for an exam every day of your working life.  This kind of pressure takes a mental and physical toll on the people doing the work.  Developer’s abuse alcohol, binge eat, take numerous prescription medications and engage in unhealthy behaviors to mitigate the stress.  It is an abusive cycle which leads to burnout and bad quality.

As a scrum master, we need to help others learn to manage time better.  First, create a routine for the development team and business owners.  The daily stand up should never state late, and everyone should attend.  Next developers need “quite time” to concentrate and do work.  People who are looking for favors, football pools, and making lunch plans are forbidden if they interrupt the developers.  Finally, headphones and other techniques to create a state of flow should be encouraged.
Business people divide their day in hour long chunks.  Software engineers think in thirds.  There are morning, afternoon and evening and each period is an opportunity to work and write software.  Another reason I have no meetings scheduled in the afternoon for the development team; I want the afternoons to be interruption free for the developers.

I also use it as a time management tool for product owners.  After lunch, I have a one-hour sprint refinement meeting.  We discuss stories for an hour and then adjourn for the day.  The time after sprint refinement is a perfect opportunity to write user stories.  Developers get into the routine of meetings in the morning and open afternoons of coding.  Product owners understand that the time after the sprint refinement meeting is for writing stories.

So a helpful way to help others better manage their time is to give them clear routines so they can set aside time to do the work.  It is not perfect, but it beats flailing around the office in a panic.

Until next time.

Monday, July 24, 2017

Life Lessons influence Your Agile Coaching

Twenty Seven years later this cover of Time
 magazine still bugs me.  They got it wrong.
Little things remind me of my mortality.  This week I received an invitation to my high school homecoming and a fiftieth birthday party for the class of 1986 afterward.  This reminder of my demise made me do some reflection.  There is nothing like the specter of death to force you to take stock of your life.  This week I wanted to share my revelations.

Demographically, I belong to the Generation X cohort of American history.  Born in the late 1960’s and early 1970’s we were raised in the Reagan 1980’s.  We witnessed the birth of Apple and the fall of the Berlin Wall.  We experienced “Morning in America” and two ugly recessions.  The revolution was televised on MTV, and the counter-revolution came from the White House.  The anxiety of terrorism was nothing compared to the possibility of human extinction caused by mistake in the Cold War.  Plenty of cultural forces mixed to create emulsion which is still relevant today.

As a nerdy Dungeons & Dragons playing child, there was no place to find solace during this period.  I was a striver and wanted to succeed.  There was no internet culture to speak of so I relied on my small circle of friends in theater, JROTC, and scouts to muddle through.  It was a lonely way to grow up.  It was also preparing for my future career because nothing is more solitary that leading change.

Like many people in the early 1990’s, I was adrift.  The job market was lousy, and the prospects for a college graduate were not good.  I worked odd jobs and spent most of my time attempting to be self-sufficient. After working in a casino for a few years, I decided to make a change and become a technology professional.  It was 1998, I was thirty years old, and I began my first entry level job as a Visual Basic developer.  I had found a career.

My career would have numerous ups and downs.  I would confront long term unemployment in the aftermath of the bubble.  I would be a consultant, and I would work full time for plenty of companies.  It would take me ten years to learn how to become a competent web developer.  During this period I was exposed to Agile and Scrum.  Since that moment in 2009, I feel like I have gone through a second educational period in my life.  I completed a master’s degree in management.  I became a certified scrum master and then later a certified scrum professional.  I began spreading my experience and knowledge around.  It has been rewarding and fun.

Lately, I have noticed how much cultural opposition within the business community there is to Agile.  It is hard to break old habits and upset personal relationships when you are trying to improve business.  Personal loyalty often takes precedence over doing the right thing for the firm.  There is a lot of understandable fear in the cubicles of America about change and what that means.

Using quantitative measure to judge performance holding people accountable for delivering a quality product, and expecting everyone contributes is controversial among white collar workers.

“It is unfair to measure me to everyone else,” someone I was coaching said.

The reality is it is unfair for someone in the office not to do their job to the best of the ability and cause customer service to suffer.  It is also unfair that you are not improving as your career progresses.  Technology professionals understand this, and it is about time other people in the business community do as well.

So as 2017 drifts lazily into its third, quarter, I am looking forward to the class of 1986 reunion.  My life struggles are a legacy for others to gain experience.  It explains why I enjoy training new developers and helping others avoid the mistakes I made in my career.  Growing old is not as terrible as I suspected.  My life experience has given me the tools to help others, and it just means I have a lot of wisdom to share.  My life prepared me to be the scrum master and the agile coach I am today.  Not a sad thought when you are confronting your mortality.

Until next time.

Monday, July 17, 2017

Work should not make you crazy

Being an office worker feels this wrong and it
needs to change or the global economy is in trouble.
I have been a business professional for over twenty years.  I have witnessed the good, the bad and the ugly of what it means to be a professional.  I am well compensated for my work, but like many people today I live paycheck to paycheck.  I have endured three recessions in my lifetime each time suffering a personal of a financial setback.  I am pretty stoic about these experiences, but they continue having a lingering effect on the kind of leadership I practice.  This week I want to talk about an issue which is an unspoken problem in the business community – mental health.

I began thinking about this topic when news came out on Mashable about Madalyn Parker.  She sent an e-mail where she told her staff that she was taking two days off for mental health reasons.  Her letter was then followed up by a letter from the CEO thanking her for taking the time to focus on her health and wished her a swift recovery.  What followed was a flurry of articles and think pieces about mental illness in the work place.  I want to add my two cents to the conversation.

The world of the white collar professional is unforgiving, highly competitive, impersonal and unfair.  The global economy does not care about the individuals who keep it going.  The factory worker manufacturing smart phones in China, the developer working late nights building applications and the young person cultivating social media likes are all part of this ecosystem.  This environment is an ideal breeding ground for mental illness.  With 1 in 5 Americans who have a mental illness, and I consider addiction part of this statistic, there needs to be a discussion about mental health in the work place.

The reason I became an agile practitioner is as a software developer I labored in plenty of situations which were dysfunctional.  I swore there must be a better way if given a chance I would help lead the necessary changes.  My career is guided by that mission.  In that respect, I am similar to the muckrakers and union organizers of the late 19th century.  These people lobbied and organized to end child labor, reduce injuries in the workplace, and enforced fire safety in all factories.  Eventually, the government became involved, and O.S.H.A. was created to ensure the abuses of the past never happen again.

Just like we do not want to work in factories where the likelihood of amputation or death is high we should also demand offices which discourage mental illness.  Here are some of the long term trends I see which are promoting mental illness.

The use of alcohol and recreational drugs as a social lubricant in business. – 

As long as there has been an America, there has been alcohol.  The nation’s drinking problem became so bad that elected officials, wrongly, passed a constitutional amendment to ban the sale of alcohol entirely. When prohibition proved to be a failure, American returned to its drinking ways.  The real spike in alcohol abuse in this nation took place in the 1950’s and 1960’s.  “The Man in the Gray Flannel Suit” and the television show “Mad Men” chronical these boozy times.

Fifty years later, alcohol is the drug of choice in the media profession.  Client in all industries is being “entertained” with fine wine and cocktails.  Account executives and vendors are exchanging and consuming alcohol, and it is a regular business practice.   Professionals see this as early as college and discover the consumption of alcohol is a way to deal with stress.  Some of these professionals develop addictions problems, and these addiction problems spill over into the business.

Also, the use of cannabis among engineers has increased over the last fifty years as well as abuse of cocaine among executive ranks.  The reliance of both legal and illegal means to alter consciousness exacerbates existing mental health issues and hurts productivity.  The office should not be a gateway to addiction.

Sleep deprivation. –

Tight deadlines, outsourcing and the around the clock nature of the economy means that a professional to conduct their job has an irregular sleep schedule.  I have written about the importance of sleep in the past, and so has my friend Lawrence Gasik.  Research has shown that people who do not get enough sleep exhibit the traits of PTSD or alcohol intoxication.  There are international conference calls to take and offshore teams to consult.  Business leaders still expect meetings in the office take place during daylight hours, so those people working on these bifurcated sleep schedules suffer in silence.  It explains why sleep aids, melatonin, coffee and Five Hour Energy drinks sell so well in the United States.  We are attempting to whipsaw our bodies into sleep and wakefulness to accommodate the demands of the global economy. This type of sleep deprivation also undermines the mental health of employees.

The focus on shareholder values instead of customer value in large companies. –

Richard Eastman of the Kodak Company paid his employees above average rates, provided numerous perks for his employees and provided outstanding service.  He resisted unionization of his office and factory workers but always made sure his pay and benefit packages were always better than the current market.  With rising unionization of the work force, capital balanced the needs of customers, labor, and shareholders.

This trend began to change as future CEO Jack Welch gave a speech about “Shareholder Value,” to The Pierre in New York.  Combined with the Chicago school of Economics, led by Nobel laureate Milton Freedman business leaders began to worry more about share price than other aspects of the firm.  The effects have been remarkable.  Stock prices have increased for many companies, a particular segment of the investment class has gotten obscenely wealthy, and many mergers and acquisitions have happened to create massive economies of scale.  Shareholder value also lead to the Financial Crisis of 2008 popularized in “The Big Short,” the rise and fall of Enron, the skullduggery of RJR Nabisco and finally the destruction numerous corporate towns in middle America and popularized by the book “Glass House.”

There is plenty of pushback in the academic community against the shareholder value movement, but the business sector has not embraced it and still do not see employees as partners in success.

The inability for business to pay people their real labor value. –

Since the Presidency of George W. Bush and the bursting of the bubble, companies have gotten very good at creating what my friend Bob Karzeniowski calls the musical chairs economy.  Using slow growth as an excuses firms are demanding more experience from applicants and cutting back training opportunities.  People cannot get on the career ladder, and those that do often have limited chances for advancement.  I also should point out that recruiters and hiring managers openly discriminate against the unemployed people and those who are laid off.

The Great Recession of 2008 – 2009, created a glut of workers.  It has taken nine years, but now that the job market has tightened, business people have lost the “muscle memory,” to increase labor participation to meet the market demand.  We now have created perverse incentives such as airlines having to cancel flights because there are not enough pilots.  Low wages, the musical chairs job market, and the mental scars of the great recession create insecurity.  This instability leads to the undermining of self-esteem and mental illness issues.

The promotions of people with psychopathic tendencies into executive leadership roles.  –

Over the last 40 years, we have been promoting the wrong people into business leadership roles.  Many of these people support the short sided notion of increasing shareholder value.  Making matters worse is some of them are psychopathic who find emotional fulfillment by playing people off each other.  Instead of nurturing others and guiding the business, these leaders create a toxic stew of dysfunction.

It is even more pernicious because these leaders become celebrities in the corporate world and media.  Finally, psychopaths are emotional chameleons kissing up and kicking down to advance their careers.  These emotional vampires undermine morale, and the mind games threaten mental health.

Finally, social stigma against people with mental illness means people who should get help do not. –

Numerous studies have shown the stigma of mental illness is the principle reason people do not get treatment.  This stigma is amplified in the business world where mental toughness and grit are highly prized; to admit weakness is to accept failure.  Venture capitalists are reluctant to give money to people who might be risky.  Someone with bipolar disorder or narcissistic rage is risky to lead a project.  The stigma of mental illness is equal to risk, so business people shun it.

I find it ironic business people does not treat individuals with diabetes or high blood pressure in a similar fashion.  Mental illness if managed correctly, resembles those chronic diseases.  So the stigma of mental illness and its effects on a career prevent people from getting help when they need it.

Taken together, I think these six factors in the modern workplace make it fertile soil to nature mental illness.  Most business people pay lip service to their employee’s mental health because they are trying to keep the business running, meet payroll, and keep investors happy.  It is an ugly spiral; if we want productivity and GDP numbers to improve the business community will have to make some significant reforms.

Just as a factory with fewer fatal accidents is more productive one with deadly accidents; then the contemporary office with fewer mental health problems is more competitive than an office filled with dysfunctional people.  What we currently have is not sustainable, it is better to reform now than wait and see what happens next.

Until next time.

Monday, July 10, 2017

Respond to Change or else

Change is not magic.
Software development is a weird stew of activities.  It is a creative activity taking the vague guidelines of others and turning it into working code.  It is an engineering activity because it requires a certain mindset only found in engineering.  It requires business acumen because software should do something which supports business.  Finally, a software developer has to adjust to change because technology, business, and the world are moving at the speed of the internet.  It is my firm belief that the best software developers and Scrum Masters need to acknowledge this change and learn to work with it.

I am coming up on twenty years in the software business, and the skills I needed at the beginning of my career do not match the ones I use today.  Some principles do translate like HTML, CSS, and object-oriented programming but in the beginning, there was no such thing as generics, responsive web design, or C#.  I relearned the skills I needed in my career every 18 months.  The reward for this struggle is employment and opportunities to share my experiences with others.  I want to make sure that no one suffers the kind of failure or mishaps I have in my career.

The constant theme in my career has been responding to change.  When careers began to dry up, I learned to code in C#.  As screens became smaller and mobile computing began to grow; I had to learn Bootstrap CSS and Jquery Mobile.  I was an early adopter of Agile and Scrum, but that has not stopped me from reaching out to find out more frameworks like LESS and SAFe to be successful.  In this business, a person needs to keep learning and growing.

In the agile manifesto, this idea is called, “Responding to change over following a plan.” In our contemporary economy, there are no promises in business so as a working person it is important to make sure your skills are up to date and marketable.  As an employer, it is important to address technical debt and make sure your staff is learning the latest skills to keep your company infrastructure up to date.  Upgrade your servers, use an office suite in the current decade, and shun mediocrity in all its forms.

The only thing sure in the business community is change and to be a successful software developer or scrum master you must learn to embrace change.

Until next time.

Monday, July 3, 2017

Feeling All American!!

America may not look good but we have a lot to offer.
The United States is commemorating its Independence Day.  It is a time to look back at the nation’s history, celebrate the present and look to the future.  I am a business person and agilest.  I am also American which means I view the world with a, particularly American perspective.  This week, I want to talk about my American perspective and how it shapes my agile practice.

My European and Canadian friend tease me with the stereotype of the “Ugly American.”  To them, the stereotype posits that we American’s are uncouth interlopers with lots of money but no manners, style, culture or ideas which have value to the rest of the world.  I disagree with them politely and let the facts speak for themselves.  America for better or worse helped create the global economy in the aftermath of the second world war; we take for granted today.  America is why you can purchase a Coca-Cola in any nation in the world. 

We are not a perfect nation.  Our politics are deeply divided, and we are currently involved in on-going wars in the Middle East.  In spite of those challenges, American’s for the last century have stood up to totalitarianism, communism, and terrorism.  When asked, we have come to the aid of our allies and attempted to act as an example for the rest of the world to follow.  That said, I think our three biggest exports to the world are philosophical. Two of these concepts come from the nineteenth century; Transcendentalism and Pragmatism.  The other is from the present day – the agile reformation.  All three of these diverse ideas influence me and my agile practice.

Transcendentalism seems very high brow and something out of a high school American literature course, but we see its influence around us.  The focus on individualism and finding a spiritual connection with the divine links it with the current new age movement.  Thoreau’s ideas of civil disobedience are part of every social justice movement.  Finally, the desire to embrace nature and simplicity is the central framework of modern environmentalism.  I see the concentration on the individual and desire to make the most of one’s time on earth outlined in transcendentalism to be revealing.  Life is too short to be working on poorly run projects and being involved in drudgery.  Work must not only provide material comfort, but it must give people purpose.  I thank transcendentalism for that perspective.  

Pragmatism was a significant movement in American thinking.  Its central idea is, “…the practical application of ideas by acting on them to test them in human experience.”  In other words, a pragmatist does not worry about grand theories of how the world works.  They are concerned about what ideas “work” in the world.  It is responding to change over following a plan.  To pragmatists, an idea or action is only useful based on its practical application in the world.  Pragmatism is why all cities in the United States have water treatment.  Thanks to Pragmatists we set aside our notions of free markets and individual liberty to charge everyone taxes to make sure water is safe to drink.  To reduce the spread of cholera and dysentery in our nation, we sacrificed some individual liberty.  This a classic example of pragmatism.  For a scrum master or agile coach, it means you need to reject ideological rigidity if you want the team to be more successful; in other words, respond to change.

Finally, we have to discuss the agile movement and how it went from an American idea to a global reformation.  The Scrum Alliance has gatherings in Dublin and Singapore this year.  The Scaled Agile Alliance is spreading knowledge around the world.  Finally, business from Korea to Canada attempting to take the Agile manifesto and make it work for their companies.  The reason why we have this broad acceptance of the new way of doing business is that it delivers improved results.  We are turning out software better and faster thanks to the agile reformation than any time in the history of the industry.  It seems pragmatism encourages these new ways of doing things in the business world.

So, this “Ugly American,” takes pride in transcendentalism, pragmatism and agile.  They are uniquely American ideas which are making the business community and the world a better place.

Happy Independence Day and Until next time.

Monday, June 26, 2017

Developing the professional scrum master

If you think this is ugly try
hiring an amateur plumber to fix it. 
The business world has a saying, “If you think hiring a professional is expensive, wait until you hire an amateur.”  The obvious meaning being a poorly trained amateur will cost the company more money than someone who is more expensive but better qualified.  This week I want to talk about the minimum standards of professionalism you should expect from a scrum master.

I am a big believer that with enough time and training anyone can develop a useful skill.  If I devoted ten years of my life learning to be a plumber I could become competent.  Unfortunately, I know myself well enough to know that I need to call a professional when my water heater breaks.  A bonded plumber is worth the time and expense for me to have hot water.

When you get into other activities training is only a small part of the equation.  You can practice piano for years and still not be good enough to entertain an audience not composed of parents.  Jazz musicians refer to the quality of being able to improvise and perform in front of an unpredictable crowd as “chops.”  The idea is that anyone can learn to play the notes, but a real musician has chops.  Hard work, combined with talent makes a jazz musician successful.

I feel the same way about scrum mastery.  Everyone can be trained to do the job, but only a minority can do the job well.  It is the difference between having a high school student perform at your night club and having Elton John setting up a residency.  Fortunately, there are plenty of good programs to train scrum masters.  I am particularly fond of the Scrum Alliance Certified Scrum Master certification because it teaches the basics of the job along with the more touchy-feely skills which come with the job.

Once they have received some training, they can then lead a scrum team.  I recommend putting a rookie scrum master with an experienced product owner. This way the scrum master can gain experience with someone who can show them the ropes of the business and the particulars of a project.  With a year or two of experience, a scrum master can help a product owner learn their trade.  Much like the ideas proposed in extreme programming an experienced veteran should partner with a rookie so they both gain from each other’s experience.

With a little luck, you will find someone who is outgoing, a good communicator, empathic, has grace under pressure and can act as team therapist.  Then and only then do you have a scrum master with chops who can take your team to the next level.  So take the time to train your scrum masters.  Next, pair them with experienced developers and product owners, so they gain confidence and experience.  Finally, make sure you find people who possess the talents which will make them successful in the job.  If you do this, you will not have to pay extra for an amateur managing your scrum teams.

Until next time.

Monday, June 19, 2017

Beware the Temptation of "Dark Scrum"

Avoid the temptations of "Dark Scrum"
I have been an agilist since 2009.  I began collecting certifications for Agile and Scrum since 2013.  I even finished up my master’s degree studying the differences between waterfall and iterative project management processes.  I have some skills.  What I find most challenging as an agile practitioner is a disconnect between those of us doing the work and the business people who depend on us.  When this happens, it creates a situation Ron Jeffries calls, “Dark Scrum.”  As a scrum master and agile coach, it is your duty to avoid this situation.  This week on the blog avoiding the temptations of “dark scrum.”

In my formulation, "dark scrum," is when the business users of Scrum use the methodology to enforce control over software development rather than use it to improve quality and customer satisfaction.  Jefferies gives plenty of good examples on his blog, but I would like to provide two more.  I consider them to be pathologies of a dysfunctional organization.

Dark scrum pathology – shoehorning arbitrary deadlines on to sprints.  

One afternoon, I was in the office of a Vice President.  I had been raising concerns with him that a project was going poorly and that I would need his support and intervention.  The meeting did not go well.

“I promised the board that this project would be done by X date,” he said.

I told him based on the stories we had and a three-week sprint cadence we could deliver by a later date.

“You are agile, figure it out,” the VP said, “I need it by X date.”

The executive violated the social compact of agile, and we removed stories and features to meet the arbitrary date.  The customer was disappointed, and the Vice President looked bad.

Dark scrum pathology – why do I have to meet with the off-shore team.

Product owners write stories, but because of the time difference between the onshore and offshore components of the project, did not participate in the stand-up meetings.  We had created a situation where the developers would ask questions, and it would take over 24 hours to get them answered.  Product owners also complained that the team was not understanding the detailed requirements to get the work done.  When prodded to attend the stand-up call with the off-shore team a product owner indignantly said, “I am not waking up that early to talk with India!”

We were able to correct these pathologies.

To address the arbitrary deadline problem, bring in executives and product owners to level set expectations.  In the world of Scrum, the product owner is the person primarily responsible for the success or failure of a project.  The executives outside the team are responsible for funding and helping to remove organizational obstacles.  Knowing financing and deadline commitments provides the product owner a framework to write stories.  The scrum master can then use team velocity and the sprint cadence to let everyone know when a deadline is realistic and when it is not.  This way the social compact of agile is respected, and there are not secrets for all the parties involved.

We solved the next pathology by moving up the stand-up meeting by thirty minutes.  The product owner could take the call from home when they got out of bed but before they came into the office.  Product owners answered questions quickly and user stories improved.  Also, automated testing got better as product owners relied on the offshore QA professionals to streamline acceptance testing.  What was once a burden, became a win-win for the entire team.

The hard part about being a scrum master and agile coach is you are forced to come up with solutions like this each day to prevent your organization from falling into “dark scrum.”  Any situation where those in power ignore the input of the people doing the work is going to add darkness to the organization.  It is why the agile reformation is so important.  By beating back the pathologies of “dark scrum,” we can be successful software developers and professionals.

Until next time.

Monday, June 12, 2017

Leading by example for the scrum master

Any good scrum master will tell you the hardest part of the job is servant leadership.  Each day you need to sublimate your wants and desires for the good of the team.  It is a difficult road to travel, and I want to discuss it this week on the blog.

I find plenty of inspiration from the United States Marine Corps.  They were into servant leadership before the concept had a name in the business world.  All Marine Corps officers learn the phrase “Ductus Exemplo,” which is Latin for the phrase “lead by example.”  That means Marine officers are expected to be an example to the troops they lead and each other.  They eat last.  They make sure their appearance and equipment are “squared away,” so that other troops will follow along.  They don’t rest until everyone come back from patrol.  Finally, they don’t ask anyone to do something they would not do themselves.

The scrum master has plenty of other responsibilities.  They are making sure the team is improving each sprint.  They train product owners and hold them responsible for their work.  They are learning new techniques to keep up with the latest technology trends.  It is late nights doing production pushes with the release team and early morning working with offshore developers.

The reason for many of these sacrifices is simple.  Someday you are going to need developers to work late or a product owner to go above and beyond the call of duty.  That is when they will follow your example and come through.

In short, servant leadership is leading by example and something you will have to do if you want your team to succeed.

Until next time.

Monday, June 5, 2017

Scrum Master Dragon Slayer

This is a typical agile implementation
Growing up in the 1980’s, when you set aside the prospect of the United States and the Soviet Union having a nuclear exchange, it was an excellent time to grow up.  Dungeons and Dragons were part of the popular culture and the movies reflected this trend with films like “The Sword and the Sorcerer,” “Conan the Barbarian,” and the cult classic “The Beastmaster.”  For a nerdy teenage boy, it was beautiful escapism.  It was also a way to learn a few serious lessons about life.  "Excalibur" showed the cost of infidelity to a thirteen-year-old who had not started shaving.  The most significant lesson came from a dark Disney film entitled “Dragonslayer.”

The film had a simple plot.  A dragon is terrorizing a local kingdom, and a wizard and his apprentice must slay the creature. The mission has additional urgency because the king’s daughter has arranged to sacrifice herself to the dragon.  The story has all sorts of threads woven together.  It is the sixth century, so Christians are using the dragon to recruit converts.  The pagan king sees the Christians and their desires to undermine his legitimacy as more important than the life of his daughter.  There are an aging wizard and impetuous apprentice along with a princess and a fire-breathing dragon to round out the cast.

Late one night in a moment of insomnia, it dawned on me this movie was the perfect metaphor for an agile implementation.  The wizard and apprentice are consultants hired by the king to help him solve his dragon problem.  These consultants discover the depths of the political and social rot in the kingdom which threatens to consume them.  Finally, there is the climactic moment where the dragon has to die.

People behave certain ways and do certain things because people have behaved that way for centuries.  Everyone is looking out for themselves, and the dragon is always in the background ready to bring destruction from the air.  I cannot describe a better way to explain a contract engagement with a client if I tried.  

The most galling portion of the film is after the dragon dies; the local king stands over the corpse of the beast with a sword and stabs the dead creature while his Chamberlain proclaims the king a “dragon slayer.”  Countless people have died in the process, and the Christians use the death of the dragon as a recruiting tool.  It almost makes a person wish the dragon could win and turn the entire kingdom into ash – almost.

Like someone who has had an agile practice for the last eight years, I identify with the wizard and his apprentice.  I am training others to be better developers, product owners, and scrum masters.  I am also looking to help develop my skills to make myself better and more useful to my clients and employers.  Often, I encounter internal rot in organizations and have to focus on the dragon flying overhead instead of the more long-range problems.

As a scrum master and coach here is what I do.  Considering I have hired to slay a dragon, the first thing I concentrate on is killing the dragon.  A common phrase in business is “…first things first; last things never.”  Fix the dragon problem.  I expect that the king will take credit for my work.  They did not become King being kind people.  Next set an example so that other villagers will aspire to be wizards.  The practice of agile will only grow if it spreads person to person.  Certifications and trade shows are necessary, but the only way it is truly going to take over the business world is when conscientious practitioners make the agile manifesto and principles work for companies.

Finally, know when to ride off into the sunset.  An agile coach and scrum master are often a threat to the executive leadership because they are more interested in getting work done than the political niceties executives seem to give more priority.  When this happens, tip your hat to the king who took credit for your job and ride off into the sunset.  It may explain why many of the better wizards of literature wander or are hermits.  Working for the King is a sure road to stagnation.

So as one sorcerer apprentice to another; always slay the dragon, recruit more apprentices by your actions, and ride off when you are not needed or wanted anymore.  It certainly beats winding up in the belly of a dragon or the king’s dungeon.

Until next time.

Monday, May 29, 2017

All about the craft of Scrum Mastery

A good scrum master is like a good camp counselor
I take inspiration from plenty of people online and if you have followed this blog for any length of time you will realize I am not afraid to cite my influences.  I have also been a brig proponent of Scrum Mastery being a profession which requires more than showing up to the office.  This week, I want to talk more about the craft and business of being a scrum master.

I have said before being a good developer is in many respects like being a good jazz musician. You can say the same about being a scrum master.  A scrum master must have some technical chops and be able to perform their duties regardless of the situation.  You need to be prepared for anything and flexible enough for when the unexpected happens.  It is hours sitting around with developers active as a “rubber duck” to help them solve problems.  It is listening to them vent about frustrations. Finally, it is about continuous improvement.

It is not an easy job.  One moment you are a therapist for a developer and the next you are disciplining a product owner who is not doing their job.  I have had moments of deep rage where I find myself shouting at my house plants.  The anger is contrasted with sublime satisfaction knowing I am shipping software and helping the business meet customer needs. I have experienced every emotion between these two polls.  Each day is a new adventure and series of emotions to experience.
Companies are looking for scrum masters at an increasing rate because they are struggling to meet increasingly challenging customer demands.  They are also attempting to take dysfunctional cultures and transform them into something where people are willing to innovate.  They want to turn the peasant farmers who labor in their cubicles and transform them into warrior poets.

It takes strange and caring people to lead this kind of charismatic change.  The ironic part is these individuals are often entrepreneurs and iconoclasts who do not mesh with corporate culture.  I am sure every scrum master has a story about visiting the Vice-President's office for removing an impediment and ignoring the office politics.  I have discovered most transgressions are forgiven if you are getting software into production.

So being a scrum master is both a profession and a craft.  I would not have it any other way, and I am looking to help other people understand this career.

Until next time.

Monday, May 22, 2017

Avoid cynicism by networking

Never be a dark scrum master
After a few years working as a scrum master, a person can develop some gallows humor.  Every excuse elicits a chuckle of dark laughter.  Each setback and technical glitch generate a wry smile of world-weary acknowledgment.  This cynical detachment is a survival mechanism; otherwise, you spiral into a cycle of depression.  The trouble with this strategy is that cynicism is not a good way to lead others.  This week I want to talk about avoiding the trap of cynicism.

One of the great things about the Agile community is there are trade associations to support the people doing the hard work.  There are the Scrum Alliance and the Scaled Agile community who provide support.  These organizations also have trade shows and conferences which act as a means to provide continuing educations.  The biggest benefit to these agencies is that we are put in touch with like-minded people, and we support each other.

Former Secretary of State Collin Powel says, “Leadership is lonely.”  As an agile coach and scrum master, most of your time is spent in the lonely activity of leadership.  You are a member of the team but you also apart from it.  You are training product owners and helping developers improve.  You are also answering to management educating them on how Agile works and how the teams are delivering software.  This loneliness creates social isolation at work.

This is why I enjoy getting together with other agile professionals at user groups and conferences.  We can swap stories, exchange solutions to common problems and be a source of moral support.  It is nice to speak the same lingo to others and to understand your struggles making organizations better are their struggles.  For a few hours each month, I feel a little less lonely.

This is why I encourage others to attend networking events, training, and conferences.  The knowledge gained is valuable but the moral support from your peer’s help you fight off cynicism.

Until next time.

Monday, May 8, 2017

Software is NOT magic

I have spent much of my professional life building and leading others who build software.  It is a rewarding process but filled with countless hours of toil and uncertainty.  I liken it to solving a crossword puzzle on a deadline every day.  This week I want to talk about software and why the perception it is free is wrong.

The world of software development is a topsy-turvy world.  The first copy of the product is prohibitively expensive filled with thousands of dollars of engineering.  The second and subsequent copies are free thanks to digital copying.  To the end consumer, this makes software look like a free and magical tool.  Nothing could be further from the truth.

Each piece of software uses a database.  That database has a structure of tables which resembles a skeleton for the application whether it is a website, mobile application or shrink-wrapped piece of software.  Those databases do their work with a language called SQL.  Depending on the manufacturer of the database the SQL will be slightly different, so software developers have learned to specialize in the various dialects of SQL.  Specialization has forced companies to invest in one brand of database over another.  It is why one group is called an “Oracle” shop over a “Microsoft” shop.

Next software is dependent on what kind of device it will run on.  An application which will run on a mobile device will need to be constructed in one fashion while one which will work on the web will have to be designed differently to work it a different environment.  It requires specialization.  So someone with HTML and Jquery experience may not be very helpful on a mobile application project.
This kind of specialization is necessary for business. Specialization is also expensive, so business people want to save money by off-shoring the work to Northern Ireland or India.  It does save money but makes the process more complicated as we are coordinating with people eight to twelve time zones away.

Software needs to go through a quality control process and then released to the general public which requires more time and effort.  When finished, you see a shiny new app or piece of software.  It looks like it was free and effortless but it requires thousands of dollars and countless hours of effort.  Just remember that the next time you accuse your development staff of being lazy.

Until next time.

Tuesday, May 2, 2017

A March in the Mud

One of the dirty little secrets of software is for every splashy app or disruptive business there are countless hours of toil.  The mental exertion takes years off your life. Software also alienates because, to be successful, you need to be thinking about software and how to keep your skills current.  The compensation is generous but the mental and time demands of the profession are oppressive.  It made me think about what makes a scrum master successful.  This week I want to talk about the gritty nature of the business.

When I was growing up, I have a great Uncle Paul who fought in Europe with Patton’s Third Army.  He refused to discuss his experiences, and when asked about being in combat he remarked bitterly,” I was cold, and it rained a lot.”  Over the years, many of the combat veterans I have known have behaved in a similar fashion.  Whether they served in Korea, Vietnam, Desert Storm or Afghanistan; the prevailing attitude was I would be unable to understand their experiences because I was not physically there.  Instead, I relied on the narrative from books, documentaries and those veterans would share their experiences.

What struck me during my investigation was the tedium of military service.  Moments of terror punctuated countless hours of boredom and following procedures.  Each day is a grind with little room for heroism or glory.  While I have never made the kind of sacrifices required of combat veterans, the grinding nature of a military campaign is familiar to anyone who has worked on an I.T. project.  In fact, every developer has a story about being on a project which resembled a “death march.”  One of my favorite illustrations by Bill Mauldin, who created the famous Willie and Joe cartoons from World War Two, is tired and muddy American Troops guarding German POWs and they are marching through the rain.  The caption offers brilliant commentary, “Fresh, spirited American troops, flushed with victory are bringing in thousands of hungry, ragged, battle-weary prisoners.”  The irony being everyone during the war is tired, hungry and battle-weary.

Anyone who works on a software project gets tired and weary.  There are too many late nights, too many slices of pizza, and too many problems to fix.  In many ways, we are like those soldiers trudging through the rain.  It is why developers prefer agile methods over the more traditional waterfall approach.  Instead of long aimless slogs in the rain and mud, at the end of each sprint, we track our progress and take stock.  Big bang releases would become a thing of the past and development would be made more sustainable.

The reality has been more complicated.  As we have learned to release software in shorter intervals, business leaders have demanded that we cram more feature into each release.  So instead of work being a “death march” it resembles being pushed out of airplanes each sprint shouting “Geronimo” and hoping we survive the experience; this is not sustainable development.

Metaphorically, scrum masters and developers are seeking a happy medium between long marches in the rain and jumping out of an airplane.  Each day should feature a win or forward progress.  Developers should not put in heroic efforts or engage in crunch time.  It is a lofty goal, and if we are doing our jobs correctly, one the agile community can accomplish.

It takes communication with business leaders and regular deployments of software into production. We need to pay better attention to the DevOps movement to see how to implement continuous integration and pipelines for projects.  Finally, it means saying “No” when people demand ten pounds of sand fit into a five-pound bag.  To do otherwise means we are no different than those soldiers slogging through the mud.

Until next time.

Monday, April 24, 2017

Building systems which work one step at a time.

As a scrum master, I spend much of my time fitting square pegs into round holes.  This includes getting people who won’t speak with each other into the same room to work out issues.  It requires technical people half a world away working together. It is challenging and deeply frustrating.  Confronted with these challenges, why does a scrum master keep going.

One of the greatest articles written about software development is entitled “The Big Ball of Mud.”  It describes how most software come into being during the 1970’s and 19080’s.  It then goes on to illustrate how short term thinking, entropy, and poor software development created the legacy systems which many developers and consultants struggle with today.  These systems are rickety.  Often they are ignored until they are so brittle that they cannot scale or no longer serve the customer needs.  This is the world I live.

It is a world of stand-up meetings with off-shore teams.  Meetings with upper management explaining that Visual Studio 2003 is no way to develop contemporary software.  It is budget meetings where you have to describe continuous integration to an accountant who cannot monetize more responsive systems.  It is the world where I fill out performance appraisal goal sheets in spite of growing evidence that contemporary performance evaluation processes do not work.

As a scrum master, we do it because we want to build systems which work.  We do it because software developers should be making software instead of dealing with corporate politics and bureaucracy.  We do it because public companies need to make the transition to the current century and global economy.  The software is just the first step when we talk about business transformation.  It is why I keep going.

Until next time.

Monday, April 17, 2017

The Rabbits of Agile

An agile coach can learn from a bunch of rabbits.
It is the Christian season of Easter in the United States.  I take this time and spend it with my aging parents and enjoy the simple miracles of daily life.  One example of the elegance of the everyday life are the rabbits which live in my yard.  The warren living under my retaining wall has survived brutal winters, scorching summers, and the attentions of my neighbor who does not like them eating her rose bushes.  They wander around the yard, snack on of blades of grass and enjoy some table scraps from my kitchen.  In a confusing world, I can count on the rabbits giving me a brief respite from the global economy.

The rabbits are more than a form of escapism.  They are a reminder of the natural world.  Each day the world is trying to destroy that warren of rabbits.  Each day they find a way to gather food, avoid predators, and make more rabbits.  These creatures are fluffy and adorable survivors; reflecting on this reality, it dawned on me as an agile coach I can learn plenty of lessons from these specimens living in my back yard.

Charles Darwin said the species most likely to survive are the ones most responsive to change.  I have lived in my home for over thirteen years.  In that time neighbors have come and gone.  Fences have gone up, and many pets have made efforts to hunt down the rabbits.  With each change, the rabbits have adapted.  They forage around the fences and make themselves hidden when people walk their dogs.  A parent accompanies young rabbits, and thy do not bother snacking on grass when I put fertilizer down.  My neighbor has gotten into the act and has decided to stop planting rose bushes.  Change and responding to change are an essential ingredient to survival.

My rabbits reminded me of engineer and lean management pioneer, W.E. Demming who said, “Survival is a choice.”  Each day the rabbits in the yard choose to do what is necessary to survive.  The minds of rabbits are not as developed as humans, but every brain cell in the rabbit skull is preoccupied with survival.  People for all our mental ability can be distracted.  Distractions pull us away from the necessary things we need to survive another day.  Our obsession with status in the office distracts us from our jobs.  Obsessing over the stock price distracts us from providing customer service.  Being the alpha dog on the development team neglects necessary software quality.  Humans are distractible creatures, and those distractions pull us away from what is needed.

So each day as a scrum master, coach or business person is a choice.  You can choose to survive, or you can pay attention to the distractions surrounding you.  From a distance the choice seems simple, people want survival and necessity.  At the moment we concentrate of distractions, and they undermine our survival.  Choose survival and change over distraction.  If a rabbit can do it, so can a human.

Until next time.

Monday, April 10, 2017

Copping Mechanisms for this Scrum Master

Being a scrum master is hard.
Being a scrum master is living a life of servant leadership.  It requires others to follow your direction without having any authority over them.  It requires the patience of Job and the wisdom of Saul.  It is long hours and emotionally taxing.  This week on the blog I want to discuss some of the emotional coping mechanisms I use.

Dealing with Sleep –

Agile teams work anywhere in the world, and if you are a large corporation, any software solution requires an off-shore team.  Development teams are located in India, Northern Ireland, and Russia.  All of these places are numerous time zones away which means to communicate with them you need to be up early in the morning or stay up late.

I have decided to take the early morning route.  My day begins at six and ends at three in the afternoon.  I am usually in bed by 8:30 PM and the process starts over the next day.  This time shifting allows me to deal with the off-shore teams.  It also grants me two hours of “me” time to do administrative work and writing before others get into the office.

Working with Others – 

Servant leadership requires mental toughness because you work with messy people; individuals who don’t follow instructions or won’t take coaching.  Each day, I am forced to work with these messy people.  It is the most difficult part of my job because I am accountable for these individuals.

Lately, I have punted in this responsibility leaning on my human resources professionals and upper management to deal with these situations.  I go about my day attempting to serve as an example to others and trying to be kind.  Sometimes, it is all you can do.

Unwinding –

The hardest part about working in technology is that your mind is always attempting to solve problems.  You may be out of the office, but your mind is still wrapping around that gnarly data issue holding up the project.  You are attending a family function, but mentally you are back at the office.

It is why weekends are so important to me.  I do not respond to mail from the office or offshore. I try to enjoy lighter activities.  Finally, I avoid my computer for a full day.  This little bit of unplugging goes a long way.

So these are some of the strategies I have to deal with the emotional stress of being a scrum master.  I would like to learn some of your techniques.

Until next time.

Monday, April 3, 2017

All about forgiveness

Talking about forgiveness.
It is evident to me that 2017 is the year of messiness.  Software is a messy activity.  The clutter is caused by the human emotions of foibles which are part of the creative process.  As a scrum master, you are the servant leader of messy people who write software.  You are supposed to live the agile manifesto and principles.  You set the example.  As a scrum master, you set the tone and help the team succeed.  It is rewarding work, but I have my moments where I am not very proud of the example I am setting.  Continuous improvement means striving to get better.  It also means you need to be able to forgive others and yourself.

My professional career has was shaped by my training in journalism and engineering.  The world of mass communications is very judgmental.  We criticize television anchors for hair color choices and how good their dentition looks on camera.  Radio disc jockeys are slaves to ratings and program managers who can crush your career.  Ratings mean money and if you provide ratings, people will ignore some of your worse personal faults.

Engineers are also a judgmental bunch and are willing to back up that judgment with the scientific method.  The code could run a few nanoseconds faster.  The class could better use the Liskov Substitution principle.  Finally, you could always tighten up the code to make it less error prone.  There is additional machismo where team members compete to assert dominance using their intelligence or programming skill.  It is brutal, and these environments discourage vulnerability and innovation.

As a scrum master, you are encouraged to help remove these dysfunctional behaviors.  Sometimes a scrum master gets caught up in these bad practices.  When you do, you are going to hurt the team.  When you hurt the team, you are undermining your credibility in the organization, and with the people, you are supposed to serve.  The first thing you should do when you hurt your team or someone on it is making amends and apologize.  Asking for forgiveness is hard, but it reinforces the agile values of respect and openness.  A team which can forgive each other when they make mistakes is going to be higher performing than one which is not.

Forgiving yourself is a much harder skill.  We know ourselves better than anyone else.  We are also the least forgiving of our mistakes.  We can feel like frauds to ourselves, and this is imposter syndrome.  Our emotional intelligence may be below average, and we find ourselves in situations which would puzzle others.  Finally, emotional control can be undermined by people who just do not want to improve.  You become a tangled bundle of rubber bands, and you feel like you can snap at any minute.  You do snap you feel riddled with guilt and self-loathing.  Over my career, I have spent a few mornings thoroughly hating the person I see in the mirror.  These feelings are not rational or objective.  These feelings just are, and you cannot escape them.

I have been leaning on friends and family for the last few weeks to receive relief.  I am seeing a doctor in order understand if the stress of the role is contributing to my emotional recriminations.  Finally, I have been avoiding alcohol and caffeine.  My brain chemistry is bad enough, and I don’t need to make it worse with outside stimulants and depressants.  I am making a conscious effort to try and forgive myself for past mistakes.

From the outside, this process is not going to look beautiful, but I need to do it if I am going to improve as a scrum master.  Everyone deserves a dose of forgiveness now and then.

Until next time.