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.

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.

 

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.

The Hero's journey is no substitute for a product

A hero's journey is not a substitute for a product.

Each entrepreneur goes through a sort of hero’s journey.  If they are lucky, once that journey is finished they will emerge out of the other side stronger, wiser, and accomplishing something amazing.  It is no secret the technology world uses the language of science fiction and fantasy.  That is why a company which becomes extremely profitable it is called a unicorn.  As an agilest and entrepreneur, I convince myself that I am lucky and smart enough to aspire to this status.  It is the story I tell myself.  In the dark moments, it is what keeps me going.  This week, I want to talk about when story telling crosses the shadowy line from inspiration to deception.

Carl Jung, one of the founders of psychoanalysis, articulated the idea the human species has a “collective unconsciousness.”  This collective unconsciousness is the common characters or myths humans use to describe themselves.  The collective unconsciousness also describes what the human species aspires to become.

Joseph Campbell then built on Jung’s work in 1948 with his book, “The Hero with A Thousand Faces,” which talks about the similarities between the mythologies of western and tribal cultures.  Roman Gods were compared with the traditions of Native Americans and Australian Aborigines.  The similarities were too hard to ignore.  We had academic proof that the human species has a common story telling tradition.

Now that this knowledge was out in the open it did not take long for others to exploit it.  One of them was a University of Southern California graduate, who just has a hit film entitled “American Graffiti.”  The other was a technology entrepreneur who cultivated the image of a mystic shaman while he sold music players and later phones.

To be successful, a company needed a story and a heroic figure to pitch that story to the media and client.  It was a way of cutting through the clutter and getting the message out.  That lesson was not lost on Elizabeth Holms who dropped out of Stanford to found her company Theranos.   She created an image which was a frittata of Hitchcock’s icy blond, Steve Jobs techno shaman, and the elegant intelligence of Meryl Streep.  Her story was simple, she was going to change the world making blood testing affordable and less invasive.  She was smart enough and stubborn enough to found a company and make it happen.

The technology press swallowed the story hook, line and sinker.  Soon she was featured in press write ups, on television promoting her company, and receiving millions of dollars in venture capital.  I will not go into the details of Theranos and the fraud they committed.  Vanity Fair Magazine has already done an outstanding job on that front.  Suffice to say, Elizabeth Holms had a good story to sell but didn’t have a product.  Her blood testing tool was nothing but fantasy.

The lesson here is that every story should have a grounding in reality.  You cannot change the world with your products if your products do not work.  The rumpled engineers have to build something before the myth makers in sales and marketing come along.  Telegenic good looks and a story are not a substitute for business acumen and a product.

Anyone who grew up during the stupid and giddy time of the dot.com bubble should have known how this story was going to end.  They chose to ignore it and suspend disbelief because the story was good.  Instead of a hero’s journey, what the public got was a true crime story of fraud and greed.
It is a sobering lesson for an entrepreneur and consumer.  I hope that we are smart enough to recognize it before it happens again.

Until next time.

March of the Flaming Squirrels

Pay attention to the Squirrels.

I have spent over 18 years working in technology.  In that time, it still surprises me how many people think what I do is magic.  Furthermore, those people think setting up complicated database and web systems are like plugging in a lamp and turning on a switch.  This creates all sorts of insane and absurd situations in the work place.

When I was a young person, one of the key measures of success was the ability to handle large piles of work with deadlines.  The metaphor my teachers used was the story of a squirrel.  Squirrels hibernate during the winter months but they still need to eat so during the summer months they spend a majority of their time gathering food to store for the winter.  They also binge eat in the fall so they have enough fat to hibernate.

I took this metaphor to heart and applied it to my undergraduate and graduate work.  Each day I spent a little time reading writing and gathering nuggets of information to help myself become successful.  It worked and it seems like a good strategy.  You do little things today so that big challenges of tomorrow don’t seem so daunting.  Then I became a software professional.

The technology world has too much work and not enough qualified people to do the work.  So instead of small efforts adding up to eventual success it takes super-human effort to prevent getting swamped from the demands of the business.  It is a like being a squirrel which is caught in a forest fire.  You still have to gather food but you also confront the grim reality of painful death.

