How I became a Pirate Bear

I am a pirate bear. 

If you have been following this blog for any length of time, you understand that I have been an outspoken advocate of Agile and Scrum.  It has become the central focus of my career.  I am one of those eccentric and creative people companies want but do not know how to utilize.  I am an anomaly in the business world, and I am comfortable with it.

Like any other technology professional, I spend my free time learning new skills.  In preparation for the Scrum Coaches Retreat in London, I spent some time learning how to use #slack.  To be honest, I am still struggling with the platform.  It feels alien to me.  I have not mastered all the tricks, lingo or etiquette of a #slack community.  I think the same way I did eight years ago when I started using Twitter.  I was able to master that, and I will be okay with the new platform.

When you join a new social network one of the more important things you do is choose a name where others can quickly identify you and touch base.  The same is true with #slack and since the network does not allow for duplicate names people rapidly get creative coming up with handles.  I decided to give myself the moniker “The Pirate Bear.”  I posted a color picture of myself in a fez and began my journey in #slack.  I was swapping information, slide decks, and gossip with other agile coaches for a few weeks when someone from England asked why I chose “The Pirate Bear.” I did not have a chance to answer the question then but feel compelled to answer it now.

Since I began my vocation as a technology professional, I have been heavy.  I blame this state of being on the nature of the profession and by using food to cope with the pressures most technology professionals confront.  I am both big and tall.  It prompted the woman who loves me to label me her bear affectionally.  Additionally, many of my LGBTQ friends and colleagues say that I would pass as a “Bear” in the gay community. I felt awkward about this at first, but I embraced it as good-natured teasing from friends.

Piracy has been a significant theme in the zeitgeist since Johnny Depp wore the costume in the first Pirates of the Caribbean movie.  Piracy has been the banner many rebels and outcasts have embraced since the age of sail.  Illegal radio stations sailed the North Sea offering programming the BBC would not provide. It became a pirate radio which has been copied by numerous radio stations around the world.  When Steve Jobs put together the product team of the first Macintosh, he told each of the engineers, “It is better to be a pirate than to join the navy.”  The secret pirate crew then changed personal computing forever.

It sounds very glamorous. The swashbuckling and mythology of piracy is quite appealing.  The reality is that a pirate’s life was dangerous and cruel with significant shifts between poverty and wealth.  A pirate sailor often faced execution if captured and often succumbed to illness at sea.  You chose piracy for many reasons, but the main reason is that you did not fit in anywhere else.

In the sclerosis of most corporate environments, if you are going to make a change, you will have to be a pirate.  You will have to be smarter, nimbler, and more unconventional.  You will suffer from being an outcast.  You may also fail in an embarrassing and ignoble fashion.  On the off chance none of that happens, you will cut a romantic figure in front of black sails and wallow in gold and rum.

Given a choice between the routine and tedium of a professional career and being a pirate; I choose to be a pirate.  It is why I am the pirate bear on #slack.

“Roar!”

Coaching should reject triage

Good for the battlefield bad for society and business

Usually, I spend my time on the blog discussing agile and how to better improve software development.  I avoid political discussion because there are much better places for people to discuss that topic.  This week, I would like to discuss something different.

This week a young person I have known since her days as a college undergraduate wrote and thoughtful post about her struggles with mathematics in elementary school.  As early as fourth grade she was taken on field trips to grocery stores to learn about careers stocking shelves after completing school.  None of the other students attended that trip.  As early as nine years of age educators and members of the community were making decisions about her life.  Today, Stephanie Orme is a Ph.D. from Penn State who is a nationally recognized public speaker and recently gave a TED talk on Diversity Game Design.  

I am very proud of Stephanie.  I consider myself one of the stepping stones on her journey and I look forward to seeing her further adventures in academia.  Her story made me think about my trip educationally and as a scrum master.  We make too many judgment calls about young people, and those judgments are harming our society and the business community.

Our education system in the United States has wide gaps of inequality.  Private schools appeal to people of means and have been training grounds of the children of business and political elites for the last 100 years.  Parents often pay a premium real-estate prices to live in communities with highly rated schools.  Young people living in rural or poor school districts are not so fortunate; it means that school districts make do with what they have, and they get involved in a practice known as triage.

Initially, from the medical field and pioneered by the French during the Napoleonic wars triage means the sorting of people to help them when confronted with scarce resources.  For example, someone with a head missing from a cannonball does not need a blood transfusion that blood can go to someone with a better chance of survival.  Paramedics, emergency rooms, and combat medics use the concept of triage daily to save lives.

As early as middle school, I experienced triage in my education.  The “smart” students participated in honors courses and segregated from other students.  These students not only had to have good test scores but they also had to have good grades.  The poor students were in remedial classes, and the unwashed middle got by with standard courses.  The exception to this rule were those with cognitive and learning disabilities who received special education.  I was terrible at mathematics, so I attended learning disability courses.

As time wore on, the honors students became more privileged as standard and remedial students shifted into less challenging classes.  Honors students received college AP courses, scholarships, and opportunities to excel. Once labeled a basic or a standard student, opportunities to reach the upper echelon was difficult.  It created a type of resentment and desire to prove those who doubted me wrong.

I was more fortunate than most.  My community college prepared me for university study. I was lucky enough to receive a scholarship to a four-year school for debate and speech.  Thanks to the financial sacrifices of my parents, the incredible support of my teachers, the encouragement of countless adults, and a little luck I became a college graduate.  If you had checked in with me as a nine-year-old, you would have concluded that I would be stocking shelves.

It would take seven years working in the radio and the casino business to find my true vocation; software development.  It would take another ten years before I would discover agile and share its worth with others.  I got by on grit, but I would be fooling myself if I did not acknowledge the privilege of supportive parents and my educational background.

