A Little Empathy Goes a Long Way

Empathy is a big deal.

As a scrum master, one of the most important qualities you can have is empathy.  It is a special quality where you can put yourself in someone else’s situation and understand the world from their perspective.  It means operating outside your comfort zone.  Today, I would like to discuss the importance of empathy for a scrum master.

Working for a large organization is hard.  Employees often feel alienated from their work and coworkers. I think a significant reason for this situation is many people in leadership roles do not understand what it takes to provide the goods and services their organization offers.  These leaders are good at managing budgets and capacity but little else. It is where empathy matters.  As a leader, you need to walk a mile in another person’s shoes.  If a leader cannot do that in reality, then they must attempt the thought experiment to see the world from the perspective of the employee.

When a leader sees the organization from the perspective of the people interacting with customers several changes take place.  First, they see the people doing the work as people instead of resources who are disposable.  Next, they understand the systems and equipment the employees are using might not be meeting the needs of the customers.  Another by-product of this exercise is leadership understands how long it takes actually to build something.  It gives leadership insight into which deadlines are real and which are fiction.  Finally, leaders discover which activities generate value and which ones do not.

Early in my career, a mentor I respect said I should never order a person to do something I would not do myself.  I still follow those directions today.  It is why I go to meetings, so my coders get a chance to write software.  It is why I fill out expense forms and project requests; so the people doing the work do not have to do it.  It is part of the servant leadership I try to practice each day. So have some empathy for the people who work for you.  You will be surprised by what you might discover.

Until next time.

The fight against alienation is real

Don't inflict help

Any time a professional person attempts to change an organization they belong they are going to face a backlash.  Socrates would argue that this kind of behavior was the product of ignorance.  The philosopher would say once people knew the difference between objective right and wrong, people would choose right.  It was an optimistic view of human nature and one which is non-existent in the contemporary office.  Business people can be nasty, cruel and brutish as Thomas Hobbes would call them in “The Leviathan.”  A business person can exhibit the manipulative insincerity of Machiavelli’s “The Prince.”  Worse of all, professionals can exhibit the traits of the “Ubermensch” running roughshod over the “last men,” as Nietzsche would call them.  Backlash, is natural in human progress and it is up to coaches and scrum masters to address it.

Fear and uncertainty dominate the contemporary office environment.  Lots of factors are to blame for this state of affairs, but the principal factor is the shareholder value postulate of business.  In this postulate, shareholders or investors are the most important constituency in a corporation.  Customers, employees, and communities which also rely on the corporation receive secondary treatment because they are not as important as shareholders.  It is how we have educated a generation of business leaders since the 1970s.

Combine this trend with the deregulatory actions of the conservative movement, and you have a recipe for sterile and exploitive work environments.  It does not matter if you are blue collar, white collar or in service industries you are generating wealth for others with little upside to yourself.   Karl Marx called this the “labor theory of alienation.” It is one of the few things which Marx has written which has held up to scrutiny over the years.

So the agile coach is often in an environment where people are alienated.  People work hard enough not to get fired but not too hard because they will be singled out for extra responsibility with no subsequent increase in pay or authority.  The “company way” keeps a person paid and provides a modicum of security.  It is a miserable and uninspiring way to work.  Thus, the coach or scrum master is fighting on three fronts.  The coach must address the apathy of individual team members.  Next, they are changing the perspective of managers who often benefit from the alienation of the workers they are supposed to serve.  Finally, inertia in the organization acts as an easy alibi to resist organizational change. It is frustrating.  You are hired by organizations to help them change, and they actively oppose the change.

What I have discovered over the last few weeks is organizations want to improve; they do not know how.  Companies need scrum masters and coaches to help them.  They are looking for individuals to offer help rather than inflict it on the organization.  Often a scrum master acts as a therapist or pastor to an organization.  A coach needs to practice non-violent language and help others find solutions rather than dictating those solutions.  It is not easy, but anything worthwhile is going to be difficult.  Backlash is natural and it is up to the agile community to turn it back on itself to effect real change.

Until next time.

Agile Exposes the Bad Boss

A bad boss is just toxic.

I was getting on an elevator at the office and I decided to make small talk with someone as we were heading up to our respective floors.

“Ready to set the global economy on fire,“ I joked.

My fellow traveler got a gleam in their eye and said, “The flames are so colorful.”