I am spending much of my time telling business people why these “fires” are bad for the business and the software developers.  As author Jimmy Leppert says, “…firefighting creates a culture of arsonists.”  In my mind, where there are arsonists there are millions of dollars of destruction and countless maimed and dead animals.  The software developers become squirrels set ablaze.

I blame a lot of things for this.  Project are funded poorly with a fixed bid mindset.  Americans do a poor job training people to be engineers and technical professionals.  Many business leaders who manage software project have no practical knowledge about how software works.  Finally, short term thinking among business investors and leaders exacerbate this forest fire thinking.  Thus, your organization, which is a fragile ecosystem resembling a forest, is beset by arsonists with flame throwers and chain saws.

I do not have any cures for these problems but I do want to point them out so people who are smarter and more influential can fix them. In order to fix a problem, you need to understand what is causing it.  So if you see your technology staff running around like flaming squirrels you should be smart enough to kick the arsonists out of your organization.

Until next time.

Well Fargo is a Victim of the Cobra Effect

Anyone who follows this blog knows that I rarely hold a grudge and I don’t like kicking an individual or organization while it is down.  I am just not wired that way.  This week I am going to make an exception because of the lesson that can be learned for everyone in the agile community.  I am talking about Wells Fargo and their latest scandal regarding opening bogus new accounts for existing customers.

This isn’t the first time I have had my differences with Wells Fargo.  They were involved in a financial literacy campaign which denigrated humanities majors and liberal arts students.  Now thanks to federal regulators they are paying a $185 Million dollar fine for creating new accounts for customers without consent.  This gets to something the agile community call perverse incentives.

One of the central tenants of “scientific management” is that you measure how an employee does their job and then based on the data, as a manager, you figure out how to make that employee more efficient.  On the surface it seems like a smart idea.  A business person measures how work is done and then they strive to use that data to improve the speed and quality of the work.  This is where the perverse incentives come into play.  If you measure something and then use it as a performance incentive it ceases to be useful because it will force people to game the system to meet the metric.  This is called the “cobra effect” and I have blogged about it repeatedly.

Based on his testimony to congress, Well Fargo CEO John Stumpf said that he set up the incentives to “cross-sell” bank services to improve the company stock price.  This was the beginning of over two hours of uncomfortable questions and criticism from both Democratic and Republican congress members.  You know that you have done something bad when both Democrats and Republicans denounce you in public.

It did not have to be this way.  Stumpf could have measured performance and created training and education programs to make his staff learn how to better “cross-sell” products.  Instead, he used the blunt instrument of job incentives and it worked for a while until regulators and congress got involved.  Wells Fargo now faces additional investigation and possible criminal penalties.  It did not have to be this way but “cobra effect” can claim another victim and it could be a major American financial institution.

Until next time.

Product Owners Have the Hardest Job in Agile.

Listen to Ben, hang together or hang separately.

I have been kicking around as a scrum master for the last three years.  I have been developing software for eighteen.  Those jobs are difficult and challenging but they do not compare to challenges faced by product owners.  This week I want to talk about the hardest job in Agile – the product owner.

The Scrum Guide is pretty clear about the members of a scrum team.  They are the developers who do the work.  The scrum master is the servant leader of the team and helps remove obstacles.  Finally, there is the Product owner.  The product owner sets priorities writes stories, and acts as the liaison between the business and the development team.  What most product owners do not know is the job includes so much more than what the scrum guide says.

A product owner needs to understand the internal politics of the organization so they can work with in it and sometimes around it to get things done.  Product owners need to understand the customer.  Not only understand the customer but be able to differentiate what software improvements will add value and which ones will waste money.  The product owner is under constant pressure to write stories and to create stories which can be transformed into testable code.  It is a grind and they need to practice mindfulness to separate what is important from what is trivial.

It is not an easy job and as a scrum master or coach you need to help them succeed.  This means spending time showing them how to write user stories.  Take time out to explain the agile manifesto and what developers need to succeed.  Take time to listen about the operations of the business and the politics of the organization.

A scrum master and product owner are equal partners.  To paraphrase Ben Franklin, you will hang together or you will hang separately.  When things go wrong it is usually the product owner who receive the blame.  As a scrum master it is up to you to make sure things do not go wrong.

Business today is not easy but a successful product owner can smooth off many of the rough edges to a software development team.  That is why it is the hardest job in Agile.

