Monday, June 19, 2017

Beware the Temptation of "Dark Scrum"

Avoid the temptations of "Dark Scrum"
I have been an agilist since 2009.  I began collecting certifications for Agile and Scrum since 2013.  I even finished up my master’s degree studying the differences between waterfall and iterative project management processes.  I have some skills.  What I find most challenging as an agile practitioner is a disconnect between those of us doing the work and the business people who depend on us.  When this happens, it creates a situation Ron Jeffries calls, “Dark Scrum.”  As a scrum master and agile coach, it is your duty to avoid this situation.  This week on the blog avoiding the temptations of “dark scrum.”

In my formulation, "dark scrum," is when the business users of Scrum use the methodology to enforce control over software development rather than use it to improve quality and customer satisfaction.  Jefferies gives plenty of good examples on his blog, but I would like to provide two more.  I consider them to be pathologies of a dysfunctional organization.

Dark scrum pathology – shoehorning arbitrary deadlines on to sprints.  

One afternoon, I was in the office of a Vice President.  I had been raising concerns with him that a project was going poorly and that I would need his support and intervention.  The meeting did not go well.

“I promised the board that this project would be done by X date,” he said.

I told him based on the stories we had and a three-week sprint cadence we could deliver by a later date.

“You are agile, figure it out,” the VP said, “I need it by X date.”

The executive violated the social compact of agile, and we removed stories and features to meet the arbitrary date.  The customer was disappointed, and the Vice President looked bad.

Dark scrum pathology – why do I have to meet with the off-shore team.

Product owners write stories, but because of the time difference between the onshore and offshore components of the project, did not participate in the stand-up meetings.  We had created a situation where the developers would ask questions, and it would take over 24 hours to get them answered.  Product owners also complained that the team was not understanding the detailed requirements to get the work done.  When prodded to attend the stand-up call with the off-shore team a product owner indignantly said, “I am not waking up that early to talk with India!”

We were able to correct these pathologies.

To address the arbitrary deadline problem, bring in executives and product owners to level set expectations.  In the world of Scrum, the product owner is the person primarily responsible for the success or failure of a project.  The executives outside the team are responsible for funding and helping to remove organizational obstacles.  Knowing financing and deadline commitments provides the product owner a framework to write stories.  The scrum master can then use team velocity and the sprint cadence to let everyone know when a deadline is realistic and when it is not.  This way the social compact of agile is respected, and there are not secrets for all the parties involved.

We solved the next pathology by moving up the stand-up meeting by thirty minutes.  The product owner could take the call from home when they got out of bed but before they came into the office.  Product owners answered questions quickly and user stories improved.  Also, automated testing got better as product owners relied on the offshore QA professionals to streamline acceptance testing.  What was once a burden, became a win-win for the entire team.

The hard part about being a scrum master and agile coach is you are forced to come up with solutions like this each day to prevent your organization from falling into “dark scrum.”  Any situation where those in power ignore the input of the people doing the work is going to add darkness to the organization.  It is why the agile reformation is so important.  By beating back the pathologies of “dark scrum,” we can be successful software developers and professionals.

Until next time.

Monday, June 12, 2017

Leading by example for the scrum master

Any good scrum master will tell you the hardest part of the job is servant leadership.  Each day you need to sublimate your wants and desires for the good of the team.  It is a difficult road to travel, and I want to discuss it this week on the blog.

I find plenty of inspiration from the United States Marine Corps.  They were into servant leadership before the concept had a name in the business world.  All Marine Corps officers learn the phrase “Ductus Exemplo,” which is Latin for the phrase “lead by example.”  That means Marine officers are expected to be an example to the troops they lead and each other.  They eat last.  They make sure their appearance and equipment are “squared away,” so that other troops will follow along.  They don’t rest until everyone come back from patrol.  Finally, they don’t ask anyone to do something they would not do themselves.

The scrum master has plenty of other responsibilities.  They are making sure the team is improving each sprint.  They train product owners and hold them responsible for their work.  They are learning new techniques to keep up with the latest technology trends.  It is late nights doing production pushes with the release team and early morning working with offshore developers.

The reason for many of these sacrifices is simple.  Someday you are going to need developers to work late or a product owner to go above and beyond the call of duty.  That is when they will follow your example and come through.

In short, servant leadership is leading by example and something you will have to do if you want your team to succeed.

Until next time.

Monday, June 5, 2017

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.

Monday, May 29, 2017

All about the craft of Scrum Mastery

A good scrum master is like a good camp counselor
I take inspiration from plenty of people online and if you have followed this blog for any length of time you will realize I am not afraid to cite my influences.  I have also been a brig proponent of Scrum Mastery being a profession which requires more than showing up to the office.  This week, I want to talk more about the craft and business of being a scrum master.

I have said before being a good developer is in many respects like being a good jazz musician. You can say the same about being a scrum master.  A scrum master must have some technical chops and be able to perform their duties regardless of the situation.  You need to be prepared for anything and flexible enough for when the unexpected happens.  It is hours sitting around with developers active as a “rubber duck” to help them solve problems.  It is listening to them vent about frustrations. Finally, it is about continuous improvement.

It is not an easy job.  One moment you are a therapist for a developer and the next you are disciplining a product owner who is not doing their job.  I have had moments of deep rage where I find myself shouting at my house plants.  The anger is contrasted with sublime satisfaction knowing I am shipping software and helping the business meet customer needs. I have experienced every emotion between these two polls.  Each day is a new adventure and series of emotions to experience.
Companies are looking for scrum masters at an increasing rate because they are struggling to meet increasingly challenging customer demands.  They are also attempting to take dysfunctional cultures and transform them into something where people are willing to innovate.  They want to turn the peasant farmers who labor in their cubicles and transform them into warrior poets.

It takes strange and caring people to lead this kind of charismatic change.  The ironic part is these individuals are often entrepreneurs and iconoclasts who do not mesh with corporate culture.  I am sure every scrum master has a story about visiting the Vice-President's office for removing an impediment and ignoring the office politics.  I have discovered most transgressions are forgiven if you are getting software into production.

So being a scrum master is both a profession and a craft.  I would not have it any other way, and I am looking to help other people understand this career.

Until next time.

Monday, May 22, 2017

Avoid cynicism by networking

