Monday, February 19, 2018

It is worth it!

The work is worth it.
I have been doing plenty of reflection.  I blame the dispiriting winter season in my hometown of Chicago.  The cold winter nights force you to confront your past and ponder your purpose.  My friends and social media contacts are asking me plenty of questions about my weird profession.  These kinds of existential moments make me want to do a little explaining.

I joined the agile reformation in 2009.  I was working as a contractor for a family run medical supply company.  I was thoroughly miserable.  I had no job security and little hope. I spent each day grinding out code for capricious people who treated everyone not family as medieval peasants.   Family disputes would boil over on to the sales floor, and anyone caught in the crossfire could lose their job.  It was such a dispiriting place to work.  I witnessed the ten-year-old grandson of the founder tease a salesperson saying, “Daddy says you are fired.”

In the middle of this night of the soul, a project manager decided the team should try “agile.”  It began with daily stand-ups and doing releases in two-week chunks.  It ended with unemployment.  The project manager left for a better job.  The IT Director realized I had more credentials than he did so I was a threat, and it made me expendable.

Between job searches, I did research and the more I learned about Agile, the more I realized it was a better way to lead software projects.  I also realized that the concepts while simple to explain were hard to implement.  Thanks to the Agile Manifesto and the early proponents of the scrum, there was a way to perform technology work without abusing people and providing better value to the business.  I would spend the next four years as a developer spreading the word about this new approach.

Things finally came to a head when I left my last role as a senior developer and became a scrum master full time.  I was no longer some developer mentoring others.  I was leading other teams and setting an example.  I thought I was ready.  I was wrong.  Over the last five years, I have been tested and challenge in numerous ways.  I have succeeded in public ways and failed in equally public fashion.  I am not the scrum master I was five years ago.  Everything I have learned along the way has made me better.

I keep thinking about a quotation from Dave Burgess I tweeted out last week.


The last nine years of my agile journey have been challenging, but it has been worth it.  I am a better leader.  I am a better developer.  The software is getting shipped on time, and the office is a little less capricious.  I do not have entitled ten-year old’s threatening to fire me, and the business community seems to be catching up to my way of thinking. 

This hard journey is probably worth it, and I am proud to be sharing it with you.

Until next time.

Monday, February 12, 2018

Flying my Pirate Flag

I am letting my pirate flag fly.
Being a full-time scrum master or agile coach is a labor of love.  An agile coach needs devotion.  The successful scrum master needs to do more than manage the version control system.  At times, they need to act like Don Quixote jousting at windmills.  All the time, they are they misfits in the organization attempting to get it to improve when inertia governs the corporate culture.  It is very lonely, and it requires reservoirs of passion which many people do not possess.  This week, I talk about the passion for being a scrum master.

It takes a unique individual to get up before the sunrise and make a phone call with a group of developers half a world away.  Additionally, that person spends hours to coordinate product owners and executives so that those developers can work efficiently.  A scrum master handles this responsibility with no authority, everyone involved has the right to say no; It takes a particular kind of person to lead and facilitate this type of activity.  It requires passion.

Being human beings, we are creatures guided by emotions and reason. The modern business has toxic emotional situations and pressures to perform.  Over time, it leads to burn out and passive-aggressive behavior.  A person does not give it their all because it will not make a difference to our bosses or the organization.  Only the application of passion can get someone through the day.

Currently, I am reading a fantastic book by Dave Burgess entitled “Teach Like a Pirate.”  Using techniques he has developed over his career as a teacher, Burgess talks about how to be a better teacher using techniques to build a passion for the subject, build rapport with students, and create situations where enthusiasm can triumph.

What is refreshing is Burgess, knows the difficulty of teaching and how high school students can be the most terrible room for any professional.  What is interesting, is that one of the first things he talks about is the need for passion.  He is also brave enough to admit that he cannot be brimming with passion every day.  He calls people who do freaks.