Until next time.

Humanities and Liberal Arts are Good for Technology

I want liberal arts in my business

Occasionally, the news of the week prompts me to yell expletives at my web browser or television.  This was a financial literacy course called, Teen Financial Education Day.  It seemed innocent enough teaching young people how to use credit responsibly, how to use the banking system, and make smart investments.  It was innocent until you saw the advertising materials which said things like “A ballerina yesterday.  An engineer today.”  As a successful scrum master and software developer this ticked me off.  This week on the blog I want to talk about why and emphasize that we need humanities, liberal arts, and the STEM in order to have a successful business community.

I graduated from Illinois State University with a major in Mass Communication’s and a minor in philosophy.  I pursued the minor because it was a subject which interested me.  I pursued the Mass Communications degree because I was going to work in radio.  I could not have picked a worse major as the radio business outside Chicago began to contract and the recession of 1990 evaporated any other jobs.  As a child of the Reagan 1980’s who said no to drugs, worked hard in school and strived to better himself; it was a very bitter pill to swallow.  I did everything expected of me by society and my elders and I was rewarded with underemployment and ridicule.

It would take me eight years from when I graduated from college to find a career in the technology field.  It was the giddy and stupid days of the dot com bubble and I went back to community college to learn visual basic.  At the ripe old age of 30, I was starting my career from scratch.  I was a self-taught technologist.  Funny thing was that my experience in newspaper, radio, and mass media made me a natural fit as a web developer.  I could discuss typography with print professionals in a language they understood.  I understood the shorthand of marketing professionals.  I knew things about color, shape and art which didn’t have to be explained.  As technology changed with the addition of CSS and XML, I was able to quickly adapt and retrain myself because I learned those concepts in school studying alien concepts like monads, existential nausea, and the payola scandals of the 1960’s.

As a liberal arts and humanity’s student, I had an advantage over my more technical colleagues because I had the “soft” skills and communications abilities to help software projects get done.  So when a bank like Wells Fargo says these skills are not necessary as part of financial literacy education it makes me want to become a hulking green rage monster.  Furthermore, when that bank is the second largest provider of private student loans in the United States, it looks like that a financial institution is trying to pick and choose which majors students should pursue.  It looks fishy at best and market manipulative at worst.

We need humanities and liberal arts in American culture.  We need humanities and liberal arts in American business because these graduates have the writing, speaking, learning and teaching skills that businesses need.  They understand different cultures.  Someone with a background in gender studies could help reduce sexual harassment in the workplace.  A worker with an understanding of Langston Hughes, Nina Simone or the Harlem Renaissance might be better explain diversity issues or #BlackLivesMatter to people who might not have that understanding.  Finally, an art history major would be a perfect choice for a UX designer or Web designer.

This is why we need liberal arts and humanities.  We need it because life is more than ones and zeros.  It is about people and inspiring them, understanding them, and helping them be better people.  It is about developing open minds and optimism about the future.  It is about understanding the past and the way our culture has evolved over the last 3000 years to become what it is today and what it might be tomorrow.  Liberal arts helps build better technology and better businesses and it is about time that others begin to see that.

Until next time.

Your Developers Are More Than Resources

These are more than resources

It is the Labor Day weekend in the United States.  I marks a turning point in the year as summer winds down and all attention turns to the fourth quarter and generating as much profit as possible before the end of the fiscal year.  As a scrum master, I spend so much time jumping from sprint to sprint that I find it hard to see the big picture of the how my projects are going.  It is a constant balancing act between tactical choices and strategic goals.   This week I want to talk about the most important part of the scrum process – the people who do the work.

I have worked in the technology business for over 18 years.  I have experienced the giddy and stupid times of the dot.com boom and the fear and uncertainty of the great recession.  The common thread through all of these periods was that work needed to get done.  In order to get that work completed many companies relied on consulting companies to augment their staff.  These “contract workers” were often treated poorly and given tremendous responsibility for the success of the project with none of the financial and career benefits if it did.  Add to this situation that many of these contract workers were working under H1-11 visas and you had a situation which resembled indentured servitude.  I remember working for one company and being in a staff meeting where everyone was afraid to speak because if they did they would be rolled off the project and they risked being deported.