Never be a dark scrum master
After a few years working as a scrum master, a person can develop some gallows humor.  Every excuse elicits a chuckle of dark laughter.  Each setback and technical glitch generate a wry smile of world-weary acknowledgment.  This cynical detachment is a survival mechanism; otherwise, you spiral into a cycle of depression.  The trouble with this strategy is that cynicism is not a good way to lead others.  This week I want to talk about avoiding the trap of cynicism.

One of the great things about the Agile community is there are trade associations to support the people doing the hard work.  There are the Scrum Alliance and the Scaled Agile community who provide support.  These organizations also have trade shows and conferences which act as a means to provide continuing educations.  The biggest benefit to these agencies is that we are put in touch with like-minded people, and we support each other.

Former Secretary of State Collin Powel says, “Leadership is lonely.”  As an agile coach and scrum master, most of your time is spent in the lonely activity of leadership.  You are a member of the team but you also apart from it.  You are training product owners and helping developers improve.  You are also answering to management educating them on how Agile works and how the teams are delivering software.  This loneliness creates social isolation at work.

This is why I enjoy getting together with other agile professionals at user groups and conferences.  We can swap stories, exchange solutions to common problems and be a source of moral support.  It is nice to speak the same lingo to others and to understand your struggles making organizations better are their struggles.  For a few hours each month, I feel a little less lonely.

This is why I encourage others to attend networking events, training, and conferences.  The knowledge gained is valuable but the moral support from your peer’s help you fight off cynicism.

Until next time.

Monday, May 8, 2017

Software is NOT magic

I have spent much of my professional life building and leading others who build software.  It is a rewarding process but filled with countless hours of toil and uncertainty.  I liken it to solving a crossword puzzle on a deadline every day.  This week I want to talk about software and why the perception it is free is wrong.

The world of software development is a topsy-turvy world.  The first copy of the product is prohibitively expensive filled with thousands of dollars of engineering.  The second and subsequent copies are free thanks to digital copying.  To the end consumer, this makes software look like a free and magical tool.  Nothing could be further from the truth.

Each piece of software uses a database.  That database has a structure of tables which resembles a skeleton for the application whether it is a website, mobile application or shrink-wrapped piece of software.  Those databases do their work with a language called SQL.  Depending on the manufacturer of the database the SQL will be slightly different, so software developers have learned to specialize in the various dialects of SQL.  Specialization has forced companies to invest in one brand of database over another.  It is why one group is called an “Oracle” shop over a “Microsoft” shop.

Next software is dependent on what kind of device it will run on.  An application which will run on a mobile device will need to be constructed in one fashion while one which will work on the web will have to be designed differently to work it a different environment.  It requires specialization.  So someone with HTML and Jquery experience may not be very helpful on a mobile application project.
This kind of specialization is necessary for business. Specialization is also expensive, so business people want to save money by off-shoring the work to Northern Ireland or India.  It does save money but makes the process more complicated as we are coordinating with people eight to twelve time zones away.

Software needs to go through a quality control process and then released to the general public which requires more time and effort.  When finished, you see a shiny new app or piece of software.  It looks like it was free and effortless but it requires thousands of dollars and countless hours of effort.  Just remember that the next time you accuse your development staff of being lazy.

Until next time.

Tuesday, May 2, 2017

A March in the Mud

One of the dirty little secrets of software is for every splashy app or disruptive business there are countless hours of toil.  The mental exertion takes years off your life. Software also alienates because, to be successful, you need to be thinking about software and how to keep your skills current.  The compensation is generous but the mental and time demands of the profession are oppressive.  It made me think about what makes a scrum master successful.  This week I want to talk about the gritty nature of the business.

When I was growing up, I have a great Uncle Paul who fought in Europe with Patton’s Third Army.  He refused to discuss his experiences, and when asked about being in combat he remarked bitterly,” I was cold, and it rained a lot.”  Over the years, many of the combat veterans I have known have behaved in a similar fashion.  Whether they served in Korea, Vietnam, Desert Storm or Afghanistan; the prevailing attitude was I would be unable to understand their experiences because I was not physically there.  Instead, I relied on the narrative from books, documentaries and those veterans would share their experiences.

What struck me during my investigation was the tedium of military service.  Moments of terror punctuated countless hours of boredom and following procedures.  Each day is a grind with little room for heroism or glory.  While I have never made the kind of sacrifices required of combat veterans, the grinding nature of a military campaign is familiar to anyone who has worked on an I.T. project.  In fact, every developer has a story about being on a project which resembled a “death march.”  One of my favorite illustrations by Bill Mauldin, who created the famous Willie and Joe cartoons from World War Two, is tired and muddy American Troops guarding German POWs and they are marching through the rain.  The caption offers brilliant commentary, “Fresh, spirited American troops, flushed with victory are bringing in thousands of hungry, ragged, battle-weary prisoners.”  The irony being everyone during the war is tired, hungry and battle-weary.

Anyone who works on a software project gets tired and weary.  There are too many late nights, too many slices of pizza, and too many problems to fix.  In many ways, we are like those soldiers trudging through the rain.  It is why developers prefer agile methods over the more traditional waterfall approach.  Instead of long aimless slogs in the rain and mud, at the end of each sprint, we track our progress and take stock.  Big bang releases would become a thing of the past and development would be made more sustainable.

The reality has been more complicated.  As we have learned to release software in shorter intervals, business leaders have demanded that we cram more feature into each release.  So instead of work being a “death march” it resembles being pushed out of airplanes each sprint shouting “Geronimo” and hoping we survive the experience; this is not sustainable development.

Metaphorically, scrum masters and developers are seeking a happy medium between long marches in the rain and jumping out of an airplane.  Each day should feature a win or forward progress.  Developers should not put in heroic efforts or engage in crunch time.  It is a lofty goal, and if we are doing our jobs correctly, one the agile community can accomplish.

It takes communication with business leaders and regular deployments of software into production. We need to pay better attention to the DevOps movement to see how to implement continuous integration and pipelines for projects.  Finally, it means saying “No” when people demand ten pounds of sand fit into a five-pound bag.  To do otherwise means we are no different than those soldiers slogging through the mud.

Until next time.

Monday, April 24, 2017

Building systems which work one step at a time.

As a scrum master, I spend much of my time fitting square pegs into round holes.  This includes getting people who won’t speak with each other into the same room to work out issues.  It requires technical people half a world away working together. It is challenging and deeply frustrating.  Confronted with these challenges, why does a scrum master keep going.

