Embrace the Pain and the Progress of Agile

I am busy with my work commitments and researching a book.  As part of my research for the project, I have spent time reading about topics outside my comfort zone.  One of the topics is an understanding of Lance Armstrong and his doping scandals.  While doing this research, I discovered the deep wells of endurance and dedication it takes to be a professional cyclist.  Each cyclist has masochistically embraced pain and suffering.

Reed Albergotti and Vanessa O'Connell described three-time Tour de France champion Greg LeMond book in their book "Wheelmen,"

"He'd hit 5,000 feet, and the air would get thin. He'd feel light-headed. He'd breathe hard. So hard he couldn't think anymore – couldn't feel anything.  And LeMond liked it that way.  He was happiest when he was suffering when he was in total pain."

LeMond was an abused child, and he would get on his bicycle and ride.  The physical pain and adrenaline were his escape mechanism.  

What many people consider masochism was a typical day's effort for a professional cyclist.  With little fanfare and attention riding, six, eight, ten hours a day, the rider would climb steep mountain trails at altitude and pursue a constant diet and exercise routine.  The routine of suffering had few guarantees because everyone else we doing the same things to remain competitive.  

After a call with my development team in India, it occurred to me that the life of a technology professional is similar to a professional cyclist.  Most people do not see the hard work and attention to detail software developers and quality assurance professionals put into their work.  The hours spent tweaking algorithms, troubleshooting bugs, and tuning database tables are invisible to the software users.  It is a grind, and it resembles the suffering of professional cyclists. 

As the coach and leader of your team, it is your job to put that suffering and grind into perspective.  Measure things like defects, lead time, number of stories getting done per sprint.  Spot trends and point out improvements.  Show your team that the hard work is paying off.  Finally, expose the team to the people using the software.  It will allow the people doing the work to see how all the effort is paying off. 

The emotional labor it takes to lead a software team is challenging, but if you put in the effort, there is a big chance that it will pay off with a victory lap or two when you complete the project.  I hope all of my readers have a fabulous Christmas holiday, and I look forward to more adventures in 2022.  

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. 

It Takes Labor and Intelligence to Make Magic

It looks like magic but it is something else.

The software business is a strange beast.  Developers wrestle with ones and zeros to create things that only existed in someone’s imagination.  We exchange terabytes each second to help us shop, get driving directions, or book a vacation.  The raw computing power we hold in our hands dwarfs the computing power which puts people on the moon.  Science fiction author Arthur C. Clark said any sufficiently advanced technology would be indistinguishable from magic. We live in these magical times, where we can get anything on our phones.  It hides an ugly reality that it takes a tremendous amount of labor and intelligence to construct these systems.  It takes more energy to maintain those systems and keep the global economy spinning.  I need to pull back the curtain and reveal the hard work behind the magic.

Software is written to solve problems or to automate a process.  The first electronic computers were created to break the Nazi Enigma codes and to calculate the trajectories of artillery shells during the Second World War.  These machines were ugly and ungainly.  The early computers did not have formal systems of logic or operations.  Smart people would have to come up with those systems.  Fortunately, the allies had people like Alan Turing and Grace Hopper to pioneer those advances.

The vacuum tubes of the early days of computers would give way to the transistors and then semi-conductors.  The transition from glass tubes to silicon wafers leads to an explosion of innovation including programming languages like Pascal and COBOL.  IBM used a startup company from Seattle called Microsoft to create the first operating system for personal computers.  The world wide web was born, and soon businesses sprang up to generate billions of dollars of wealth.  In hindsight, all of this “progress” appears inevitable.  In reality, it is the work of tens of thousands of engineers and software developers who will forever remain anonymous.

These were people who sacrificed time with family and friends to stare at green computer screens attempting to squeeze additional seconds of processing time out of applications.  These were people who came up with algorithms that allowed efficient organ donations.  They were UI/UX designers who discovered horizontal scrolling hurt sales and created designs that improved closing rates.  It was late nights, cold coffee, and exhaustion, which constructed the technology we take for granted.  I am one of those anonymous foot soldiers in this march of progress.

As I became more experienced as a software engineer, I realized the way we lead those projects was not improving with the technology. We were doing the same crazy things and expecting the same results.  It is why I become a member of the agile reformation.  I wanted to make a change.

Today, many of the people making decisions about technology have not constructed that technology.  These people have ideas but no practical knowledge of how to make those ideas work.  Confronted with this reality, they have engineers, developers, and designers to make the idea a reality.  Unfortunately, because they think technology behaves magically, they believe its creation is a magical process.  It is not magic but the product of hard work and intelligence.  No amount of wishful thinking will change the realities of Moore’s Law.

It is why we have the agile manifesto and principles.  We want our work to be more sane, satisfying, and sustainable.  It is only four values and 12 principles, but they make all the difference in an organization. We do live in a magical world.  It is a world created by the sweat and toil of smart people.  By understanding the labor which goes into technology, we can make the world a little more magical.

Until next time.

Scrum Master Dragon Slayer

This is a typical agile implementation