I blame most of this misconduct on how technology work is funded in a corporate environment.  For instance, much of the technology work is considered an overhead expense.  Thus, to keep expenses down many business people only hire the bare minimum of technology staff.  There are a few help desk people.  Network engineers dot the organization chart and you see a manager keeping everything running on time.  Software developers and User Experience professionals are not considered “necessary” for the operation of the business until new software needs to be written.  Thus, when they are needed they are brought in like mercenaries to try and build software they have little professional or personal investment to build with any sense of craft.  They get paid for showing up and billing.  They are not compensated for creating shippable code.

Many of the people who do the work are referred to by other business people as “resources”.   People ask questions such as, “Do we have enough resources, to do this project?” or “Do we have the right resources with the correct skills?”  Every time I hear technology workers referred to as resources, it makes my flesh crawl.  It treats highly educated and smart people like they were rivets in a giant construction project.  I have never heard of iron workers referred to as “resources” by construction managers but every project manager I have known has referred to developers as resources.  It is so prevalent that I even catch myself saying it from time to time.

People who build software are not resources.  They are flesh and blood.  They work in cubicles and offices around the world from Chicago, to Belfast, to Chennai.  They are the people who are building to global economy one web page and user class at a time.  They take the vague ideas of a sales person on the back of a napkin and transform it into working software.  They maneuver through corporate politics and red tape to get things put on production servers.  They tolerate not having office supplies because there is no budget for paper clips from finance.  They work late hours and early mornings to communicate with off shore teams.  They make your business successful.  You just don’t see it because we keep all the lights on and everything working even if it requires metaphorical duct tape.

So show a little respect to your developers and the people who employ them.  They are more valuable than you know and they are more than just “resources”.

Until next time.

Reflecting Upon a Turning Point.

My Philosopher's journey continues

This week marks a bit of a turning point for me.  I have been part of R.R. Donnelley for three years.  This week as part of a complicated stock split, I am joining LSC Communications.  I am excited like a child going to a new school but I am also a bit scared by the unknown.  This week, I want to reflect on my agile journey and where it is taking me.

Three years, I left a consumer foods company as a programmer to become an architect.  My credentials as a scrum master gave me a leg up from the other candidates.  Quickly, I noticed that my new leadership had other plans for me.  Soon, I was leading a team of developers as a scrum master.  I was certain that change would come quickly and that the team would be kicking butt and taking names.  I was wrong.

I had to drop a few authoritarian traits I had picked up over the years.  I had to read numerous pieces of literature helping me expand my knowledge about agile and scrum.  I spent plenty of late nights working with the developers fixing bugs.  Finally, I had to confront the reality that I did not have all the answers.  It was humbling and a necessary experience.

Today, I am a few years older and wiser.  I am a much better scrum master than I was three years ago. Joining LSC Communications, I will not only be a scrum master but also coach for other teams in the organization.  It should be a valuable experience.

The philosopher Heraclitus said we could never set foot in the same river twice.  As I am about to cross over into another unexplored territory, I can say that I am not the same scrum master I was three years ago and I am ready for the challenge ahead of me.

Until next time.

I Can't Believe I was Being this Dumb

I can learn a few things from this guy.

A scrum master is a leader without any authority.  They are someone you follow because they help you become a better developer and help you finish projects in a timely manner.  It is not for everyone.  I spend much of my time in self-reflection and attempting to improve my skills.  I also have to control my autocratic and curmudgeonly nature when I am dealing with individuals who are not pulling their weight.  On twitter, I had an interesting interaction with someone I respect in the user experience field Gail Swanson and I think there are a few lessons to be shared.

Like many of us, she uses twitter as a place to vent frustrations, test out ideas and share knowledge.  I respect her and follow her because she has plenty of things to say about being a good user experience person.  Then she shared this on twitter.

Imagine if your boss referred to the male employees as 'boys'. Doesn't feel right, does it.

— Gail Swanson (@practicallyUX) August 12, 2016

I responded with the following

I use "Ladies. And Gentleman" is that acceptable? https://t.co/5enCJj4YpZ

— (((Ed Wisniowski))) (@eeeThree_ed) August 12, 2016

Finally, Angela Dugan chimed in and she might as well have dropped a mike.

