Constant learning begins with you.

It is never too late to learn

I have spoken before about how technology changes quickly and that to be successful you need to be a continuous learner.  A software developer has to relearn their profession every eighteen months.  When you lead these individuals, you should foster an environment of constant learning.  The global economy and technology field depends on the forward momentum of learning. 

The world we live in today is radically different from the start of the internet era.  Do it yourself videos are everywhere on YouTube.  Today, anyone with a video camera and an opinion can behave like a network pundit.  In the world of technology, the hacker ethos and open source community have won the debate about how enterprise systems should operate.  It is a world of open source, cloud computing, and mobile devices.  Business leaders are struggling to understand these changes.  

With change happening so quickly, it is easy to see how people can fall behind.  It is why there are so many training conferences, continuing education courses, and ongoing programs in business to keep the skills of professionals up to date.  It is why I continue to dabble in software development even though I spend the majority of my time in a coaching role.  It allows me to understand the challenges and opportunities that developers face each day.  It also gives me a chance to kick off the rust and stretch myself creatively.  

I am working with .NET Core technologies for the past week, and it has been a valuable learning experience.  Instead of XML configuration files, .NET Core uses JSON.  The Bootstrap CSS system is now on version four, and communicating with Restful APIs is like connecting to a database.  I felt like a child learning to program again.  I watched a few training videos on YouTube and made the typical mistakes someone learning does.  I also had the experience of satisfaction of getting something to work correctly hours of tinkering.  

Now when I am making technology decisions, I can make a more informed choice because I have worked with the systems in question.  It is a better approach than sitting passively behind a desk and waiting for a consultant to whisper something in your ear.  It is my experience that the best leaders are the ones who lead from a position of expertise and empathy.  These people understand the day to day struggles of the business and market forces they are facing.  

It is why I attempt to kick off the rust and do some programming.  I learn new things and do some programming.  I know new things, and it provides me with insights into how people I serve work.  To foster an environment of learning, you must be willing to learn new things.  

Until next time. 

Professionalism and Developers Part 1

Developers see the world differently.

I have spent a long time working in the software business.  I was not very good as a software developer until I did it professionally for ten years.   Today, I still consider myself a mid-level developer in terms of skill.  What set me apart later in my career was the professionalism I brought to the job.  Documentation would get written, time cards would get filled out, and I spent a lot of time over-communicating with management and stakeholders.  As I moved into project management, scrum mastery, and leadership, I noticed that software developers struggle with professional behavior patterns, which other business professionals have internalized.  We should discuss this.

The subject of professionalism is a touchy one in software engineering.  If you look at the history of the profession, it is easy to see why.  Bill Pflegin and Minda Zetlin, in their book, “The Geek Gap,” points out business people and technology people see the world from two different frames of reference.  A business person wants to be likable and profitable.  If you are agreeable, others are more receptive to your product which you are selling.  Thus, business people are very focused on being likable.  Engineers are not concerned with being likable.  The most important thing for an engineer is to make sure things work.  An engineer spends most of their time wrestling with the rules of physics or computer science to get things to work faster, better, and more reliably.  Something works, or it does not, and this binary view of the world and their career is often disorienting to business people.

Next, developers since the 1950s have a deep affinity for counter-cultural movements.  Beatnik, Hippie, Anarchist, Libertarian, and Punk mindsets permeate the culture of programming.  The let it all hang out attitude of developers is similar to the approach of Jazz musicians.  Hair color or politics does not matter; what matters is technical ability and the respect it generates.  It is why we have engineers with “UNIX beards” because they honor other engineers for the work they have done, and they do not care what business people think.  Someone like this does not have to care about being likable because they build things that work and keep the organization going. 

Finally, developers are more creative and intelligent than the average business person.  Creative people are alienating to people who are not.  Creative professionals are deeply suspicious of authority and rules.  Combine these two factors, and it is natural to see how business people and engineers distrust each other.  It is also why engineers chafe at the rules, regulations, and notion of professionalism.  To the engineer, professionalism is the curtain that hides the inability to solve problems and make things work.

There are three key reasons why developers and engineers do not behave as professionally as other business people.  First, they see the world differently and judge their value from a different frame of reference.  Next, developers embrace sub-cultures that do not respect authority.  An engineer or developer appreciates accomplishment or skill.  Finally, developers being more creative and intelligent, often chafe at rules made by others.  These three ingredients combine into a perfect stew of unprofessional behavior.  I will talk about how to work with these realities in my next blog.

Look forward to seeing you then.

Until next time.

 

Motivate Others Instead of Bossing Them

Motivation is Powerful

The biggest challenge for a coach or leader is motivating others.  If anyone could do it, the world would be a different place.  Problems like hunger, climate change, and a properly fitting pair of slacks would quickly happen because people would want to address those problems.  In reality, we struggle with these challenges because it is hard to motivate others, and there is an entire group of people who want to discourage people from thinking there are solutions to these issues.  Motivation is getting people to swim against the current of conventional wisdom. 

 

Motivating others is a full-time job.  It requires the application of soft techniques of persuasion and other times the blunt force of human resources.  People want to feel useful and challenged, but often they settle for security and routine.  A leader needs to work with these messy people and give them a chance to rise to their circumstances.  I struggle with this because I come from a command and control environment.  I would discover later in my career; this approach does not work with technical or creative professionals. 

 

The global economy has shifted from building things to creating experiences, services, and ideas.  It is a complicated process, and it requires more than following orders.  It requires looking at things from different perspectives.  The creative process requires a sense of craft.  Finally, it demands that people look at problems and question established answers.  People who excel at these skills are rarely the type to follow orders.  

