How Did We Do in 2015?

Looking back at 2015, I will drink to that.

The end of the year is a special time.  For me, it is an excuse to dress up in formal ware, have a good meal, and stay at a hotel where my only risk is trying to find my room key.  It is also a time to make a few predictions and look back at the previous year.  This week I wanted look at some of my past predictions and see how accurate I was.

Last year, I made three major predictions. The first was that competition will do what it is supposed to do in 2015.  In the world of wireless phone service, this seems to be working as a full scale price war has broken out between Sprint, Verizon and T-Mobile.  Unfortunately, this is not the case regarding net neutrality as major cable operators including Comcast were trying to create pay for faster service paths.  I am also concerned about plans which do not use data for preferred streaming services.  It also looks like oil prices are also falling because American production capacity is matching that of the OPEC nations.  Competition works if we let it and 2015 validated this.

My next prediction was that the internet of things would pivot.  To many people outside the tech world, the only kind of internet of things they see are home thermostats and the smart televisions that are being marketed.  I think that we are a long way away from smart refrigerators which will reorder food or water heaters which will conserve energy by burning gas when it is cheaper.  Still smart watch use continues to grow and I helped this trend by getting my father a smart watch for Christmas.  After some hiccups setting up the watch, things are going well.  If my seventy something father can use a smart watch, then the future of wearable technology might have a chance.  As for the rest of the internet of things, I think we are going to have to wait a while longer.

My final prediction in 2015 was that agile was going to grow.  I was correct in that prediction but with that increased growth came backlash.  Corporations are learning that in order to be agile they will have to change more than how software is written.  Financing of projects and the relationship between business people and technology professionals will have to change.  This type of change has been especially hard for more conservative organizations who have been doing things a particular way for so long they see no reason to change.

In addition to push back from the CFO and the finance department, developers are also revolting.  Things like SOILD development and test driven development are skills which challenge many developers who began as hobbyists and then entered the field.  The discipline of scrum also has created push back because for years many developers have been able to hide in plain site without having to create shippable product.  That has changed and now it is easy to spot poor quality work and sandbagging among the development staff.  Software engineering is starting to resemble actual engineering and it is a positive trend.  For those unwilling to adapt they are pushing back.

So those were my predictions for 2015, next week I will make some predictions for 2016.  I look forward to seeing you then.

Until next time.

A Holiday Message from Dirty Fingers.

Have a good Christmas.

It is easy to get discouraged at the office.  There are lots of mean, petty and crazy people.  You also have to cope with bureaucracy and office politics.  As a scrum master these issues come with the territory.  This week I wanted to take a break from that and give everyone a message of hope.

The world is a cruel place and life can be nasty and brutish.  This does not mean that we have to be.  The Christian holiday season is a time to spend with family and take stock.  There are going to be many changes in 2016 and I will be previewing them next week.

I have a great many things to be grateful for in spite of the windmills I keep jousting in my current roll.  I am rolling along in my middle age healthy and happy.  I have great family and friends who are supportive.  I also have the community of agile developers and scrum masters to provide me help and guidance.  I would not be here and this blog would not be possible without your support.  I would also like to single out two people in particular Bill Buse and Alan Dayley for being my personal muses and mentors this year.  Thanks guys.

So I would like to wish all my readers a Happy Yule, a Merry Christmas, and a joyful Kwanza and look forward to seeing you in 2016.

Until next time.

Making a Difference

How does a scrum master describe his job at the
office party?

The other night I was having dinner with someone who worked as a nurse.  I understood what they did for a living and when they discussed their work it was easy to understand their frustrations and successes.  Then I told them I was a scrum master and they gave me a blank stare. It seems the world of technology has not filtered out to the fly-over country and so I spend a lot of time explaining to people what I do for a living.  This week I thought I would help others have that awkward conversation about what you do for a living.

At first, I struggled with metaphors to describe what a scrum master does.  In a way, we are coaching helping software developers and business people do their work faster, better, cheaper, and with less hassle.  It did not seem adequate.  Then I thought about Stephen Ambrose and his book, Band of Brothers.  A scrum master is like a platoon leader for a group of para-troopers.  They lead, look after the well-being of their people, and are on the front lines of the software development action.  It seemed a stretch because I do not jump out of planes or get shot at by enemy troops.  May-be a scrum master is like an orchestra conductor getting developers and the business to play together.  Again not very good because classical music does not have a culture of improvisation that developers use to get the job done every day.

May-be I should skip the metaphors.  Each day, I work with developers from Chennai, India.  Then I go into the office and try to work with the on shore developers.  Next, I help my product owners learn to write business stories.  I spend a few minutes being demeaned by my project manager and try to stay positive for my software developers and my business leaders.  I manage up setting expectations and receiving one-word e-mail replies from vice presidents who don’t have time for me unless something is wrong.  I am sweating deadlines, answering awkward questions, and pushing the people I am responsible for to complete deadlines.

I have to be a cheerleader staying positive in some of the most discouraging situations.  I have to be an actor because I have to receive abuse and condescension from business people and say that I like it.  I am a business consultant showing people how to do things a better way and I am a therapist as I help my developers get through personal problems and business frustrations.  It is also a calling like being a member of the clergy because we are pushing people to see a better way.

The best answer I can give is that a scrum master makes a difference.  Many of the software products you use and the apps on your phone are built by software developers.  The scrum master makes sure that construction gets done.  The scrum master keeps the wheels of the global economy spinning as they take numerous conference calls and sitting through endless meetings.  We are not middle managers; we are on the front lines making things happen.

So the next time someone at a holiday party makes a remark about what they make, smile and given them a steely stare and say you make a difference.  It is the only way I can describe what a scrum master does.

Until next time.

You can't fight mother nature.

The flooding is pretty bad in Chennai

This has been an unusual week.  My off-shore development team have been off-line because of horrible flooding in Chennai, India. I have been worrying about the health and safety of my teams which include a few newlyweds and new parents.  This natural disaster also gave me pause to think about the things we can’t control.

A common theme in Western literature for the last two hundred years is the struggle human beings have over nature.  We have fought it on land, sea and air.  We have endured terrible cold and withering heat.  Authors from the naturalistic period of writing have been very honest with their readers.  People struggle against nature and sometimes nature wins.  More contemporary writing has ignored this wisdom and has championed human engineering and willpower.  Some books pioneer the bogus notion that we can use our willpower to transcend reality.

This kind of magical thinking has crept into the business world. It is not uncommon for project managers to think that if people work harder, faster, or smarter that can overcome the constraints of time and nature.  It is true that we can manage time better, but we cannot change the fact that you cannot force twelve months of work into five months of time.  Each day project managers and scrum masters are asked to do this and it undermines the very nature of our profession.