@eeeThree_ed @practicallyUX how about "team" or "everyone". Unless it's a super gender specific topic/event, why even bother being specific

— Angela Dugan (@OakParkGirl) August 13, 2016

It took some time for this to sink in but it dawned on me that words and behaviors matter.  What I consider being respectful to my developers comes off as condescending and superior.  How I spoke to them effected their performance and it need to change right away.  I was being dumb.  So now, I use the terms “everybody”, “team” or “folks” to refer to the people I am working with.  I was doing something dumb and it took people I respected to point it out to me.

A contemporary scrum master has to interact with numerous people.  They work with off shore teams and on shore teams.  They are mixed by gender and religious affiliation.  I have Sikh, Muslims and Hindus working for me off shore.  On shore, I deal with evangelical Protestants, Neo-Pagans and Atheists.  What unites all of us is that we know how to code and that we are working on the same project.  I as the scrum master need to respect these cultural differences and keep everyone focused on the end goal.  My personal feelings or prejudices need to called out and controlled if I am going to guide these individuals to their goal.

It also means that the macho cruft that you see in software development needs to go away.  I am fortunate enough to work at an organization where women are incorporated into all of the development teams.  I think that has improved the development teams.  The testers, technical leads, developers, and QA people who are female are regular members of the teams and because of their skills have earned the respect of their male colleagues.  For our organization, diversity produces better results.

So there you have it; a scrum master needs to change and adapt.  The increase of off-shore development and the number of woman in the profession, has made me confront some of my own prejudices and make changes. I hope others can learn from my example.  I am just trying to be a better scrum master and guy.

Until next time.

If it isn't broke you better fix it.

This didn't have to happen.

I have been off line for a week as I attended the Gen-Con game fair in Indianapolis and tried to get back into the swing of things at work.  While I was away, I had a chance to recharge my batteries and have a good time playing board games with friends.  I also got to have a little fun with the people at Big Potato Games which is seems like a fun group of people who are making a big splash in the industry.  When I came back two things happened which got my attention which illustrated the paradox of contemporary business and modern technology.

The first was the problem with Delta Airlines and its reservation system which grounded the company for two days.  The second was a small article in the technology press about Windows 10 updates.  Both articles illustrate to me that the business maxim, “…if it isn’t broke don’t fix it,” is seriously wrong.  If you are a company in the 21st century if you want to remain in business it is your responsibility to upgrade your technology infrastructure and applications.

First, Delta airlines relies on its reservation system to be managed on AS/400 systems and mainframes using the IBM Transaction Processing Facility software.  The software was last upgraded by IBM ten years ago and the only people who can fix something if anything goes wrong are IBM consultants.  If something goes wrong a CIO and their company is forced to call IBM to make changes and corrections.  In the same ten year span, Microsoft has had four operating systems; Windows 7, Vista, Windows 8 and Windows 10.  Presently, there is an entire ecosystem of developers outside of Microsoft who can alter, improve or fix these systems.  So if an airline wants more availability to labor and more up to date systems they should go with a Microsoft solution.

This did not happen for a few reasons.  First, airlines for all their talk of customer service and being high tech are notoriously stingy with money to upgrade and improve their technology infrastructure.  So what they did is graft other technology systems on to their old IBM infrastructure.  If the AS/400 went down, it would create a cascading effect which would shut down the airline.  According to the news, that is exactly what happened as numerous technology professionals scrambled to get the systems back up and running.  It also lead to the CEO of the company publicly admitting they are doing the best they could to fix the problem without knowing exactly what went wrong.    Next, the people who make the decisions about the funding felt this risk was so unlikely that they decided that the system was not broken and so they did not need to make improvements.

This kind of thinking is foolish.  Software is like any other machine but it manufactured out of ones and zeros instead of steel.  Machinery needs to be maintained or it will break down.  Fail to change the oil in your car and see what happens after 100,000 miles.  That is the exact situation which happened at Delta. The people driving the organization put off or ignored routine maintenance to its systems because it would cost money to do so.  As long as everything was working, there was no need to do maintenance and upgrades.  As you can see, this cost the company millions of dollars when the system failed and hurt its reputation for quality service.

