The Messy Nature of Software Development

Software is messy

I have been in the software business for nearly twenty years.  I began as an entry level programmer and made the transition to scrum master and agile coach.  It was not pretty or heroic.  It was a journey filled with personal and professional setbacks.  Sometimes, I wonder how I didn’t wind up begging for change on the side of the road.  Somehow, every setback I have faced has led to a larger and better opportunity.  This week on the blog I wanted to discuss something which we do not discuss often; the messy nature of software development.

If you are not already following Angela Dugan’s blog, “The TFS Whisperer,” you should.  One of the posts struck me for its honesty and courage.  She talked about how application lifecycle management and DevOps are “messy.”  I add that everything involving software is messy.

The creation of software is a new trade.  It began in the days of vacuum tubes after World War Two and had grown into an activity employing a total of 11.5 professionals worldwide.  The term bug came from a moth trapped in a box of the first vacuum tubes of the ENIAC computer.  Today, bugs represent any of the defects or mistakes we perpetuate in code.

In the seventy-plus years since the beginning of professional programming, the activity has not fundamentally changed.  Smart people work in isolation writing software code, and business people take it for granted that is works.  The reality is software is one of the few activities which has not been taken over by automation.  It is a creative and manual process. It is both an art and science.

Unlike construction which has a set rules for engineering and gravity software development lives in a strange world where the rules do not matter or change with each release.  Deadlines are either fluid or hard as stone.  People work late nights and early mornings to get the product out on time.  Personal relationships suffer as support calls intrude on anniversary dinners and you are asked to release software on Sunday afternoons.

The people who do this work are smart and creative.  Too often the demands of the business community force leaders to treat these people like machines which run on caffeine and pizza.  The people who write software have children, significant others, and aging parents.  They have felt and experience the entire range of human emotions.  They are more than points of data in an Excel spreadsheet or a line item in a project plan.

It matters because software is one few activities in business which is immune to automation.  It is manufactured by hand by these creative human beings.  So software is “messy” because people under great pressure author it every day.  Software development is “messy” because people make mistakes.  It is “messy” because people have emotions which are hard to control.  Finally, software development is “messy” because business people treat software professionals as interchangeable “staff” instead of skilled artisans.

I have spent numerous nights questioning my ability and worth thanks to the messy nature of software development.  I am sure that other software professionals have done the same. This business is humbling.  Angela and I agree; software development is messy because very human people are involved in every stage of its creation.

Until next time.

Everyone has a bad day.

Everyone can have a bad day

Everyone is entitled to a bad day.  We live in an imperfect world where directions are not followed, colleagues don’t have the same sense of urgency, and the printer is out of toner.  It is worse for agile teams because they are expected to deliver at the end of each sprint and a few bad days can pile up into a failed sprint. As a scrum master it is up to you to accept bad days and help you team avoid future ones.  This week on my blog the emotional work necessary to make it through to bad times.

Each agile team depends on a scrum master.  It is part of the scrum guide and is a necessary to help teams improve.  When the team is having a bad day it is particularly important the scrum master is around to listen team member’s vent.  Listening is one of the most important skills of a scrum master.  It will help you diagnose problems with the team and learn about the obstacles which are creating that bad day.  Some of the issues are interpersonal, in this way it is up to the scrum master to play therapist and counselor to the individuals having problems.

This work is hard and emotionally draining.  Some of this work can be futile.  One employee spent most of their time not doing work instead of completing projects, it drove me insane.  If they spent as much effort doing what was expected as they did attempting to avoid work they would have been a valuable team member.  Instead, deadlines were missed and the morale of the remaining team was brought down.  I spent much of my time doing HR work documenting this individual’s malfeasance and senior leadership could not or would not remove this individual from the development team for cause.  It would take the entire team turning over and a series of layoffs before this individual would be let go.  It took three years to manage out a bad team member from a scrum team when it should have been a matter of weeks.

Other times you have members of your team who are whiny, entitled, and unable to follow directions.  The project management tool is too complex.  People are not returning phone calls and they can’t get work done on time because they won’t work more than forty hours.  When you attempt to coach these individuals they have an alibi for their behavior and ignore your direction.  These are people who are not good enough to keep and they too good fire.  You are going to spend most of your time working with these individuals.

Sometimes, I have to let down the mask of command and let the team know that I am sick, tired or angry, otherwise it will come out in a spasm of unprofessional behavior.  I am constantly on guard of mansplaining to a co-worker.  Sometimes it gets to the point where I have to say, “I am very angry with you and in order to be professional with you I have to walk away and cool off.”  It isn’t pretty, but for me it is necessary if I am going to do my job properly.