There are contingencies which can be made and allowances which can be incorporated into a plan.  Unfortunately, real life gets in the way and projects slip.  As Mike Tyson used to say, “Everyone has a plan until they are punched in the mouth.”  People get sick, snow falls, and entire cities and engulfed in flood waters.  People who make software are not tools to be used up and thrown away.  Software developers are not resources, they are flesh and bone people; so asking why the project is not on track is not only stupid but insensitive.

My heart goes out to the development teams, their families and the citizens of Chennai, India.  I hope all of you get through the catastrophe safe and sound.  Some things are more important that project deadlines and this is one of them.

Until next time.

The Coffee Pot and Innovation

The coffee pot can tell you a lot
of things about the corporate culture. 

Certain things happen in a business which are illustrative of that organizations culture and its approach to innovation.  This week I wanted to share an example.

The facts

It is 8:30 on a week day.  The coffee pot is out of fresh coffee and a pound of fresh ground coffee is sitting next to the pot.  The department manager comes into the office and sees there are no pre-measured packages from the coffee service.  They retrieve three pre-measured bags of coffee and make a pot of coffee.

The maker and innovator in the office perceives 

“This is why we cannot innovate in the business.  You had a pound of coffee and could not make a pot of coffee without a measuring spoon or visually filling the coffee filter.  This means we are inflexible to changing situations, unwilling to try new things, and unable to deal with ambiguity.”

The person who made the coffee perceives

“I don’t see it that way.  The pre-measured coffee is just the right amount.  I do not have to measure it.  I don’t have to guess and I know that I am going to get a good pot of coffee every time.  This means less waste and everyone got a cup of coffee with no fuss.”

Some conclusions

I need to read some Wittgenstein or take a class on his feelings about the nature of reality.  I am the innovator in the office and being unable to make coffee without pre-measured packages makes me crazy and is an example why change and innovation is so difficult.  The person who made the coffee does not see this as a symptom of a larger cultural issue and is more concerned with the end result rather than the process of making coffee.

This further reinforces what I have been reading in business literature and in cognitive psychology.  People want creativity until they are confronted with creative people and ideas; then educators and business leaders reject creativity.  So we create a situation of cognitive dissonance where we want people to be creative and adaptable but when they are we discourage those behaviors.

This is the world of shadows that a scrum master needs to navigate. We need to help people learn new ways of doing things but not be too creative otherwise we are going to face backlash and rejection.

So how do we agile professionals learn to better manage change in organizations who prefer the coffee in pre-measured packages?  I would love to hear your recommendations.

Until next time.

Product Owner Anti-Patterns

If your product owner behaves like this
way they are doing it wrong: very wrong!

Every scrum master needs to be on the lookout for some anti-patterns in how product owners do their jobs.  In a perfect world, the product owner and the scrum master are like siblings working toward the same goal.  The reality is that mismatched business priorities and lack of cooperation by business partners can happen in any organization.  So this article will help you recognize the smells which you should look out for as a scrum master.  I hope a few of you will be kind enough to provide some suggestions of how to deal with these anti-patterns.  Many of these examples come from Roman Pichler’s excellent book on product ownership.

The Under Powered Product Owner

We have all seen this product owner.  They have the look of an abused animal.  They are not empowered to say “no” and they when they say that they speak for the business you know what they are really saying is they speak for their boss who will overrule them when it is convenient.  The under-powered product owner is a figurehead who is their because the scrum process says so.  The people with the real say will not abdicate their authority to let this product owner do the job.  The authoring of user stories consists of being called into the boss’s office to take dictation from the boss.  Priorities are set by the boss and if something goes wrong it is the fault of the development team rather than the boss.  Everything is a priority so nothing is a priority until something goes wrong which triggers a spasm of unsustainable development. 

The Over Worked Product Owner

According to Certified Scrum Master training, each software project should have a product owner and a scrum master along with a group of developers ranging in size from five to seven people.  Executives look at this as a waste of resources and often assign multiple scrum masters over many development teams and do the same with product owners.  The by-product is the over worked product owner.  Currently, at my firm I work with a Product owner with his work divided among four software development teams.  What this does is that it forces the Product owner to only spend the minimum amount of time necessary to get stories written and to make sure that priorities are getting fit into the sprint. The stories are rewritten by the scrum master or another developer so they are clear enough to be understood by the other developers.  Stand up meetings, retrospectives, and demonstrations are missed because they are not considered critical by the product owner.  The only time they turn up is when something goes wrong or when upper management is paying attention.  Quality suffers, and the notion of sustainable development is nothing more than a sick joke.

The Absent Product Owner

Sometimes projects are kicked off and the executives who demand the work can’t find or won’t hire a product owner.  The software is still expected to get written but no one can be bothered to write the user stories.  Software developers and scrum masters should just be smart enough to find out what creates user value.  This creates situations where what is constructed is often not what the business wants. Fortunately, the failure process is faster so the executive can ask questions like “what is wrong with you people?” and “this is a simple business process why am I paying you so much money to screw this up?” 

The Product Owner by Committee

Some projects have a great deal of visibility and multiple project teams; this creates the product owner by committee.  These are individuals who are all empowered to write stories in the backlog and they are also equally empowered to set priorities.  This pulls the development like taffy and forces the scrum master and the development team to juggle priorities with dexterity of chain saws.  One mistake creates, the loss of a limb and the destruction of a career.  In addition, the horrific aftermath generates meetings which are outside the scrum process and cut into the productivity of the team.  This is why many of us in the agile community are discussing how to scale large projects because multiple development teams and product owners leads to this situation.

The Rogue Product Owner

This is a product owner who has his own personal interests in mind rather than the needs of the business when creating work for the development team.  You know when you work for a rouge product owner when your boss comes to you and asks what your team is working on.  This is because the team is making life easy for the product owner but new customers are not being generated because the features to attract those new customers are not prioritized as highly by the product owner.  This undermines the agile process because the only value being created is for the product owner instead of the business. 

So there you have it; five different anti-patterns for product owners.  Be on the watch for all of them otherwise your life as a scrum master is going to become very painful.

Until next time.

When the Mad Hatter gets Sick and Tired.

This mad hatter needs the party to end.

The work of a scrum master is full of details, stress, and strain.  This week it caught up with me and I wound up in the hospital suffering from food poisoning and inflamed bowls.  Being sick is a humbling experience and it puts things in perspective.  I wanted to share some of that perspective.