The other new item I saw this week was a brief blurb about how Windows 10 updates are not an iron clad guarantee that a system will not be compromised by hackers because people generally do not upgrade the other software on their machines.  As a technology professional we have seen people with Windows 10 machines with copies of Office 2007 on them.  This mixing and matching of software in the real world is common because people don’t have the money to upgrade everything.  This creates openings for hackers and people willing to do bad things.

This is short sided like a person not changing the oil in their car.  When you upgrade an operating system you should be able to update the software which is on that operating system.  This is why I am a big fan of Google Documents and Microsoft’s Office 365 software because these cloud based systems update automatically and do not rely on the user purchasing and installing upgrades.  The burden is no longer on the consumer but on the company providing the software which is what it should be.

So in one week the world witnessed an object lesson in why the phrases, “…if it isn’t broke don’t fix it,” is wrong.  Old and outdated software which was not maintained properly failed spectacularly.  The only people who could fix the software was a third party vendor which was not responsive.  The pennies saved on upgrades and improvements became millions of dollars in technical debt which shut down the company.  Finally, the reputation of the company was hurt by this kind of thinking.

It is also clear that just upgrading operating systems is not enough the applications which run on those operating systems need to be improved.  I understand that in the world of technology bragging about your new data center or software upgrades to your core business is not as glamorous as web application or phone app but it is just as important because when those systems fail they fail in an embarrassing and spectacular fashion.  So it is up to everyone from the largest company to the personal consumer to pay attention to how they maintain their software.  If not, expect to be grounded.

Until next time.

When your office resembles high school

We grow up but never out of high school

When I was a high school student, I had an irrational fantasy about being an adult.  I truly believed when I left school, I would enter an adult world and be surrounded by grown-ups acting in grown up ways.  In the thirty years since high school, I have been bitterly disappointed. This week a few thoughts about how your office resembles high school.

Any American who attended a public high school knows that the students live in a social and cultural limbo. Over achieving strivers are wedged together with cheerleaders.  Hard rock students in black concert shirts walk the hallways with people into hip-hop wearing track suites.  The public high school is one of the few places where people from different economic circumstances, races, and levels of educational acumen are forces to interact with each other.  Naturally, they self-separated and create tribes.

As a dorky kid, I was both outcast and court jester for the insular and sad world.  Eventually, I found a niche in forensics to develop my public speaking and in JROTC to improve my self-discipline. The formative time shaped me into what I am today.

To my surprise, the mean girls who tormented me in school would resurface as marketing, human resources, and project management professionals.  The homecoming kings and athletes would transform into sales professionals and executives.  The dorky people who said not to drugs, studies hard, and developed insane technical skills.  We still answer to these monster in corporate environments.  No wonder so many of us become entrepreneurs.

The first thing I have learned is that mean girls grow up to be mean woman.  I have also learned that mean people are not worth your emotional energy.  They are going to remain mean so the best strategy is to ignore them or treat them with the contempt they deserve.  Telling someone they are being a jerk is the first step in getting them to change.  It is also good to point out to their bosses that the mean person’s attitude is why projects are not getting done on time or on budget.  You will be pleasantly surprised what happens next.  A good leader will fix that situation immediately.

As for the athletes and popular people who become executives, I have found listening to sports radio and watching ESPN sports center gives me enough knowledge to talk sports without sounding totally clueless.  It also allows you to use sports metaphors to describe technical situations.  For instance, I was building a web site and running into problems with the corporate active directory.  I told a boss that the situation was like a basketball team with a player who won’t pass the ball.  A few phone calls later my issue was fixed.

I am not suggesting that you become a tattle tale but I have discovered that when interpersonal issues prevent a project getting completed leaders behave like a high school principle and step in.  It is not pretty but in a world where dollars and cents count.  The person who gets work done is always going to receive preferential treatment over the person preventing that from happening.

So none of us really escape high school but hopefully as adults we can deal with the people who act like they are still in it.

Until next time.

Lessons learned being a scrum master

Failure is just part of being a good coach.

Being a scrum master is more than taking a test and receiving a certification.  There are plenty of hours of hard work and endless meetings.  As a rookie scrum master, I thought I understood the role.  Today, I know better.  This week some lessons learned.

