Looking back at the people who influenced me.

Inspiration comes from plenty of places.

I find inspiration from some of the weirdest places.  I could be watching a Bollywood movie or enjoying one of the many Dune books by Fran Herbert or his son Brian.  I also identify with comedies inspired by former cast members, so Saturday Night live.  I even ponder if Bill Murray is my spirit animal.  These influences have shaped my leadership style.  This week I want to discuss influences.

In my view, there are two kinds of influences; positive and negative.  Negative influences are anti-examples.  It is something or someone you refuse to emulate in your leadership.  The positive influence is one you want to fold into your practices.  I consider both types important for shaping your style of leadership.

I have many positive influences in my career; people like Andy LaChapelle, Roy and Yvonne Guash and JoAnn Pankow from Harrah’s Casino in Joliet.  I have technology professionals like Angela Dugan and Allen Dail who shape my views about corporate IT.  The most influential group in my life are the numerous coaches and competitors I have met from the world of college forensics.   People like Megan Koch, Craig Cutbirth, Elige Wilson and Ed Suitor shaped me into the person I am today.

Over my career, I have worked for numerous organizations and leaders.  The negative experiences have marked me like tattoos.  Each one made me swear to myself I would never subject any who works with me.  For example, I consulted at a company where a majority of the technology staff were consultants with H-111 visas.  Meetings were grim and quite affairs because anyone who spoke up was rolled off the project and deported back to their nation of origin.  I remember being told by e-commerce solutions should like about inventory levels because high margins were superior to happy customers.  Finally, I worked for an emotionally stunted man who would yell at me to work faster and then yell at me when I would make a mistake because was working too quickly.

In these moments of darkness, I swore I would never do things like that to people who worked with me.  I have had my moments of weakness and have fallen short of my expectations, but I have never been intentionally cruel to people.  Knowing that helps me sleep better at night.

Positive and negative influences matter and they shape the leader you become.  Paying attention to both is important.

Until next time.

The Bull has Two Sides

You find lots of strange things online.  This week I turn to the pages of the New Yorker to enjoy a few lessons about web design.

Times Square in New York City is receiving a face life to make it more pedestrian friendly.  The work began in 2012 and should be finished sometime in the summer of 2017.  Leading the construction is an architecture firm lead by principal partner Craig Dykers.  His office overlooks the Wall Street bull, and it gives him some insights into the design.  According to the December 14th,  2016 New Yorker.

Dykers told me that he has observed the crowds around the bull for years, and that the tourists can be divided roughly equally into those who pose at its head and those who pose at its rear end. (The bull’s nose, horns, and testicles have been rubbed, for luck, to more or less identical degrees of shininess.) Dykers said the statue is a useful reminder that humans are diverse, and have their own ideas about design. “A lot of our work as architects takes into account that just as many people are interested in the backside of the bull,” he said.

There is wisdom in this observation as you are constructing websites or software applications.  No two people view a web page the same way again.  Some view it from the metaphorical horns and others view it from the metaphorical behind.  It is up to us to accommodate both of these perspectives and to test it accordingly.  As an engineer and scrum master, I look at a website very differently than a sales person or pricing managers.  I am a big believer in Agile and Scrum because I can test out concepts early and fold them into later releases so that I do not have to deal with the crushing disappointment of spending my life building something my customers will not use.

So remember the horns and behind of the bull, and build software iteratively.  It is not only a good practice but a healthy way to avoid disappointment in this business.

Until next time.

Developers Need to Develop Discipline

Discipline means more than looking like a professional

At least once a week, I receive an email or tweet featuring an article claiming agile and scrum are dying.  Many of these items are click bait.  A few are about poor agile implementations.  This week I saw a new variation on that theme, and it was from one of the initial signatories of the Agile Manifesto; Robert Cecil Martin aka “Uncle Bob.”  I took some time to watch his video, and I encourage you to do the same.  This week I want to discuss one of Uncle Bob’s main themes – discipline.

I was a self-taught developer.  During the giddy and stupid days of the dot-com boom, I decided to change careers at the ripe old age of thirty.  I remember going to job fairs with floppy disks and resumes looking to break into my first career role.  I knew a smattering of HTML and Visual Basic.  ServiceMaster took a chance on me, and my software development career was born.  I would learn SQL and many other skills during my first two years in the business.  It would take me another eight years for me to develop any confidence in my skills.  Today, I have eighteen years of experience, and I still consider myself an intermediate level developer.

The reason why I feel this way is that I have made numerous mistakes over my career and had the scars to show for it.  I still struggle with practices like Test Driven Development and SOLID programming.  In the fast-paced world of software development, I struggle to pick up these concepts as quickly as my peers.  I would be humiliated at job interviews when people reviewed my code claiming that if I have learned code at “X” university or code camp, I would be so much more professional.

