Layoffs are Not the End

It was a rough week to be a technology professional. Layoffs hit the industry hard, and the biggest casualty was Meta which ended the careers of eleven thousand employees for its failed bet on the Metaverse and overenthusiastic hiring during the pandemic. I watched the news with a strange pang of memory. My career contains plenty of firings, layoffs, and assorted catastrophes. I know what it is like to not have a job anymore. This week, I feel it is necessary to talk about layoffs and how to muddle through the process of starting over. 

The first thing you should understand about being laid off is that it is not a personal failure. It was a failure of the company to manage it's business and workforce. People who work in professional fields are told from high school that their success is their responsibility. The sad truth is success in a corporate environment is not merit-related but relationship based. Having good mentors, visible success in front of senior leadership, and looking like a leader are often more important than being good at your job or having actual leadership skills. To this day, I am still amazed people are in charge of millions of dollars and the careers of dozens with the emotional understanding and leadership skills of a fraternity member you find urinating in your hedges each week after a home football game.  

Someone I respect in this business once said, "Do your job and if they have a problem with that, let them fire you." It was a bit of wisdom I have carried with me for my entire career. I say this because plenty of business decisions happen without consideration of merit. Thus, layoffs are another example of poor leadership and planning creating problems for others. It is upsetting because one day, you have a job, and the next, it is gone, and you feel guilty, wondering if something could have saved your job. The truth is nothing you could have done would have held your position. Someone put together a spreadsheet showing the cost savings of a reduction in payroll; then, it was up to executives and managers not affiliated with the people doing the work to decide who stayed and who would go. It is not personal, just a cell in a spreadsheet and a business decision. An employee delivering value to the company with a family to support is cast aside like a broken office chair. 

The impersonal nature of layoffs is what is so demeaning about the process. It stings and creates a grieving process that will take a few weeks. One moment you were a valuable employee helping the team, and the next, you were packing your desk and being escorted out of the building. I experienced a workforce reduction numerous times in my career and have found a better job with better pay each time. Career instability will take a toll on your personal life because nothing undermines a romantic relationship like unemployment. Still, the good news is that with the right partner, a layoff is a temporary setback, not a life-ending event. 

The technology business is tiny, and word travels fast in this community. Already support groups are popping up to help people caught up in the layoffs at Meta and Twitter. Recruiters are working the phone, attempting to place skilled engineers with new jobs. Executives at companies are looking to snatch up talent who can provide value immediately for the business. Finally, technology workers are in great demand because there is still too much work and insufficient skilled people. 

As a survivor of layoffs, I understand the disappointment and heartbreak which comes with being let go. Technology is a harsh world. This week was especially rough, but it will improve, and each of us will be better for the experience. 

Until next time. 

Agile guiding the three tribes of business

The tribes of business create a tower of babble.

I am grateful to be blogging again.  I took a week off to address some health issues.  Recovery from illness is nature’s way of forcing a person to review priorities.  It makes you take stock of what is essential.  I have spent the last ten years of my life involved with the agile reformation.  It is clear to me one of the biggest challenges faced by agile practitioners is helping others change the mindset from a command and control perspective to an agile view. It is going to require coaching and patience.  Today, I want to discuss the leading challenge coaches and scrum masters face.

Since Frederich Winslow Taylor published “Principles of Scientific Management,” over one hundred years ago corporations separated their workforce into three distinct tribes.    The workers who did the manufacturing, service, or sales work.  The next group was the owners or executives who Karl Marx called the bourgeois.  The final collection were managers.  The tribes formed a lopsided pyramid where power resided at the top, and those at the bottom were expected to carry out orders without question.  When we discuss “top-down” management it is executives giving orders to professionals.  The professionals then made sure the orders were performed by those doing the work.

The modern manager has only existed since the founding of the Harvard Business School in 1908.  Management training often began in the office and shop floor.  After the founding of the M.B.A. program at Harvard, growing corporations could hire college-educated people who understood finance and the legal aspects of running a large business.  Managers had formal training equal to doctors and attorneys.  The professional-managerial class created a disconnect between those who did the work and those who employed the labor. 