So unless they are all freaks, how is it that outstanding teachers can maintain a passion for what they do?  Burgess gives a simple answer, and that is to ask questions about what inspires passion in a person. The first question is what subject areas in your field of expertise excite you?  For me, it is metrics and measurement of continuous improvement.  Nothing is more satisfying than putting an easy to understand chart on the wall explaining the team is improving.

The next question is what part of your job is the most satisfactory?  It is the reason you keep doing it.  I have written about this for years.  When software ships and the team feels like they have done a good job is what keeps me taking the call from India each day.  The final question is about personal passions.  For me, it is board games, family, friends, craft cocktails, and good food.  Those things provide me with inspiration and love for what I do.

So in the lonely world of a scrum master or agile coach, it helps to find your passion daily.  With Dave Burgess and “Teach Like a Pirate,” I might have seen a means to do that.

Until next time.

Monday, February 5, 2018

Five simple steps.

Constraints matter.
I have been involved with Agile for nine years.  One of the greatest discoveries of my agile journey is the realization that I am learning new things and continuously improving the way I conduct my servant leadership.  I was encouraged to read Eliyahu M. Goldratt’s, “The Goal,” and it exposed me to the theory of constraints.  Now that I have finished the book I have a few thoughts on the subject.

I have written about the theory of constraints in the past.  The main gist of the book is to identify bottleneck or limitations in an organization.  Once you find a restriction, work can be done to mitigate the effects of that obstacle.  It seems common sense, but in the rush and frustration of our daily jobs, we often miss these common sense approaches.

Goldratt shows his most revealing insight. The mitigation of constraints follows a clear and easy to reproduce the process. The process is as follows:
  1. Identify the system's constraint.
  2. Decide how to exploit the system constraint
  3. Subordinate everything else to the above decisions
  4. Elevate the system constraint
  5. If in the previous steps a constraint have been broken return to step 1, but do not allow inertia to cause a system constraint.
Five steps and it does not matter if you are working in a machine shop or managing a bunch of creative professionals, a person can improve the efficiency of a process.

I have been struggling with the notion of exploiting and subordinating a constraint.  Fortunately, the theory of constraints has plenty of academic support and an excellent blog about these five steps.  I look forward to using them at my firm.

Until next time.


Monday, January 29, 2018

Empathetic relations come before education

As an agile coach and scrum master, I find myself in a peculiar place.  I have been with one organization for five years, and I am unable to increase their agile maturity.  We are stuck.  We are going through the motions of agile but work is not sustainable, and dysfunction exists between the business partners and the development team.  This week, I face an agile implementation which is stagnating.

As an agile coach and scrum master, you need to take a hard look at yourself and how you do your job.  It is lonely and unforgiving.  You need to evaluate how you can improve and how you help others.  In many respects, you are acting like a teacher, therapist and camp counselor. 

Where do teachers go for support?  How do therapists deal with human suffering without being crushed by its weight?  What does a camp counselor do when they cannot be enthusiastic?  The answer to all of these questions is they depend on the support of peers and more experienced professionals.  There is an entire branch of therapists who treat other therapists.  Teachers have support groups and working teams.  Camp counselors rely on directors and adult leaders for support.

Scrum masters are very alone and are misfits in many organizations.  They belong to a company, but they spend a majority of their time fighting the corporate culture to meet goals.  Their managers misunderstand them and because they do not have any real authority often ignored by others.   For me, I depend on the support of others from the agile coaches’ symposium in Chicago.  I count on my immediate manager and interact with other coaches on LinkedIn. 

I depend on these people like a drowning person clings to piece of driftwood. Leading organizational change requires the stamina of an Olympic athlete, the patience of Job, and the self-esteem of Rod Blagojevich.  Few people have all three of these traits.  It is why I have to depend on the coaching of others.  It is a both a means to improve and receive the support I need to get through the day. 

Currently, I am dealing with exceptional levels of toxicity from business partners.  The situation has deteriorated so much one product owner will not speak to me directly but will tell someone else to convey information to me.  It may be acceptable behavior for mean girls in high school but is outrageous for a business person to act in such a fashion.  All I can do it take responsibility for this professional failure and make the best of the situation. 