Lewis Carroll the fellow who wrote the Alice in Wonderland books, said “Between the idea and the reality lies the shadow.”  As a scrum master in a large bureaucratic organization, I have been living in those shadows for two years.  I have witnessed incompetence tolerated and rewarded for longevity with the organization.  I have also witnessed one of my business users speak to a developer as if they were cocker-spaniel.  I have spoken about sustainable development and had an executive look me cold in the eye and say, “You are agile figure it out.”  I have also said and done a few things I am not very proud of.

The stress of the deadlines imposed by others not related to the teams, the lack of qualified product owners, and the open hostility of some of my business partners to scrum and agile have taken a toll on me and my health.  Sometimes what keeps me going is the hard work of the developers who work with me and that desire to be successful.

It has occurred to me that I have been pushing myself too hard.  A night in the hospital under observation will do that to a person.  So I am going to try and take a step back and try to pace myself a little better.  No late nights and answering e-mail at weird hours.  Saying no more often when asked to do things.  Finally, just acknowledging that I cannot change my organization.  It is going to take more than this Mad Hatter to change an organization like mine.

This sounds like defeat.  It is not; it is me taking care of my own health and well-being.  I blame stress on what happened to me and I need to remove some of that in my life.  Until I leave the shadows, I will just have to accept my current role.

Until next time.

Show some love for the product owner

Show your product owner some respect.

I spend a lot of time talking about agile and what it means to be a scrum master.  This week I wanted to change things up a little bit because I think many of us in the agile community have been neglecting one of the most important people in the agile process- the product owner.

I am a big fan of Roman Pichler’s book on product ownership.  In it, he says that being a product owner is one of the hardest jobs in technology.  You need to understand the nature of the business, be able to act as a liaison to the technical team, and finally understand the nature of building software.  I would like to add a few more.  A product owner should be able to advocate the priorities for the business, they should act as a cheerleader for the team, and most importantly they need to be empowered to say no.

Too often in large organizations, executives treat their departments like feudal kingdoms.  The only way to get promoted or advance is to serve at the pleasure of the lord or lady running the department.  This forces the people working under these feudal rulers to avoid telling the truth about project progress and saying no to situations which are misguided.  It is up to the product owner to act as this informed chancellor to the lord or lady of the department.  This delicate balancing act is not for the meek.

Making matters worse, if that projects in large organizations are funded by the project instead of by the department.  This means the product owner is not a full time position but rather someone appointed by an executive because they have some project management experience.  So in essence you have a product owner who is not empowered, not able to say no, and has no vested interest in the project being successful.

This is where I spend a great deal of my time trying to train product owners as they come and go in the organization.  I teach them how to write user stories.  I teach them how to write given, when, then statements to help the developers with test driven development.  I also try to help them navigate the weird world of technology as they are asked countless questions by the development team for situations they never considered.

I work with three product teams over two continents.  I also have two very different product owners.  I have to be respectful and firm to both of them.  I also feel a great deal of empathy.  They are working one of the hardest jobs in technology.  I also understand that I can be eccentric, mercurial, and a little tightly wound so their job is just a little more difficult.

So the next time you get cranky with your product owner; take a step back and think for a moment.  They are working in one of the hardest jobs in technology.  They are also working with you and your goofy technology team.  Show a little love and respect.

Until next time.

A Little Respect for the Scrum Master

I spend my days working with software developers and helping them get work done better, faster, and with higher quality than they did before.  This week,

Building software is not for the meek!

I wanted to take some time out and talk about why being a scrum master maters.  Technology is one of the hardest things in business to manage and it helps put things into perspective.

One of the key things everyone in technology needs to understand is that the ability to write code is rare skill.  For every thousand people working in accounts receivable, there may be only five able to write software which manages the accounting systems.  Because of relative scarcity of people with these skills, there is always too much work for too few people.  This makes business people testy because they are taught that customer service should be instantaneous and to be forced to wait for IT seems like a waste of time.  Often business people accuse IT departments of being lazy or non-responsive.

 Also many people outside technology think that putting together good working software code is as easy as composing a power point slide or an excel spread sheet; this is a gross misunderstanding.  So they see the eccentric people who develop software as detriment to the business.  Combined with how expensive software developers are to hire, it is no wonder that there is so much push for off-shoring.
 
The funny thing is that off-shore teams and no different than their domestic counter-parts.  A developer in India or Northern Ireland is just as rare as they are in the United States.  They are paid higher rates than their peers and make a very good living because they still very rare compared to the world population.  They are less expensive that American or European developers but they are still an expensive labor force.  They are also just as over-worked as their on-shore colleagues.

Now add to the mix a twelve or thirteen-hour time difference, child care concerns, and the cultural obstacles which obviously crop up between two nations and you have a recipe for disaster.  Fortunately, software developers being smarter than the average person have learned to deal with the obstacles and build software.  It is not pretty at times but the work gets done.

It is up to scrum masters to get development teams working together and efficiently.  We have to bridge the ocean gaps and make our off shore partners feel like they are making a difference.  It is up to us to put together a vision and then direct others to make that vision possible.

I was attempting to explain my job to others and it is hard.  Some people get offended that I work with off-shore teams because they think I am enabling the loss of jobs in the United States.  Others think that what I do is not real work because all I do is participate in conference calls.  The truth is that scrum masters who work with distributed teams are essential parts of the global economy.  We keep the projects going.  We make sure the software is delivered on time.  We keep the promises executives and sales people make to their clients each day.  It isn’t like being a nurse or a fire fighter but it is just as important.  

So if someone says they are a scrum master give them a little respect. They are the people who make sure the global economy does not collapse into a big ball of mud.

Until next time.

Some things every scrum master should say.

A scrum master should be like Gimli

As a scrum master, it is easy to get enveloped in gloom and doom.  You are removing impediments, trying to change the corporate culture and learning to work with people who think you are crazy.  Sometimes, I think that jousting with wind mills might be an easier line of work.  This week I want to talk about a few simple things you can say which will make being a scrum master a little easier.

Why Not?  

Many times a software developer will say something can’t be done.  It is your job to say, “Why not?”  Challenge people to defend why something can’t be done.  If they say it is process then ask them what the process is.  If they say they have not worked with a technology before send them to training.  If they are not getting cooperation from a product owner then it is up to you to escalate it to upper management to get that situation corrected.

More often you will get to the bottom of a deeper problem. For instance, someone said that we could not make improvements to software because the database was using outdated technology.  This spawned an entire project as upper management was alerted to the problem and decided to allow the team to fix it.  It took over ten months but now that development team is working with an up to date database.  The business is thrilled because the software is working ten times faster.  Upper management is happy because a series of customer complaints was eliminated and the developers are happy because we cleaned up a pile of technical debt.