When you discuss the term servant-leadership, many scrum masters see the developers they work with as servants.  This is backward.  A scrum master is a servant to the development team.  They provide help and guidance where they can they take care of the other team members before they take care of themselves. Most people see rank as having privileges; I disagree.  Rank is about responsibility for others, fulfilling those responsibilities and receiving only the privileges which benefit the entire team.

I am an extroverted person and according to the Myers-Briggs personality test I fit the model of charismatic leadership.  This is great for politics or giving presentations to a room full of fanboys but it is a handicap for a scrum master.  The reason is this leadership style means you talk more than you listen.  This is a recipe for failure for a scrum master.  To make change and coach others you need to listen and observer with the attention to detail of an anthropologist out in the field.  One of my early mentors, Andy LaChapelle said it best, “You have two ears and one mouth use them in that frequency.”

Finally, to be a scrum master is to let others do the work.  This has been the hardest lesson to internalize.  I have been a Type “A” person with plenty of nervous energy. When a task was incomplete, I would step in and finish it.  That is wrong and like an NFL coach going into a game to kick a field goal.  The scrum master is the coach and it is up to them to let the team members succeed and fail on their own terms.  It is maddening but so is coaching a team all week getting them in a position to win and have the kicker miss a field goal.

So experience has taught me that to be a successful scrum master you need to be a servant leader putting yourself above others.  A successful scrum master listens more than he speaks.  Finally, a successful scrum master lets the team do the work and self-organize.  I hope you take these lessons to heart so you don’t have to learn them the hard way like I did.

Until next time.

What Donald Rumsfield can tell us about being a Scrum Master

Donald Rumsfield back in the day.

Donald Rumsfield is going to be a controversial figure in history.  The Princeton graduate will be the center of plenty of scholarship about the Iraq war and the events surrounding the September 11th attacks.  Looking over his conduct of the Department of Defense and business career, I am not a big fan of his leadership style.  What I do acknowledge is his famous quotation about ambiguity and uncertainty.

“There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don't know. But there are also unknown unknowns. There are things we don't know we don't know.”

This week on the blog some things a scrum master can learn about ambiguity from the former Secretary of Defense.

Known-Knowns

Every scrum master confronts these each day of their career.  The coffee pot is broken.  Active Directory permissions are not correct for a developer and the compliance committee will not allow a production push for two weeks.  These are the known-knowns.  They are the daily challenges and impediments which crop up and are expected.  These issues are easily solvable, have been solved in the past, or can be ignored with little risk.  As a scrum master it is your job to sweep these kinds of issues out of the way to make your team successful.

Known-Unknowns

This is what traditional project managers call risk.  These are situation which can plan for but might not happen.  The most famous example is Eisenhower’s communique he was to send if the D-Day invasion failed.  As a scrum master, things can go horribly wrong and allowances for these things are necessary.

This situation also happens when developers are asked to do something they have not done before.  In my case, it is using modal forms with Bootstrap 3.  This known unknown is taking longer than I expected to implement.  If I have more serious time pressures, I would use a different approach on the website I am refactoring.  I am learning this new skill and taking the time to master it because it will transform into a known-known if I do the work.

Unknown-Unknown

These are the surprises, calamities and disasters that befall a development team.  The production server has not been upgraded to the latest version of the .Net framework.  The network administrator won the lottery and had tenured his resignation immediately.  Finally, the third party API the application relies on changes without notice.  An unknown-unknown quickly becomes a known-known because of the severity of its impact.

These land mines are silent and deadly traps which make the life miserable for a scrum master and technical professionals the serve.  It has been my experience that many of these unknown-unknowns are the product of technical debt.  So to reduce the amount of ugly surprises, reduce the amount of technical debt.

Unknown-Knowns

Salvoj Zizek, a philosopher and cultural critic mentioned there is a fourth category which Rumsfield neglects.  The is the world of the Unknown-Known.  This is a piece of knowledge you have which you chose to ignore.  An example of this could be a tech-lead who refuses to write unit tests because his “code does not have bugs.”  In my experience, the situation crops up because politics, prejudice, or human nature prevents us from acknowledging the evidence we are confronted.  You see this situation in co-dependent relationships and dysfunctional teams.  It is the duty of a scrum master to call this out and make sure that developers are aware of everything they need to be successful.