Someone I respect said, “Empathetic relations come before education.”  This week that message clobbered me like a sixteen-ton weight.  Crushed by this new knowledge and experience, it occurs to me that I can not just attempt to teach others the skills of agile with the power dynamic of a teacher to a student.  For greater agile maturity at an organization, the coach needs to relate to the business partners as peers. 

If agile is going to grow then, people must want to be open, committed, focused, courageous, and respectful.  It is now clear to me I cannot use the coaching style of a movie director or drill sergeant.  I cannot be a teacher at this stage.  My knowledge needs to be offered as a friend.  If not, then agile will stagnate and not mature at an organization. 

A failure is a useful tool.  It educates more than any success possibly could.  This week, I experienced a failure I might not recover from at my current firm.  Whatever the future might bring, the lessons are going to stick with me the rest of my career.

Until next time.

Monday, January 22, 2018

The Social Compact of Agile

If you don't set priorities your office could be like this.
From the Iron Mitten web site.  
One of the biggest challenges in technology is there are not enough people to do all the necessary work.  Only about 18.5 million people in the world of 7.4 Billion people can maintain software and modern computer networks.  That means that less than .05% of the world have the skills to keep the global economy spinning. It would not happen without dedicated project professionals and smart technologists holding everything together.  Without prioritization, the gears of the industry would grind to a halt, and that is what I want to talk about this week.

When Thomas Hobbes wrote “The Leviathan,” in the aftermath of the English Civil War; he spoke about something called the social contract.  The social contract to Hobbes was an unwritten set of rules where individuals traded their liberty with the state in exchange for safety and protection.  Ignore the social contract, and society would collapse, and philosophers and social scientists still use the idea of a social contract to explain how communities work.

In the world of business, we also have social contracts.  People who have more authority have offices instead of cubicles, so they meet with people in private.  When it is time to distribute profits, shareholders receive preference over employees.  Finally, no one gives human resources any trouble because they have the authority to hire and fire anyone.  None of these rules are written down, but we all know they exist.

In agile, there is one social compact.  The product owner sets the priorities, and the development team says how long it is going to take to do the work.  The developers may disagree with the preferences, but they have to accept them.  The product owners may not like how long it will take to do the work, but they have to agree with them.  It is the trade-off which makes agile work.  If neither the developers nor the product owner respects this setup, then the implementation will fail.

It is well and good if you have only one project and one team.  What happens when you have multiple projects and not enough teams to do the work?  It is when prioritization becomes more critical.  Business leaders need to be part of the process, and they need to know what is being worked on and when.

There are plenty of processes to set priorities.  The most significant challenge for me is the mindset of the business of professionals.  Sales and marketing professionals are trained to think each “no” is one less objection to “yes.”  It is admirable for a sales professional; it is madness for a large organization as self-interested and selfish people scratch and claw to “yes.”  Projects hopscotch up and down in priority as developers struggle to stay ahead of the shifting needs of the organization.  Unclean code is released to production because someone needed a feature released “today.” I continue to struggle with this challenge.

So as a scrum master or agile coach, you need to enforce the social contract of agile.  That social contract is product owners set priorities and developers say how long it is going to take to do those priorities.  If you can do this, you just might succeed.

Until next time.



Monday, January 15, 2018

Smoke detectors explain technical debt

Should have checked the smoke detectors.
Since the holidays, I have made a point to spend time with people outside the technology field.  This experience has been beneficial because I spend my time explaining what a scrum master does and how we do it.  This review of the basics is allowing me to reflect on work and how to make it better.  It is a fresh perspective which has allowed me to look at old concepts in a different light.  This week I want to revisit technical debt.

I own my own home.  Since I am a homeowner, I have smoke detectors.  These little battery powered devices warn me when there is a fire or when I am burning a roast on the stove.  So smoke detectors offer protection to a homeowner so they can escape the house quickly and call the fire department.  Smoke detectors are so useful you receive a discount on your home insurance if you have one, and, in some municipalities, you are required to have at least one in your home.