Sometimes I skip lunch with my team members so that I can collect my thoughts.  Other times, I leave the office to take a walk or go to the barber shop to try and improve my attitude.  The point is you cannot always be upbeat and inspirational every working day of your life.  You are allowed to have bad days.  This might explain why psychotherapists always have a professional therapist to speak with.  Dealing with all that mental illness and human suffering takes an emotional toll and they need to speak with somebody who understands.  I wish there was a service like that for scrum masters.

So don’t worry.  You are allowed to have a bad day.  What you are not allowed to have is that bad day effecting your long term effectiveness or your team.  Take time out to unwind and de-stress.  Walk away from situations which trigger anger and remember that the scrum team needs you in order to be successful.

Until next time.

When to hang it up

Sometimes you have to pack your bags.

Last week I spoke about “struggle” and what I felt it meant.  It inspired a strong reaction from a few people.  Watching this reaction, it dawned on me, I was witnessing a conversation I had three years ago.  Each of us have moments in our careers where we consider leaving and going someplace else. Some of us have that choice forced upon us while others have a “moment of clarity” and then give their notice to their boss.  This week I want to talk about when it is time to leave.

I have been a software consultant and full time software developer for many years.  It was filled with frustration and failure.  Additionally, when I was a consultant I was often treated like high paid “help” who was supposed to keep his head down, mouth shut, and ignore the dysfunction which surrounded me.  I even completed a project early for a client and instead of being rewarded with an extension I was thanked and promptly rolled off.  I have been fired a week before Christmas and had to explain it my former spouse.  I have looked over my shoulder worried I was not good enough and smart enough to work with the other developers in my company.  I needed to make change.

With my own money, I took my Certified Scrum Master training.  I was feeling despair and working as a heads down developer was taking a toll on me.  This was a chance to practice what I preached about Agile.  After becoming an architect at a different firm, they learned about my Scrum Master training and made me the servant leader of development team.  Looking back on that experience, I realize that I was raw, cocky and untested.  One developer openly rebelled against me right away and I would spend weeks and months attempting to effect change.

That was three years ago.  Now, I am training product owners for division of my company, serving as a scrum master, and being “spun off” as my firm splits into three companies.  In those three years, being in the trenches as a scrum master has made me a much better servant leader.  I am even participating in the company mentoring program.  I voiced that I was restless and frustrated with the pace of change I am trying to effect and it looks like someone listened. For me, it is a sign that I need to stay because big changes are coming and my peers and superiors see that I should be part of that change.

I will only speak for myself but if you cannot get training through your work and if you are asked to do one thing but are rewarded for doing something else then it is time to leave.  Before I started working as a scrum master, I was a senior developer for a food company.  I was talking about a software project with a superior and he said I should start over because it didn’t look like something he could use on his iPad.  It was the final straw and with-in a month I was gone.  Since then, that company has paid hundreds of thousands of dollars in agile consulting and they laid-off over 100 people, mostly older workers, in order to be more nimble.  They could have saved a lot of money and preserved those jobs if they just figured out how to keep me and allow me to spread agile through the firm.  I am glad I am no longer there.

Each member of the agile community is responsible for his or her own career.  We have to make choices every day about what we do and who we serve.  We also need to remember that we need to serve ourselves.  If we are unhappy or frustrated with what we are doing then we need to change.  If that means leaving one company to go to another then so be it.  For me, I am staying where I am.  I am entering an exciting time of change and I look forward to the challenges.  When I can’t say that any more then I have to quit.

Until next time.

Reputation is not licence to be a jerk

We know lots of people like this.  A few of them 
 set the conversation of the technology world.
 Image courtesy of Slate.com.

The world of technology is filled with plenty of smart, talented and colorful personalities.  This dynamic was one of the reasons why I was drawn to the business.  This week I want to talk about of these colorful personalities and how he represents some of the worst impulses in the technology business.

There are plenty of stereotypes in the technology business.  These are reinforced by popular culture in productions as diverse as James Bond movies, the Fox series 24, and the HBO program Silicon Valley.  Having over 18 years’ experience in the business, I have seen many of these stereotypes in real life.  I have also met plenty of great people who are unique and innovative in every way.

By any standard, Alex St. John should be seen as one of the leading minds in the technology field. He was self-educated and self-taught.  He created the DirectX technology which powers Xbox and just about every PC game on Windows.  His work helped make Microsoft the power house it is and he earned further accolades founding his own company.  This kind of achievement should make St. John a good will ambassador for the technology field instead, he is coming off as a colossal jerk.