Let’s try it out.

Software engineers love to argue.  They argue about technology.  They argue about politics and they love to argue about pop culture.  This means that most of your time with the developers is going to be spent listening and adjudicating arguments.  At this point of the day you are supposed to say, “Why don’t we try it out.”

Instead of arguing about technical issue, conduct an experiment and compare the results side by side.  We are software engineers, we should act like engineers from time to time.  Compare third party controls with each other.  Marissa Mayer when she was at Google famously ran fifty a/b tests to determine which color blue generated more click-thrus for an ad.  Microsoft is constantly testing new formats and ways to try and improve its product.  Even, Chevy is conducts testing to find out how it can improve its automobiles.

Experimentation is necessary and important as software developer.  You need to try new ways of doing things and try out new ideas.  Otherwise, you will become intellectually stagnant and become eclipsed but others who are willing to grow and develop.

What are we waiting for?!

Many people are afraid to take initiative.  The reason why is that they have been discouraged from doing so since grade school.  Too many people have been trained to ask for permission instead of doing what is right.  This type of conformity used to work but now it is an obstacle to meeting customer needs.  So when action is necessary, ask “What are we waiting for?!”

Asking this question provides a sense of urgency to the situation.  In addition, it helps the team outline obstacles and challenges early.  This way when development gets under way the team already has some mental preparation for what they need to do.

This isn’t an exhaustive list but try these phrases out and see if they help inspire your team and clear up conflict.

Until next time.

Fighting the Corporate Immune System.

The game of business can be crooked.

One of the most interesting things to come out of biology over the last century has been something known as the Gaia hypothesis.  The theory says that living things interact with non-living things in such a way that a whole ecosystem behaves like a living organism.  It has a lot of criticism in the scientific community and if correct could upset our ideas of natural selection. What makes it appealing to most people is that it conforms with our notions of belonging to an organic whole of life having a purpose on the planet.

If you could apply the Gaia hypothesis to an entire planet in theory you could narrow the focus to a work place.  This week, I want to talk about the immune systems that organizations develop when you are trying to lead change.  I stand by my assertion that the modern corporation is the last vestige of feudalism in contemporary society.  Notions of human dignity, intellectual growth, and making a difference are quickly subsumed by the petty power games of executives, the demands of shareholders, and the peer pressure of the others who share your cubical space.

This is a challenge for agile professionals because continuous improvement and accountability are major threats to executives who see their command and control structures threatened by people in taupe blazers.  The modern business has four major defense mechanisms.

Quid Pro Quo Behavior – 

This phrase means tit for tat.  It is often used during sexual harassment training to describe a sexual favor being traded for bit of career advancement.  For the agilest, this means that people in the organization do favors for each other and in doing so create a currency.  This currency is bartered around the organization and it used to get work done and cover up malfeasance or laziness.  As long as the Quid Pro Quo behavior is not discussed or exposed it will continue.

Social Networks – 

Spending time with people develops bonds.  Friendships with develop and they become a kind of armor against people who want to change things.  A project manager with a close friendship with a department head can get away with plenty of bad behavior to subordinates.  The relationship cultivated will trump the duty of the department head to hold that individual accountable.  So pointing out the misconduct is really threatening your credibility as a person to that department head.

Not invented here – 

Plenty of organizations consider their processes to be unique to their businesses, so anyone who suggests that accounting behaves the same way regardless of the product produced will be treated like a heretic.  Worse these people might be treated like someone “…who isn’t being a team player.”  To suggest that methods of doing things have been tested and true in other organizations, is undermining the uniqueness and authority of the organization you work with.  The change agent will be cut off and eventually removed.

Tenure –

In some organizations the only way to get ahead is to stick around and put up with drivel until someone retires and you are promoted in that person’s place.  What this does is encourage group think and lack of risk taking because the way you move up the organization ladder is to avoid calling attention to yourself.  Thus, the least innovative, curious and creative people make decisions.  It is the reward of the bland and boring.

So this week think about these four pieces of an organization’s immune system and how as a change agent you can work around them.

Until next time.

The Drivel in Your Office

It looks cute and adorable but the by-product
of a bull and grass might be cluttering up your office. 

It is good to be back on the blogosphere.  I took a week off because a combination of personal and professional pressures made it hard to get anything done.  I have been finding it difficult to do any writing of a meaningful nature.  This week, I want to talk about the little things that add up and make you miserable in the office.

One of the common things office workers describe in great detail is called the spiral of rage.  In short, little annoyances pile up which are outside your control.  An office printer low on ink, combined with no coffee at the coffee pot, an irritating co-worker and unrealistic deadline pressure combine into an explosive and combustible mixture where you are a helpless passenger in your angry body.  We tend to trivialize these emotions and call them first world problems but to people in the cubical near you they are very real.

These problems impact productivity and the happiness of the people in the office because they illustrate the lack of control, empowerment, and authority they have earning a living.  They can’t pick up a phone and ask for help because there are too many layers of corporate bureaucracy between them and the person that can fix the problem.  What makes this more maddening is that the person who can fix the problem is a few desks down but is powerless to help without an e-mail from someone at the corporate office.

I call these situations “drivel” because it sounds sophisticated and it is more professional than the term my father uses for the by-product of grass and a bull.  In Harry G. Frankfurt’s essay “On BullS#%t”, he says that “drivel” is not lying but rather the use of language to obscure.  The contemporary office is filled with “drivel” and it is up to us as scrum masters to deal with it so our people can concentrate on work.

I find that most “drivel” is caused by the toxic mix of lack of authority and the devious application of authority by others.  For instance, that co-worker who can’t help fix the problem is overworked with numerous requests so they use the e-mail from corporate as an excuse not to help.  That person may also use that alibi to spend some time looking up train sets online or day-trading stocks.  The situation makes you feel equally powerless to do your job.

Another situation comes to mind when I was an entry level programmer at ServiceMaster.  Robert Pollard, the CEO, had just asked the office to go to business casual.  He still wore a bow tie to work.  Many of the executives continued to ware dress shirts and bow ties.  When promotions were announced, the executives who wore bow ties were advanced over those who did not.  It was a sick game of copy-cat but the message was loud and clear.  If you wanted to advance in the organization you needed to ware something other than business casual.

So “drivel” instead of shipping product guides your business.  It is aggravating but it is something that every scrum master needs to deal with and I am looking forward to hearing from other scrum masters about how you deal with it.

Until next time.

Agile and Scrum Prevent You From Cutting Off Your Own Hands

You can learn a lot about software from a table saw.