Smoke detectors have one significant drawback; they are battery operated.  When the batteries run out, and a fire breaks out you are helpless.  The smoke detector companies fix this by forcing the alarms to “chirp” which is a friendly reminder to change the batteries.  This week, I awoke to my smoke detector “chirping” at 2 AM in the morning.  Like many men my age, I attempted to roll over in bed and ignore the situation.  Ninety minutes of insomnia later, I wandered the house searching for batteries to replace the faulty one in the “chirping” detector.

The next morning over an extra cup of coffee, it occurred to me that I treated my smoke detector like many organizations treat technical debt.  I do not change batteries until I have to and usually it is at an inconvenient time.  Fortunately, being a former boy scout, I was prepared with batteries in an easy to find location.  I swapped out the batteries and went back to bed. 

If you are a homeowner, you have four strategies to deal with smoke detectors.

  1. Change all the batteries at once typically during daylight savings time.
  2. Change individual batteries when they run out of charge and begin chirping.
  3. Ignore chirping smoke detectors until you get fed up and change the battery.
  4. Remove and disconnect all the smoke detectors and hope you never have to deal with a fire.

As a homeowner, I use strategy two and three.  I know others who use the other two approaches.  Swap out smoke detectors and batteries, and you have the four classic strategies companies use to address technical debt.

The most efficient way to deal with technical debt is to follow the first strategy by changing batteries and updating systems on a regular basis.  By doing this, you reduce expected outages.  Agile and scrum encourage this approach.

Many CIO’s and managers I know consider this madness because there is a not enough time, money or people to keep updating systems.  It means they rely on strategies two and three.  It may be suitable for a chirping smoke detector on a cold night but is lunacy for a multi-billion dollar enterprise.  It creates situations where firms could lose millions of dollars while they wait to bring systems back.   

So the next time someone looks are you funny when you talk about technical debt just explain it to them like changing the batteries in a smoke detector.

Until next time.

Monday, January 8, 2018

Eat up

I feel like a shark!  "Chomp!"
Social movements and organizational change are difficult to measure, and it is particularly hard to do in the world of business.  The business press concentrates on investing and accounting.  Since the beginning of the agile reformation, those of us involved in the change have openly wondered if we are making an actual difference.  As 2018 begins, it looks like agile is becoming mainstream and successful.

In 2011 a famous editorial appeared in the Wall Street Journal, It was titled, “Software is eating the World.”  The principal thesis was for companies to succeed they have to behave more like software companies.  It was a daring argument.   The seven years which followed have vindicated that notion.  Google, Tesla, Amazon and a funny project called Bitcoin are dominating headlines and the business community.

Tesla is still struggling to meet its production commitments and Bitcoin, to me, feels like a blue sky stock but what all of these firms have in common is a willingness to innovate, iterate, and move fast to satisfy customer demand.  Even companies who lost their way are embracing blockchain technologies, cloud computing, and rapid software development. 

It is satisfying to know that my career choices have mirrored changes in the business.  While business is changing business leadership is struggling to keep up.  Organizations charts still matter in many places.  Command and control measures which existed for years are difficult to discard, and inertia prevents most organizational change.

It has created a quandary and spawned an entire industry of coaching and consultants, who are attempting to show others how to do business with the agile paradigm.  What these coaches discover, is a business is a social construct along with a business entity.  The ego of a director may be more important than the needs of the company.  Board members excuse a lousy quarter because they golf with executives.  Whole industries condoned sexual harassment and assault as long as the abusers generated revenue.  

Which is why I find the turnaround at Microsoft so fascinating.  They went from a sales culture under Steve Balmer to an engineering culture under Satya Nadella.  After product failures like Zune, Vista, and Windows Phone, the organization decided to place its future in the hands of a software engineer who felt building better products was the path to commercial success.  It is a gamble which has paid off handsomely.

Microsoft has embraced Agile, and it is paying enormous dividends.  That is why this week an article appeared in Forbes called, “Agile is eating the World.”  The reformation is growing, and the success is getting noticed.  It is a satisfying development to me.  I am no longer a lonely missionary in the wilderness, but a professional at the table is making a difference.  It is nice to see the times change.

Until next time.