A funny thing happened to me when I started working as a scrum master.  I was now bringing on software developers to new teams.  Some of them had masters degree’s in mathematics and computer science, but they never wrote a unit test or worked with source control tools.  I would have to educate them on how to be better developers who to be professional and disciplined.

According to Uncle Bob, half of all developers have less than five years of experience in the profession.  That means that those freshly scrubbed developers are learning how to work on large code teams, write unit tests, and develop business knowledge.  It is up to more experienced professionals, like me, to help them develop these skills and have a sense of pride and craft in what they do.  They should avoid the numerous mistakes I made in my career because I will show them how to avoid them.

So what does it mean to be a disciplined software developer?  The first trait of a disciplined software developer is that they use source control for their work.  The code is checked in on a regular basis, and it is commented to explain what it is doing.  A developer should also know how to do branching and merging so that they can segregate code based on the needs of the business.  Working with source control allows a developer to work on large or small projects.  It does not matter if you use GIT or Team Foundation Server for source control.  Learn to use source control.

The next trait is the desire to improve your skills.  A disciplined developer is reading up on new techniques and practicing them outside of work.  When the time comes, this will help solve business problems and speed up work.  I am also a big fan of using the phrase, “why not?” at the office.  That is because someone has discovered a new way to do something and I cannot think of a valid reason why we should not try it.  My software developers started using MOQ and incorporating dependency injection into our software projects because of this attitude.

The last trait of a disciplined software developer is humility.  I am very hostile to the brogrammer movement in development.  Developers should be willing to learn from each other and develop new techniques based new knowledge.  The arrogant disregard of others and the showing off of software development skills is not helpful or necessary in the activity.

So to be a disciplined developer you need to leverage source control, be willing to learn new things, and approach the business with some humility.  Being a programmer and scrum master is one of the hardest jobs I have ever had.  It has been financially rewarding and professionally fulfilling.  It also took me eighteen years to get to this point.  For all the new software developers entering the market, I hope I can help you avoid the mistakes I have made in my career.

Until next time.

Good Scrum Requires Organization and Improvisation

Good Scrum is like good jazz

The life of a scrum master is a daily adventure.  No two days are the same.  One day everything is going well and the next you are confronted with a production server meltdown.  You have tremendous responsibility but no authority to get anything done.  This week I want to talk about two skills you will need to develop to be successful, organization and improvisation.

As scrum master presides over a fluid and ambiguous environment.  Product owners want to succeed.  Finance people are tracking the money.  Your boss wants to know when you are going to push code into production.  To answer this and numerous questions which come up during your work day, you must be organized.  I keep file folders with information regarding each project.  Additionally, I insist that the product owner and the team keep the product backlog neat and tidy.

Use your source control and project management tools to the best of your ability.  It does not matter if you use Jira or TFS 2015.  These software products are designed to keep you organized.  If you want to be old school, use a whiteboard and post-it notes; as long as the information is accurate and readily available to everyone.

I like to use the “arms-reach” rule.  This rule states that any and all information about a project should be within arms reach of the scrum master.  So when your boss asks how the sprint is going, you can show them a burndown chart.  A developer might have questions about the I.P. addresses of a server.  You should be able to reach an excel spreadsheet or file folder in your drawer to return that information.  It will enhance your credibility with the organization and the people who work with you.

Finally, do what many people in the media business do; they keep a schedule file.  They have twelve folders for each month of the year.  They have additional folders for each day of the month.  When you need to do something date sensitive place, it in the correct month and date folder.  Each day you pull the current day's folder, and that provides you with an agenda fo what needs to do.  Once you get into the habit of doing this, you will wonder how you lived without it.  Once you get into the habit of doing this, you will wonder how you lived without it.  

The next skill I strongly recommend is improvisation.  Being able to respond to change over following a plan is a tenant of the agile manifesto and a great definition of improvisation.  In a typical day, a scrum master will reschedule a backlog refinement meeting to help a developer with SOLID development or they will spend time with finance people to explain the scrum process.  You need organization so depending on what happens the information you need is in “arms-reach, ” and you can change direction.

Improvisation does not mean making stuff up or bullshitting your way through your day.  It means addressing the unexpected with the correct response.  When humor is required, use humor.  When it is necessary to be firm, you will have to act.  It requires organization and mental disciple.  The way to develop those skills is by taking some improve classes or getting involved in organizations like ToastMasters.  There you will learn both public speaking skills and the ability to think on your feet which are key to improvisation.

So to summarize, to improvise you need organization.  Developing these two skills will make you a better scrum master.

Until next time.

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.