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.
 
 

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.

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.

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.