Labor unions and economic growth helped to conceal the disconnect between workers and managers.  The events of the 1980s helped change the dynamic.  The government slashed regulations and curtailed labor unions; business leaders wanted to do more with less.  Business outsourced non-essential parts of the company and contractors replaced full-time workers.  Finally, manufacturing was off-shored to countries with lower labor costs.  Each step along this path, it was professional managers who made those strategies work.

For creative activities like software development, entertainment, and advertising, the more with less approach was not working.  With no knowledge of the work, executives would give orders.  Managers could manage work but have no idea how long it would take to complete the job.  Finally, workers did not care what they were doing or why they were doing it so long as they got paid.  Work would linger, and projects would run over-budget.  Meanwhile, customers were receiving low-quality products which were not meeting their demands.  It was ugly, and everyone in the business world through it was healthy.

Because they felt there was a better way to do work instead of “top-down” management, some of the biggest names in project management created the agile manifesto.  Organizations would now benefit from workers interacting directly with customers.  Small teams would lead change instead of bourgeois executives coercing people to do things against their will.  The pyramid of workers, executives and professionals would be tipped over with all three tribes working toward a common goal of helping the customers.  It was utopian and viewed the world through the lens of engineering.

Since that moment, agile is eating the world.  Successful companies in the global economy embrace the concepts of agile and those who do not flounder.  The reality is much more complicated.  Dark Scrum is a constant challenge in the business world.  Bad Agile is everywhere, and plenty of bad actors are attempting to capitalize on the spread of agile.

Scrum masters and coaches are innovating and attempting to change business for the better.  To effect change, we need to stick to the basics and the agile manifesto and agile principles.  We need to embrace scaling for more substantial organizations, but we should not be bound to one particular scaling framework.  Finally, we need to embrace our technical excellence and increase soft skills.  I am a big fan of Kim Scott’s “Radical Candor,” and I am beginning to embrace “Co-Active Coaching.”  Together, by understanding how the different tribes of the business interact, by practicing technical excellence, and finally, by perfecting soft skills we can make the lopsided pyramid of the contemporary business world a better place.

Until next time.

Agile, Story Points and Rock-n-Roll

The Crüe are very rock-n-roll and agile.

Being an agile coach is filled with plenty of touchy-feely moments.  You have to deal with difficult emotions and move change through an organization which is satisfied with the status quo.  Other times a coach or scrum master must deal with the practical matters of scheduling a meeting and facilitating a retrospective.  Finally, you are learning new things and applying them to your clients.  My vision of how story points work has changed over the years.  Recently, I am looking at story points in a new way, and it is good enough to share.

My first thoughts about story point made me think of them as measures of volume.  A story point contained a certain number of hours, and it would be easy to convert the two back and forth.  After my first 18 months of being a scrum master, I saw the folly in that way of doing things.  It became apparent that story points represented something analogous to distance.  An Olympic runner can cover 3,000 meters in under four minutes.  I can walk it in about a half hour.  Story points provided a quantitative way to measure uncertainty and help communicate to upper management.

Now I see a story point as the sum of four factors; complexity, risk, effort, and uncertainty.  We sum all these factors together and round them up to the nearest whole number in a Fibonacci sequence.

So if I wrote it out a math formula it would look like this:

Story Point = Complexity + Risk + Effort + Uncertainty
F_N = [Story Point]

Where F_N is a number in a Fibonacci sequence.

The new acronym for this is CRÜE, after the rock band Mötley Crüe.  By today’s standards, this giant of 1980’s glam metal would flame out in the public eye.  The band was nihilistic, misogynistic, and poster children for the destruction of alcohol and drugs could do to a person.  Finally, the lead singer killed someone in the act of vehicular manslaughter.  In spite of all the baggage, you could count on the band to put on a great show.  You could also count on them to be blaring out of any stereo at a house party during the 1980s. People of a certain age have memories of significant life events happening with Mötley Crüe playing in the background.

As an agile coach, I will let the young people concern themselves with sex, drugs, and rock-n-roll.  It is not my lifestyle.  I prefer agile, story points, and rock-n-roll.  If you are talking about story points, talk about Crüe; complexity, risk, uncertainty, and effort.

Rock on people and until next time.

Goodhart's Law is Going to Get You.

Goodheart's law strikes!

Information technology is hard work.  I have written about it before on this blog.  I have plenty of empathy for others who work in this profession.  I do not have much understanding of poor service or lazy behavior.  I am even less forgiving when large organizations brag about their success in public and struggle to do the basics in private.