Because we rely on information and creativity more than ever, leaders need to convince people why things need to happen instead of what needs to happen.  Give a problem to a bunch of creative people and tell them why it needs solving; you will be surprised by the effort they will put into solving it.  Telling people why something is essential creates a common cause with the team.  Explaining the urgency and necessity gives importance to work.  People with purpose are better than those with a plan.

So as a leader, you need to show others where you want them to be rather than telling them. Act as an example by listening to others and avoid asking someone to do something you would not do yourself.  Support others as they struggle to come up with solutions and listen to what others have to say.   It is surprising what you will learn.  

I do not have a magic recipe for motivating others.  Each day, I do my best to explain why certain things should happen.  The team should be concerned with how it should happen.  Finally, try to be an example for others to emulate.  Motivating others is not an easy process, but if you can do it right, the results are deeply satisfying.  

Until next time. 

When Culture Eats Agile for Breakfast.

Bad Culture is like canoeing over a waterfall.

I am very fortunate to have family and friends who are into musical theater.  For an aging high school theater nerd, it is always fun to sing along with a show tune while driving.  The funny thing about musical theater since the Second World War is that it has tried to tackle social issues.  “West Side Story,” addressed gang violence and racism.  I remember “A Chorus Line,” exposing me to gay characters.  Finally, “Hair,” had a rock-and-roll soundtrack and a fiercely anti-war message.  Over the weekend, I was running an errand, and the family was listening to the “Hamilton,” Broadway cast album.  I had an unusual emotional reaction, and then I began to think about my agile journey.  

One of the essential songs in the show, “Hamilton,” is “The Room Where it Happens,” where the characters Alexander Hamilton, George Washington, and Thomas Jefferson make backroom deals and compromises to keep the American republic moving forward after the revolution.  It is an excellent song about power and the practical matters of running a country.  It is also an ironic song because Hamilton’s rival Arron Burr jealously wants to be in the room where those compromises happen.

I thought back to a previous position where my manager would joke that I attempted to drag the company toward agile “kicking and screaming.”  The last two years of my career were so frustrating because I would propose solutions and fixes, but because I was not in the room with the decision-makers, my expertise was ignored or actively discouraged.  I would even complain to my manager that I wanted to be in the place where the decisions occurred.  Naturally, when I had my exit interview, I cited the firm’s lack of agile adoption as the reason for leaving.  Looking back at the experience, I realized my efforts were not going to gain traction because the culture of the firm was not going to value agility.  It valued tenure and experience over actually getting work done.  The stock market has rewarded the organization appropriately.  I was never going to be in the room where it happens because I had not paid the twenty-year commitment of time and adequately ingratiated myself with the other leaders.  Shipping software and delivering value was considered a threat rather than a virtue in that organization.  

The rough learning experience helped me grow and develop as a professional, but it reinforced the notion that culture is more influential than agility.  A dysfunctional culture or organization is going to actively fight against agile because agile quickly exposes the rot in the organization, and that threatens the careers of people who professionally benefit from that inefficiency.  People will quickly ally against any change, which is threatening.  The 14th State of Agile report echoed this state of affairs when they said cultural acceptance of agile is lagging because of leadership, not understanding it, and the organizational culture resisting its improvements. 

It occurred to me that unless you have senior leadership working alongside agile coaches and scrum masters, the rest of the organization will continue to do what it has always done through the force of inertia.  Even if I were in the room for decisions, at the old organization, it would not have made a difference because the leadership would not have understood a word I was saying.  So as a coach or scrum master, pay particular attention to culture because if they do not value the agile manifesto or principles, you are going to paddling against the current.  If the senior leadership does not understand agile, then you might as well go over a waterfall in a barrel.  

Agile works, but if you don’t have the right culture, you are up a dangerous creek.  You do not need to appreciate show tunes to get that message.  

Until next time.  

Be an Example for Your Scrum Team

Leading by example is a key tool.

It takes hard work and commitment to become a leader.  You spend years learning to master your craft and developing the credibility you need to influence others.  Once you have reached that level of skill, you are in charge of a bunch of people, and management expects results.  Here is where the leadership gets tricky; you often do not have a clue how to motivate a group of strangers into delivering the results desired.  It is time to discuss that challenge.  

When I join a new organization or client, I want to promote the five values of scrum; openness, focus, commitment, respect, and courage.  It amazes me how many corporate cultures discourage these traits in their people.  Often individuals have worked in environments which promote orthodoxy, compliance, and obedience.  We teach people to do things the company way, and if they cannot, they leave.  Conditioning like this over the years is hard to overcome.  What helps breakthrough is to practice the skills you want others to copy.  

I want people to understand commitment by practicing it myself.  I spend time with the developers during product release or critical bug fixes.  Often, I am not required to be there, but if I expect someone to work overtime to fix a problem, I better be willing to do the same.  

You cultivate openness and respect by doing simple and small things.  Call people by their names and avoid using nicknames for your people.  I prefer to be called Ed instead of Edward.  I also do my best to pronounce the names of my off-shore developers.  It is a sign of respect when you address a person by their name and pronounce it correctly.  Openness is being clear about what you expect and what others should expect from you.  I open conference calls five minutes early because I want meetings to start on time.  When I miss a meeting, I send out a notice so that people know I have a reason and respect their time. 

Courage is living your life in an honest and frank manner.  It is saying what needs to be said when it is not popular.  It is making promises to others and honoring them.  Courage is betting your career each day and taking risks to get things done.  