I got off on my floor and breathed a sigh of relief.  The metaphorical pyromaniac was too eager to be pulling my leg.  The experience brought into stark contrast how tired many of us have become in the business world. The daily frustrations of working in a modern office force many professionals into the cynical behavior of inflicting harm on others as a means of satisfaction.  It is perverse, and it is wrong. The cynicism in the elevator is one of the reasons I have been such an enthusiastic proponent of agile.  I firmly believe there must be a better way to structure work so that it is sustainable, sane, and satisfying.

Inc. Magazine and Monster.com pointed out this week that 76% of bosses in business are “toxic.”  This toxic leadership is why so many people rely on jaded cynicism.  It is crucial as an agile coach and scrum master to break this cycle of toxicity.  According to the article in Inc. magazine, a toxic boss exhibits some or all of the following traits.

1. They are power-hungry
2. They micromanager
3. They are absent
4. They are incompetent

It is up to people like me to expose these bosses to the organization and coach them to be better.

The Power Hungry

Working for a power-hungry boss is a little like being a supporting cast member in Game of Thrones; you are going to wind up suffering a cruel ending to satisfy someone else’s ambition.  It surprises me how many business leaders think servant leadership is similar to the game “Masters and servants.”  The reality of servant leadership is much different.  In the end, what everyone needs to understand is a power-hungry boss is concerned about one thing; themselves.  A power-hungry boss will put personal interest over the needs of the company and employees.  Agile exposes the power-hungry because they often become impediments to shipping solutions.

The Micromanager

The hardest part of leadership is the lack of control we have over our fellow humans.  A leader can spend years training people to do the right thing and meet a certain performance level, and they can still disappoint at critical junctures.  To combat this helplessness, managers create processes and steps which they expect people to obey like robots.  It creates an illusion of control where employees do what they can to avoid hassle rather than what is necessary to succeed.  Thus, reports have perfect typography and proper tab spacing, but the data within that report shows lead conversion is falling.  The emphasis on working solutions instead of comprehensive documentation in agile should expose micromanagers.

The Absent

Over the years, we tell countless stories about military leaders who “lead from the front,” instead of from behind a desk.  I am currently reading one about William Slim who commanded the 14th Army of Burma during the Second World War.  It is easy to get caught up in the trappings of authority.  In an office of cubicles, having your office is a status symbol.  It gives you the power to shut people out and focus on administrative duties.  The autonomy and control over who has access is a powerful motivation for people to advance into leadership.  In reality, a leader has to be more visible to the people they are leading.  A leader should know about the people who make them successful.  If the leader is not around and they become distant figure the people who make them successful will ignore them in time of crisis.  Agile attempts to counter this kind of toxicity with its emphasis on face to face communication.

The Incompetent Leader

A leader should not be able to do your job, but at the very least they should understand what it takes to do your job.  What I have discovered over the years is people who have never managed a computer network or written a line of code often lead technology teams.  These people know how to manipulate budgets and control the project, but they do not know how to direct technology professionals because they think they are no different than shipping clerks or factory workers.  Agile with its emphasis on cross-functional teams and delivery exposes the incompetent.

I am a big believer in the idea that you should tell and expose the truth wherever you find it.  Sooner or later, someone in a position of authority is going to act on that truth.  I feel this way because it is how we defeated leaded gasoline and paint.  It is how we have reduced smoking in the United States by half since 1964.  It is an approach which led to the birth of agile.

If we are honest with ourselves, we should acknowledge the power-hungry, micromanagers, the absent, and incompetent and expose them so their toxic effect on the workplace can be mitigated.  It matters, and if we are not successful, all we can do is watch the pretty colors as the world burns.

Until next time.

A lack of skin in the game for employees

From the blog: ON ART AND AESTHETICS

Last week I talked about three types of cultural factors which can make an agile implementation challenging.  I also spent some time catching up with some of my contemporaries discussing the application of Agile at different firms.  It was a disappointing discussion.  This week I want to talk about agile and the lack of follow through in many organizations.

I started thinking about the inability for the organization to improve their agile maturity when fellow agilest David Koontz posted an article from the Harvard Business review about the failure of digital transformation at many firms. It opened my eyes.  I then noticed a new book published by the author Nassim Nicholas Taleb called “Skin in the Game,” about the uneven relationships we create in the labor market.  The most telling passage was the following.