Over the weekend, my father and I collaborated on a woodworking project for my home.  As I have grown older, I appreciate the time I have with him.  Over the last seventy years, he has acquired plenty of wisdom.  He likes to share it with me from time to time.  This week I want to share my father’s wisdom with you.

We were working with a table saw constructing a gaming table for my house.  I am intimidated by power tools.  I am afraid of injuring myself or someone else.  My father said, that my fear was justified but I needed to get comfortable with power tools because, “It isn’t any harder than writing software,” he joked.

After a few hours on the table saw, my father mentioned, “We have plenty of wood son; you only have two hands,” At this moment, I realized this bit of wisdom also applied to software and Agile.

Too often, software developers are trained in isolation learning to work by themselves.  They do not learn to work with others and once they basics are mastered they develop their own “style” of programming which is often incompatible with other programmers.

You also do not see formal training in Test Driven Development and debugging code.  I realize now this is like not warring safety goggles when you are using a power tool.  The “commando code” style many developers learned needs to go away because when something goes wrong it really goes wrong with that style.

Unit tests make sure that if a class changes and functionality is disrupted a developer can find and diagnose the problem.  Otherwise, it could take hours to track down and fix the problem.  Source control systems such as Git and TFS exist to make sure everyone is working on the same code set.  This prevents one developer from overwriting the changes of another developer.  Finally, design patterns like SOLID, make sure that developers have a common reference point to discuss the architecture of software.

As a junior and intermediate developer, I rebelled against these practices.  Now that I am a senior developer and scrum master, I embrace them.  My career is testimony to this change of heart.  I have broken software builds, destroyed production servers, and over billed numerous credit cards.  The results of this carelessness were long bouts of unemployment and financial hardship.  To put it mildly, I have figuratively cut off my hand more times than I can count.

So to my fellow Scrum Masters and developers.  Slow down there is plenty of wood but you only have two hands.  It is advice, I should have followed years ago.

Until next time.

The Postulates of Impostor Syndrome for the Scrum Master

We are not impostors under a mask!

When I think about it, I do not consider myself a successful person.  I have an average home.  I drive an average car.  My one extravagance is my collection of compact disks and the toy soldiers which bring me joy.  I am not one of the rich and famous.  I am just an ordinary person who when I die will have my name forgotten just like many other people who came before me.  This kind of realization makes me sad.  I am one of the many unwashed masses of people.  These are the facts as I understand them and they are woefully misguided.  I suffer from what authors Pauline R. Clance and Suzannne A. Imes call “impostor syndrome.”  After a week away from work and some reflection, I wanted to write about it.

The best definition of impostor syndrome I can find online comes from Forbes magazine.  In short, a person with impostor syndrome feels like they are going to be exposed as not being smart, talented, driven, and competent enough to be doing what they are doing.  It is that little nagging voice in the back of their head which says, “Who are you kidding.” It undermines your self-confidence and your ability to do the work you are doing.  It is what David Foster Wallace would call a Darkness which is following you around.

In the business world of continuous improvement, six sigma, and agile impostor syndrome is about as common as post-it notes.  The reason why is that for many people in that world we are open to and provide criticisms and critiques of each other’s work.  We can always be faster, smarter, and better communicators.  Sometimes, this generates soul crushing moments of frustration and futility.  Nothing is worse than being told you could have communicated something better when you send out 10 e-mails daily, speak to people personally twice in a day, and have a white board filled with information for upper management to read.  It is almost like they want me to sit on their chests like a hungry cat wanting to be fed on a lazy Sunday morning.

I think something deeper causes us to feel like we are impostors.  Human beings are pretty complicated things.  Over the last four hundred years we have done a pretty good job understanding how bodies work, but we are still struggling with understanding how our minds work.  We are not computers who all run code the same way.  We are complicated puddles of emotions, memories, and experiences who if we try hard enough can be rational thinking beings when the need arises.  This is why it is hard for me as a scrum master to be upbeat and positive all the time; sometimes the Darkness wins.  After some thought, on the matter I broke this down into four things which foster these feelings of being an impostor.

Consider these to be Wisniowski’s four postulates of Impostor Syndrome.

The Outside Image

As early as middle school, a professional is taught to dress and act a particular way.  While other young people get tattoos, piercings and are looking to have hair colors that do not occur in nature; the larval professional is told that they must act, dress and behave in a certain way to be credible for others.  This learning process creates what is known as a mask of command which other see but hides your true self.  This personal branding and quest to build leadership presence is not a natural process for most people so it creates a kind of cognitive dissonance where professionals are afraid that someone will penetrate their mask.  The situation is still not as bad as during the mad men era of the late 1950’s and early 1960’s but it is still there.  Just ask yourself when was the last time you saw a banker without a neck tie at the local branch.

The Inner Turmoil

Every human being is the sum of their experiences and not all of these experiences are good.  Each of us have suffered from failure, heart break, frustration, and disappointment.  This undermines your self-esteem.  The trouble is that in the business world you cannot be emotional because being emotional is a sign of weakness.  Thus, these feelings are buried and over time if they are not addressed they can manifest themselves in harmful ways.  In the quest to be strong, we undermine our own health and mental well-being.

The first two postulates of impostor syndrome cover what can be controlled by the individual.  The last too are outside of an individual’s control.

Our Public Reputation

Every professional is concerned about his or her personal brand and how others see them.  Around the office we all know people who are the ones who drink too much, who over share their lives, and who smell like feet.  To be a successful professional, we want to be perceived as the one who is hard working, knowledgeable, and able to take difficult projects and succeed.  The trouble with this is, try as we might to cultivate a positive reputation, it is out of our control.  Other people control our reputation because it is a product of our actions and the perceptions of others who see our actions.  One person’s hard worker is another person’s suck up to management.  The person who is fashionable to one co-worker is another person’s dressed inappropriate for the office.  Because of this lack of control, we try even harder to influence those opinions because a negative reputation could affect our career.

Our Personal Misconceptions

Finally, human beings are evolved creatures with emotions and an unconscious mind.  Cognitive science has shown that our unconscious mind can deceive us.  It has been shown that people suffering from Anorexia look at themselves in the mirror and have very different perceptions than people who do not suffer from the disease.  People with impostor syndrome reflect on their appearance and achievements through the same kind of distorted lens.  We did not graduate from school because we worked hard.  We did not earn the career success we have.  We see it as luck or the intervention of others.  Thus, even though the facts of our lives may say otherwise; our unconscious minds and emotions trick us into thinking that we are somehow faking it through our careers.

So those are my postulates about impostor syndrome.  I have been thinking about this lately because being a scrum master is to live with self-doubt.  You could always be better, more efficient, and able to handle more.  The reality is that sometimes you need to accept yourself warts and all and do the best you can.  I look forward to hearing what you have to say about this and how it applies to your work as an agile practitioner or scrum master.