Focus is one of the hardest things to do in a corporate environment.  Internal politics dominate decision making, people are worried about who gets the credit, and the noise from business media and shareholders can be a distraction.  Each day you are pulled in different directions.  Focus is being able to set aside those distractions and concentrate on what is essential.  To me, I must deliver software at regular intervals and provide value to my customers.  In the words of one of my mentors Angela Dugan, “Do your job, and if they fire you, it is their problem.”

The values of scrum need to be practiced by the team.  It means walking the walk as well as talking the talk.  It is why leadership is hard.  

Until next time.

Avoid Heroism and Practice Radical Interdependence.

Anyone who tells you leadership is easy is either a liar or a fool.  Each day leadership is tested by interpersonal disputes, market demands, and gaps in knowledge.  People count on leaders to have emotional balance when everything is going wrong.  It is facing difficult questions when you do not know the answers.  You must be firm one moment and understanding the next.  When things go well, you give credit to others, and during failure, you take responsibility.  Leadership is one of the most challenging skills to cultivate.  It is a duty and calling rather than a heroic struggle.  I want to discuss it.  

Leadership is more than a stance.

We often train a leader at an early age.  Young people become captains of sports teams or members of the student government.  Junior ROTC programs do an excellent job of teaching the skills of leadership and followership.  The early training in leadership is beneficial, but over the last thirty years, I have discovered that it is incomplete.  For the last two hundred years, we have expected leaders to have answers to every challenge and be able to motivate others.  A leader formulated a plan, and the followers executed the project.  Today, in a global and creative economy, this is no longer true. 

A contemporary leader must depend on others with specialized knowledge.  A deep understanding of the law, finance, computer software, logistics, and marketing is impossible for one person to gather in a lifetime.  Today, a plan requires multiple people to formulate and execute.  The contemporary world is too complicated and chaotic to come up with natural solutions.  

It is why I discovered a TED talk from South African food executive Lorna Davis.  She talked about how she bought into the myth of heroic leadership.  She also found heroic leadership did not effect change within her organization.  People applauded her works and went about doing the same things they did before she joined the organization. Heroic leadership failed.  She goes on to mention that a new model of leadership needs to develop, and she called it “radical interdependence.”  A leader should have a goal, and it is up to the team on how to achieve that goal.  It requires listening, empathy, and giving others a chance to excel.  It is anything but heroic.  

I did not realize I was using this approach when I confessed during a meeting I was stumped.  I did not know how to address a quality problem, and I asked, “Anyone have any idea how we are going to fix this?”  Within a day, I had answers, and the leaders at the off-shore office were implementing them without checking for permission.  The off-shore team knew if I disapproved, I would let them know, so they decided to take the initiative.  I am confident our quality issues will clear up.  

Radical interdependence requires trust and allowing others to come up with solutions.  It involves a surrender of control, which many successful people find uncomfortable. It relies on asking questions instead of giving orders.  It is physically and mentally exhausting because you are stretching your emotional intelligence and practical knowledge.  You are learning and growing with the people you are leading.

Leadership is the most challenging skill a person can acquire, and it is impossible to master.  It is clear why the military calls command a burden.  Each day you are tested, and failure can mean the loss of millions of dollars or even lives.  I think Lorna Davis has some useful guidance about leadership.  I am going to ignore the liars and fools.  

Until next time. 

Grateful for the Agile Coaching Summit in Chicago

Left to Right: Ben, Me, and Mara.

A big challenge for any scrum master or coach is the feeling that you are alone in the organization you are leading change.  Cultural inertia, fixed mindsets, and the pressure to deliver have a way of draining a person of enthusiasm and devotion to the agile reformation.  Professionals like us need an opportunity to recharge our batteries and spend time among like-minded individuals.  The Agile Coaching Summit at the Guaranteed Rate headquarters in Chicago was one of those opportunities.

If you are an agile professional, there are plenty of opportunities to interact with others.  Social media features countless user groups for agile professionals.  Two significant conferences begin and end the summer, offering learning credits and a chance to rub shoulders with others.  The Agile Coaching summit in Chicago is different.  The Agile Coaching summit in Chicago is different.  It is more intimate with room for about 150 people.  Skill levels from new scrum masters to hardened coaches leading enterprise change at Fortune 500 companies are present.  What unites all of us is a desire to make a difference at our organizations and our devotion to agile.  It is a great mix, and it is why I attended the inaugural meeting and why I went this year. 

In a change of pace, we had not one but five keynote speakers.  Some were coaching language, others spoke about positivity, another was an improvisation coach talking about coaching conversations; finally, we learned about generational differences in the workplace.  It was upbeat, positive, and informative.  All these speakers spoke about the skills necessary to be successful leaders, listeners, and coaches.  Not a single one was an agile specialist.  The focus on these areas creates an impression that agile coaching is more about coaching others for success than agile.  It was a necessary pallet cleanser for a great conference. 

Saturday opened with coffee and breakfast and quickly moved into in-depth learning sessions.  I was busy learning about a wiki book imitative while others were discussing “agile fakes.”  Later sessions included conversations about how executives undercut agile, and it is always good to learn how to perform Kata experiments to change behavior.  The best part of this gathering is to see old friends and to meet new ones.  People swap war stories about creating organizational change.  We catch up on each other’s children, careers and personal lives.  I even spent time bantering about smart lights and how to set them up in a new house. 