One of the greatest articles written about software development is entitled “The Big Ball of Mud.”  It describes how most software come into being during the 1970’s and 19080’s.  It then goes on to illustrate how short term thinking, entropy, and poor software development created the legacy systems which many developers and consultants struggle with today.  These systems are rickety.  Often they are ignored until they are so brittle that they cannot scale or no longer serve the customer needs.  This is the world I live.

It is a world of stand-up meetings with off-shore teams.  Meetings with upper management explaining that Visual Studio 2003 is no way to develop contemporary software.  It is budget meetings where you have to describe continuous integration to an accountant who cannot monetize more responsive systems.  It is the world where I fill out performance appraisal goal sheets in spite of growing evidence that contemporary performance evaluation processes do not work.

As a scrum master, we do it because we want to build systems which work.  We do it because software developers should be making software instead of dealing with corporate politics and bureaucracy.  We do it because public companies need to make the transition to the current century and global economy.  The software is just the first step when we talk about business transformation.  It is why I keep going.

Until next time.

Monday, April 17, 2017

The Rabbits of Agile

An agile coach can learn from a bunch of rabbits.
It is the Christian season of Easter in the United States.  I take this time and spend it with my aging parents and enjoy the simple miracles of daily life.  One example of the elegance of the everyday life are the rabbits which live in my yard.  The warren living under my retaining wall has survived brutal winters, scorching summers, and the attentions of my neighbor who does not like them eating her rose bushes.  They wander around the yard, snack on of blades of grass and enjoy some table scraps from my kitchen.  In a confusing world, I can count on the rabbits giving me a brief respite from the global economy.

The rabbits are more than a form of escapism.  They are a reminder of the natural world.  Each day the world is trying to destroy that warren of rabbits.  Each day they find a way to gather food, avoid predators, and make more rabbits.  These creatures are fluffy and adorable survivors; reflecting on this reality, it dawned on me as an agile coach I can learn plenty of lessons from these specimens living in my back yard.

Charles Darwin said the species most likely to survive are the ones most responsive to change.  I have lived in my home for over thirteen years.  In that time neighbors have come and gone.  Fences have gone up, and many pets have made efforts to hunt down the rabbits.  With each change, the rabbits have adapted.  They forage around the fences and make themselves hidden when people walk their dogs.  A parent accompanies young rabbits, and thy do not bother snacking on grass when I put fertilizer down.  My neighbor has gotten into the act and has decided to stop planting rose bushes.  Change and responding to change are an essential ingredient to survival.

My rabbits reminded me of engineer and lean management pioneer, W.E. Demming who said, “Survival is a choice.”  Each day the rabbits in the yard choose to do what is necessary to survive.  The minds of rabbits are not as developed as humans, but every brain cell in the rabbit skull is preoccupied with survival.  People for all our mental ability can be distracted.  Distractions pull us away from the necessary things we need to survive another day.  Our obsession with status in the office distracts us from our jobs.  Obsessing over the stock price distracts us from providing customer service.  Being the alpha dog on the development team neglects necessary software quality.  Humans are distractible creatures, and those distractions pull us away from what is needed.

So each day as a scrum master, coach or business person is a choice.  You can choose to survive, or you can pay attention to the distractions surrounding you.  From a distance the choice seems simple, people want survival and necessity.  At the moment we concentrate of distractions, and they undermine our survival.  Choose survival and change over distraction.  If a rabbit can do it, so can a human.

Until next time.

Monday, April 10, 2017

Copping Mechanisms for this Scrum Master

Being a scrum master is hard.
Being a scrum master is living a life of servant leadership.  It requires others to follow your direction without having any authority over them.  It requires the patience of Job and the wisdom of Saul.  It is long hours and emotionally taxing.  This week on the blog I want to discuss some of the emotional coping mechanisms I use.

Dealing with Sleep –

Agile teams work anywhere in the world, and if you are a large corporation, any software solution requires an off-shore team.  Development teams are located in India, Northern Ireland, and Russia.  All of these places are numerous time zones away which means to communicate with them you need to be up early in the morning or stay up late.

I have decided to take the early morning route.  My day begins at six and ends at three in the afternoon.  I am usually in bed by 8:30 PM and the process starts over the next day.  This time shifting allows me to deal with the off-shore teams.  It also grants me two hours of “me” time to do administrative work and writing before others get into the office.

Working with Others – 

Servant leadership requires mental toughness because you work with messy people; individuals who don’t follow instructions or won’t take coaching.  Each day, I am forced to work with these messy people.  It is the most difficult part of my job because I am accountable for these individuals.

Lately, I have punted in this responsibility leaning on my human resources professionals and upper management to deal with these situations.  I go about my day attempting to serve as an example to others and trying to be kind.  Sometimes, it is all you can do.

Unwinding –

The hardest part about working in technology is that your mind is always attempting to solve problems.  You may be out of the office, but your mind is still wrapping around that gnarly data issue holding up the project.  You are attending a family function, but mentally you are back at the office.

It is why weekends are so important to me.  I do not respond to mail from the office or offshore. I try to enjoy lighter activities.  Finally, I avoid my computer for a full day.  This little bit of unplugging goes a long way.

So these are some of the strategies I have to deal with the emotional stress of being a scrum master.  I would like to learn some of your techniques.

Until next time.

Monday, April 3, 2017

All about forgiveness

Talking about forgiveness.
It is evident to me that 2017 is the year of messiness.  Software is a messy activity.  The clutter is caused by the human emotions of foibles which are part of the creative process.  As a scrum master, you are the servant leader of messy people who write software.  You are supposed to live the agile manifesto and principles.  You set the example.  As a scrum master, you set the tone and help the team succeed.  It is rewarding work, but I have my moments where I am not very proud of the example I am setting.  Continuous improvement means striving to get better.  It also means you need to be able to forgive others and yourself.

My professional career has was shaped by my training in journalism and engineering.  The world of mass communications is very judgmental.  We criticize television anchors for hair color choices and how good their dentition looks on camera.  Radio disc jockeys are slaves to ratings and program managers who can crush your career.  Ratings mean money and if you provide ratings, people will ignore some of your worse personal faults.