A scrum master needs to understand and confront the known-knowns, the known-unknowns, the unknown-unknowns and the unknown-knowns facing his team.  Otherwise, the project might go as smoothly as the Invasion of Iraq.

Until next time.

Rethinking how I look at story points.

Story points are not like coffee cups

I have been an agilest since 2009 and that means that my knowledge of scrum and agile have grown over time.  Occasionally, I have to reconsider some ideas I took for granted.    This week would like to review the notion of story points.

My change of heart came about when one of my developers Larry Gasik came to me and confronted me about how we treat story points.  Many scrum masters and people in the agile community treat story points as measurements of volume like cups at a coffee shop.  If a developer works six hours a day on code then three story points’ holds up to 18 hours of work or (3*6).  By the same logic a five point story can hold (5*6) or thirty hours of work.

I have been doing it wrong.  A story point is more like a measure of distance rather than volume.  This blog from Mountain Goat Software does a better job explaining this better than I can.  To calculate the “distance” of a story point it is the sum of difficulty and ambiguity rounded up to the nearest number on a Fibonacci sequence.  If I were to write a formula for this it would look like this.

Story Point = Difficulty + Ambiguity
F_n = [Story Point]

Where F_n is a number in a Fibonacci sequence.

Here is where the math gets important.  An Olympic runner can run a mile in under four minutes.  A middle aged man like me can walk that distance in about thirty.  The size of the mile does not change just the ability of the person to cover the distance.  So two people will take a different amount of time to complete a three point story.  So two people will take a different amount of time to complete a three point story.  Now we can use ranges of time.  In the case of three story points, on the low side (3*1) for one hour to complete a story point to eighteen hours or (3*6) on the high side.

This accomplishes three goals.  First, story estimates deal with ambiguity better because the ranges of time get larger as the story point increases in size.  Second the story point allows for better forecasting because developers who concentrate on story points and velocity can plan how much work they can handle in a sustainable fashion.  Finally, saying a story point is a range of time prevents managers and other business folks packing more work into a story point because it is not a fixed volume of hours.

By treating story points like units of distance instead of volume you eliminate numerous distractions in your agile practice.  Managers will not treat sprint estimates like quotations because of ambiguous nature of the amount of time it will take to do the work.  This also prevents a manager from placing more work into a sprint saying, “It was five story points and it only took you 20 hours so I am going to add about ten more hours of work to keep you busy.”

This helped me come up with something I call Kedar’s computation after my technical lead.  Story points also help reduce risk in a project. For instance, say your developers spend six hours a day coding.  The range of hours inside a story point is between one and six.  Following this reasoning three story points could take as little as three hours of work or 18 hours of work.  Now, you have a sprint with 39 story point’s worth of work.  The product backlog items in the sprint could be divided in two ways.  The first way is 13 three point stories.  The other way is three 13 point stories.  Doing a little arithmetic on the back of a napkin this is what you discover.

Given:
13 three point stories.
(3*1)*13 = 39 || (3*6)*13 = 234

Given:
Three 13 point stories
(13*1)*3 = 39 || (13*6)*3 = 234

The amount of hours are the same!  It is pretty cool but here is where you as a scrum master and project manager can say that you have more confidence in getting the work done.  Thirteen point stores are more risky to complete than and three point story and here is why.   Say the developers get stuck on a thirteen point story and fail to deliver it during the sprint.  The math looks like this below.

26/39 which simplifies to 2/3

Now do the same thing for the sprint with 13 three point stories.  The team gets stuck on a three point story.

36/39 which simplifies to 12/13

The team is going to be more satisfied with the work when they deliver 12/13 of the work than 2/3.  Management and the people paying the bills are going to be more forgiving of the team when only 1/13 of the work is incomplete rather than 1/3.

This is Kedar’s computation, which shows that while the work is the same, the risk is much greater for fewer stories with larger story point totals.  To go back to our runner analogy, the runner is completing smaller chunks of the race at a time and is more likely to complete the entire race.  We have a better means of tracking how far along the runner is during the contest.  It may take them a longer or shorter period of time to finish the race but the distance traveled is the same.  The only difference is that it has been divided into smaller laps.

This is why I have changed my mind about story points.  They are more a measure of distance with ranges of time rather than fixed volumes of time.  Making this intellectual shift will make estimating with story points more helpful.

Until next time.