Stop Treating people like Data Points

People are not data points.

I entered the technology business to try and make a difference.  I became an agilest because I spent too much of my time following the orders of damaged, neurotic, and mean people.  They were the kind of people who used their position of power for petty displays of superiority.   I knew there was a better way to lead others.  I knew there was a better way to get work done.  This is why I become an agilest.

Along with the spread of Agile, another trend cropped up in business.  This was the use of big data and algorithms to make decisions.  I trace the origin of that back to the book “Moneyball” and the story of the Oakland Athletics using data to improve the performance of the ball club without having to spend money like the New York Yankees.  Since then, the use of advanced statistical metrics has exploded in baseball.  What worked in professional sports was adopted into other businesses.

I call this neo-Taylorism after the business pioneer Frederick Winslow Taylor who authored the book, “Principles of Scientific Management”. Taylor did make the factory floor safer and faster but it also treated the people who did the work no differently than the machine tools or materials used to make the product.  The demands of Taylorism in business created a backlash and unions grew in strength and influence.

As our economy shifted from a manufacturing to a service economy, neo-Taylorism reared its ugly head in the cubical farms across our nation.  Customer service reps were measured on how long people waited on hold.  Sales people were judged on how many cold calls they made a day.  It was also used in human resources as Credit Scores were used to determine reliability.

This began to reduce people to data points rather than individuals.  It also gave professionals and people like me a bad name.   It is no wonder that professionals are held in such contempt in certain parts of the country.  When you see someone as an entry in a spreadsheet instead as a person and they are bound to view you with contempt.

This is why I don’t like to use metrics as a menu to set expectations for the team which works with me.  Instead, I like to use metrics to show how we can improve performance and how we did in the past.  I truly believe that once you use a metric as a quota it ceases to be useful.

So to my friend in the agile community, please continue to measure the performance of your teams.  Just do not use those metrics as quota’s because if you do everyone being judged by these metrics will game the system to make them better than they actually are.  If we are going to measure performance and be agile we need to treat people like individuals rather than points of data.  Otherwise, we will suffer a backlash of our own.

Until next time.

In order to change you need to listen.

Change begins with listening

One of the biggest obstacles to change is an organization is status quo thinking.  People develop routines and when those routines are challenged there is a push back. It happens in politics.  It happens in business.   It even happens in sports.  Being a scrum master means being a change agent.  This week I want to talk about fighting resistance to change.

At the turn of the century, one of the most popular books in the business community was “Who Moved My Cheese.”  In it, the authors tell the story of two mice “Scratch” and “Sniff” who live in a maze and discover the cheese has been moved to a new location.   The one mouse staves and the other learned to adapt to the change.  I have always been a bit of a cynic about this book.  I saw it as a happy talk way of accepting cram downs, corruption, and unfair treatment.

Now I am a scrum master and  many of the people I work with are like the mice in that book.  When asked why they do certain things they lock up in paralysis of say, “…that is how things were always done.”  Man people I have met in business are content to settle into comfortable routines.  The mental laziness of not questioning how things are done is preferable to existential nausea caused by asking if there is a better way of doing things.  In dysfunctional organizations, these lumps of human clay are often promoted and continue to enforce these dysfunctional practices.  Soon if becomes obvious to everyone that to get ahead you have to keep your head down, your mouth shut, and not make any waves.

This is even harder in large and bureaucratic organizations because people are protecting turf in the organization.  Leveraging cloud services like Azure is inevitably going to run into resistance from network teams because it takes control away from them and puts it in the hands of developers and business people.  Automated builds and continuous integration are good things but regulatory compliance becomes a committee of “no” for these improvements to the organization.

This kind of intellectually lazy resistance to change makes me crazy.  When confronted with this kind of thinking, I get angry.  After a particularly bad day someone I respect pulled me aside and said, “…you need to listen more.”  I was taken aback.  Listen more? Why should I listen more?

It took some time to sink in, but I am beginning to understand what he was thinking.  When change comes to an organization, people are fearful or what will happen to them.  I need to listen to those fears and way those concerns.  I need to listen to what is working and what isn’t working.   Change for the sake of change is just as damaging as doing nothing.  Changes must be responsive to the situation you are in rather than a reason for being.

I need to listen more.  The best reformers were people who listened and made others willingly join rather than those badgered.  The truly fervent are the most devoted.  Ther fervent are also alienating and if I want to lead change the last thing I need to be is alienating.  I need to listen to others and alienate them less.

I get angry and discouraged many times as a coach and scrum master.  Change is a difficult process.  Leadership is lonely.  The good news is that leadership and change done properly can improve the lives of others.  The struggle is worth it.  Resistance to change can be defeated and the most powerful tool is listening.  I should give it a try.