“True, a contractor has a downside, a financial penalty that can be built into the contract, in addition to reputational costs. But consider that an employee will always have more risk. And conditional on someone being an employee, such a person will be risk-averse. By being employees they signal a certain type of domestication.”

In short, being an employee of a large company creates people afraid of risk and rocking the boat. The company through its leadership and culture incentivizes particular behavior.  The employee trades their skills and dependability in exchange for a paycheck.  It creates situations where conscientious people tolerate ignorance and inefficiency because they say, “…that is how we have always done it.” Thanks to this submissiveness large firms stagnate and die.

It also explains to me why agile coaches are contractors.  In the words of Ken Schwaber, agile holds a mirror up to an organization.  Many organizations are not equipped professionally or psychologically to look at that reflection because they would see the incentives they have created are perverse and the services they offer are not meeting customer needs.  It is like being in the Jean-Paul Sartre novel “Nausea.”  The world we know crumbles away, and we see the disorienting reality of how things are working. Confronted with this we have three choices:

1. Wallow in despair and impotence
2. Ignore the truth and pretend nothing has happened
3. Take action and try to make change

The modern corporation incentivizes employees to make the first two choices.  Those who choose the third option either quit or the company fires them.

So as a scrum master or agile coach we are stuck making a change at the margins and moving on when we cannot do anymore.  The global economy continues to spin, and nothing seems to change. It is easy to get discouraged, but the size and diversity of the agile reformation continue to grow.  According to Scrum.org, over 100,000 people are trained at Scrum.  Figures from the Agile Alliance and Scrum Alliance are harder to come by, but eighteen years ago the manifesto began with fifteen people in a ski lodge.   The growth of the movement has been increasing and today’s consultants and practitioners will become tomorrow’s managers, directors, and executives.  It is a matter of time, and the Agile reformation will be driving reform inside the business establishment.

So perverse incentives prevent businesses from being more innovative and agile. The good news is the agile reformation is growing and with this growth will come increasing acceptance.  It will not be easy, but it will be worth it.

Until next time.

Keeping it simple.

The light switch should be our inspiration

One of the most important principles in Agile is simplicity.  I work with plenty of clever people which means we come up with plenty of complicated ways of doing things.  True innovation and progress happens when we find simple ways of doing complicated things.  This week we are covering the virtues of simplicity.

When we talk about simplicity, we are not talking about something which is simple.  We are talking about something which is simple to use, simple to work with and simple to understand.  The example I like to use most, is the electrical power grid.  When we need to put a light in a room we plug in a lamp and turn on the switch.  The technology and work that goes into getting electricity to that lamp is very complex to but to us it is simple.

Technology like smart phones, web sites and accounting software should be like the electrical power grid.  Sadly, it is not.  Microsoft technologies are great for PC’s but in order to write web applications for a phone you need Xamarin or understand HTML5 to write Windows 10 applications.  Those applications do not work on Android and iOS devices.  This is just a sample of some of the technologies which do not play nice with each other for either market or technical reasons.

The blame for this trend is very smart people who, instead of working together to create simple and elegant solutions, have split into warring tribes.  It would take an entire book to discuss the history of why this has happened.  So to the average consumer we have a layer of complexity to everything we do and it needs to stop.  Even Apple has made music players a colossal mess making it impossible for people to manage the thousands of songs in their music libraries.

I do not have any magic bullets to fix this but is up to everyone in the agile community to try and reduce this kind of complexity.  It will not be easy but neither was setting up the national power grid.
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.

You are not a ninja!

Agile professionals are NOT ninjas!

Like most professionals, I tend to get ornery from time to time.  I am beginning to think that this is a healthy response to working in present day corporations.  Human beings have gone from being hunter gatherers to living in cubical farms in the span of 5,000 years.  It does not surprise me that there is not some kind of psychological backlash to this situation.  Further changes in the professional world like the hoteling of work spaces and the growing dependency on contract workers has made life in the corporate world seem like something out a Franz Kafka novel.  Today, I want to talk about something that have been bothering me over the last few weeks.  The growth of faux titles that agile professionals are using to try and describe themselves.

My irritation began when I noticed that someone began using the phrase “code ninja” to describe themselves and scrum master skills.  I have already blogged about what I think about people who describe themselves in this manner.  Now, I am seeing terms like “Agile evangelist” and “Wizard” cropping up in some discussions about agile professionals.  I understand why people are doing this to try and brand themselves and make themselves more appealing to the market but it really needs to stop right now.