It is this knowledge which has shaped my perspective.  The Harvard business review talks about a “fixed mindset” vs. a “growth mindset.”  Thanks to triage in education, we take young people and place them into boxes.  We then triage those boxes into careers and roles in our community.  It is a more significant problem in business because often leaders are more comfortable around people with similar educational and cultural experience.

As someone who has not fit neatly into a box his entire life, it encourages me to adopt a growth mindset for others around me.  I cannot help everyone, but I will try to help those I can.  With a little luck, there will be more people like myself and Stephanie Orme helping reform business and culture.

Until next time.

Why Healthy Ownership

"Healthy Ownership" created to fight abuse

I have been in deep thought about what we in the agile community need to do to make businesses more responsive to market demands.  The reality is that many relationships in the technology world can be abusive; this why I want to talk about the reasons why I have been working on “Healthy Ownership.”

It is not a secret that software developers can be jerks.  It is also not a secret that there are plenty of raging asshats in the technology business.  Finally, if you work in a shrinking industry, the pressure to do more with less can be absurd.  With all of these realities, there is no reason to be involved in the following behaviors.

Questioning the estimates of a development team.  

I have written several times about the underlying social contract of agile.  Product Owners set priorities and development teams to estimate how long it is going to fulfill those priorities.  I had a product owner question those priorities saying, “You did something similar last sprint so I thought you could do it faster this sprint.”  All user stories should be negotiable but for things like scope and acceptance criteria.  When product owners start questioning how long it takes to complete that scope you break the social contract of agile.  It is this kind of conduct which demotivates the development team and gives them license to question the judgment of priorities of the product owner. 

Not writing a unit test or chipping in with QA work.

I have known developers who have looked down on quality assurance people.  Experience tells me that these individuals are not very good developers.  Software development is complicated, and the process of authoring it creates intellectual blinders.  Quality assurance people guarantee that those blinders are less convincing.  They ask uncomfortable questions, probe weaknesses in logic and are willing to take a sledgehammer to a sink to make sure that everything works as promised.

Quality assurance people help developers improve, and developers help QA people understand what they are testing.  A recent blog post mentions a professional golfer is not finished with a hole until they put the ball into the cup.  For weekend beer league golfers, it is good enough to get it close to the hole and “pick it up.”  Writing unit tests and doing QA work separates professionals from beer league developers.  Refusing to do this means you are rejecting the professionalism of your craft. 

Ignoring refactoring and technical debt

Technology is a brutal business.  It is unforgiving and humbles the best of us.  It changes so quickly; a developer needs to relearn their job every eighteen months.  It means that code they are working on needs continuous refactoring.  What is working in the short term may be hard to maintain or adapt to changing business needs.  It is why technical debt and refactoring matter.

Many people in leadership roles have a, “if it is not broken do not fix it,” attitude.  Neglecting technology is like ignoring your household plumbing.  It may work now but when it does break it is going to create a tremendous mess.  Paying attention to technical debt and refactoring is common sense like changing the batteries on your smoke detectors. 

All three of these pathologies brought me and others together to create “healthy ownership.”   These behaviors are abusive and counter-productive to any team.  Only be addressing these dysfunctions will the practice of software development improve.

Until next time.

What You discover at a coaching retreat

Why teammates from the Agile Coaching retreat.

I have been offline for a few weeks.  The reason was I had to have some downtime as I was involved with a conversion of a TFS 2015 server over to an instance of VSTS.  Also, I was getting ready for a trip to London for the Scrum Coaches Retreat.  The pressure along with the time requirements forced me to set aside my writing.  Things have settled down, and so I can get back to writing about agile.

It has been a whirlwind three weeks.  Family functions, work, and this trip to London have been my focus.  When you have time out for yourself, you learn a few things.  The primary lesson came from a scrum master I met from England.  Dominic Kavanaugh who pulled me aside during a stressful moment and said, “This retreat isn’t about shipping anything; it is about learning.”  From that moment, I had an epiphany.

The agile manifesto says working software over comprehensive documentation.  The principles of agile stress shipping software in small increments.  What I realized is I have forgotten a fundamental lesson about continuous improvement.  Learning and growth are a vital goal of being agile.  Shipping software is not a hamster wheel where everyone goes around and round shipping software and not improving.  It was my big revelation.

The revelation came as my team of coaches came upon the idea of “Healthy Ownership.”  I was complaining about the abusive relationship developing between my product owners and developers.  Soon another joined my group and spoke about quality assurance not working well with developers.  Finally, Dominic entered the group and talked about technical debt.  What united all three of these themes was that the development teams did not have a shared sense of ownership to the work they were doing.

Together, the team of us set out on a journey to try and come up with a way to discuss dysfunctions and how to fix them using a coaching approach.  It was the first time I exposed to terms like “clean language,” follow-on questioning, and guided conversation.  It was positive to have ten strong personalities in the room who were all success focused.  One person was our enforcer of norms.  The other was making sure we covered the topic of quality assurance.  Another was our enthusiastic product owner.  All of us learned to work together in three short days, and we came up with a “Healthy Ownership” model of coaching.

I am pretty proud of the small part I had to play in the creation of this tool; I hope to use it for the remainder of my career.  First, it is a descriptive approach to solving problems.  Often as a coach or scrum master, you want to jump in with an answer to a technical question or process problem.  It may answer the question, but it impedes self-organization on the team.  Next, we approach issues like a doctor looking at symptoms.  We gather information, ask a few questions and provide the right nudge to a person.  Finally, we are just getting started.  All of us have committed to being ready to improve and flesh “Healthy Ownership,” out.

I was not sure what I expected at the coaching retreat, but now that I have attended one, I see it as a valuable and worthwhile experience.   I am looking forward to going the next time.  I am also looking forward to sharing with you my experiences.

Until next time.