Until next time.

Sharpening the Saw for the Scrum Master

Even a chain saw needs to be sharpened.

Being a scrum master is a calling.  It isn’t like being a catholic priest but is certainly is a calling because you are leading change in your organization.  It is not easy and it requires a bit of missionary zeal.  Because, if you are part of a business reformation it is going to require a level of commitment not typical in most cubical dwelling workplaces.  Having priests and nuns in my extended family, I always wondered why they went on retreats.  This week, it dawned on me why and I wanted to share my thoughts on the subject.

In the book, “Seven Habits of Highly Effective People” one of the seven habits they suggest is known as sharpening the saw.  This is what author Stephen R. Covey calls the opportunity to take a break, train and learn new skills because if you do not you will be like a saw which is over used.  After a while the blade will dull and it will be unable to cut anything.  So highly effective people take time to read, learn new things, and relax.

Since working as a member of a religious order requires incredible people skills, hours of listening, and zero compensation; the risk of burn out is very high.  This is why I think the retreat came into being.  It is a chance for priests and nuns to be among their own kind.  They share stories.  They pray.  They spend time away from the people they are supposed to be serving.  It is not just about the religious mission of these people.  It occurs to me that it is a necessary survival tool in order to do their jobs.

Being a scrum master is one of the hardest jobs in technology.  You are a servant leader of software developers who are notoriously hard to lead.  Contemporary business culture is still struggling to integrate the message of the Agile Manifesto and the principles of agile.  Business leaders expect agile to work in organizations without training their people or hiring people to work full time as product owners.  It is exhausting.  For every success, there are countless failures and you are always expected to be upbeat and willing to continuously improve.

So this week, I am going to take some time to sharpen the saw.  I am going to clean my house, read a trashy pulp novel, and go to a museum or two.  I might even binge watch a few episodes of Dr. Who in order to prepare for the new season.  I am taking my retreat.  I suspect that it is just what the doctor ordered.

Until next time.

Scrum and the Five Dysfunctions of a Team

Teamwork is not about Dysfunction.

From time to time, the vice-president of your organization wants to speak with you.  In my experience, they usually ask me to pack up my desk and leave the company.  Currently, that has not happened at my current firm.  So I am sure you can imagine what I felt when I was called into the vice-presidents office for a brief discussion.  After the heart palpitations subsided, I was given a homework assignment and it has been one of the nicest things an executive has ever done for me.  This week I want to share with you what I learned.

Patrick Lencioni, and his book “The Five Dysfunctions of a Team” wound up on my reading list thanks to a healthy recommendation by my vice-president.  In the book Lencioni talks about a mythical tech-company and a mythical CEO with some very real world problems.  The executive leadership is fighting, they are not making many sales and the corporate culture is toxic.  Something has to be done.  This is when the mythical CEO steps in and starts training the executive team.

During this training the CEO outlines the five dysfunctions of a team and how to cure them:

• Absence of trust
• Fear of Conflict
• Lack of Commitment
• Avoidance of Accountability
• Inattention to Results

What makes Lencioni’s book so good is that he treats the training of this mythical executive team in a realistic way.  Some people do not buy in and others pay the dysfunctions lip service.  It is only when people start quitting and getting fired that things start to get real and behaviors start to change.  The pressure of working in the tech-industry also helps mold these people into very different leaders by the end of the book.

I really like this guide book about the dysfunctions and what can be done to cure them.  I highly recommend them for my fellow scrum masters.  Still I could use some help, how do I trust people who have violated my trust?  How do I work with those who avoid accountability?  Finally, how do I work with people who refuse to show vulnerability when it comes to work?  I do not know the answers but at the very least Lencioni’s book helps me understand some of the questions.

Until next time.

Change Happens, Damn it!

Change is never easy.

This week I experienced tremendous change in my agile team.  A technical profession was made an offer they could not refuse and they left my development team.  It was bound to happen sooner or later but I was not expecting it so soon.  It made me think about many things and put into perspective the last part of the agile manifesto which is responding to change over following a plan.  This week I want to talk about change and learning work within it.

I have mentioned the philosopher Heraclitus said, “No man can step into the same river twice.”  This pre-Socratic philosopher could be considered the intellectual god-father of Agile because a central portion of his philosophy is concentrated on change.  Other philosophers have discussed change, but Heraclitus was the first so he has a special place in my heart.

The initial founders of the agile movement when they created the manifesto were also concerned with change.  The world of technology changes too quickly to use old methods of software development.  When President Obama took office there were 150 million Facebook users.  Today, that figure is at over 1.1 billion.   The only way that Facebook could accommodate that kind of growth was revise how it did things from publishing code to managing its servers.  It takes an army of very smart people but Facebook has been able to do it because they have been able to embrace change.  This is why the web site can accommodate the blind and have over 50 different designations for gender.

Human beings evolved intelligence in order to better adapt to change however since we are evolved creatures we still have some more primitive traits in our behavior which makes it hard for us to accept change.  This is why Spencer Johnson made so much money with his book “Who Moved My Cheese?”  In the book he creates a modern fable about two mice named “Sniff” and “Scurry” and how they respond to the cheese in the maze they work in being moved.  Once he is done with the fable, Johnson sets about some concrete examples on how to deal with change in an organization.  The book was an instant smash and inspired a parody called “Who Stole My Cheese.”  I like both books.  I enjoy the original because it has some practical guidance about change and I enjoy the parody because it is a necessary to point out that change management never works in corrupt or greedy organizations.

As an agile professional, you are going to have to deal with cheese being moved and being the person moving it for you agile teams.  For instance, I was in a meeting and an executive was issuing orders on how we were to name things in the backlog.  Everyone in the room smiled and nodded like sycophants while I was openly frustrated.

“What’s wrong, Ed?” the executive asked with the empathy of a hangman.

“My cheese is being moved,” I replied throwing my pen down on my note pad, “I have been trained to name these things a certain way for six years and you expect me to change overnight by fiat,”

It was hard but now I have embraced the change and now I find myself correcting other people in the office when they do not name things in the same manner as that executive.

Change is not easy but admitting you have a problem with a type of change or the pace of that change is a step closer to embracing it.  You can then rationally step back and learn to work with that change in your situation.  Sometimes that means changing your behavior and other times it means changing how you do something.  In a world of constant change, you either adapt to those changes or you will be left behind.

Until next time.

The High Stakes Poker Affecting your Agile

Business is not like poker,
but many in leadership think it is