Engineers are also a judgmental bunch and are willing to back up that judgment with the scientific method.  The code could run a few nanoseconds faster.  The class could better use the Liskov Substitution principle.  Finally, you could always tighten up the code to make it less error prone.  There is additional machismo where team members compete to assert dominance using their intelligence or programming skill.  It is brutal, and these environments discourage vulnerability and innovation.

As a scrum master, you are encouraged to help remove these dysfunctional behaviors.  Sometimes a scrum master gets caught up in these bad practices.  When you do, you are going to hurt the team.  When you hurt the team, you are undermining your credibility in the organization, and with the people, you are supposed to serve.  The first thing you should do when you hurt your team or someone on it is making amends and apologize.  Asking for forgiveness is hard, but it reinforces the agile values of respect and openness.  A team which can forgive each other when they make mistakes is going to be higher performing than one which is not.

Forgiving yourself is a much harder skill.  We know ourselves better than anyone else.  We are also the least forgiving of our mistakes.  We can feel like frauds to ourselves, and this is imposter syndrome.  Our emotional intelligence may be below average, and we find ourselves in situations which would puzzle others.  Finally, emotional control can be undermined by people who just do not want to improve.  You become a tangled bundle of rubber bands, and you feel like you can snap at any minute.  You do snap you feel riddled with guilt and self-loathing.  Over my career, I have spent a few mornings thoroughly hating the person I see in the mirror.  These feelings are not rational or objective.  These feelings just are, and you cannot escape them.

I have been leaning on friends and family for the last few weeks to receive relief.  I am seeing a doctor in order understand if the stress of the role is contributing to my emotional recriminations.  Finally, I have been avoiding alcohol and caffeine.  My brain chemistry is bad enough, and I don’t need to make it worse with outside stimulants and depressants.  I am making a conscious effort to try and forgive myself for past mistakes.

From the outside, this process is not going to look beautiful, but I need to do it if I am going to improve as a scrum master.  Everyone deserves a dose of forgiveness now and then.

Until next time.

Sunday, March 26, 2017

Taking a sick week

The hardest part of being a leader is the emotional self-control.  How do you maintain your emotional even keel when you have people lying?  How are you supposed to trust people when they let you down on a regular basis?  How do you inspire others when they are more interested in the office pool and watching the clock at the end of the day?  Usually, in this blog, I try to provide answers which I have discovered over the years.  This week I am out of answers.

I am pretty worn out at the office and I have been struggling with sleeplessness.  I also am feeling whipsawed by professional and personal setbacks.  I am not much good to myself or anyone else right now.  I am kind of messy and in a corporate environment that is a forbidden state.

I will be back next week with more wit and wisdom but for the moment I am going to take a rest.


Until Next time.

Monday, March 20, 2017

Rage is when I am most vulnerable

Don Quixote got nothing on me.
Being a scrum master is a hard job.  It includes plenty of early meetings and late nights.  It is a life filled with stress.  Sometimes, there is a payoff when the customer is happy, and the software is in production.  Software development is a messy job.  Inevitably that dirt rubs off on people especially the scrum master.  Cleaning off this grunge has an emotional toll and this week I would like to talk about it.

As a scrum master and agile coach, I am a big believer in the idea of servant leadership.  The Marine Corps saying, “Ductus Exemplo,” is starting to become slang among business executives.  It is a fantastic concept, and I strongly support it.  The hardest part of being a servant leader is the everyday realities of being in charge of complicated software projects and managing people who are equally messy.  The mask of command and professionalism falls away, and you become vulnerable which for a leader is dangerous.

This danger of vulnerability means your raw nerves are exposed, and your emotions are controlling you rather than you controlling your emotions.  Losing emotional control means you will say things you should not and do things impulsively without thinking them through.  It is a dangerous place to be and one which can undermine your leadership credibility.

I have to confess that the above situation happens to me more than it should.  I become a fountain of rage at times.  In particular, when confronted with an individual who refuses to be accountable for their conduct I become a character from a Robert Louis Stevenson novel.  I get angrier when I spend time coaching someone, and they ignore my direction.  It makes a person feel like Don Quixote jousting with windmills.  The reward for your trouble is getting knocked off your horse and the laughter of by-standards.  Getting up and dusting yourself off to do it again looks stupid and futile when you have to do it with weekly regularity.

So here I am at my most vulnerable, filled with rage, feeling like a failure and believing the effort is futile.  These feelings can be fleeting, or they linger.  It is the worst when you are alone in bed trying to sleep, and the vulnerability is thicker than the darkness in the bedroom.

Like any leaders, I have to deal with these emotions and the emotions of my team.  It is not easy.  The rewards are fleeting. I promised myself that when I became a business leader, I would try to be firm, fair, and inspire others.  I fall short from time to time, but I still aspire to that ideal.  I have no choice; it is a promise I kept to myself and to the people I serve.  People depend on me.

Until Next time.

Monday, March 13, 2017

"Never Events" in Software Development

Without "Never Events"
a doctor is nothing more than a glorified butcher
There is a phrase in the medical profession known as a “never event.”  It is something that should never happen in a hospital or another medical setting.  People have been practicing medicine since Neolithic times.  We have only been writing software for about seventy years.  I think we can learn a few things from the field of medicine and I would like to discuss it on this week’s blog.

The term “never event” came from a medical paper from the National Quality Forum.  These are mistakes which should never happen in any medical setting.  Some examples of these never events are, people receiving the wrong type of blood during a transfusion, surgeons amputating the wrong limb, and discharging an infant to the wrong set of parents.  If something like this happens, the doctor is subject to profound liability, and a patient could die.  It is why they are called “never events.”

I thought about this, and I felt that those of us in the software business should have a series of “never events” for our profession.  If we are going to improve in the agile community, we need to have a set of standards and those standards should include things which should never happen.

Here is my list of never events for software development –
  • Code which exists in production should never reside on individual’s computer; it should all reside in source control.
  • The database administrator should never ignore system backups of data; data should be backed up regularly and before scripts are applied to the system.
  • All code which performs business logic should have unit tests; this way you will understand where the system has changed and what the possible changes are.
  • Network servers should receive regular patches and security upgrades; this will discourage hackers and avoid technical debt.
  • A developer should never work longer than 10 hours; fatigue causes mistakes.
  • Before checking in the code, it should be code reviewed by another developer; an extra set of eyes on the code prevents errors and helps to learn.