I am at a client, and I have the following interaction with someone from the help desk; they said, “Can we close this ticket? If it ages any longer, it effects out SLA.”  My first reaction was surprise.  My second emotion was anger.  The help desk person was asking permission to close the ticket and open a new one because if they did not fix the ticket at a particular time, it would reflect poorly on him and his consulting company.  He was going to lie to make his response time look better than it was. 

It is human nature to please others.  British economist Charles Goodhart coined the maxim, “When a measure becomes a standard, it ceases to become a good measure.”  When you judge or pay people based on a measure, they will game the system in any fashion to make themselves look better.  You see this in economics.  It happens in video games and depressingly at work.  My help desk technician was living proof of Goodhart’s law.

Martin Fowler wrote a great article on the subject, and it outlines how to avoid this trap in agile practice.  Metrics are abused regularly in business.  In a large organization, the only way leadership can track progress is by reviewing these metrics.  Thus, the people doing the work are more focused on the outputs of hitting the metric numbers instead of the outcomes satisfying the customer.

I see service level agreements or SLAs as a necessary evil in business.  You have to hold vendors and third-party partners accountable.  Such a contract controls my current situation.  In a perfect world, my help ticket would age, and someone who could help me would respond to my issue.  The technician was afraid that if the ticket aged, they would receive a poor performance review or get fired.  It is an ugly situation, and if a company is going to succeed, they with have to address it. 

Large organizations need to focus on execution.  To focus on this goal, metrics and SLA’s need to be used judiciously; outcomes are superior to outputs.  It is a message which did not reach the help desk or his boss. 

Until next time.

Avoiding the Dumpster Fire

I have seen this ugliness before.

Technology is evolving and improving.  What is not improving is how we lead technology projects.  I have been in the business for twenty years, and it is clear how we lead technology projects needs significant improvement.  Last week news broke Hertz rental car was suing Accenture for 32 million dollars because it could not deliver improvements to its website.  I am surprised this kind of thing does not happen more often because plenty of large projects burn through obscene amounts of cash.  On the blog this week I want to talk about project failure and how it should provide businesses with a model on how not to do large projects.

Nathan Allen writes an excellent blog on all the things which went wrong during the Hertz affair.  It would be amusing if it did not involve the squandering of millions of dollars.  It contains all the usual culprits in a massive software delivery death march.  Salespeople made promises to executive and then forced technology professional to keep them.  Poor infrastructure at the client exacerbated poor development from the consulting company.  The deadlines were unrealistic, and the client abdicated all responsibility for the success of the project.  Add in a pinch of arrogance from a top tier consulting firm, and you have a perfect example of what scrum masters and project managers alike call a dumpster fire. 

Nothing is more dispiriting than working on a dumpster fire project.  It stinks, and it is fraught with getting your career burned.  Often, developers put their heads down and hope no one blames them for the catastrophe.  The main reason for this state of affairs is large projects are so big that any small setback will grind the project to a halt.  The state of affairs undermines the psychological safety of the people doing the work, and everyone is afraid to step forward and be honest with project leaders.  I suspect this was the primary factor why the project failed.

Deadlines were missed and missed multiple times.  When it was over, 32 million dollars disappeared.  What makes the entire episode more galling is Accenture refused to do more work unless Hertz paid more money to fix a broken project.  Failure crashed into failure setting more money on fire, and the only solution was to throw more money into the flames.

I have worked with several people from Accenture.  They are very good at selling products and getting paid, but they are not good at delivering results.  In the world where they work, it was more important to get paid than it was to provide value.  According to the agile manifesto, this is a refutation of the value of customer collaboration over contract negotiation.  It is clear Accenture is more interested in contracts than helping customers.

I entered the agile reformation because I wanted to build things rather than toil in obscurity.  I have worked on projects where we extracted money and value from the customer rather than deliver it.  Working on a project like this does pay the bills, but it does not move the practice of software development forward or improve the reputation of the development profession. It is up to experienced agile and project management professionals to pour cold water on these dumpster fires.  The business needs to set a standard which is more than watching piles of money burn.  Otherwise, we will have more trash fires like Hertz and Accenture.

Until next time.

Estimation is not an alibi for failure.