Growing up in the 1980’s, when you set aside the prospect of the United States and the Soviet Union having a nuclear exchange, it was an excellent time to grow up.  Dungeons and Dragons were part of the popular culture and the movies reflected this trend with films like “The Sword and the Sorcerer,” “Conan the Barbarian,” and the cult classic “The Beastmaster.”  For a nerdy teenage boy, it was beautiful escapism.  It was also a way to learn a few serious lessons about life.  "Excalibur" showed the cost of infidelity to a thirteen-year-old who had not started shaving.  The most significant lesson came from a dark Disney film entitled “Dragonslayer.”

The film had a simple plot.  A dragon is terrorizing a local kingdom, and a wizard and his apprentice must slay the creature. The mission has additional urgency because the king’s daughter has arranged to sacrifice herself to the dragon.  The story has all sorts of threads woven together.  It is the sixth century, so Christians are using the dragon to recruit converts.  The pagan king sees the Christians and their desires to undermine his legitimacy as more important than the life of his daughter.  There are an aging wizard and impetuous apprentice along with a princess and a fire-breathing dragon to round out the cast.

Late one night in a moment of insomnia, it dawned on me this movie was the perfect metaphor for an agile implementation.  The wizard and apprentice are consultants hired by the king to help him solve his dragon problem.  These consultants discover the depths of the political and social rot in the kingdom which threatens to consume them.  Finally, there is the climactic moment where the dragon has to die.

People behave certain ways and do certain things because people have behaved that way for centuries.  Everyone is looking out for themselves, and the dragon is always in the background ready to bring destruction from the air.  I cannot describe a better way to explain a contract engagement with a client if I tried.  

The most galling portion of the film is after the dragon dies; the local king stands over the corpse of the beast with a sword and stabs the dead creature while his Chamberlain proclaims the king a “dragon slayer.”  Countless people have died in the process, and the Christians use the death of the dragon as a recruiting tool.  It almost makes a person wish the dragon could win and turn the entire kingdom into ash – almost.

Like someone who has had an agile practice for the last eight years, I identify with the wizard and his apprentice.  I am training others to be better developers, product owners, and scrum masters.  I am also looking to help develop my skills to make myself better and more useful to my clients and employers.  Often, I encounter internal rot in organizations and have to focus on the dragon flying overhead instead of the more long-range problems.

As a scrum master and coach here is what I do.  Considering I have hired to slay a dragon, the first thing I concentrate on is killing the dragon.  A common phrase in business is “…first things first; last things never.”  Fix the dragon problem.  I expect that the king will take credit for my work.  They did not become King being kind people.  Next set an example so that other villagers will aspire to be wizards.  The practice of agile will only grow if it spreads person to person.  Certifications and trade shows are necessary, but the only way it is truly going to take over the business world is when conscientious practitioners make the agile manifesto and principles work for companies.

Finally, know when to ride off into the sunset.  An agile coach and scrum master are often a threat to the executive leadership because they are more interested in getting work done than the political niceties executives seem to give more priority.  When this happens, tip your hat to the king who took credit for your job and ride off into the sunset.  It may explain why many of the better wizards of literature wander or are hermits.  Working for the King is a sure road to stagnation.

So as one sorcerer apprentice to another; always slay the dragon, recruit more apprentices by your actions, and ride off when you are not needed or wanted anymore.  It certainly beats winding up in the belly of a dragon or the king’s dungeon.

Until next time.

The Hero's journey is no substitute for a product

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

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

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

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

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

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

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

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

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

Until next time.

Your Developers Are More Than Resources

These are more than resources

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

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

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

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

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

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

Until next time.

A scrum master should do more than punch a clock

A good scrum master is like a good camp counselor

As we head into summer, it is a good time to reflect on the first half of the year.  I am going through numerous personal and professional changes.  My role is going to be changing at my firm and there are plenty of comings and going.  This week I wanted to discuss some insight I gained at the office.

Many of you know, I am a big fan of Angela Dugan and her blog The TFS Whisperer.  For three days, she came to my firm and conducting training for Visual Studio Team Services and spent quality time with Product Owners at my firm.  What happened next was a revelation.  The following Monday half of the scrum masters in the organization were rolled off.

I think it would be unprofessional and small to discuss the details of why those scrum masters are gone.  Instead, I will say their departure reflects a divide in the agile profession of scrum master.  There are two camps; one camp see being a scrum master as being a glorified project manager, the other camp sees the scrum master as a servant leader, coach, and therapist for development teams.  I belong in the latter camp.

There is plenty of blogs on the web which say that being a scrum master is not being a project manager.  Yet, I see some scrum professionals who see their job as nothing more than scheduling meetings and updating the scrum board too.  This is not being a scrum master.  It is a person accustomed to doing things the old way of attempting to survive in the corporate rat race.  They do not really add value and often create scrum-butt situations.

In my opinion, a scrum master is more than someone who punches a clock and generates reports.  They are more like a camp counselor or youth pastor minus the bad facial hair.  They have to hold other people accountable.  They have to train product owners to a basic level of competence.  They have to make sure that people are shipping working product into production.  Finally, they have to keep people motivated because software development can devolve into a soul-crushing activity.

In short, being a scrum master is hard emotional and intellectual work.  If you are not willing to do that work then you are likely to get rolled off a client.

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.

No More Heroes - Why?

Their is a difference between fast and agile.

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

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

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

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

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

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

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

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

Until next time.