Those are my starting points for “never events” in software.  Look forward to what each of you thinks should be included on this list.

Until next time.

Monday, March 6, 2017

Why good developers put up with bad workplaces.

Working in technology should
 not feel like being in a sweatshop.
I touched a nerve with my blog last week and it kicked off plenty of debate.  What struck me was the insight from Steve Seather who asked, “…why would anyone work in such a wrong place?”  This week why good people put up with bad workplaces.  I have been a contractor and full-time employee in the technology business for almost twenty years.  I have a lot of experience in bad workplaces.  I will also cop to the fact that I was a poor software developer for the first ten years of that career.

According to the United States Census website, approximately 7.3 Billion people live on the earth.  According to the Verge website of that roughly 18.5 million people know how to write and maintain software.  If you do the math, only .05% of individuals on the planet know how to keep the modern global economy moving.  In short, there is too much work chasing too few people able to do the job.

Since software can be written quickly in a cafĂ© in Nigeria or a pub in Northern Ireland, the laws of supply and demand get twisted into a pretzel.  Domestic developers are pitted against offshore teams to keep wages low but because the skills are still rare wares are relatively high compared to other professionals.  Something has to give, so IT professionals become swamped with work.

IT professionals commonly work long hours and fight unrealistic deadlines because of this labor shortage. Software professionals become contingent workers because much of their work is project based.  They are hired and fired at will and often treated with contempt because they are often “the geeks” they have to pay.  So many people in the profession do receive excellent compensation, but they have zero security or respect.  Like rock musicians, they are only getting paid when they are working.  Unlike rock musicians, we rarely have adoring fans.

Making matters worse is the H1-B visa.  The United States immigration service provides this service.  In short, if you are a foreign national and work in the United States you need an H1-B visa.  If you lose your job you have 30 days to find a new one; otherwise, you are deported. Over my career, I attended many staff meetings where everyone was afraid to talk because if they offended the Vice President, they would be rolled off the project and deported back to the country of origin and this is why I compare the H1-B visa to indentured servitude.

Finally, many managers who lead IT teams have no understanding of the messy nature of building software and treat it like the manufacturing of machine tools.  They use project management and manufacturing techniques to lead IT professions which create numerous situations of labor alienation and crushes productivity.  IT professionals like any other employee have to put food on the table.  IT professionals put up with the lack of respect, overwork, poor security, and incompetent leadership for one reason – the paycheck.

It should not have to be this way.  The Agile reformation started because many smart people felt there was a better way.  People could do work more productively and more sustainably.  It is why I am and agilest.  It is also why I will not put up with ever working in a lousy environment again.  I am getting to old for that kind of grief.

Until next time.

Monday, February 27, 2017

Harassment is NOT Agile

Harassment is unacceptable always
Writing software is one of the few human activities we have not been able to automate.  This is why people like Angela Dugan and I say that software development is a messy process.  In spite of the education and training necessary to be a good software developer the technology business still struggles with misogyny.  If software development is going to become agiler, we will need to address these issues.

I have been adamant on this blog that the technology world needs to be more accommodating to women.  I have openly criticized the misogyny of others in the technology business.  This week Susan J. Fowler described her experiences working as an engineer for Uber.  I will let the blog post speak for itself.  As a developer, you should not have to put up with unwelcome sexual advances from management.  Also, when you make a credible accusation of harassment, it should be treated seriously by human resources.

I think this is part of what Slate magazine calls, "..the open hostility many technology firms have for women." I have noticed this throughout my career and have repeatedly called it out.  Women are just as good as men as software developers. Gender is not an obstacle to success in this field.

I suspect that misogynistic men join the software business for three principle reasons; 1) they like building things, 2) they like showing off their intelligence for ego gratification purposes, and 3) people in the technology business like creative destruction especially if you can flout social norms.

Building things is a natural human endeavor.  Building things are traditionally masculine in many cultures.  Thus, women involved with technology could be regarded with suspicion because they took part in a traditionally male activity.  Since the rise of second-wave feminism, men have been pushing back in the indiscrete ways to women who want to participate in manly activities.  I firmly believe that this is insecurity on the part of some men who feel threatened by women competing with them for success.

Since the early days of Western civilization, men have enjoyed bragging.  They would brag about athletic prowess and business success. Scientists and philosophers would opine about their intelligence to anyone who would listen.  Over the last four thousand years, men continue to do these things and being the smartest, best, and most successful engineer is a gateway to more success.  Thus, the engineering culture of software includes plenty of people who are willing to tell you how smart they are.  A select few can back up that claim.  Throwing women into this completive and egotistical environment is a recipe for harassment.

Finally, the notion of creative destruction appeals to many.  For the smart but emotionally unintelligent, an algorithm is a tool for vengeance for every playground bully, spurned romance or humiliation suffered.  Success is the best revenge and what better revenge than to ruin someone who metaphorically kicked sand in your face financially.  For the people who are not technically gifted but are more emotionally intelligent and competitive, the world of technology gives them a place to move fast, take names, and amass lots of money and power.  Naturally, these folks gravitate to sales and management.

Combine the need to build things with egotistical preening and the ability to engage in creative destruction; you have a toxic stew of masculinity which is particularly hostile to female engineers.  If the technology business wants to become more agile and fruitful, this kind of behavior needs to stop before a sexual harassment suit with punitive damages in the hundreds of millions of dollars shuts down a promising technology company.

Quid Pro Quo sexual harassment or hostile workplaces are antithetical to Agile.  It undermines trust on software teams.  It halts the exchange of ideas at the firm.  Finally, it creates an environment of fear which acts as cancer on any organization.  As Agile Coaches or Scrum Masters, we need to be on the front lines and help manage this behavior out of any organization.  What happened to Susan Fowler should not happen to anyone at any company.  That fact it happened at a technology company makes me doubly determined to make sure it does not occur at any technology company I am associated.

Until next time.

Monday, February 20, 2017

Disagreement means learning

Listen and Disagree
It is invigorating to have back and forth between fellow agile professionals.  It represents the give and take of knowledge between people.  People inevitability disagree about subjects, and the practice of Agile is no different this week I would like to talk about disagreement.