Estimation is not a quotation of work.

I spend plenty of time working with people who are just learning about agile and scrum.  The agile reformation has spread worldwide; what it has not done is penetrated deeply into organizations.  Elite information technology teams quickly accept the new paradigm and start to deliver.  Executives and leadership notice and they want to replicate these effects in the organization.  It is when this happens the life of a scrum master gets complicated.  If agile is going to succeed at scale in large organizations leadership must change how it views work.  It begins with accepting all estimations are not quotations for labor. 

Ryan Ripley, a coach, and trainer I respect is an advocate of the “no estimates,” camp of agile.  I have blogged about this school of thought, and I consider myself a skeptic.  I think it is easy for a team to operate without estimating but executives who are paying the bills are horrified when highly paid professionals say they do not have an educated guess about when they will finish work. 

The reality is executives are craving certainty in an uncertain business world.  An executive wants to know the budget is not getting wasted.  Most executives do not understand the technology which keeps their organization workings, so this creates an additional level of anxiety.  Finally, technology is changing so quickly a course of action which made sense at the start of the project can backfire at the end of the project. 

Agile and scrum attempt to solve this by using rapid iterations to build a shippable product which business professionals can then inspect and adapt. It works like a charm, but for larger projects with multiple handoffs between systems, it can create a sense of apoplexy.  Teams are on schedule but with different cadences of work.  Software code on one team does not work correctly with a different team.  Meanwhile, time continues to move forward, and deadlines made without any feedback from the people doing the work begin to slip. 

Estimates are treated like quotes because when deadlines slip executives can point to the faulty projections as an alibi for failure.  Activities such as construction and automotive repairs are easy to estimate because the rules which govern those activities are reasonably constant.  Concrete dries at a particular speed.  A repair shop can replace a tire in about an hour.  The laws of gravity have been steady for eons.  The nature of software development makes it nearly impossible for smart people to provide accurate estimates. 

Multiply this reality over numerous projects which have to work together with tight deadlines and tighter budgets you have a recipe for madness.  The software teams are groping in darkness, and the executive team is demanding some light and direction.  What can be done to break this pattern of insanity?

The first thing which needs to change is executives should understand estimates are not quotes of work.  An estimate is an educated guess at best and a cruel lie at worst.  Software working in production is the only credible sign of progress.  Based on what is working in production a leader can make more informed decisions about what to do next. 

Next leadership needs to fund cross-functional teams.  Often projects are supported, and they have a beginning, middle, and end.  When a project ends the team is disbanded and with it the knowledge to maintain or improve the system just created.  High functioning teams should stay together and given different projects.  A marketing team like this will develop logarithmic expertise and use it to defeat the competition.  If you watch Netflix, I recommend the story of Barbie and the “pink berets,” who worked in Mattel’s marketing department.  

Finally, leadership should accept software development and other complicated projects should resemble the commute to work.  Somedays the traffic is heavy and others it is light.  Construction can cause backups, and occasionally a car fire will create a gaper's delay.  Accept variability of work and try to avoid forcing unreliable estimates into schedules not grounded in reality. 

If executives and business leaders can understand these principles estimates will no longer be an alibi used to forgive failure.

Until next time.

Break out of your rut!

I have been thinking about my craft.  A scrum master is a coach, therapist, and advocate for their team.  We have emotional ups and downs in the profession.  We are also fortunate enough to make a difference in the organizations we work.  It is rewarding but filled with the trade-offs professionals are confronted.  This week wanted to discuss a constant force in the life of a scrum master continuous improvement.

As a professional, it is easy to get into a rut.  Decision fatigue sets in and so you order the same thing for lunch or manage how you deliver software.  Routine and inertia are comfortable because it provides a false sense of security in an uncertain world.  Your heart could stop from a simple blob of cholesterol or the company share price could crumble overnight, but thanks to the routine we ignore these catastrophes.  Inertia is safe and secure.  It is also the enemy of continuous improvement and agility.  It is why scrum requires retrospectives.  The feedback allows everyone evaluate how to improve. Development includes the product owners and the scrum master.