Sunday is usually a laid back affair, but there were great sessions about coaching teams versus one on one coaching.  We had conversations about dealing with difficult team members and discuss product ownership.  It was a great weekend, and I strongly recommend it next year.  Many thanks to Emilio B. Perez and the folks at Guaranteed Rate for a successful summit and I look forward to ACS2000.

Until Next time.

Four Simple things

It can get lonely.

The biggest challenge as an agile professional is leading organizational change.  Often, you are a lonely voice in an ocean of indifference.  People do not like the daily routines and rituals disrupted, and agile professionals are doing it with frequency.  The resistance is a natural response to change.  Humans have a craving for stability in an uncertain business world.  The situation sets the agile professional up for isolation and loneliness.  I want to discuss the support system you need to overcome the adversity.

Being a scrum master or coach is a difficult calling.  It requires tremendous emotional labor, and you are attempting to overcome decades of resistance to change within an organization.  To be successful, you need to have a support system which will help you get through the rough patches.  Here is my formulation of that system.

An Understanding Significant Other

If you have a spouse, boyfriend, or girlfriend, they need to be understanding.  You are going to have unannounced late nights being with the team fixing production bugs.  As a servant leader, you will confront difficult emotions, and it will take you time to unwind from them.  It helps to have someone in your life who loves and respects you to listen. Finally, they should be willing to work with the ebb and flow that technology professionals encounter daily.  It is like being married to a police officer or firefighter.  The job always finds a way of intruding into the relationship.

A User group or Network of fellow Agilests

Many organizations do not have a large cohort of agilests.  It is why being a coach can be so isolating. It is why you need a regular group of people to meet with discussing current trends and new techniques.  It can be an online group or frequent meetup.  The purpose is to have a peer group which can provide emotional and professional support.  Often a problem you think is intractable is something someone else has solved.  The user group acts as a repository of information, a social circle of peers, and group therapy.

Support from Senior Leadership

Change does not happen, spontaneously.  Often, it requires outside events to force change or an internal mandate to make change happen.  An agile coach without the support of senior leadership is not going to be successful.  Cultural inertia is a common obstacle to change.  Often when you ask why something is done a particular way the response is, “…because we have always done it that way.” Senior leadership can give you a mandate and authority to improve a process.  Executives provide the nudge necessary when things need to change and when people dig in their heels.  Finally, senior leadership is a source of validation which makes the hard work and sacrifices worthwhile.

Allies in the Organization

As a firm moves along the agile journey, a coach or scrum master is going to gather like-minded people who are allies.  Organizational allies are gold to a coach or scrum master.  The people joining you will spread the message you are sharing. Associates will provide emotional and technical support.  Colleagues will support you during a difficult decision and join you for lunch when times are less stressful.  Cultivation of colleagues will keep the agile transformation going long after you have left the organization.

So to avoid burn out and isolation a coach or scrum master needs; an understanding significant other, a network of fellow agilest, support from senior leadership, and allies in the organization.  Without these things, an agilest will have a lonely run with an organization.

Until next time.

Fight Bad Agile!

Command and control did not
 work then and it will not work now.  

I have been involved in the agile reformation for the last ten years.  In 2009, the agile manifesto was relatively young, and it was a quirky idea to make software better. Today we have three primary scaling techniques for agile.  The reformation has grown and splintered over the years, but the manifesto remains the pole star which every variation circles.  Now business professionals and executives are paying attention to the reformation.  Agile is eating the world, but instead of confronting opposition, we are dealing with corruption caused by the status quo as it exists in many companies.  The corruption creates bad agile, and it is up to coaches and scrum masters to call it out.

Last week, I pointed out that a common dysfunction in organizations is leadership spends too much time pleasing superiors rather than doing the necessary work to make the business successful.  The behavior hurts collaboration between departments and categorizes people as resources which can be swapped out like machine parts.  It is dehumanizing and alienating.  Agile helps fight this dysfunction with emphasis on cross-functional teams and less organizational friction.  The challenge of agile is it works well in the realm of the team, but as it attempts to scale out to the organization, it butts against status-quo thinking, entrenched political agendas, and the command and control mindset of most executives.

Put yourself in the shoes of a typical executive who has spent ten, fifteen, or twenty years in an organization. The executive has presided over budgets and deadlines.  The contact they have with the people doing the actual work is limited, and their knowledge of project management is slight, so they hire project managers to handle the responsibility.  Most of the time, executives spend time involved with pleasing superiors and political sparring with rivals.  An agile coach comes along who tells them they have the wrong career focus, and they have been leading their people incorrectly.  Agile, with its emphasis on inspection, adaption, and transparency, undermines political infighting within an organization, which means career advancement depends on results instead of deception.  It is going to create anxiety, and the executive is going to push back.

The executive is not evil in this instance; the new way of doing things creates uncertainty and fear.  It is natural they would be resistant when confronted with this upsetting of psychological safety.  As a coach, it is going to be your responsibility to address the resistance.  You are going to walk the executive through the process of shifting from a command and control mindset to an agile mindset.  It will not be easy.

Instead of telling people what to do, the scrum master will have to show them.  Lead by example, give the team what they need to succeed, live the agile manifesto and principles, and point out organizations friction where it exists.  Inspection, adaption, and transparency are designed to hold everyone accountable particularly executives.

Bad agile happens because self-interest and the status quo are more important than getting work done.  We tolerate double standards, and it creates corruption.  It is up to each scrum master or coach to reveal this corruption so we can mitigate its effects.  It is up to each of us to show instead of telling others what to do.  Finally, we need to create psychological safety among leaders if they are to embrace agile.  Otherwise, we remain stuck with bad agile.

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.