We are agile professionals.  We are not wizards pulling rabbits out of our pointy hats and summoning a Patronus when an impediment crops up.  We are not Jedi because I doubt we would ever get the licensing from Disney to use the title and we don’t have cool light sabers.  This also means we have to deal with Sith and frankly the thought of executives with the power to force choke is a little disconcerting.  We are not ninjas because even though we are highly skilled professionals we are not being asked to kill people.  Finally, we are not evangelists.  Evangelism requires blind faith, total dedication, and the commitment to orthodoxy.  That is the antithesis of Agile.

Agile requires its practitioners to try new things.  One of the tenants of the manifesto, is we respond to change over following a plan.  Pragmatism, the scientific method, good engineering, and relying on a community of professionals is what makes us agile.  Contemporary evangelism tends to shun these values.  I will concede that it does take a leap of faith to try and change how contemporary business is done but we are no different than the professionals who applied W.E. Deming’s methods in Japan or the lean manufacturing professionals currently practicing in the United States.

Finally, if you call yourself an agile apostle and you are not one of the original signatories of the Agile Manifesto you deserve a good dose of scorn and ridicule.  Agile was not dictated to us like the Koran to Mohamed or revealed to us via golden tablets to John Smith.  It is the product of thousands of people attempting to pull business out of the 19th century and into the 21st. It is changing and evolving and responding to change.

Drop the silly titles and let your work speak for itself.  We are Scrum Masters and Agile Coaches.  We are servant leaders trying to help others be more productive and content with their careers.  We need to get our hands dirty, refactor code, attend meetings, deal with the personal problems of our developers and try to make a difference in the lives of the people we work with.  This is not glamorous or flashy work but it needs to be done.  I you want to call yourself a ninja or Jedi then I think we are not going to work well together.  Don’t worry those of us exhibiting the quite professionalism the job requires will still be here to clean up your messes.

Until next time.

The Virtues of Agile: Focus

Focus Matters

This is the last of our series of articles about the virtues of Agile.  This week we cover the topic of focus.

Countless leadership books and seminars have said that focus is one of the most important skills a person or group can have if they want to succeed.  My favorite book on the subject incorporates science fiction into this scholarship.  For a software developer, focus is the key component to getting work done because it requires a tremendous amount of concentration to create software.  So of all the agile virtues, why have I saved focus for last?

This is because I strongly believe that focus comes about when the other four agile virtues are practiced.  I feel that it is not possible to have focus unless your teams have courage to get the job done, they respect each other and outsiders, are open to new ideas and challenges, and have commitment to get the job done.  The other four virtues act as lenses which generate the focus necessary to achieve goals.

I also feel this is easier said than done.  Today a person faces more distractions and obstacles to focus than any other period in contemporary business.  E-mail, instant messages, social media, and endless meetings seem to tug and pull at us like evil seagulls looking for a snack.  Add to the mix the office politics which accompanies an organization and you have a toxic stew of distractions.

This is why I like the scrum process so much.  A developer or scrum master can concentrate on a fixed goal for a fixed period.  It is easy to tell someone asking for additional features to say, “…that is a great idea we will put it into the backlog and then we can discuss it during sprint planning.”  Requests for favors go away because developers who work for me just direct those requests to the business owner and scrum master to prioritize.  This cuts down on “me to!” development which doesn’t add value but adds complexity to the project.

I am also discovering that focus needs to be reinforced on the team.  A scrum master should always say what the overall goal of the project is and how meeting sprint goals is just another land mark along the way.  A scrum master also should keep meetings to a minimum so that people who work under him or her can concentrate on what it takes to get the job done.  Finally, as a leader, the scrum master should pick a few attainable goals and stick with them.  This should create focus for the rest of the team.  If this strategy is good enough for the Secretary of the Navy then it is good enough for me.

It is easy to write about scrum.  It is much harder to actually do it in the real world.  I hope that this series has given you a chance to reflect on the agile virtues and how to use them in the real world. I look forward to sharing more of my acquired wisdom in the New Year.

Have a safe and sane New Year.

The Virtues of Agile: Commitment

Commitment is a strong bond

This is part four of five of our series of articles about the virtues of Agile.  This week we cover the topic of commitment.

Commitment is one of those things which is earned just like respect.  Sadly, our contemporary business culture makes it hard to make commitments which harms the success of organizations and makes it harder to for commitments to be made by line employees.  This creates situations where employees are “tuned out” of what is happening in the organization and who just go through the motions of serving the needs of the customers.  It is depressing and feels like being on a losing sports team.