I was doing a product increment planning meeting for the product owners to coordinate releases and plan for the future.  On a whim, I decided to include a retrospective of the last quarter to get a sense of where we are and where we are going.  A tense hour later a few lessons were learned.  Using a four “L” retrospective, I wanted to understand how as a product development team we were doing.  The answer was unambiguous.  Some things which we could control had to change.  The retrospective included passive aggressive conduct, and a few choice criticisms pointed at me.  It was worth it.

Based on what I learned, I am going to conduct retrospectives differently with the development teams.  I am going to work with the product owners more closely to help them manage their work more closely.   Finally, I am going to try and break out of my decision fatigue.  Continuous improvement matters, and if you expect it of others, then you should expect it of yourself.

Until next time.

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.

The fatberg in your organization

This is grotesque monster is lurking in your organization

Last week I shared some thoughts about technical debt.  It is a pretty important topic because plenty of organizations are dealing with the repercussions.  As a scrum master and coach, you will have to navigate this treacherous territory because in the world of enterprise technology you are often attempting to update systems while trying to keep the business running.  I liken it to performing heart by-pass surgery on someone running a marathon. 

To illustrate the damage of technical debt, I point to the city of London.  It is suffering from a particular problem which is grotesque and illustrative of legacy systems.  A “fatberg,” is clogging the sewers of the city.  Over the length of the tower bridge spanning the Thames River, it weighs several thousands of metric tons.  Composed of fat, condoms, towelettes, and sewage, it is a drain clog of biblical proportions.  City officials concede that if the object is not broken up, it will cause the sewers on the cities east end to back up.  Combine a sewer system first constructed in the 1750’s with twenty-first-century human waste you create a “fatberg.”  It is a perfect metaphor for technical debt. 

The sewer system was not designed to scale to accommodate a population of over 8.5 million people.  Making matters worse non-biodegradable towelettes and latex condoms did not exist in the 18th century.  Finally, human behavior changed with people dumping their cooking fat into the drain instead of recycling it for soap and further cooking.  The result is one of the most repulsive examples of human waste created by humankind. 

There is no easy fix for this disaster.  Workers are spending time breaking up the “fatberg,” and civil engineers are attempting to find ways to prevent this environmental abomination from happening again.   Some of the problems can be mitigated by banning moist towelettes which are not bio-degradable.  That is still not going to prevent people from dumping cooking fat down the drain unless the government can come up with a program to recycle it.  Such a recycling program would rival what happened in the United States during the Second World War.  We have also not come up with a decent substitute for latex condoms. 

The depressing reality of this situation is similar to what happens every day in a fortune 500 company.  Bad data pollutes systems, and that data requires teams of professionals to organize and understand it.  People exchange excel spreadsheets via e-mail with no change management or concern for security inside an organization.  Finally, countless human hands are used to bill, invoice, and collect money from customers.  It has all the making are a “fatberg.” 

I am a lonely voice in the wilderness about this issue, but continuous improvement depends on the removal and mitigation of technical debt.  Otherwise, your organization is going to confront its own “fatberg,” and it will not be pretty.

Until next time.

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.

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.

Thank-you.

Until Next time.

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.

In order to change you need to listen.

Change begins with listening

One of the biggest obstacles to change is an organization is status quo thinking.  People develop routines and when those routines are challenged there is a push back. It happens in politics.  It happens in business.   It even happens in sports.  Being a scrum master means being a change agent.  This week I want to talk about fighting resistance to change.

At the turn of the century, one of the most popular books in the business community was “Who Moved My Cheese.”  In it, the authors tell the story of two mice “Scratch” and “Sniff” who live in a maze and discover the cheese has been moved to a new location.   The one mouse staves and the other learned to adapt to the change.  I have always been a bit of a cynic about this book.  I saw it as a happy talk way of accepting cram downs, corruption, and unfair treatment.

Now I am a scrum master and  many of the people I work with are like the mice in that book.  When asked why they do certain things they lock up in paralysis of say, “…that is how things were always done.”  Man people I have met in business are content to settle into comfortable routines.  The mental laziness of not questioning how things are done is preferable to existential nausea caused by asking if there is a better way of doing things.  In dysfunctional organizations, these lumps of human clay are often promoted and continue to enforce these dysfunctional practices.  Soon if becomes obvious to everyone that to get ahead you have to keep your head down, your mouth shut, and not make any waves.