Agile and the Toxic office

The Open office plan circa 1960.  

A modern office resembles the dark vision of Jean-Paul Sartre’.  In his play “No Exit,” he traps three characters in a room.  The characters psychologically torment each other.  The lights never dim and no one can escape.  To Sartre’, “hell is…other people,” and they are impossible to escape.  It sounds like a perfect description of the modern office with cubicles and open floor plans.  By design or neglect, the contemporary office has become a toxic hell which white collar workers navigate each day.  As an agile coach and scrum master, you need to fight this toxicity and make work better. 

The open office is not a new concept.  As business expanded, hundreds of people were needed to perform necessary clerical work.  Captains of industry required contracts typed, checks deposited, and in a time before computers numbers crunched.  Many of these jobs became obsolete with the advent of computers and photocopy machines.  Today, an employee with a laptop can be more productive than an entire 1950’s office pool.  It is impressive when you think about how office work has changed over the last seventy-five years.

It is also surprising how little has changed.  Alcohol abuse is still a problem in the corporate world.  The “Peter Principle” which promotes people to their level of incompetence is still in practice.  Finally, according to Gallup, two-thirds of workers in the United States are disengaged.  I feel strongly Agile came into being because competent, hardworking people thought it was possible to do better.

The reason offices converted too open plans is the combination of perverse economic incentives and naive notions of what it takes to build a collaborative team. In cities with large business communities, rent is at a premium.  In Chicago rent increased by 20% in 2016 and currently leases at $50 to $60 a square foot.  Based on the price pressure, business owners have the incentive to get the maximum amount of use out of each square foot.  The open office makes that possible and managers can squeeze more people into less space.  The open office plan began with Frank Lloyd Wright and his Johnson Wax office building; it also has an origin in German design from the 1950’s.  The open office would facilitate conversations, collaboration, and innovation.  The reality of open offices is an environment employee’s loath.   

It does not help the shareholder value theory of business motivates many managers.  To these managers, the only thing which matters in increasing the share price or dividend for the company stockholders.  Thus, the open office and the shareholder model of business creates a fiendish replication of Sartre’s hell.  We are trapped economically in a space which is designed to torment us.  It is this combination of poor work environment and leadership which ignores stakeholders, customers, and employees are why I think we have such a severe problem with disengagement and alcohol abuse in office culture.  When there is a disconnect between your work and your wellbeing, something has to give; for many, it is their self-esteem and enthusiasm for work. Marxist philosophers call this “Labor alienation,” and it is just as bad today as during the sweatshops of Dickens.

Agile came into being because people doing the work of building the world economy through there was a better way.  These people were project managers and technologists.  None of them were Fortune 500 executives.  Individuals and interactions, responding to change, customers collaboration, and working systems were more important than everything else at the office and embracing these values we say we are trying to make the office less toxic. 

Many of us feel we are powerless to change things in the office.  Agile gives us the tools to expose dysfunction and reduce alienation.  We have to be brave and smart enough to use those tools; otherwise, we will continue to have the same office as we have had for seventy-five years and there will be "no exit," for us. 

Until next time.

No Estimates have a spot at the Campfire

Lots of debate around the campfire.

One of the best things about being a member of the Agile community is the smart and enthusiastic people you encounter online and in person.  It is refreshing and challenging to be around people who have a shared vision of making business faster, sustainable, and more intelligent.  The commitment to the goals of agile does not mean we are ideologically unified and dogmatic.  Like any healthy practice, we disagree with each other about basic principles, ways to spread adoption, and innovations.  The creative tension is essential.  I want to add my two cents to an on-going debate which a colleague Ryan Ripley brought to my attention from the sober and restrained convention floor of the #BetterSoftwareCon in Las Vegas. 

The #NoEstimates movement has become a very vocal camp in the agile reformation.  If you follow the debate, it is easy to see why.  The estimation process at many companies is farcical and corrupt.  Story points were created to provide the benefits of estimation without the obvious drawbacks.  The #NoEstimates crowd take this to a logical conclusion and say estimating is a waste of time and energy.

I do not feel very strongly about #NoEstimates.  What makes it interesting is it provides a different perspective to authoring software.  Neil Killick then posted a white paper this week showing some qualitative measurements which show a no estimates approach works just as well as a story point approach.  

I was skeptical but, I decided to give the article the benefit of the doubt.  Killick uses T-Shirt sizes to measure ambiguity and difficulty.  Using arithmetic and charts, he shows how he can forecast project completion.  The approach is well thought out and clear.  It is also story points dressed up to look like #NoEstimates.  It requires the product owners to spend time doing arithmetic instead of writing stories and working with customers and developers.  Personally, I struggle getting product owners to perform the basics of their duties.  Thus, using Killick’s approach may work for a different agile implementation but not for mine. 

I genuinely dislike debates which generate more heat than light.  Killick provides a good approach for a more mature agile team.  I am glad I had a chance to learn about it and will keep it in my chest of tools if I feel it worth trying.  The agile manifesto says, “Individuals and interactions over, processes and tools.” I believe that Killick’s approach is a process which might work with a particular set of individuals.  I also think that discussion of #NoEstimates is good for the agile movement.  People try out ideas, test them, and they are adopted or rejected over time.  It sounds mighty agile to me.

Until next time. 

Understanding Estimation for the Misinformed