One of the more interesting books about leadership is “Team of Rivals,” by Doris Kearns Goodwin.  The central thesis of this book was that President Lincoln had a unique leadership style where he relied on the opinions of political rivals in this cabinet to help him better manage the events of the American Civil War.  Having a room full of devil’s advocates made Lincoln a better leader.  Numerous other articles and books have also surfaced which emphasized that diversity of opinion and perspective is necessary for success and innovation.

Lately, my blog posts and discussion on the Google plus agile community are being challenged by coach from Europe.  Some people would recoil from this kind of push back; I do not.  This individual has credentials and plenty of experience in the field so while I may disagree with his opinion; I respect his perspective.  I am a firm believer in disagreeing with people without being disagreeable.

My approach to Agile and Scrum centers around the Agile Manifesto and Agile Principles.  The Scrum Alliance gave me formal training as a Scrum Master.  Finally, I have spent nearly four years in the role of a scrum master shipping software with domestic and offshore development teams.  I have seen some things and done some stuff.  My experience colors my agile knowledge and opinions.

The product owner has the hardest job in the scrum.  The Scrum Master is a Coach, Therapist, and often the bad cop which keeps things moving forward.  Finally, the development team generate shippable code each day and are the unsung heroes of the process.  I live this experience every day and hope each of you who read this blog gain from my knowledge.

Disagreement is healthy, and if you are not willing to consider other opinions and activities, you are not going to grow as Scrum Master.   Listen to others who you disagree with; you never know what you might learn.

Until next time.

Monday, February 13, 2017

When to Unleash the Kracken

Make sure you mean it!
I have called being a Scrum Master many things.  It is a coaching role.  Being a scrum master can resemble being a therapist.  I have even compared being a scrum master to a parish priest.  The job is not easy.  A scrum master has plenty of late nights and early mornings.  One of the things they discuss in training for Scrum Masters is an important responsibility.  A scrum master can terminate a sprint.  Trainers don’t often consider this awesome responsibility but this week I will.

When things go badly in spaceflight mission control can terminate the mission.  When that happens, the astronauts turn the ship around and head back to earth via the shortest route.  When things go wrong on a scrum team, we have what is called an abnormal termination.  The sprint ends immediately, the team does a retrospective and plans a new one.

There is a contentious debate in the Agile community about who has the right to terminate a sprint.  I belong to the ideological camp that a scrum master should have this terrible duty.  I feel this way because the scrum master is the protector of process and improvement of the team.  When the Product Owner or the development team is in a hopeless situation, it is up to the Scrum Master to recognize it and take draconian measures.

Terminating a sprint is a huge deal.  Do not do this lightly.  It should be the plan “C” or “D” for any sprint.  Terminating a sprint creates all sorts of attention in an organization and is profoundly disruptive.  When a Scrum Master kills a sprint, it is the equivalent of Zuse saying, “Release the Kracken!”  Do not do it unless you are certain.  Otherwise, it is like pulling a fire alarm because you do not want to go to class.

The following are the rare reasons why a scrum master ought to terminate a sprint.

Project funding has changed drastically-

In an uncertain global economy, projects get canceled, and new ones are spun up.  These events impact your plans.  If this happens, the scrum master may want to terminate the sprint.  The termination will give the Product Owner, development team, and Scrum Master a chance to take stock and decide what the next steps to pursue.

The Product Owner is fiddling with a sprint while it is in progress-

I working with a product owner who was under so much pressure they could not prioritize work.  Sprints would begin, and stories would be swapped out with others.  Things which were a priority during sprint planning would be dropped days before the end of the sprint and replaced with stories of equal size.  The development team was forced to try and do the same amount of work in half the time.  Confronted with this bad faith behavior, I hit the self-destruct button and brought it to the attention of my Vice President. Leadership replaced the Product Owner in the aftermath.  The development team resumed sprinting.

The team grossly underestimated the work they could do in the sprint-

We have all had the “ten-minute change,” conversation. A product owner or someone from the business asks for a change to the system.  The developer listens to the request absentmindedly and says the change takes approximately ten minutes to perform.  A week later the developer admits the change affected other systems and it would take longer than expected.  Soon the rest of the development team is sucked into correcting the situation.

As my mentor, Angela Duggan would say, “developers are afraid of looking incompetent or unskilled.” This fear pushes software developers to underestimate work.  The team commits to something and then realizes it is more complicated than first expected.  If your development team has with six weeks of work in a three-week sprint, it is acceptable to hit the reset button.

These are three of the rare situations where you might terminate a sprint.  If you have other suggestions, I would love to hear them.

Until next time.

Monday, February 6, 2017

Scrum should not be a cargo cult.

Scrum should not be a cargo cult.
Blogging about business and scrum opens you up to feedback and criticism.  Confronted by people who challenge your ideas allow you to reflect on your knowledge and beliefs.  A college of mine took offense to me referring to the meetings of a scrum as “rituals” last week.  I would like to address his concerns.

The primary criticism of my article was that I was encouraging a “cargo cult” kind of scrum.  The term comes from a Scientific American article from 1959 which documented primitive tribes in Melanesia coming in contact with missionaries and soldiers.  The connection prompted these indigenous people to create cults to encourage cargo to be delivered to them.  Primitive air strips, airplanes, and shipping terminals cropped up in the hope that actual cargo planes and people would show up.

The pre-modern culture felt if they mimicked the trappings of technology without understanding the principles behind that technology they would receive the prosperity which comes with modernity.  This assumption is wrong.  The tribes created many faux landing strips and cargo depots in the South Pacific.

People in the agile community, use the story of the cargo cult to illustrate the difference between going through the motions of agile and being agile.  In a perfect world, a business would reconfigure itself to follow the word and spirit of the Agile manifesto.  We do not live in a perfect world, so it is up to scrum masters and agile coaches to provide structure for the transition from traditional business to agility.

The events of scrum provide a means to help speed that transition.  Business people and developers are forced to inspect, act and adapt to changing situations.  That is the heart of an agile business.
When I refer to the meetings and events of the scrum as rituals, I mean the meetings should have purpose and significance.  I am not attempting to create a “cargo cult” in an organization.

I am glad someone challenged me on my assertions, and I look forward to more give and take in the future.

Until next time.

Monday, January 30, 2017

Why we have rituals in scrum

Becoming a scrum master is like becoming a priest
I am in the process of training a new scrum master at my office, and they asked why we have so many meetings in Scrum.  This week I wanted to share my thoughts on the subject.  The Scrum Alliance has plenty of documentation about Agile, the roles in a Scrum team, and rituals associated with it.  As an experienced Scrum Master, I wanted to dig a little deeper into the activities and explain why they are important.