Until next time.

Reflecting on Why a Scrum Master is a Commander.

The aftermath of the U.S. Election has rubbed a lot of nerves raw.  I did not expect these results.  Between bouts of sleeplessness and eating comfort food, I did a lot of reflection.  I thought about what I stood for and what it means to the others around me.  I am scrum master and a servant leader.  I have spent the last twenty six years of my life attempting to reach this point.  During my dark night of the soul, I recalled the words of Former Secretary of State Collin Powell who said, “Command is Lonely.”  This week on my blog, I want to talk about how a scrum master is often in command.

The scrum guide is ambiguous about the authority of a scrum master.  It is very clear about the responsibilities and expectations of the role.  The agile community has filled in some of the blanks with talks about a scrum master being a servant leader.  I have written about this myself.

Over the last year, through a few successes and countless failures it has occurred to me that to be a scrum master is also about being in command.  It isn’t the typical command many of us think.  There is no barking of orders and obedient subordinates fulfilling those orders with the predatory efficiency of ants.  It is a different kind of command.  The kind of command where when things go wrong everyone turns to you.  Powell fought in Vietnam so he knows a few things about when things go horribly wrong.  This is why command is lonely.  When the metaphorical bullets are flying and you have situations which could cost money, careers, and lives; it is up to you to lead.

For a scrum master, that means staying up late with the development team when they are deploying code after hours.  It means being a calm head when others are panicking.  It means listening to others even people you find abhorrent.  It means many things and nothing at all because being a commander is not an official title bestowed by someone else.  It is earned.

This means each day as a scrum master, I have to earn my command.  I have to put in the effort to work with my development team.  I have to make sure that I am doing the best as I can to help the team improve.  I have to be able to work with people I disagree with better.  Other people are counting on me and need me to be an example, I will be a better example.  Not only do I need to know the agile manifesto and its principles but I need to practice what I preach every day.  I have to listen more and talk less.  Command is hard and it is going to be lonely.

Doing these things is not going to be easy but if I want to change the business culture of my company or found my own then I need steel myself for the hard work.  It is going to be a struggle but nothing worth fighting for should be easy.  Even in darkness we can find resolve and purpose.

Until next time.

Complexity is not cool

Complexity does not help.

One of my biggest frustrations as an agile coach, scrum master, and software developer is how blithely business people think complexity is a good thing.  I do not refute that contemporary society is complicated and that living and working in global economy is challenging.  That does not mean that business people have a right to make this situation more complicated because complexity hides inefficiency, corruption, and stupidity better than any conspiracy theory could imagine.  This week I want to talk about simplicity and why it is important in agile and business.

This week the Harvard Business Review came out with a great article about the bank crisis of 2008 and how eight years later we still haven’t recovered from it.  At the heart of the article was the thesis that career specialists in an industry don’t make good decisions.  Worse, career specialists suffer from three characteristics which hurt their industry: hubris, blinkered vision, and lack of foresight.  With these three traits it was only a matter of time that these experts created a situation which nearly ruined the global economy.

I run into these situations all the time.  I remember having a discussion with an executive which sold medical supplies to nursing homes.  We were talking about how we set prices for our customers and how we do the accounting.  I was given a lecture about how our business was different from a traditional “retail” business because the products were going to nursing homes.  I remarked that the rules of accounting have not changed in 100 years and that everyone learned accounting from the same textbooks in college.  I was told that I had a bad attitude and that I should adjust the accounting system to meet the needs of the business.  Shortly, I left the company.  It was clear it was the kind of culture which used complexity hide misconduct.

Another instance was a company president who could not purchase an MSDN licenses to make sure all of his software was upgraded.  They would rather pay for a license here and there.  This meant the office had versions of office ranging from 1995 to 2003 and applications could not communicate with each other.  It was a nightmare that could have been solved if someone picked up the phone and purchased a license for the entire office.  Instead, it was easier for someone to go to the office supply store and pick up another shrink wrapped box of software which they would have to integrate with the rest of the office.  A complicated problem could be solved with a simple phone call but leadership choose complexity over simplicity.

According to the principles of the Agile Manifesto, simplicity is the art of maximizing the amount of work not done.  This means as the agile coach and as a scrum master, I spend a great deal of time asking if we really need to do something.  I spend plenty of time trying to find the simplest path to a solution.  I also say no to plenty of requests.  It isn’t easy but if you are going to reduce complexity at the office someone needs to be smart enough to say, “I don’t understand this, and because I don’t understand it, I can’t make it work.”

Until next time.