When I speak with business professionals, they often struggle to understand the basics of the agile reformation.  For example, when I hold someone accountable for not doing work, they are shocked I am expecting results.  Many times, I feel like am discussing a round planet with people who still think the earth is flat.  These kinds of misunderstandings often lead to dramatic blow-ups as the agile coach expects one result and the business a different outcome.  This week and over the next few weeks I will try to explain some of the basic ideas agile practitioners use.  Today, an overview of why the agilest use story points.

One of the most controversial activities in business is project estimation.  The reason why is many estimates for creative projects is a lie.  The company is lying to itself about what it wants and how much it is willing to pay for it.  The creative team usually lies about how long it is going to take to complete the work.  To any objective person outside this process, it looks like madness.  Everyone is lying, money is getting spent, and nothing gets into production. 

Project Estimation is farce and tragedy.

The agile manifesto came into being with the twelve principles of agile because the failure of major projects in the business world was becoming unsustainable. The firm spends too much money for too little return on investment; something had to change.  The first thing the agile reformation addressed was estimation. 

A traditional project begins with executives looking at the corporate budget.  After the debt is serviced, shareholders compensated, and payroll met a portion of the money is left over.  Managers then submit requests to spend this leftover money on capital improvements and technology projects.  Based on profitability and political clout, this money is doled out.  For the attentive, you will notice the business executives do not experience the same reality of the front line consumers or employees.  Thus, a software project begins with a pile of money.

The managers and directors once they receive this money then have to figure out how to spend it.  The money comes with plenty of strings.  The project has to meet a deadline which may or may not be grounded in reality.  The plan must work with current technology at the firm.  Finally, the manager must have people who understand how to take that pile of money and turn it into working software. 

What happens next is something resembling a demented game of “Name that Tune.”  The manager goes to consulting companies and internal development teams asking how much time it will take them to satisfy the project requirements. The consulting company will bid a price to earn the business.  The internal developers will offer an amount to remain employed.  It goes on until the bidding ends and the project begins.  The costs are not grounded in reality, and neither are the estimates.

What happens next is both farce and tragedy.  The workers with the limited budget and impossible timeline fail to deliver.  Making matters worse developers are expected to incorporate changes mid-stream and the deadline does not change.  Eventually, the deadlines are missed.  The budget is used up, and cost overruns are rampant.  Finally, people quit because they are burnt out for working numerous hours of overtime to deliver a flawed product.  Quality suffers, money is wasted, and this approach ruins reputations. 

The primary cause for this kind of disaster is many managers equate time with money.  So, if you have $40,000 and it takes 1,000 hours to do something, this means it will cost $400 an hour.  Now suppose you have a consultant who will do the work for $200 an hour.  You can do twice as much work.  It depends on both of the people having the same skills and ability which is not the case. 

Story points for estimates came into being because time does not equal money for complicated projects.  Those projects also feature tremendous uncertainty and are often resistant to automation.  Instead of telling a manager that the team will be able to do the work in 1,000 hours at $400 an hour, a scrum master or product owner will say the team can do fifty story points a sprint and there are roughly 213 story points of work.  The ridiculous game of name that tune goes away and people can start having realistic discussions of time and money. 

Next week I will show you how that works.

Until next time.

Food Trucks and the Theory of Constraints.

The food truck can teach us about theory of constraints

In the global economy, events are moving at the speed of light.  An order placed in Singapore triggers a cascade of events in Tokyo and then at the corporate headquarters in Chicago.  Technology makes this kind of speed and accuracy possible.  To many people who use this technology, it is like magic.  To people who build and maintain these systems, it is hard work.  So the biggest challenge of our time is how to balance the desires of people who think technology is magic with the reality of innovation being hard work.  This week an introduction to the theory of constraints and what it means to a scrum master.

I have been reading a book entitled, “The Goal: A Process of Ongoing Improvement,” by Eliyahu M. Goldratt.  It puts the reader in the shoes of a plant manager of a failing company.  His wife is unhappy with all the responsibilities he has which keep him away from his family.  His boss threatens to shut down his plant in 90 days.  He is also dealing with his children and his aging parents.  It is a trifecta of stress which would grind down any person. 

The main character has to juggle these competing demands on his time and energy while confronted with the collapse of his marriage and loss of his job.  He decides to concentrate on saving his job to provide for his wife and family.  Over the course of the book, the protagonist learns about the theory of constraints and how to use it to save his plant.  I will let you find out for yourselves if his marriage survives. 

I am personally surprised that I did not get exposed to this idea sooner in my career.  In layman’s terms, the theory of constraints posits that a system can only operate at the speed of its slowest sub-unit.  For instance, if you have a food truck, you have someone taking orders, someone doing food preparation, and someone plating finished products and delivering them to customers.  I realize that this example features a crowded food truck but stay with me.  The cashier can take an order every two minutes.  The owner can prep food for about 10 minutes per items on the menu.  Plating and delivering food takes five minutes. 

In this simple example, it is clear the slowest part of the process is preparing the food.  If there are ten items on the menu, it takes 100 minutes or almost two hours.  If done in a just in time fashion, then it takes 10 minutes.  So, a busy developer visiting the food truck outside of the office has to wait almost 20 minutes to get a meal.  This kind of service would put the food truck out of business.  The bottleneck is food prep.  Most food trucks avoid this issue by doing food prep in advance.  It reduces meal time from 20 minutes to seven. It is a major improvement, and it might keep the food truck in business. 

As a scrum master, it is important you recognize the bottlenecks which slow down the flow of value through the organization.  Are product owners not writing stories?  Are developers not doing test-driven development?  Maybe the release process is taking too long.  A good scrum master will figure this out and try to smooth worth through the system. 