The role of a Scrum Master is a complicated one.  I have written about the topic numerous times.  As I have grown more comfortable in the role, it occurred to me that this position resembles the life of a parish priest or Protestant minister.  You are always visible and accountable to the people you serve.  I firmly believe in the need for a human being to have ritual and routine in their lives.  Both Carl Jung and Joesph Campbell, mention that the collective unconsciousness is something which needs nurturing.  If we do this, then we are on the way to building effective teams.

The daily stand up-

Each day the team gathers around the metaphorical campfire and talks about what they have done, what they will do, and obstacles.  Working in an office creates a few anti-social behaviors.  It is very easy for people to cocoon into their desks and ignores others.  The stand up breaks people out of that unhealthy habit.  Each day for 15 minutes they interact with the scrum master and each other.  The group stands because it forces people to pay attention to one another.  It also keeps side talk to a minimum.  Finally, it helps foster a sense of teamwork because everyone is participating and involved in the success of the project.

After a few weeks or months, the scrum master should not facilitate the meeting.  Instead, the team should learn to run its stand-up meetings.  It is part of the ethos of self-organization.  It is essential to the success of agile at any organization.

Backlog Grooming or Refinement – 

The Product Owner has the most difficult job in agile.  They work with the “business” and the development team to create software each sprint.  Backlog refinement is where most of this job happens.  The Product Owner and the development team go over the backlog.  This meeting is designed to clear up any misunderstanding, explain user stories, and set priorities. It is an informal meeting with back and forth conversations.  The Product Owner facilitates this session.  It can be done regularly each day or scattered around a work week.  The keeps communication between the team and the product owners flowing.

Sprint Planning – 

The Scrum Master, Product Owner, and development team get together to decide what they want to work on in the next sprint.  Using the refined backlog the team and the Product Owner decide what to do next.  This meeting is a little more formal as the team estimates and tasks out the work.  The meeting also ends with a consensus about what the sprint goals are and how to meet them.

Sprint Review or Demo –

One of my biggest frustrations I had as a developer was spending a year on building a software product and then showing it to the user community and having them say it is not what they wanted.  The sprint demo is designed to eliminate this situation.  After a sprint, the development team shows off their work to the Product Owner and the people who are stakeholders in the project.  Here they gather notes and feedback where they can improve.  The demo also shows the business that things are getting done and that they will have software in a measurable amount of time.

The Retrospective – 

The retrospective led by the scrum master.  It is a combination of rituals.  It is about what happened.  It is also a look forward at how to improve.  Everyone participates in the process, and everyone contributes.  It is up to the Scrum Master to take notes and help the team improve on how it is supposed to do its work.  The retrospective is the most difficult part of the scrum process, so a scrum master good at facilitating meetings is essential.

So this is my take on the rituals of Scrum and why we do them.  They are all important, and if you do not do them, the effectiveness of your scrum teams will suffer.

Until next time.

Monday, January 23, 2017

The Messy Nature of Software Development

Software is messy
I have been in the software business for nearly twenty years.  I began as an entry level programmer and made the transition to scrum master and agile coach.  It was not pretty or heroic.  It was a journey filled with personal and professional setbacks.  Sometimes, I wonder how I didn’t wind up begging for change on the side of the road.  Somehow, every setback I have faced has led to a larger and better opportunity.  This week on the blog I wanted to discuss something which we do not discuss often; the messy nature of software development.

If you are not already following Angela Dugan’s blog, “The TFS Whisperer,” you should.  One of the posts struck me for its honesty and courage.  She talked about how application lifecycle management and DevOps are “messy.”  I add that everything involving software is messy.

The creation of software is a new trade.  It began in the days of vacuum tubes after World War Two and had grown into an activity employing a total of 11.5 professionals worldwide.  The term bug came from a moth trapped in a box of the first vacuum tubes of the ENIAC computer.  Today, bugs represent any of the defects or mistakes we perpetuate in code.

In the seventy-plus years since the beginning of professional programming, the activity has not fundamentally changed.  Smart people work in isolation writing software code, and business people take it for granted that is works.  The reality is software is one of the few activities which has not been taken over by automation.  It is a creative and manual process. It is both an art and science.

Unlike construction which has a set rules for engineering and gravity software development lives in a strange world where the rules do not matter or change with each release.  Deadlines are either fluid or hard as stone.  People work late nights and early mornings to get the product out on time.  Personal relationships suffer as support calls intrude on anniversary dinners and you are asked to release software on Sunday afternoons.

The people who do this work are smart and creative.  Too often the demands of the business community force leaders to treat these people like machines which run on caffeine and pizza.  The people who write software have children, significant others, and aging parents.  They have felt and experience the entire range of human emotions.  They are more than points of data in an Excel spreadsheet or a line item in a project plan.

It matters because software is one few activities in business which is immune to automation.  It is manufactured by hand by these creative human beings.  So software is “messy” because people under great pressure author it every day.  Software development is “messy” because people make mistakes.  It is “messy” because people have emotions which are hard to control.  Finally, software development is “messy” because business people treat software professionals as interchangeable “staff” instead of skilled artisans.

I have spent numerous nights questioning my ability and worth thanks to the messy nature of software development.  I am sure that other software professionals have done the same. This business is humbling.  Angela and I agree; software development is messy because very human people are involved in every stage of its creation.

Until next time.

Monday, January 16, 2017

Explaining being a scrum master to civilians.

A scrum master is a servant-leader
One of the things which make working in the 21st century so dispiriting is most people cannot easily describe the work they do.  During the middle ages, people were farmers, blacksmiths, nobles or merchants.  The roles and job descriptions were easy to understand.  Today, the work of content curators and account managers creates plenty of ambiguity and misunderstanding.  This week on the blog, I want to clarify the definition of a scrum master.

The Elevator Pitch

When I am at social functions, networking events or family gatherings people ask me what I do for a living.  I say scrum master and I get a puzzled look, and they ask me, “What kind of job is that?”

This is what I say.
“I build software and help developers and businesses develop software on time, on a budget, and with minimal bugs.”
The person nods and smiles, once this sinks in and switches to a new topic.

The Scrum Master Syllabus