This is even harder in large and bureaucratic organizations because people are protecting turf in the organization.  Leveraging cloud services like Azure is inevitably going to run into resistance from network teams because it takes control away from them and puts it in the hands of developers and business people.  Automated builds and continuous integration are good things but regulatory compliance becomes a committee of “no” for these improvements to the organization.

This kind of intellectually lazy resistance to change makes me crazy.  When confronted with this kind of thinking, I get angry.  After a particularly bad day someone I respect pulled me aside and said, “…you need to listen more.”  I was taken aback.  Listen more? Why should I listen more?

It took some time to sink in, but I am beginning to understand what he was thinking.  When change comes to an organization, people are fearful or what will happen to them.  I need to listen to those fears and way those concerns.  I need to listen to what is working and what isn’t working.   Change for the sake of change is just as damaging as doing nothing.  Changes must be responsive to the situation you are in rather than a reason for being.

I need to listen more.  The best reformers were people who listened and made others willingly join rather than those badgered.  The truly fervent are the most devoted.  Ther fervent are also alienating and if I want to lead change the last thing I need to be is alienating.  I need to listen to others and alienate them less.

I get angry and discouraged many times as a coach and scrum master.  Change is a difficult process.  Leadership is lonely.  The good news is that leadership and change done properly can improve the lives of others.  The struggle is worth it.  Resistance to change can be defeated and the most powerful tool is listening.  I should give it a try.

Until next time.

When to hang it up

Sometimes you have to pack your bags.

Last week I spoke about “struggle” and what I felt it meant.  It inspired a strong reaction from a few people.  Watching this reaction, it dawned on me, I was witnessing a conversation I had three years ago.  Each of us have moments in our careers where we consider leaving and going someplace else. Some of us have that choice forced upon us while others have a “moment of clarity” and then give their notice to their boss.  This week I want to talk about when it is time to leave.

I have been a software consultant and full time software developer for many years.  It was filled with frustration and failure.  Additionally, when I was a consultant I was often treated like high paid “help” who was supposed to keep his head down, mouth shut, and ignore the dysfunction which surrounded me.  I even completed a project early for a client and instead of being rewarded with an extension I was thanked and promptly rolled off.  I have been fired a week before Christmas and had to explain it my former spouse.  I have looked over my shoulder worried I was not good enough and smart enough to work with the other developers in my company.  I needed to make change.

With my own money, I took my Certified Scrum Master training.  I was feeling despair and working as a heads down developer was taking a toll on me.  This was a chance to practice what I preached about Agile.  After becoming an architect at a different firm, they learned about my Scrum Master training and made me the servant leader of development team.  Looking back on that experience, I realize that I was raw, cocky and untested.  One developer openly rebelled against me right away and I would spend weeks and months attempting to effect change.

That was three years ago.  Now, I am training product owners for division of my company, serving as a scrum master, and being “spun off” as my firm splits into three companies.  In those three years, being in the trenches as a scrum master has made me a much better servant leader.  I am even participating in the company mentoring program.  I voiced that I was restless and frustrated with the pace of change I am trying to effect and it looks like someone listened. For me, it is a sign that I need to stay because big changes are coming and my peers and superiors see that I should be part of that change.

I will only speak for myself but if you cannot get training through your work and if you are asked to do one thing but are rewarded for doing something else then it is time to leave.  Before I started working as a scrum master, I was a senior developer for a food company.  I was talking about a software project with a superior and he said I should start over because it didn’t look like something he could use on his iPad.  It was the final straw and with-in a month I was gone.  Since then, that company has paid hundreds of thousands of dollars in agile consulting and they laid-off over 100 people, mostly older workers, in order to be more nimble.  They could have saved a lot of money and preserved those jobs if they just figured out how to keep me and allow me to spread agile through the firm.  I am glad I am no longer there.

Each member of the agile community is responsible for his or her own career.  We have to make choices every day about what we do and who we serve.  We also need to remember that we need to serve ourselves.  If we are unhappy or frustrated with what we are doing then we need to change.  If that means leaving one company to go to another then so be it.  For me, I am staying where I am.  I am entering an exciting time of change and I look forward to the challenges.  When I can’t say that any more then I have to quit.

Until next time.

The Power of No

Sometimes it just needs to be said.