The theory of constraints contains plenty of mathematics and ways to measure flow through the system, but the general idea is to find the slowest part of the system and maximize it to find the slowest part of the system and maximize its output while preventing work from stacking up before the bottleneck and slack gathering behind it.  Like many discoveries in science, engineering, and project management it is pretty simple once we understand it. 

Until next time. 

Admitting personal failure

I failed.  I will get over myself.

There is a saying in the medical profession, “When God puts his hand on the left shoulder of a patient, take yours off the right.”  The meaning being that patients die and even the best doctor will have to accept that they cannot heal everyone.  This week I am leaving the University of St. Francis business incubator, and I am shuttering much of my start-up.  I want to discuss this on the blog this week.

Seven years ago, in the aftermath of my failed second marriage, I founded E3 systems. The goal was to create an online inventory management system which other small and medium sized businesses could use to manage their organizations better.  I wrote software non-stop for weeks.  I would sequester myself to focus on setting up business structures which would scale.  I had numerous arguments with my product owner who also happened to be my father.

I would run into various business situations like people expecting me to give them my product for free.  One potential client loved my work until they realized they would have to pay me.  I even did a classic Silicon Valley “pivot” writing software which handled fleet and equipment maintenance.  I flooded social media with youtube videos, tweets, and Facebook posts and information on my product.  I did everything with scalable technologies and paid for everything out of my pocket.  Sadly, I could not do business development and close sales.  As my advisor told me, I was a dilettante.  The business world rejected me with harsh Darwinian indifference.

I toughed it out for seven years.  I kept my day job and hoped someday I would pack up my cubical and go full John Galt.  The last two years have been a denial of reality.  I did not have a market for my products, or a means to sell those products.  I failed.

I am disappointed, but I have learned some valuable lessons.  I understand that I am pretty good at operations and project management.  My software development skills have dramatically improved including my use of SOLID and test-driven development.  I have been jumping on the chest of a dead business.  Everyone knew this but me.  Now that I have a moment of clarity, I see that now is the time step aside and accept its demise.

I will still be open for consulting and will be happy to continue Agile coaching but my days of selling software as a service are over.  I have a relationship with the Will County Project Acclaim which I will continue to support.  I am shuttering my cloud based software on September 1st.  I will keep this blog open because I still have plenty to share about agile and software development.

In the agile movement, we say, fail early and fail often. Failure is the ultimate learning experience.  As a failed entrepreneur of a startup, I consider this something which makes me a better leader, agilest, and software developer.  Once the disappointment wears off, I will be ready for my next act.  I suspect it will be a command performance.

Until next time.

Feeling All American!!

America may not look good but we have a lot to offer.

The United States is commemorating its Independence Day.  It is a time to look back at the nation’s history, celebrate the present and look to the future.  I am a business person and agilest.  I am also American which means I view the world with a, particularly American perspective.  This week, I want to talk about my American perspective and how it shapes my agile practice.

My European and Canadian friend tease me with the stereotype of the “Ugly American.”  To them, the stereotype posits that we American’s are uncouth interlopers with lots of money but no manners, style, culture or ideas which have value to the rest of the world.  I disagree with them politely and let the facts speak for themselves.  America for better or worse helped create the global economy in the aftermath of the second world war; we take for granted today.  America is why you can purchase a Coca-Cola in any nation in the world. 

We are not a perfect nation.  Our politics are deeply divided, and we are currently involved in on-going wars in the Middle East.  In spite of those challenges, American’s for the last century have stood up to totalitarianism, communism, and terrorism.  When asked, we have come to the aid of our allies and attempted to act as an example for the rest of the world to follow.  That said, I think our three biggest exports to the world are philosophical. Two of these concepts come from the nineteenth century; Transcendentalism and Pragmatism.  The other is from the present day – the agile reformation.  All three of these diverse ideas influence me and my agile practice.

Transcendentalism seems very high brow and something out of a high school American literature course, but we see its influence around us.  The focus on individualism and finding a spiritual connection with the divine links it with the current new age movement.  Thoreau’s ideas of civil disobedience are part of every social justice movement.  Finally, the desire to embrace nature and simplicity is the central framework of modern environmentalism.  I see the concentration on the individual and desire to make the most of one’s time on earth outlined in transcendentalism to be revealing.  Life is too short to be working on poorly run projects and being involved in drudgery.  Work must not only provide material comfort, but it must give people purpose.  I thank transcendentalism for that perspective.  

Pragmatism was a significant movement in American thinking.  Its central idea is, “…the practical application of ideas by acting on them to test them in human experience.”  In other words, a pragmatist does not worry about grand theories of how the world works.  They are concerned about what ideas “work” in the world.  It is responding to change over following a plan.  To pragmatists, an idea or action is only useful based on its practical application in the world.  Pragmatism is why all cities in the United States have water treatment.  Thanks to Pragmatists we set aside our notions of free markets and individual liberty to charge everyone taxes to make sure water is safe to drink.  To reduce the spread of cholera and dysentery in our nation, we sacrificed some individual liberty.  This a classic example of pragmatism.  For a scrum master or agile coach, it means you need to reject ideological rigidity if you want the team to be more successful; in other words, respond to change.

Finally, we have to discuss the agile movement and how it went from an American idea to a global reformation.  The Scrum Alliance has gatherings in Dublin and Singapore this year.  The Scaled Agile Alliance is spreading knowledge around the world.  Finally, business from Korea to Canada attempting to take the Agile manifesto and make it work for their companies.  The reason why we have this broad acceptance of the new way of doing business is that it delivers improved results.  We are turning out software better and faster thanks to the agile reformation than any time in the history of the industry.  It seems pragmatism encourages these new ways of doing things in the business world.