When I describe the job of a scrum master, it often looks like a college syllabus.

A good scrum master is:
  • An excellent communicator with individuals, small groups, and the organization.
  • They understand the agile manifesto and principles of Agile and practice them every day.
  • They are a trainer and coach making product owners, developers better and their job.
  • They educate business leaders and stakeholders on how agile is making their business better.
  • They are good listeners
  • They have grace under pressure
  • The can educate developers on TDD and SOLID development
  • They are servant leaders
  • They ship working software regularly.
  • They make a god damn difference.
These are the signs of a good scrum master, and I try to aspire to these goals each day.

The bottom line.

Being a scrum master is a hard job.  It is also a calling of sorts closer to being a priest or pastor than a software professional.  A good scrum master can reinforce your belief and faith in agile, or they can turn into a tool of oppression.  I have never been into oppression, and I want to be someone who makes a difference.  That is why I am a scrum master and why I have such high standards for the profession.

I hope this clears up any misunderstandings.

Until next time.

Monday, January 9, 2017

Continuous improvement is a scrum master job.

Development is a lot like theater
One of the greatest things about my job is that I spend numerous hours working with people.  I am learning new things on a constant basis.  I also spend time teaching others how to be better in the workplace.  It is this back and forth which keeps me going into the office.  This week I was asked about how you inspire teams to make continuous improvement.

Business professionals use sports metaphors to describe what they do.  I was never any good at sports, so I look business through the filter of music and performing arts.  I think it is a more constructive way to look at the work.  There is no scoreboard hanging over the cubicles in the office.  Business leaders are often too busy to chart out plays, and there is no playoff season or championship.  Business is an ongoing activity.

To me, the world of work resembles repertoire theater or a jazz orchestra.  Each week the company needs to put on eight shows a week with a matinee on Sunday.  The quality of the performance needs to be professional grade because people will not pay big money to see an elementary school recital.  People get sick, and performers drop out but in show business terms, “The show must go on!” If the show does not go on then, people do not get paid.  The cruel arithmetic of performing arts is that quality must be outstanding and that people must want to purchase your product.  Otherwise, you starve.

So as a Scrum Master or Agile Coach you need to look at your job as if you were a theater director or the leader of a jazz band.  Instead of being autocratic about the work, you will need to be collaborative.  You will have to get to know the people you work with and understand them as people.  Do they have children, are they single, is this their first job or do they have experience?  Do they show up for work on time?  Are they prepared?  Can they improvise and can they handle the pressure?  As coach and scrum master you need to know.

Once you understand the above, you can lay out the goals and mission of the team.  Scrum is good about this.  Each sprint has a beginning, middle, and end.  The release of working software should is like a performance.  When the curtain falls, the scrum master and the team decide how to do better job next time.

I am a big believer in the 1% principle.  Each sprint, I want to improve the performance of the team by 1%. If I have thirteen iterations in a year, the team has increased its performance by 13%.  Over a period of five years, that would be a 65% growth in efficiency.  That is the kind of return which creates pay raises and promotions.  So create small increments of improvement and meet them.  Over time, you will be amazed by the results.

Finally, Agile and Scrum can not overcome a poor work ethic, incompetence, or stupidity.  Being average is not sufficient.  As a coach or Scrum Master, it is your job to help everyone become a better team member.  People unwilling or unable to improve must go.  It is best for the individual and the team.  It is one of the hardest decisions to make.  As someone laid off multiple times, I speak from experience.  Each time I have lost a job I have bounced back and been a better developer.  Nothing focuses the mind quite like unemployment.

So look at your role as a theater director.  Get to know your people.  Collaborate with your team and hold them accountable for small improvements over time.  Finally, remove people from the team holding them back.  Being a scrum master is not easy, but it is the most rewarding job you will ever do.

Until next time.

Monday, January 2, 2017

Looking back and forward - 2017

After 2016, I think we
all need a tall glass of wine
Technology is a dynamic industry.  One moment you can be on top of the world and the next you are like Nokia unable to adapt to market conditions.  This week I am going to take a look at some of my predictions from last year and see how accurate I was and look ahead to 2017.

Looking back, it is clear that when I paid attention to technology and trends in the industry, my predictions were accurate.  Apple computer did have a rough year with tax issues from the European Union and sales which dipped for the first time in years.  Microsoft is growing its business with the Azure cloud services and a full embrace of Linux.  It also has surprising sales of its Surface Pro 4.  They are still going to founder in the phone market, but they are ruling in the desktop and enterprise realm.  My prediction that the Scrum Alliance was going to have some growing pains came to fruition.

When I looked at politics in 2016, I was wrong.  I predicted that election season would be a draw with the Democrats retaining the Presidency while the Republicans would keep the House of Representatives and lose the Senate.  Instead, Democrats made slight gains in the House and Senate while losing the White House by the statistical margin of error in Wisconsin, Michigan, and Pennsylvania.  President Trump's mandate is about 100,000 votes in three states which are .08% of the total votes cast.  Please read this great article with lots of wonky footnotes on how this happened from Vox.  Republicans have complete control of all three branches of government since 1929 in spite of their razor-thin margins of victory.

As a blogger and pundit, I need to take responsibility for when my predictions are correct and when I get them wrong.  I also should learn from my mistakes and extrapolate what I need to do to make better predictions.  Here is what I expect in the coming year.

Big Fight over Net Neutrality.  

There are already rumblings in the new Trump administration that net-neutrality is going to open to discussion.  Changing the current net-neutrality rules will be a gold mine for cellular phone providers and cable companies; it will be bad for everyone else. The internet rose up in rebellion and forced members of Congress to drop support for a law which would have made pay to play access to the web law of the land.  This time around the fight is not going to be in Congress but in the FCC and it is going to be harder because political appointees are going to be much less susceptible to public pressure.

Deregulation a-go-go

Many Republicans have a love affair with Ayn Rand.  Now that Republicans control all three branches of government prepare for a full wave of deregulation in technology and business.  Overtime rules will be cut back.  Financial regulations will be revoked, and a worker in this economy is going to have a more difficult time.

Those are the only two big predictions I have for the new year.  The interesting thing about working in the technology world is that change is a big constant.  If you are not paying attention, then you are bound to be surprised by something.  I look forward to being along with you for the ride because 2017 is going to be a challenging year.

Until next time.