This week I wanted to discuss something which is pretty important to every business person and entrepreneur I know.  For years we have been taught the importance of yes, getting other people to say yes, saying yes to the deal, and making sure you say yes to any reasonable request.  People who say no are not team players or willing to succeed.  The reality is that saying no is as just as important to success as saying yes.

Daily we read stories about work life balance and what it takes to be successful.  A common theme in many of these articles is the ability to say yes.  It is easy to see why coaches and mentors say this.  Saying yes is easy; doing what you promised when you say yes is hard.  This way it is easier to make a promise and break it because you can always ask for forgiveness.  Business is filled with plenty of people who can make promises but cannot fulfill them.  This situation means that as a business person or leader you spend a majority of your time in a constant state of distrust because you do not know who is telling the truth and who is just saying what you want to hear.  It is madness.

This is why “no” is so powerful.  Because it cuts through the phoniness of typical business interactions and lets people know what is really going on.  The word “no” builds trust because they can honestly engage in pragmatic discussions about what can and can’t be done. I am not advocating being negative or reflexively saying no all the time but the judicious use of the word no can make your life much easier.

Let me give you a few examples:

• Can you stay late tonight – “No, my daughter is playing softball tonight.  Can I come in early tomorrow or work on this after the game”
• I need this software by X – “No we do not have enough developers or time to build all those features.”
• Can you build this software for a fixed bid – “No, this does not compensate properly for the work we do.  Feel free to take your chances with someone else”
• Can you take an extra project – “No, I am flattered but I want to devote my attention to these other projects and make them successful.  I might not give this new project the attention it deserves”

In each of those examples, saying no sets limits.  You are not being negative or hostile you are just setting limits to prevent others from exploiting your desire to help them.  There are plenty of people in business who don’t respect limits and those are people who have high turn-over and bad work environments.  By outlining limits you act as a warning sign to people in authority.  They have to hire more people or redo budgets rather than taking undo advantage of people working for them.  It also prevents vendors or clients from making demands which might cost you money.

So the next time you are tempted to say yes, take a deep breath and remember the power of no.  It may just save you time, money and aggravation.

Until next time.

The Insanity of Software

At times someone distills perfectly what it means to be a software developer.  This week Peter Welch posted the following article to Gizmodo and I strongly recommend it to my readers “Why a Job in Programming Is Absolute Hell”.  This week, I wanted to comment on this blog and try to let you know that while programming is hell; the trip is worth it if you can help customers try and solve their problems.

Welch’s thesis is that while software development does not require you to lift 50 pounds or dangle from a building while you wield together iron girders, it is filled with stress and insanity.  I can attest in my career that software is one of the few products we make in western civilization which is made completely by hand.  That said many of the people who build software see themselves as artists and craftsmen.  This is a recipe for mental illness and conflict.   Because no two software developers will build the same thing the same way, this means that the more software developers you have working on a project the more disagreements about how the work is going to get done.

I am going to postulate something known as Wisniowski’s theorem.  For every developer on a software team, the amount of disagreement increases by the power of the number of developers on the team.  Thus, a team of seven developers is two to the seventh power more likely to disagree about how to build something than a team of two developers.

To prevent this from spiraling out of control, scrum masters and project managers were created who were supposed to act as guides and leaders to prevent conflict from spiraling out of control and get work done on time.  This has created an entirely different set of problems because many project managers and scrum masters do not come from a technical background.  So they do not know how to mediate conflict in a technical team or even what questions to ask.  This means that developers become insubordinate and work around the project leadership to get work done.  By the time someone has realized what has happened, it is either too late or the developer has decided to switch jobs working someplace else.  If this sounds like madness, it is.

So what company to do?  Well many people purchase software in the hope of never having to figure out how it is constructed.  Others pay millions of dollars for consulting companies to build the software and hope that it works.  Finally, the truly brave hire developers and IT professionals and hope that they can keep the organization afloat.  I have lived it for over 15 years and I have to scars to show it.

This is why I founded E₃ systems.  I wanted to help businesses with low cost and low hassle solutions to fleet maintenance and inventory management.  Contact us today and we will tell you how.

Software development is filled with stress and insanity.  It has rewarded me with a modicum of independence and a middle class lifestyle but I know for a fact that there has to be a better way to practice my profession.  So enjoy that working software because someone had to go a little insane to make it a reality.

Until next time.