So, this “Ugly American,” takes pride in transcendentalism, pragmatism and agile.  They are uniquely American ideas which are making the business community and the world a better place.

Happy Independence Day and Until next time.

March of the Flaming Squirrels

Pay attention to the Squirrels.

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

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

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

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

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

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

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

Until next time.

Well Fargo is a Victim of the Cobra Effect

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

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

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

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

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

Until next time.

Process is a lame excuse

Responding to change is like jazz, blues, and rock

One of the central tenants of the agile manifesto is responding to change over following a plan.  For someone with a background in science or engineering it seems commonsense.  Sadly, many people in leadership roles see responding to change as a threat.  This week I want to talk about “process” and why it get in the way of agility.

I have plenty of late nights and early mornings on the phone with off-shore consultants.  These meeting are typical stand-up meetings familiar with co-located teams.  It is also an opportunity to share technical knowledge.  According to the scrum guide, stand up meeting should be fifteen minutes long.  The scrum guide does not take into account a team thirteen time zones away and working with complex legacy system.  So our meeting lasts about thirty minutes and we have follow up calls between individual members.  We have no formal process but the scrum guide is not helpful so we responded to change over following a plan and had a longer meeting.

Many business leader like to say they have processes in place to minimize risk.  It has been my experience that many of those processes are in place to maximize control because those business leaders do not trust their people to do the job correctly.  This makes me sad.  Instead of working with customers and solving problems, many people spend their days wrestling with the bureaucracy and process.  Confronted with this environment people loose initiative and motivation.  Eventually, nothing gets done except the stale process.

This may have worked fifty years ago but product cycles are measured in weeks instead of years today.  People need to be motivated and engaged if the wish to compete in this new business environment.  Process makes it hard for people to be motivated and engaged because it discourages original thinking and ownership of decisions.

That does not deter business leaders from coming up with more process.  To them, a business is like a symphony orchestra with every not scripted and every performer knowing his or her place.  If someone deviates from the music sheet or the conductors instructions then they are expelled.  I strongly disagree with this metaphor, I see a business like a jazz or blues combo.  The players have strong technical skills but com improvise based on the situation and can adapt to changing situations with the audience.  To a command and control business leader, this is unacceptable and a recipe for chaos.  To the agilest, it is responding to change over following a plan.

One of my favorite stories about Jazz history is about Benny Goodman.  A critic said his music was immature and untrained.  Goodman responded by recording Mozart’s Clarinet Quintet in A major to critical and popular acclaim.  In a more modern context Wynton Marsalis plays trumpet in both jazz in classical situations.  Finally, Trombone Shorty easily transitions between Jazz and Rock music.  In short, it is common for jazz musicians to cross over into other styles of music while it is uncommon for classical performers to do so.  I blame the “process” of training and conditioning of classical musicians who struggle in ambiguous creative environments.

This is the big challenge of business.  Do we want our employees to be like classical musicians of like jazz musicians?  In my opinion, I am going to trust my business to the jazz nerds.  The will be able to respond to change when necessary.  This is why I rebel against process.  I see process as a necessary evil.  I also see it fungible and able to change.  This drives my superiors crazy because sometimes the process is the only thing which keeps them in control.  Squeaky wheels often call attention to a bad axle and managers hate that.

So I say to you, treat process with contempt and skepticism because it is an excuse for behavior at a company rather than a reason.  This makes it impossible to respond to change.  W.E. Deming said, “Survival is not mandatory,” if you follow process chances are you are more likely to become extinct.

Until next time.

Being a scrum master is about struggle.

This is what struggle looks like.

Some careers are prestigious.  Others people have high paying careers.  Finally, there are plenty of people who define their careers based of the daily struggles they give.  This week after a long three day weekend I want to talk about struggle.  

When I hear the word “struggle” it sounds like a cliche.  I have heard pampered athletes use it to describe contract negotiations.  I have seen interviews with escaped murderers talk about their “lives of struggle.”  I have even witnessed a teen-ager user the term “struggle” to describe efforts to find a liquor store to sell him beer under age.  Struggle can get to be pretty meaningless because it has so many different meaning to so many different people.   Describing struggle seems just as futile as describing “love.”

My definition of struggle requires personal sacrifice in the face of indifference and hostility.  The example I use to illustrate struggle is the lives of ballet dancers.  For years, they toil in obscurity.  A dancer can spend hours practicing and in rehearsal.  They contend with abusive instructors, self-doubt, eating disorders, and injury.  All of this pain and sacrifice for a chance to be on stage and hear the applause of the crowd.  Dancers also suffer a physical toll for this life and it is clear to see when you look at photographs of the feet of dancers.  To me, that is struggle.

A scrum master’s life is to be in a constant struggle with the organization, colleagues and the status quo.  You are like Don Quixote in Man of La Moncha jousting with windmills and upsetting the authorities.  It is not the kind of career which allows quick advancement up the corporate ladder.  A scrum master must listen like a minister, inspire like an apostle, and be ostracized like a martyr.  They should have good technical skills and social skills good enough to act like a therapist to the people around them.  It is not an easy job. 

So to be a scrum master is to live a life of struggle.  You don’t go into it for fame and fortune.  You do it in order to make a difference in the organization and if that is not why you are their then you need to be doing something else. 

Until next time.