As a scrum master and business leader, you need to commit to your team members and over time they may commit back to you.  There is no promise in this situation.  Some employees are just commitment phobic.  This is because they see work and the rest of the world as transactional.  They want to make sure that they have some “What’s in it for me?” moment.  So if they provide a service they get a compensation they feel they are due.

Commitment is different from this transactional model of viewing the world.  It is giving yourself over to something greater than yourself.  For the American armed forces, that this the “unit” which you belong.  For clergy, it is to your religious mission and for the entrepreneur it is to the business they founded.  This means that commitment requires sacrifices of time and behavior.  Many religious orders require vows of celibacy.  For the entrepreneur, it means long days of travel and work with no immediate pay off.

That said, commitment creates fiercely strong bonds between people who have made those commitments.  Military leaders work hard to develop these commitments to their troops because they know when shots are fired in anger they will have to count on those people to shoot back.  Business leaders need to work just as hard because while the decisions they make may not be life or death, they do effect the lives of the people who work for them.  Treating people like disposable tools to be replaced when they wear out is not going to generate commitment.  Something else has to be done.

Making sure that employees are constantly being trained and retrained to do their jobs better is one sign of commitment.  Another is providing them a game plan for how to improve their careers.  Nothing is worse for someone than stagnation and giving people a chance to grow and develop is an example of the organization making a commitment to them.  Business leaders can also get to know not only the employees but their families.  Asking about a daughter’s soccer game or looking at pictures of a Christmas recital can go a long way in showing employees you care and are committed to them.

There is no guaranteed pay off for this but when you need people to work overtime or deal with adversity a little commitment on your part could yield some commitment on theirs.

Have a Happy Christmas.

The Virtues of Agile: Openness

Everyone should feel safe in the Sauna

This is part three of five of our series of articles about the virtues of Agile.  This week we cover the topic of openness.

When I talk to business leaders about openness, I try to relate my experiences at my local YMCA as a metaphor.  As I have gotten older I, like so many of my peers, am trying to take better care of myself which means trips to the “Y” for some exercise.  It also means I get to sit in a hot tub and spend about a half hour in the sauna.  It is in the sauna where we can learn a lesson about openness. 

Each person in the sauna is naked or warring a towel.  Someone usually is reading a newspaper or magazine, someone else is chatting about the day’s events with a friend, and everyone mentions how warm it is in the sauna.  What does not happen is violence.  The reason why is there is no way to sneak a weapon into the sauna unless you are willing to do something extreme and uncomfortable.  The worst thing which can happen in the sauna is you are embarrassed about your shape or have a tattoo or piercing you might regret.  Everyone is forced to be a little open in the sauna.

An agile team and the organization should be like a sauna.  The low dry heat represents the pressure we face every day in the business world.  Everyone should be willing to be metaphorically undressed when in the hot house of business.  This means agendas are out in the open for everyone to see.  If someone does something embarrassing the others react to it with good natured respect.  If someone feels faint or passes out they get help and provide assistance.  In the sauna, we are all a bit naked and tired.  

This does not mean you have to be totally open.  Confidential information, like salaries and trade secrets, do not have to be discussed in the sauna if someone does not want to discuss it.  Sometimes, information needs to be parceled out in small bites and that too is acceptable.  What is not acceptable is outright deceit or lying to have advantage over the others. 

This is why openness is difficult to cultivate in an agile team.  For years developers and executives have been trained that “knowledge is power” so they tend to hoard information.  In an open team, the rookie developer would know that the old hand on the team has not worked with LINQ statements over his career and might need help.  The veteran may know the business and why a certain approach is being used to fix a problem and should share that with junior developers instead of having them hacking away at code in the dark. 

Openness begins with a scrum master who lets the team know what is going on each day in the stand up and during the course of the day.  They help the developers stay focused by avoiding distractions and having them concentrate on sprint goals.  They also have to good sense to look the other way when open of the team members metaphorically drops his towel and makes themselves vulnerable.  I also make a point about joking about my lack of muscle tone to keep the team loose. 

Openness is about being safe with in your own skin and when exposed to the skin of others who are in the same situation you are in.  Without this virtue team collaboration is partial because everyone will be concerned about agendas, possible threats to their career, and lack of safety. 

Until next time.