I can provide numerous examples which have already been articulated elsewhere on the web.  These offenses break down into three categories.

• He does not see the value of women in technology.  Exhibit A.
• He thinks that exploitative work conditions in the software business, particularly, the game business are acceptable.  Exhibit B.
• Finally, anyone who disagrees with him is a “whiner” of not willing to work hard.  Exhibit C.

I have stated repeatedly, technology needs more women.  The fresh perspective they provide to technology is essential to improving product quality.  It also makes the office less like a Mongol raiding party and more like a 21st century work place.  The less testosterone in technology the better.

Next repeated studies have shown that long hours are a hindrance to productivity rather than a boon.  Notions of “crunch” time and working eighty hour work weeks are exploitative and boarder on the illegal practice of wage theft.  Additionally, the twelve principle of Agile discourage this mindset stressing development should sustainable.  To St. John and others developer burn-out, turnover, and alienation are the cost of doing business.  Technology workers are not different that sweatshop workers and they should be grateful for the conditions.

Finally, St. Jon has ridiculed people who disagree with him about issues of diversity and exploitation of tech workers by claiming they are not ambitious enough or smart enough to understand his arguments.  In St. John’s world, I would have died of a heart attack because I would be living on steady diet of caffeine, pizza, and stress.  The technology world has undermined two of my marriages because of high stress, turn over, and uncertain employment conditions.  It is hard to keep good employees if they don’t see or sleep with their significant others.  I consider myself a valuable professional to any organization, but to St. John, I am just a pencil to be ground down into a nub to be replaced by someone else just as disposable.

Bottom line, if you do not agree with St. John, then you are neither smart nor talented enough to work in technology.  This may explain why he is spending more time coaching CEO’s and HR professionals on how to recruit technology talent than actually managing technology talent.  I have worked for people like St. John who are convinced of their intellectual and moral superiority. It is not fun and I consider those periods the low points of my career.  Technology is changing thanks to agile and efforts to improve diversity.  Faced with the changing environment you can, lead, follow, or get out of the way.  I think that St. John is about to get trampled to death.

Until next time.

Obstacles to Agile

Courtesy of the Harvard business review.
Being a change agent is hard even for a King.

The life of an agile profession both in the corporate world and as an entrepreneur is filled with uncertainty.  Big wins are offset by frustrating losses.  Efforts to keep an even keel are quickly undermined by others and setting aside some time for lunch seems like a herculean effort.  This week I want to postulate a few things I have encountered that make the success of an agile implementation doubtful.

 Cultural Inertia-

If you run into employees or members of management who say, “We have always done it this way,” you are facing cultural inertia.  Human beings need ritual and consistency to make them feel like they belong.  Rituals also produce a sense of certainty in an uncertain world.  When an organization or individuals are afraid to change they are really asking for certainty in an uncertain world.  This is why bad processes and procedures linger.  People are invested in these bad processes and rewarded for perpetuating them.  Thus, as most agile leaders try to instigate change they are going to receive push back.

 Quid Pro Quo behavior-

This term is used in sexual harassment training but is also go for anyone attempting change management.  This is a Latin phrase which means, “tit for tat.”  Another way of explaining it is, “You scratch my back and I will scratch yours”.  A business operates through the countless interplay of people and often they do favors and collect favors from others in order to do their job.  For instance, accounts payable depends on the format of a report being a certain way and in excel.  As a favor a manager makes this happen so when they have to do an expense or provide a bonus to a valued customer, accounts payable with go along without any conflict.

This is maddening behavior for technology professionals and ageists because the obvious answer to the situation would be to automate the report with a script or some reporting software.  This solution may save time and money from the firm but it takes away influence from the manager who is doing the favor for accounts payable.  Thus, they will do what they can in a passive aggressive means to undermine the effort.  For the agilest it makes sense to understand how these little power games are played in the organization.

 People getting by on Charm-

This week, I had a conflict with an employee with seven years more tenure in my organization.  I held him accountable for poor performance and undermining a project.  I later learned that he has some protected status in the organization because of a favor he did for a vice-president five years previously.  Since then, he has been using his charm and charisma to instigate projects.  He never finishes those projects but he is always first in line for the next highly visible project which he can scapegoat on to someone else.

I did what I could and pointed out the facts which explained why a project is twelve weeks behind.  I will not be working with this person in four weeks as I am transferred to another team and group of developers.  He is now someone else’s problem and I hope that his continued negligence is pointed out.  Being charming is no substitute for knowing how to do your job or getting results but it amazes me how many people survive in business because of it.

Be on the watch for these three things in your organization because knowing about them is going to make it easier to create positive change.

Until next time.