Before I worked as a technology professional, I worked in a casino as a pit boss.  Each night, I would see fortunes come and go based on the flip of a card or the fall dice.  It made an indelible impression upon me.  I met plenty of fantastic people and I also learned a great deal about myself and leadership.  Some of the lessons I gained on the casino floor still linger with me.  This week I noticed something as stocks were falling and the business news was discouraging, business leaders see what they do in the same high end poker players play their game.

When you watch poker on television it looks glamorous and sophisticated.  The reality is much more pedestrian.  What looks like two hours of key decisions is really six to eight hours of grinding action punctuated by a few interesting hands.  The producers of these poker programs make sure that the action is properly edited for television.  Getting to the final table is also a marathon which could last a week sitting grinding out hands of poker eight to ten hours a day until the final eight players are left.

Many of the people who are in senior leadership positions are like those poker players.  They are survivors of your corporate culture grinding out their positions by taking calculated risks when necessary and sitting out a majority of the action.  They are not innovative or creative people by nature.  They know when to bluff, bully, and calculate the odds when they have a promising looking set of cards in their hand.  They also understand the old adage, “If you can't spot the sucker in your first half hour at the table, then you ARE the sucker.”

This is why it is so hard for agile initiatives to happen at some organizations.  The constant experimentation, transparency, and risk taking necessary to innovate are an anathema to people who have spent their entire careers keeping their metaphorical cards close to their chests.  Poker is also a zero-sum game where there is always a winner at the table and a loser.  Someone succeeds and someone fails or gives up.  This gives failure an additional stigma which is something that business leaders which to avoid.

Agile is about the opposite of this kind of mind set.  It resembles a bunch of grown people playing with Lego pieces rather than a serious high stakes card game.  It requires creativity which many people find alien and scary.  Finally, it means trust and transparency which is the last thing you will ever find at a poker table until this last card is turned over.

So if you are leading an agile effort go to your local poker room and take a look at the players around the table.   The reality is they are going to look much like the business people you are going to have to convince to try a new way of doing things.

Until next time.

Are these factors holding back your agile adoption?

When the emperor has new clothes we need to speak up.

Once in a while I see something and it inspires me.  I get fired up and feel like ranting into the night like some kind of crazed deviant looking for windmills to joust.  This week I had one of those moments and it steeled my resolve.  I am an Agile professional and I want to help change the way people work.  

It all began when I read a fantastic blog post from Isaac Socolick, talking about Legacy thinking versus Agile thinking.  This got me thinking.  It has been fifteen years since the agile manifesto and plenty of business organization are struggling to adapt to the new paradigm of how business works.  I have been part of this effort for the last six years.  Why is change so difficult for these organizations? I have a few hunches.

Legacy Funding of projects-

At large organizations products are funded on a limited basis.  Teams are funded, spun up and then they are wound down once the project is completed.  This is a standard water fall approach.  Once the project is completed then it was folded into the support stack of the organization to be forgotten.  No consideration for Net Present Value is made.  Often input for what the customer wants is ignored and the project is seen as a test for a project manager or executive who wants to advance.  Finally, the process is managed not by operations people who understand the business but by accountants and CPA’s who understand pushing money around the firm.  So projects are funded with a thrown together team, with a defined deadline, and with limited input from the customers.  No wonder projects fail so often in corporate settings.

Quid Pro Quo behavior –

I have mentioned this before in this blog but bureaucratic organizations are organized around rules and favors.  The rules are covered by regulatory compliance and common practices in the organization.  Favors are people deliberately circumventing those rules in order to accomplish something.  This sets up a system of favors which makes the Tammany Hall politicians of the nineteenth century look like pikers.

This forces business leaders to trade favors with each other to accomplish personal and business goals.  Many of these favors happen under the noses of leadership because to expose these favors would open the firm up to scrutiny from regulators or worse upper management.  So what happens is a “Tit for Tat” or Quid Pro Quo culture were executives do favors for each other rather than focusing on the customer.

Ego Driven leadership – 

Since Lee Iacocca took Chrysler in the early 1980, a new kind of business leader has emerged.  This was the business person and celebrity.  They were in the company commercials.  They spoke for the company when asked to testify to congress and they behaved like monarchs running their business empires with imperial control.  Unfortunately for every, Lee Iacocca there were numerous failures such as Carly Fiorina, Al Dunlap, and the most infamous Ken Lay who transformed Enron into securities fraud and criminal organization.

People seeing this trend in business decided to jump on this bandwagon.  These executives in training began worrying about their own personal brand rather than how they were going to run the business.  They discovered with a few accounting tricks they could cover up, poor sales, a lack of customer service and poor innovation.  They further burnished their credentials by leading legacy style projects which improved their brand but did not help the business.  Developers have had a name for this for years, they call it "ego driven development".  Well ego driven leadership is the byproduct and it is hurting businesses all over the world.

I got involved in Agile and the reformation it is leading in business for six years.  I have the enthusiasm of a new convert but I know that trends like the above are going to hold back the necessary progress which we are trying to achieve.  We need to expose these obstacles in order to remove them.

Until next time.

How my agile is changing.

Those of us in the agile community spend a lot of time talking about building software and helping our business partners.  What I have discovered over the last six months is that for a large organization like mine agility is a relative concept.  What I am discovering is that the business is struggling to keep pace with the developers.  This week I want to provide a few helpful tips to explain how you can help your pals in the business keep up.

Have a release plan – 

Software projects in my organization have a budget along with a beginning, middle and end according to the executive leadership.  To the suits at corporate, they don’t know or care about sprints, iterations, and burn downs.  So we have been forced to come up with a bridge document between the backlog and what the leadership expects.  This is the release plan.  Since my leadership does not understand the terms epic, theme and story; we substituted the words milestone, feature, and story.  This made it easier for the executives to follow along.  In our backlog we organized everything by milestones then placed features under them and finally had stories under those.  What happened was a revelation.  The business owner knew what was expected to be completed and then wrote stories to accommodate that structure.  Sprints were now planned around delivering features and we were doing better at delivering what the business wanted instead of what the business owner wanted.

Metrics –

Professional athletics is concentrated on metrics.  How fast you can run.  How high you can jump.  How many interceptions you throw during a football game.  The game of metrics has been transformed by the practice of sabermetrics and “Money Ball.”  Development which is done primarily by engineers has been very poor at measuring performance.  This is why I have started to measure the team velocity in story points.  I am also comparing the amount of work scheduled versus the capacity of the team.  This provides the team with positive reinforcement along with upper management a way to gauge how we are doing.  I will also be doing more advanced things like comparing bugs with velocity and understanding if we have good code quality compared to team morale.
 

Developer and Scrum Master training –

I find it interesting that we are working on software which runs the business but the developers and scrum master do not know a lick about the business.  That is changing.  I am spending about 90 minutes a week learning the business with people on the front line.  This training will become a training program for all the developers on the team.  Each of us working on the project should be competent enough to work as an entry level employee using the software.  This is a new experience for me and my developers.  I don’t know why we did not think of it sooner.

Tender loving care for the business owners – 

My organization has had a spotty record with business owners.  They have taken a training course in how to be product owner and then they have been left to fend for themselves with little direction from their business units or help from the scrum teams.  I have made a point of each business owner I work with giving them a copy of Roman Pichler’s fine book “Agile Product Management with Scrum.”  I also spend time with them helping them groom stories so that the developers know what they are doing and can deliver that in one sprint.  I help them tie stories into the release plan.  The product owner has one of the hardest jobs in an agile organization.  Your scrum team will not succeed if the product owner doesn’t.

The most important part of the agile manifesto is to adapt to change over following a plan.  Well we are changing and this is how we are doing it.

Until next time.

Getting inside your bosses head.

Your boss isn't that bad once you understand them.

As a software developer and scrum master, I have a unique perspective on the world of business.  I am a highly skilled and compensated professional.  I also have had the misfortune to experience the uncertainty of the gig economy, and the abusiveness of contemporary project management.  It took a serious toll on my physical and mental health.  It also pushed me to set up my own business and become part of the agile reformation.  This week, I want to talk about the pressures that our business partners are going through each day and how we techies can help them.

There are two contemporary stereotypes technology professionals have about their bosses.  One comes from the Mike Judge movie “Office Space”.  The boss is Bill Lumbergh, he went to the correct business schools and says all the right things but it is clear he has no understanding how the business works.  In addition, Lumbergh’s leadership skills are of the color by numbers variety which inspires zero confidence and undermines initiative. The other which comes to mind is British television series “The IT Crowd.”  This boss understands the business.  She also has great leadership skills and seems to be able to work with her colleagues but her major fault is that she doesn’t understand a thing about technology and the two technology professionals which work underneath her.  This makes the show very funny as her employees Roy and Moss make a mess of the corporate infrastructure.

The reason these two stereotypes are so popular in entertainment is that they are very common in the business world.  I spent many years of my career working with poor leaders.  This makes working with the good ones very inspiring.  I have noticed these people both good and bad have similar characteristics and are under similar pressures.  Fortunately, Paul Glen wrote one of the better books on technology and leadership called “Leading Geeks.”  He outlined the differences between people who work with technology and the people who lead them.  His thoughtful insight changed my perspective and made me a better developer.  It also made me a better leader.

Glen says that leaders have several characteristics:

• Leaders get paid to influence others
• Leaders see being likable as a key to success
• Leaders care about the product.
• Leaders care about the destination instead of the journey.
• Leaders see technology as a part of commerce not as something with a value all its own.

When I saw this bit of wisdom, it changed me.  To me, the technology worker, I was judged if my code worked in production and was reliable.  My boss was judged on how they can influence others to write that reliable code.  I have known countless developers with autism spectrum disabilities or poor attitudes but they were always retained in the company because their code worked.  These people received more perks and authority because they keep the business running.  A boss is very much like a teen-ager in the high school cafeteria. They have to make friends with the right people at the right time in order to further their careers.  So being likable is a necessary survival skill.

Developers are process focused and see the creative process of writing code as rewarding.  Leaders do not.  They want to see working code in production and software products which solve particular business problems.  They are also under time and budget pressure so they are constantly asking about status updates.  Finally, technology people love technology for its own sake.  Most business leaders see technology as a tool to be used.  This is why when showing off a piece of software developers are more deferential to their peers than a business owner who would not hesitate to call something a “piece of junk.”

These are the things which make your boss different from you.  The time, money and social pressures of leadership at a major business changes people and their perspectives.  You will be a better developer and agilest if you understand these differences.  This way you can help your boss become more successful and in turn you can earn some success along the way.

Until next time.

No More Heroes - Why?

Their is a difference between fast and agile.

I hit a nerve last week with my blog.  I spoke about the quite heroism that goes into keeping the global economy running.  It was greeted with a great deal of enthusiasm but I also received some push-back.  Someone I respected, Geoffrey Dunn, mentioned that he didn’t want to work for firm which expected heroism from its employees.  He preferred boring work days punctuated with routine successful software releases.  He even put together a hashtag stating that we need #nomoreheroes in the world of software development.  After some thought, I realized he had a point.  The global economy must also be sustainable where heroism is not necessary.  

One of the most important principles of the Agile Reformation is:

Agile processes promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely.  

I think that this is one of the most overlooked principles of agile.  Work that requires attention to detail, creativity, and intellectual muscle power just isn’t successful when it is being rushed.  Psychologists, describe a period where we are most productive as a state of “flow.”  This is a state where we have focus, and complete immersion in what we are doing.  It typically requires being well rested, limiting distractions and having the opportunity to do something which is intrinsically rewarding. 

Sadly, most companies do not see software development and technology as a “force-multiplier” for their business but as a cost center to be controlled.  Thus, they try to jam as much software development into as little time as possible with employees they consider expendable.  The worst example of this is in the computer game industry. “Crunch time” and “death marches” have become synonymous with software development because many people who control businesses is have no understanding how software is built and who does the work. They just think software is magic that can be conjured up in a moment’s notice. The reality is that human beings require sleep, food, clear goals, and empathy to accomplish goals. 

The global economy is moving very fast.  So fast that it is hard for business people to stay ahead of the decision curve.  This means they make unrealistic demands on the people who help keeping the business running; the software developers and engineers.  This is why they are being asked to work long hours.  This is why they are under so much pressure.  It is also why there is so much desire for outsourcing and contract workers because in a “gig economy” workers need to be added and removed from projects at a moment’s notice.  

I want to argue there is a difference between fast and agile.  A fast workplace grinds out work at a blistering pace but it may be of questionable quality and utility.  An agile workplace delivers on a constant basis and it is high quality and provides value to the business. A fast workplace burns through its employees like they are fire wood.  An agile workplace treats its people like the skilled artisans and helps them grow and develop.  A fast workplace is moving quickly but has no idea where it has gone and where it is going.  An agile workplace knows where it has been and where it is going to go next.  When plans change they easily make changes.  A fast company will crash in a spectacular way and then make a course correction.  

I agree that companies should have #nomoreheroes.  If firms are led correctly and with attention paid to more agile means of doing business success should be a routine activity rather than the result of heroism.  

Until next time.