Looking Ahead to 2019

Happy New Year!
 Looking back and forward.

The Christmas holidays are a blur of family, friends, and food.  The last week has been an exercise in sleeping late, snacking on food which is bad for me, and drinking a variety of fermented beverages.  It is also a time to reflect on the last year and look forward to 2019.

I got a few predictions right in 2018.  The battle between Amazon and Google did get fiercer.  I purchased smart lights and expanded the number of Google devices in the marketplace.  It is also clear Google is starting to pull away with a better quality product.  As of August 2018, Google was starting to pass Amazon in sales.  I hope this forces more innovation and lowers prices.  It would be nice if these smart speakers were the cost of a contemporary clock radio.

I was partially correct about politics in the last year.  Democrats did make a comeback, but the GOP leveraged its structural advantages to retain the U.S. Senate and some state house governments.   It was also clear the two parties are tragically unable to compromise.  Authors pointed out these differences were not a question of ideology but epistemology.  When Christine Blasey Ford, provided credible accusations of sexual assault against a Supreme Court nominee GOP senators saw someone who was “misremembering” a teenage event to destroy a career.  Democratic senators saw it as behavior toward women which was disqualifying.  In light of these events, it is clear the GOP, and the Democrats see women and sexual assault in different ways.

Last year was not just the spectacle of politics and commerce; I made some significant changes.  I decided to concentrate more on my brand.  I presented to the Agile 2018 conference, and I am working on my 2019 white paper for next year.  I spent time at the London 2018 coaching retreat and have given more discussions on Healthy Ownership.  It is a good start, but I have more work to do.  I have to concentrate on my coaching certification with the Scrum Alliance.  I am also returning to work, so I am looking forward to working with new people and challenges.

So what does 2019 look like?  I have three predictions.

The Messy Repercussions of Oversight – 

With Democrats controlling the House of Representatives, oversight of the executive branch will begin.  It will create numerous uncomfortable conflicts around the emoluments clause, nepotism and petty corruption from the executive branch.  I feel this oversight is necessary to hold powerful people accountable.  The aftermath of this oversight will be increase distrust in government and the deepening of the epistemic divide between the two major political parties.

Chubby Capitalism –

The American economy is chugging along creating jobs and wealth.  I suspect much of the growth is the result of low interest rates and mergers.  Gross domestic product is increasing, but there are troubling signs the good times are going to slow down.  I affectionately call the situation, “chubby capitalism,” as large companies bloated with market share and stock buy-backs struggle to adapt to the changing global market.  Some of these “chubby” companies are going to get eaten alive by faster competitors.  Others will be forced to shrink or face extinction.  Caught in the middle will be workers facing more risk and insecurity caused by the binging and purging which will happen next year.

Agile Tribes – 

I have noticed serious disagreements among the members of the Agile community.  The feud between the “No Estimates,” crowd and those who are skeptical is becoming bitter.  Kanban is growing in popularity, and this creates friction with Scrum professionals.  Finally, businesses are creating these quasi-roles for scrum coaches, senior scrum masters, and junior scrum masters.  I want both the Agile Alliance and Scrum Alliance to put down their collective feet and insist that scrum mastery and coaching are complementary skills.

So that is 2018 and a look ahead to 2019.  I hope everyone has a safe and sane New Years.

Until Next time.

Acknowledgements for the Christmas Season

My Christmas Card to you

The Christian holidays are always tough; you are preparing for gatherings of family and friends.  Free time is spent shopping, and disposable income comes and goes faster than a drop of water in the desert.  In the middle of this frantic scramble, I was looking for work.  I am happy to report I am returning back to work on January 3rd.  Adversity has a way of revealing the kind of person you are and this week I wanted to set this aside and thank a few people who have helped me over the last year.

I am deeply grateful for the support I received from my colleagues at LCS communications as I decided to pursue other ventures.  Wayne Reno was a great mentor and I hope someday to develop the emotional intelligence he possesses.  Thomas Collier was my partner in managing a chaotic software development process; he was both a voice of reason and experience.  Finally, I have to extend a hand to Kedar Godkhindi who was both a technical lead and a friend.  I could not get through this hardship without their support.

I also had plenty of former developers and colleagues come forward and pick up my spirits.  Larry Gasik is the curmudgeonly guy you always want in your corner during a rough patch.  I also want to recognize Gene Stetz who is never at a loss for words and has plenty of wisdom to share.   Michael Kappel is an eccentric and artist who will always inspire me.  Finally, I have to recognize Daniel Porrey who took a chance on me five years ago and thought I would be a good scrum master.

The agile community has been great particularly, Kat Daugherty who inspired me to submit my first white paper to a major conference.  I also need to recognize Anke Maerz who has been a pillar of support during the last six months.

I have plenty of people to thank but I don’t have enough room to recognize you all.  As we slide into the holiday and New Year, rest assured I am deeply moved how everyone had supported me over the last year.  2019 is a clean slate and I look forward to filling it with more learnings, news, and wisdom.  Happy Christmas and a joyful New Year.

Until next time.

Dealing with Scary Stuff

I am scared but I am going to be OK.

I have a sign on my wall which says, “If your dreams don’t scare you they are not big enough.” It has been a frightening period for me.  I am interviewing for new opportunities, sending out applications, all the while the holiday season approaches.  It is a lonely period despite the support I have received from family, friends, and colleagues.  Periods like this test a person and this week I would like to discuss it.

Since high school, I have been one of those students who could be labeled as “striver.” I wanted to advance myself and do better for myself and my family.  Pushing myself academically and participating in extra circular activities, so I would get noticed by a college.  It happened with a twist. I was offered a scholarship to a university and then it fell through.  I went to a community college for the first two years of my college career.  In hindsight, it was a perfect move as I was able to deal with the pressures of college with the support of my family.  When I transferred to a four-year university, I learned the discipline it takes to succeed academically.  It was not easy, but the early lesson was that success required sacrifice and discipline.

Sadly, those two qualities are not helpful when jobs were scarce as was the case in the recession of 1990.  Keeping the lights on and the rent paid required the swallowing of personal pride.  It meant working retail working for commission.  It was dealing cards at a casino.  I discovered I was good at computers and learning how to program them.  I was lucky when I left the casino industry, it was the giddy and stupid times of the dot-com boom.  I transitioned from dead-end jobs to a career.  It only took seven years out of school to make this basic professional milestone.

In the intervening period, I have been fired and laid off more times than I can mention.  I struggled to keep the lights on and the mortgage paid.  People have treated me in a grossly unfair fashion and I have received numerous second chances throughout my career.  The adversity which has dominated my career makes me contemptuous of others who have not had similar experiences.  It is also why I roll my eyes when I hear certain public figures discuss their “life of struggle.”

The ups and downs of my career took a heavy toll on my marriage and family life.  It has changed me more than I would like to admit.  In spite of it all, I have remained committed to the business of building working software and attempting to make work more satisfying, sustainable, and sane.  I am committed to large businesses treating people with basic decency.

I am going to give that vision a hard test.  The experience is going to challenge me in ways I am not comfortable.  I might fail.  I still have to try because I owe it to the people grinding out code.  I owe it to my family and I owe it to myself.  My dreams are very big and they scare me witless.   I look forward to defeating the fear and sharing those dreams with you.

Until next time.

When you lose a bet on your career.

Boy, did I fail.

It has been a crazy week.  I made the transition from working on a gigantic waterfall project to unemployment in the span of an afternoon.  I was feeling a flurry of emotions.  At first, I was ashamed and disappointed.  My feelings then migrated to anger and bitterness at how cheaply was thrown aside.  Currently, I am feeling determination and resolve to get back to work.  Through all this process, I have been overwhelmed by well wishes and support from the agile community.  It is this support which is keeping me going during this difficult time.

I joked glibly; I was betting my career that the project I was on could benefit from my agile knowledge and approach.  In less than seven business days, I was rolled off the project and laid off.  I did not receive any feedback from peers; I was just marched into the HR office and let go.  I should be angry and bitter, but that is not going to help me get back to work.  Fortunately, my colleagues on social media and #Slack came forward.  I received comfort, coaching, and support.  I also took some time to think.

It is not comfortable looking at failure.  It is necessary if I am going to grow and develop as a person.  It is one of the main postulates of agile is, “…to fail early and often.” In that respect, I was successful.  I failed, and now I have to take that failure and learn from it.  I am going to do a better job vetting employers to make sure they want the agilest working on their staff.  I am going to change the notifications on my mobile phone, so I am not distracted during the workday, and I can concentrate better.  Finally, I am going to focus more intensely on Radical Candor and Non-Violent Communication.

I have plenty of free time, and so I am going to use this opportunity to decompress and spend with family and friends.  I will live through this and would not be this brave without the help and support of everyone around me.

Until next time.

Rubbing Agile on It

I am in here somewhere.

Being part of a large project team is a huge challenge.  You are a member of a cast of hundreds.  Individually, you do not have much influence on the success or failure of the project, but everyone knows when you are behind schedule.  Finally, as a late arrival to a project underway, you feel like you are out running a giant boulder of death attempting to crush everything in its path.  I am where I need to be because it is clear I have to rub a little agile on this situation.

As an agilest in the middle of a very waterfall project, I understand that I am a square peg in a round hole. My boss rejected my first project plan because it was a word document with a list of risks, the people who were going to do the work, and a general timeline over eight weeks.  I was instructed to put something together more detailed in Microsoft Project.  I have not written a project plan since graduate school and never professionally.  I was content with user stories and a Kanban board.

Into this world, I am a stranger in a strange land.  The good news is that I know enough about lousy project management to try and apply better project management techniques.  I am consulting with the people doing the work so that I can put together more detailed steps in the project plan.  I am a big believer in customer collaboration over contract negotiation.  It caused shrieks of horror, but I like to share information with our client even if we are under contract with a fixed date.  I would instead practice “radical candor,” rather than “ruinous empathy.” Instead of weekly status reports, I will radiate information daily out of the “war room,” I am supervising.  By my estimation, the more frequent updates will create more goodwill with the clients.

Even the most waterfall project can benefit from the Agile Principles and the Agile Manifesto to achieve positive results.  It is my current thesis, and I am willing to bet my career on it.

Until next time.

The Art and Science of Getting Stuff Done.

If it was easy we would figure out how to automate it.

It feels good to be back.  I left my old firm and joined a new organization.  I took the week off to get accustomed to my new surroundings and sleep schedule.  I also had a holiday week, so I used the opportunity to catch up with family and friends.  Now that I am getting comfortable with my new role, I wanted to talk about the biggest challenge we face in agile and scrum.

The creation of software is one of the few modern products we produce which is nearly impossible to automate.  We have figured out how to automate plenty of things related to software development.  Testing can be automated.  DevOps demands the software building process to be automated.  Anything which is repetitive and tedious can be automated.  Writing software requires plenty of skill and practice to do it well.  Someone needs to take the vague ideas of the business and turn them into something concrete so that the software developers can create something valuable.

It means authoring software is a human process.  Human beings are notoriously messy and prone to error.  If you accept the reality of human messiness, it is easy to understand why projects fail and work does not get done.  A colleague of mine put it best when he said, “It all comes down to people, you can have the best process, but if the people can’t or won’t do it you are lost.”

Specialized professionals have come into being to help make sure the organizations keep going and the processes work.  These people have plenty of different titles and roles.  These people are scrum masters, project managers, and bosses of every conceivable size and strip.  What united them all is they need to be good with people and have strong leadership skills.

The good news is there are plenty of good programs which teach leadership skills.  Combined with practice and desire; anyone can become a competent leader.  Thanks to the Agile Alliance and the Scrum Alliance, we can train skilled people to become Product Owners and Scrum Masters.  These courses and training programs represent the science of project management.  The art combines the technical aspects of scrum mastery and putting it together with the messy nature of human beings to create something new.  It is not easy, and it is emotionally draining.  If done right, it can generate millions of dollars in value.  If done poorly, it resembles a tragically executed piece of performance art.

So leading projects is both an art and a science.  The science understands the things like testing paradigms and the art enters the picture where you have someone with gout working late hours and not getting the work done.  It is not easy to be nothing worthwhile is easy.  So remember the art and science related to your role.  You are going to need both.

Until next time.

Some thoughts on personal change

A typical day for a scrum master; doughnuts and coffee

I have called working in the business world bipolar, toxic and an excuse for mental illness.  I still feel this way, but along the way, I have encountered numerous pockets of decency and professionalism.  I have made plenty of friends along the way.  This week, I took a massive step in my professional career and resigned from my present organization.  I will be joining another firm on November 19th.

When I was growing up in the 1980’s, my parents and teachers spoke about how a career was a pathway or process.  You would join a company and throughout your career advance up the organization.  Your loyalty to the organization came with a measure of job security, and a means to support a family.  I was instructed people succeeded and failed based on individual merit.   The recession of the early 1990’s and over twenty years of being a technology professional have proven those ideas false.

I have spent plenty of time around the damaged, neurotic, and mean people who make up a significant minority of business professionals.  In my worst moments of vulnerability, I have choked back tremendous amounts of rage and bitterness.  In my better moments, I have forced myself to see the good in others.  I was disappointed from time to time, but often my optimism was rewarded.  I leaned on colleagues to muddle through the long days and lack of support, and I relied on my fellow agile coaches who saw something in me I did not.

It is easy to see the bad in the world and wallow in nihilism.  Creating a reformation is going to be hard work.  A modern shareholding company is the closest thing contemporary society has to medieval feudalism, and those in power will do anything to remain in charge.

Fortunately, there are others like me who are agitating for change and a serious business case for making those changes.  Developers, agile coaches, scrum masters, product owners, and random strangers want these changes.  Together, we will work to make the modern corporation more sustainable, sane, and satisfying place to work.  I have spent five years learning to be a great scrum master and coach.  It is now time to put that experience to use expanding the agile reformation. 

Until next time.

Psychological Safety in a Bipolar Business World

Psychological Safety means treating
 people like humans instead of insects. 

The global economy is a bipolar place.  The wealth and highs of success transform people into demigods.  The lows reduce human beings into squalid grubs struggling to survive.  For the white-collar professional caught in the middle, it feels like being in a bivouac of army ants.  You are being pulled in all directions by the tensions of others and the environment.  It is a stoic existence where we have no choice other than rely on others for our own survival.  It is alienating and undermines many of our desire for meaning.  The agile coach and scrum master must struggle against this reality each day.  In the corporate world, we should treat people as human beings instead of insects foraging for the benefit of an elite. 

The alienation of workers and disengagement it causes is why many consultants and agile experts are starting to discuss something called “psychological safety.”  John Dobbin wrote a great article about the subject on LinkedIn this week.  Pioneered by organizations like Google, psychological safety is behavior which allows people to work together in an environment of mutual respect and innovation.  It mirrors the work of Kim Scott, a former Googler, who wrote the book “Radical Candor.”  Aside from being the product of Google’s “don’t be evil,” days these two ideas come from our primitive reptilian brains.  Conflict with co-workers, a challenging boss, or business conditions create a situation where our fight, flight or freeze reactions to danger are triggered.  The emotional response is helpful during an avalanche or an attacking lion, but can create a toxic sludge in the cubical farms where many of us earn our living.

Unlike a backed-up storm drain, cleaning up the mess from the fight or flight response requires tremendous amounts of emotional labor and a huge dip in productivity.  From personal experience, I have had weeks of anxiety and self-doubt thanks to being ridiculed by a manager in front of product owners.  The episode gave those same product owners license to ignore coaching.  The sludge became more difficult to wade through at the office.

As I have become more experienced as a coach and scrum master, it is clear to me that psychological safety needs to be encouraged.  People need to feel you sincerely care about them and you are willing to hold them accountable. Leadership is more about creating this environment of learning than giving orders and controlling others.  I am still learning about how to do this as a professional but the Harvard Business Review is giving me a good head start. 

As a knowledge worker you should not be strung out like an army ant holding the colony together.  If the office is a toxic sludge of anxiety, it is time to grab a shovel and start the difficult process of creating psychological safety. I we fail we are doomed to live in a bipolar business world.

Until next time.

Agile Coaching must work with Corporate Leadership.

They made great art but the rivalry was toxic.
 Don't let this happen to your coaching relationship
with business leaders.

One of the best things about being an agilest is the network of smart and committed people who are willing to provide insight into how they are solving business problems.  I know if I ask for help I receive plenty of suggestions and feedback.  I wrote a blog about how agile is good at exposing toxic leadership inside an organization.  I received some criticism from people I respect who thought I was creating a false conflict with leaders.  Let me explain myself.

Organizations are coming around to the Agile Reformation for one apparent reason; it is good for business.  Faster time to market and more precise focus on meeting customer needs translates into profits.  Business leaders are also discovering disengaged workers, and toxic leaders are a drain to the bottom line.  It is just like what baseball manager Tommy Lasorda said, “Happy Cows make more milk.” The reality of the benefits of Agile provides an opportunity to make business better.  It also means business leaders and agile coaches have a vested interest in working together. 

The tension between leadership and agile coaches happens when agile exposes inefficiencies in the broader business.  Development teams release software, but the business users are not interested in testing.  Network professionals block the use of Continuous Integration/Continuous Deployment tools because they see it as a career threat.  Finally, pointing out a toxic leader can jeopardize the balance of power in office politics.  I struggle to navigate these situations. 

Often when teams become more agile, the surrounding business is stuck in the status quo.  It is inside this shadow zone where a company makes the transition from doing agile to being agile.  The metaphorical rubber hits the road in that place.  The only way it can succeed is if business leaders buy in, agile professionals lead by example and teams follow through.  A woman I respect very much said, “Do your job, tell the truth and if it does not work out it is their problem.” 

A large organization can behave like an addict they know they are involved in the self-destructive activity, but they cannot stop.  Only when the organization realizes they have to quit will they.  A scrum master or coach needs to be available when they are ready to make the change.  Leaders should be partners in any agile transformation.  Collaboration and cooperation should be the guiding principles of this relationship.  If it collapses into codependence and conflict, then it is time for the coach to admit failure and go elsewhere. 

Until next time.

Agile Exposes the Bad Boss

A bad boss is just toxic.

I was getting on an elevator at the office and I decided to make small talk with someone as we were heading up to our respective floors.

“Ready to set the global economy on fire,“ I joked.

My fellow traveler got a gleam in their eye and said, “The flames are so colorful.”

I got off on my floor and breathed a sigh of relief.  The metaphorical pyromaniac was too eager to be pulling my leg.  The experience brought into stark contrast how tired many of us have become in the business world. The daily frustrations of working in a modern office force many professionals into the cynical behavior of inflicting harm on others as a means of satisfaction.  It is perverse, and it is wrong. The cynicism in the elevator is one of the reasons I have been such an enthusiastic proponent of agile.  I firmly believe there must be a better way to structure work so that it is sustainable, sane, and satisfying.

Inc. Magazine and Monster.com pointed out this week that 76% of bosses in business are “toxic.”  This toxic leadership is why so many people rely on jaded cynicism.  It is crucial as an agile coach and scrum master to break this cycle of toxicity.  According to the article in Inc. magazine, a toxic boss exhibits some or all of the following traits.

1. They are power-hungry
2. They micromanager
3. They are absent
4. They are incompetent

It is up to people like me to expose these bosses to the organization and coach them to be better.

The Power Hungry

Working for a power-hungry boss is a little like being a supporting cast member in Game of Thrones; you are going to wind up suffering a cruel ending to satisfy someone else’s ambition.  It surprises me how many business leaders think servant leadership is similar to the game “Masters and servants.”  The reality of servant leadership is much different.  In the end, what everyone needs to understand is a power-hungry boss is concerned about one thing; themselves.  A power-hungry boss will put personal interest over the needs of the company and employees.  Agile exposes the power-hungry because they often become impediments to shipping solutions.

The Micromanager

The hardest part of leadership is the lack of control we have over our fellow humans.  A leader can spend years training people to do the right thing and meet a certain performance level, and they can still disappoint at critical junctures.  To combat this helplessness, managers create processes and steps which they expect people to obey like robots.  It creates an illusion of control where employees do what they can to avoid hassle rather than what is necessary to succeed.  Thus, reports have perfect typography and proper tab spacing, but the data within that report shows lead conversion is falling.  The emphasis on working solutions instead of comprehensive documentation in agile should expose micromanagers.

The Absent

Over the years, we tell countless stories about military leaders who “lead from the front,” instead of from behind a desk.  I am currently reading one about William Slim who commanded the 14th Army of Burma during the Second World War.  It is easy to get caught up in the trappings of authority.  In an office of cubicles, having your office is a status symbol.  It gives you the power to shut people out and focus on administrative duties.  The autonomy and control over who has access is a powerful motivation for people to advance into leadership.  In reality, a leader has to be more visible to the people they are leading.  A leader should know about the people who make them successful.  If the leader is not around and they become distant figure the people who make them successful will ignore them in time of crisis.  Agile attempts to counter this kind of toxicity with its emphasis on face to face communication.

The Incompetent Leader

A leader should not be able to do your job, but at the very least they should understand what it takes to do your job.  What I have discovered over the years is people who have never managed a computer network or written a line of code often lead technology teams.  These people know how to manipulate budgets and control the project, but they do not know how to direct technology professionals because they think they are no different than shipping clerks or factory workers.  Agile with its emphasis on cross-functional teams and delivery exposes the incompetent.

I am a big believer in the idea that you should tell and expose the truth wherever you find it.  Sooner or later, someone in a position of authority is going to act on that truth.  I feel this way because it is how we defeated leaded gasoline and paint.  It is how we have reduced smoking in the United States by half since 1964.  It is an approach which led to the birth of agile.

If we are honest with ourselves, we should acknowledge the power-hungry, micromanagers, the absent, and incompetent and expose them so their toxic effect on the workplace can be mitigated.  It matters, and if we are not successful, all we can do is watch the pretty colors as the world burns.

Until next time.

When the Story is Not Done

Things go wrong during sprints.

One of the most important facets of agile is the quick cycle times make it possible for people to react to change rapidly.  The end of each sprint is an opportunity to gauge success and look for areas of improvement.  The speed forces us to do work in smaller chunks and gather feedback and direction from customers.  An agile team can bite off more than it can chew in a sprint.  Today on my blog, I want to discuss some recommendations on how to handle stories which take longer than a sprint.

In a perfect agile practice, each team completes all of the work they commit to in a sprint.  The need to “roll over,” critical work to the next sprint does not happen.  In the fallen world where most of us live and work, stories do not get finished at the end of the sprint.  It creates a challenge because the unfinished story might delay a release or throw a delivery timeline off schedule.

The Scrum Guide does not say much about what to do when a story is incomplete at the end of a sprint.  Since there was no consensus, a beginning scrum master just rolled over the story and asked the team to finish the work in the next sprint.  The approach was no different than letting a milestone slip in a waterfall project.  The collective wisdom of the web stepped forward, and experts suggested an incomplete story should return to the backlog and reprioritized.  If the story still had value it can be placed in the subsequent sprint; otherwise, it can wait.

Concentrating on what is important rather than what is unfinished each sprint is what makes agile so powerful.  Unfortunately, unfinished work can become technical debt overnight and create conflicts inside the agile team.  Many stories are incomplete because the team has not met the standard of care for the story.  Unfinished unit tests and incomplete acceptance criteria are prime culprits for this situation.  The group wants to split the story and lower the number of story points so that it does not look like the velocity of the team is impacted.  The truth is velocity is affected.  The team failed to deliver story points in the previous sprint, so the velocity has gone down.  A team should both see and feel the effects of not meeting the standard of care.  People outside the team should also see an honest portrayal of the challenges the team is facing.  There should be no secrets on an agile team or in an agile enterprise.

When a team fails to deliver this is also an opportunity to bring up in the retrospective what caused this kind of setback.  Product owners should understand there is more to a story than writing code and developers should be more assertive about how they communicate.  The team should own up to the failure and try to do a better job next time.

Failure is hard, but it educates better than any success ever could.  It also makes future victory sweeter.

Until next time.

Agile and the Toxic office

The Open office plan circa 1960.  

A modern office resembles the dark vision of Jean-Paul Sartre’.  In his play “No Exit,” he traps three characters in a room.  The characters psychologically torment each other.  The lights never dim and no one can escape.  To Sartre’, “hell is…other people,” and they are impossible to escape.  It sounds like a perfect description of the modern office with cubicles and open floor plans.  By design or neglect, the contemporary office has become a toxic hell which white collar workers navigate each day.  As an agile coach and scrum master, you need to fight this toxicity and make work better. 

The open office is not a new concept.  As business expanded, hundreds of people were needed to perform necessary clerical work.  Captains of industry required contracts typed, checks deposited, and in a time before computers numbers crunched.  Many of these jobs became obsolete with the advent of computers and photocopy machines.  Today, an employee with a laptop can be more productive than an entire 1950’s office pool.  It is impressive when you think about how office work has changed over the last seventy-five years.

It is also surprising how little has changed.  Alcohol abuse is still a problem in the corporate world.  The “Peter Principle” which promotes people to their level of incompetence is still in practice.  Finally, according to Gallup, two-thirds of workers in the United States are disengaged.  I feel strongly Agile came into being because competent, hardworking people thought it was possible to do better.

The reason offices converted too open plans is the combination of perverse economic incentives and naive notions of what it takes to build a collaborative team. In cities with large business communities, rent is at a premium.  In Chicago rent increased by 20% in 2016 and currently leases at $50 to $60 a square foot.  Based on the price pressure, business owners have the incentive to get the maximum amount of use out of each square foot.  The open office makes that possible and managers can squeeze more people into less space.  The open office plan began with Frank Lloyd Wright and his Johnson Wax office building; it also has an origin in German design from the 1950’s.  The open office would facilitate conversations, collaboration, and innovation.  The reality of open offices is an environment employee’s loath.   

It does not help the shareholder value theory of business motivates many managers.  To these managers, the only thing which matters in increasing the share price or dividend for the company stockholders.  Thus, the open office and the shareholder model of business creates a fiendish replication of Sartre’s hell.  We are trapped economically in a space which is designed to torment us.  It is this combination of poor work environment and leadership which ignores stakeholders, customers, and employees are why I think we have such a severe problem with disengagement and alcohol abuse in office culture.  When there is a disconnect between your work and your wellbeing, something has to give; for many, it is their self-esteem and enthusiasm for work. Marxist philosophers call this “Labor alienation,” and it is just as bad today as during the sweatshops of Dickens.

Agile came into being because people doing the work of building the world economy through there was a better way.  These people were project managers and technologists.  None of them were Fortune 500 executives.  Individuals and interactions, responding to change, customers collaboration, and working systems were more important than everything else at the office and embracing these values we say we are trying to make the office less toxic. 

Many of us feel we are powerless to change things in the office.  Agile gives us the tools to expose dysfunction and reduce alienation.  We have to be brave and smart enough to use those tools; otherwise, we will continue to have the same office as we have had for seventy-five years and there will be "no exit," for us. 

Until next time.

No secrets on an agile team.

No secrets on a crap game or agile team.

I went to San Diego this week to talk about “Healthy Ownership,” with other agile professionals.  The experience got me out of the office and listening to others and their challenges making their workplaces better.  During the discussion, I recalled an old saying I learned when I worked as a dealer and pit boss at Harrah’s casino, “There are no secrets on a crap game.”  It occurs to me that wisdom can be applied to any agile team.

Working a crap game in progress, for the uninitiated, is confusing.  Dice are flying in the air and depending on the number they land hundreds or thousands of dollars can be won or lost.  It is a loud, frantic, and intense game of chance.  Since it is so fast, the dealers need to have incredible arithmetic skills, manual dexterity to make payments, the customer service skills of a butler, and the grace under pressure of a bomb disposal expert.  It was the most difficult job I ever had.

The reason dealers and pit bosses say, “There are no secrets on a crap game,” is things move so quickly on a crap table that bets are often made while the dice are in mid-air.  Only by shouting out your bet and having it confirmed by a dealer does it “count.”  If the dice bounce off a player’s arm on a crap game the other players will get angry and will often leave the table.  The superstitious behavior of gamblers encourages craps dealers to vocalize everything they do.  A dealer repeats back bets to the players.  A dealer often recites the payouts they are making and where those bets are located on the felt in front of them.  All this happens because the game needs to keep moving and no one wants to lose out on a bet.

In a world where agile teams have healthy ownership, the teams should exhibit three qualities.

1. Open Dialog.
2. Increased Empathy.
3. Collective Ownership.

For a crap game to be successful, open dialog needs to exist on the crew.  It is why everything is vocalized.  At casinos, my experience was crews were scheduled together so they learn to work together.  Finally, everyone on the crew is accountable if someone cheats or something goes horribly wrong.  It seems the casino business was into healthy ownership before agile professionals.

What does this mean for software development teams?  To achieve open dialog, the development team, scrum master, and product owner need to be in constant communication.  Stand up meetings need to be frank and to the point.  Product owners should listen in and make sure they can answer questions.  Scrum masters should facilitate discussion using the product backlog as the central hub of information.  Finally, developers should follow up on acceptance criteria to make sure what they are building is what the product owner needs.  If anyone is in doubt the should speak out.

To increase empathy on the team, the scrum master and product owner should share a work space.  It allows the scrum master and product owner to understand each other’s routine.  Using video conference equipment also helps.  It lets individuals see each other as real people instead of disembodied voices on a conference call.  Teams should work together in open spaces with areas for mob programming and rooms for privacy; I find both are necessary for the success and sanity of developers.  The most important piece is to make sure each member of the team understands the challenges and responsibility of the others so they may have empathy.

The final outcome of collective ownership is necessary for Healthy Ownership to thrive. It means the scrum master, product owner, and development team share equally the success and failure of each sprint.  I find this to be the most difficult outcome to achieve.  It requires highly skilled people to give up a little of their ego and make sacrifices for others.  To borrow a phrase from Benjamin Franklin, the agile team needs to hang together or all of them will hang separately.

To have healthy ownership an agile team needs; open dialog, increased empathy, and collective ownership.  The development team should not have any secrets just like a casino craps crew.  Following this model will create the healthy ownership which will help every team a success.

Until next time.

Listening, Compassion, and Shared Context make coaching rewarding.

Healthy Ownership requires plenty of tools.

I have spent a majority of my life around educators.  I have family members who were teachers and administrators.  Many of my peers in college are teaching at the university and high school level.  I also spend my time on social media following teachers, trainers, and educators of all stripes.  A common refrain I hear from all these people in my life is satisfaction they receive when students they serve understand a difficult concept or master a skill.   For many of them, this feeling of satisfaction is why they got into education.  It is the same reason I am an agile coach and why I am championing the notion of “Healthy Ownership.”

My attendance at the agile coach’s retreat earlier this year was an awakening for me.  I spent time with other coaches and learned some valuable lessons about myself.  I also worked closely with ten gifted people who held each other accountable and created something called “Healthy Ownership.”  Born out of frustration in my agile practice, “Healthy Ownership: was an opportunity for me to learn better techniques of coaching. It was also a chance to step aside and learn how others lead and motivate teams.  It is surprising what I learned. 

The most important lesson is to listen to what people are saying.  I struggle with this ability at work.  Put me in front of a PBS documentary, Anime show or Kaiju film, and I am perfectly attentive.  In work situations, I struggle to listen.  My inability to pay attention to verbal and non-verbal cues hurt my coaching.  Thus, I am committing myself to be a better listener, so I understand the hidden and apparent challenges to the teams I am serving. 

After listening, I need to work on guiding others to have more compassion for their colleagues.  You cannot fundamentally change how empathetic a person is but you can help someone it is their self-interest to help others. Ayn Rand speaks about the “virtue of selfishness.”  I consider her thinking to be an alibi for callousness and contempt which will undermine any team attempting to succeed.  It is why everyone needs to understand they are working together.  You may not be able to increase team empathy, but by reducing callousness and contempt among team members, a coach will have a better success rate. 

Finally, after guiding others to help team members, it is essential to create a shared context.  It means a product owner, developer and scrum master should understand how to better focus on what they need to do together to be successful.  For instance, my teams discuss technical debt daily. The purpose of the discussion is for product owners to understand the obstacles the teams need to overcome to deliver the product.  The mindset of continuous improvement seeps into everyone’s mindset, and during sprint planning, we have frank discussions about the amount of refactoring we need to accomplish.  The shared context is building quality for the customer faster.  If the product owner sees how hard it is to get stories finished, they pay attention to technical debt. 

I am going to be in San Diego as part of the agile coaching exchange talking about “Healthy Ownership” and how it has changed my perspective.  As you can see, I am going to be talking about it for the remainder of my career. 

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.

Each Scrum Master and Agile Coach Should Embrace the Weird.

Be Weird!

Being a scrum master in a large organization is filled with contradictions.  The scrum master is a servant leader for development teams with zero authority unless earned.  A scrum master removes impediments to progress and leads to continuous improvement.  It is a mission which often puts the scrum master in conflict with the organization they work.  People in the business see you as a misfit and weirdo.  I firmly believe this is a good thing and coaches and scrum masters should embrace their inner weirdo.

I kept thinking about how change is often promoted by the eccentric, weird, and outcast among us.  Allan Turning and Ludwig Wittgenstein are intellectual giants of the twentieth century.  One invents the concept of software development and computer science.  The other gave us the “Tractatus- Logico Philosophicus.” Our understanding of computing and language would never be the same thanks to these two people.

Both people were also profoundly weird.  Turning was a closeted gay man with a penchant for wearing a gas mask to ward off allergies.  He was also overly protective of his tea mug chaining it to a radiator.  Wittgenstein was weirder than Turning;  he quit university teaching to build a house for his sisters.  He claimed his book “Tractatus- Logico Philosophicus,” was the last book of philosophy anyone will ever need, and he also liked to pick fights with his contemporaries like Karl Popper. 

Today people like Turning and Wittgenstein would not make it out a Ph.D. program at a big ten college let alone be tenured faculty at a major university like Cambridge of the 1930’s.  The world of business has similar stories.  Bill Gates was a college dropout who could not complete his eagle scout when he was in high school.  By every definition he was a nerd, breaking into computer labs to get more time on mainframes.

I doubt a computer company or venture capitalist would give someone like Gates the time of day.  His elevator pitch would be too bland, his sweat-stained oxford shirts would not look professional, and what does a college dropout know about business.  The truth is Bill Gates is one of the countless oddballs, misfits, and weirdos who have moved business, technology, and society forward.

It is why when I saw this tweet from the Muppets I had a revelation.

Some people think it's okay to be weird, but they're wrong... It's AMAZING to be weird!!! There's absolutely nothing better!

— Gonzo (@GonzotheGreat) September 6, 2018

Being weird is amazing.  Not living in the box others live in is fantastic.  Being able to speak truth to power because they do not take you seriously is fantastic.  Making changes which are crazy enough to work is terrific.  Being weird is a lonely path, but the friends you do make are amazing.

As a scrum master or agile coach, you are in a weird role doing weird things which the rest of the organization consider weird.  The truth is what you are doing is amazing, and you are going to be remembered with more fondness than the boring CEO who speaks in accounting jargon.

Go forth, be weird and be amazing!

Until next time.

Time to call out bad agile before its too late.

Do you want this person coaching your agile efforts?

Agile is not a revolution in business.  You do not see technology professionals and agilists with pitchforks and torches wanting to burn down global capitalism.  It is a reformation where smart and conscientious people are attempting to reform business.   It creates a backlash against people who are happy with or benefit from the status quo.  Backlash is a natural reaction to change.  What I have discovered this week are developers I have known and respected for years heckling an introductory agile training course in their company.  Via social media, I had a front-row seat.  It was deeply troubling, and I wanted to blog about it.

Plenty of technology leaders have criticized Agile and Scrum.  I have written two blogs directly addressing these concerns. What struck me, recently, was the contempt I was experiencing from quality developers about the basics of agile.  I witnessed a series of vomit GIFS and videos of people attempting to self-harm while the presentation was in process.  One commenter said, “Reading these to my team (we all hate agile) and we are LOL” and the thread continued with someone else saying, “…I have a passion for hating agile so yeah I’m LMAO.”  Making matters worse the slides showing agile principles were mislabeled and out of sequence.  Combine this with an instructor who looked like they never had to deliver working software it was brutal and disappointing.

After some back and forth with the hecklers, someone I deeply respected got to the meat of the why there was so much contempt.  The agile manifesto and principles of agile were “insulting,” and further elaborated, “if your leadership is buying into agile, it works.  However, that is not a case at most companies.  This is much harder to install at something that isn’t a startup.”

The contempt is a product of poor leadership support of agile.  The ridicule comes from skilled and experienced developers who want to ship software without getting bogged down in process.  The laughter comes from poorly coached and led efforts to guide agile at the firm.  The cynicism is a product of “dark scrum” and the creation of a software sweatshop mentality.

It was upsetting to experience this kind of pushback.  I do not discount this experience.  People with PMP certification and limited exposure to agile feel threatened by the reformation of business.  Some of the unscrupulous put on the title of “Agile Coach” without the experience or the mindset of a coach.  These individuals peddle their services as consultants or thought leaders.  Often people like this are about a helpful as butchers in an emergency room and just as dangerous.

Poor agile leadership, coaching, and education deserve contempt.  Those of us who bring a sense of artisanship and care to agile need to point out bad actors and improve the field.  Often, we are brought in to clean up the wreckage created by these people. We should also extend help to the bad actors to improve their ability to do the job.

I firmly believe a terrible agile application to a company is worse than no use of agile at all.  Based on the contempt some of my developer friends heaped on the agile trainer; it is clear they feel the same way.  Coaches and scrum masters like myself will be around to help guide others.  It also looks like we are going to clean up this mess left by others.

Until next time.

Talk to People Instead of E-Mailing Them!

Instead of sending an e-mail pick up the phone.

I have been a business professional for a long time.  I have been working in technology for two decades.  In that time, the world has changed radically for good and ill.  What has not changed is the time suck which is e-mail and how it is cancer for many organizations.

E-mail is as old as the internet.  Before the creation of the World Wide Web, the most common use of the internet was swapping files and sending e-mail.  Business organizations saw the utility of the application and used it as a means to create a way to cut down on the number of business memos.  What happened is the creation of a flurry of messages through companies as people used the tool to improve communication.  With the advent of e-mail and voice mail systems, managers hoped the worker bees in the cubicles would not ignore important information.  According to my experience, the cobra effect raised its venomous head.

The information did move more smoothly, but it created an incredible amount of noise which drowned out the necessary information. Instead of business goals; office gossip, invitations to lunch and memes began to clutter up inboxes.  The torrent of information became a tsunami as network systems were tuned to send SMTP messages.  Today, every file dropped into an FTP folder, or work item changed in JIRA or help desk ticket created generates an e-mail to provide you with a friendly reminder.  Today, a business professional has to act on hundreds and thousands of e-mails – daily.

The ocean of e-mail both trivial and critical is overwhelming.  It has created the inbox zero phenomena and a perfect storm of professional apathy.  All e-mail has the same relative importance, so it is easy to ignore messages equally.  Managers have used the folder routing features of Outlook and GMail to ignore inquiries and information from subordinates skillfully.  Help desk people with a particular form of sloth will ignore complaints for days.  The ability to use email as a tool of deflection seems, to me a credible reason why productivity has been relatively stagnant over the last decade.

What makes e-mail so insidious is that it is a written record of the conscious and unconscious mind of an organization.  An e-mail gives an employee an alibi creating the impression they spoke up about important issues even if management ignores that information.  Sexual harassment and gossip exist in the company e-mail database like an improvised explosive device waiting to dismember.  Finally, criminal and unethical behavior are spelled out for prosecutors and the journalists to expose.  It is why the e-mail database for Enron is still used by software companies to test e-mail products.  The criminal conduct and general idiocy of the Enron organization live forever.  Technology, human resources, and public relations professionals use the Enron e-mail database as a simulation of what might happen in an actual corporation.

To me, e-mail is not a tool for clear communication but a device for obfuscation.  It is the written equivalent of snowflakes coming together to create a blizzard of awfulness.  Individuals compensate with text messages sent between private phones, executives and other essential people having multiple phones to have conversations.  It is critical information being harder to share and keeping secrets for personal gain.  Finally, business professionals spend three to five hours each business day according to Forbes monitoring and authoring e-mails.  I think this is crazy.  Instead of helping customers, innovating the business or solving problems we are doing ticky-tacky work monitoring e-mail.

One of the agile principles says that face to face communication is preferable to other forms of interaction.  So my warning to any scrum master or agile coach is to pick up the damn phone, call people, and speak to them.  Get up from your desk and walk over and talk to people rather than hide in your office.  Use video conferences and insist that everyone turn on their camera so that we can read body language and know they are paying attention.  A lousy organization is not going to change if we insist on doing the same thing redundantly.  It is time to reconsider e-mail and how we use it.  It cannot hurt to try.

Until next time.

Product Owners deserve Healthy Ownership.

Spending quality time with Alex Sloley

I have been working as a scrum master for the last five years.  What I have discovered over that period of my practice as a coach and scrum master is that product ownership is the weak leg of the triad of Scrum roles.  We spend plenty of time making scrum masters and developers better, but we still struggle with the purpose of the product owner.  I suspect this is because as a former technical professionals scrum masters and developers speak a similar language.  Product ownership is different in experience and expectations.  It is why it is the weak leg because it is so radically different to slinging code.  It is why I want to talk about “healthy ownership” on my blog this week. 

The notion of “Healthy Ownership,” was constructed when I attended the Agile Coaches Retreat in London this summer.  I had just finished a contentious sprint planning session before getting on a plane to England where a product owner questioned the estimates of the development team.  It was a gross breach of the social compact of agile.  The product owner protested, “They did something similar last sprint, I thought they would be faster this sprint.” Typically, I do not want to drink bourbon at the office, but at that moment I was sorely tested. 

I brought this and other examples of bad behavior to the other coaches.  I pleaded with them for help. Others had similar challenges and solutions.  The truth was they did, but no one had come up with coaching techniques that would help them rectify the situation.  Like any other self-organizing group of individuals, we came up with a team to address this situation.  We had numerous people with different perspectives from former developers to project management professionals who were attempting to instill professional practices in their organizations. 

We had three goals: 1) open dialog between team members, 2) increased empathy between team members, and 3) collective ownership of outcomes.  It was not going to be easy.  We did discover that we could combine coaching techniques to gather information and come up with scenarios for common pain points.  From there we could collect data and try to inform and persuade others on how to approach situations.  It is not a script or prescriptive but more like a way to practice common coaching techniques with common problems on agile teams.  It is not perfect, and we are still forming approaches, but for the rookie coach or scrum master, it acts as a safety net.

Flash forward to the Agile 2018 conference, and I heard other people discuss their challenges in getting buy-in from product owners and developers.  It is why I am grateful for Alex Sloley and his discussion about transplanting the brains of product owners and scrum masters.  By shifting the roles of a scrum master and product owner, we get to “walk a mile in someone else’s moccasins.”  The product owner understands the challenges of the scrum master and developers while at the same time the developers and scrum master understand the challenges of the product owner.  It was a nice juxtaposition, and I will use the term “backlog coaching” in my practice for the rest of my career. 

So to me, “healthy ownership,” means putting yourself in another person’s situation and understanding the unique challenges they face.  It means that it may be necessary to do a “brain transplant” or less drastic measures for people to understand what is going on in the development process.  Product ownership is the weak leg of a scrum team, but it is because coaches and scrum masters do not pay enough attention to the role and how to make it better.  It is why I am going to be spending more time with my product owners and walking a few miles in their moccasins.  With a little luck, I will reduce the stress on my development teams and improve the performance of my product owners.

Until next time.

Looking back at Agile2018

Spending time with fellow
 speakers Michele Sliger and Erika Lenz

This year is a personal and professional adventure for me.  I journeyed to the Scrum Alliance coaches retreat in London.  Last week, I was a presenter at the Agile 2018 conference.  Each of these experiences has made me a better scrum master and agile coach.  Now, that I am back home and have a more stable schedule; I will be blogging on a more regular basis.  This week a few take-a-ways from the #Agile2018 conference.

Data and Metrics-

The Wednesday keynote was Troy Magennis who spoke passionately about data and agile.  He proposed that agile professionals find a better way to present data to others and that data should inform decision making rather than reinforcing existing prejudices. 

He also provided data showing notions of teams being smaller than nine people may be counterproductive in larger projects.   He pointed to studies where groups of eleven to nineteen people are less efficient by a fraction compared to seven to nine-person teams.  He then argued that fewer handoffs between teams would make up for this difference.  It was provocative, and I look forward to people testing out his thesis. 

Presenting for the first time. 

The conference featured numerous presentations on metrics and data in agile.  I believe the use of quantitive data rigor in project and business management is a good thing.  For the remainder of the conference, numerous sessions covered the use of data and metrics in Agile. 

Outcomes are better than output-

The Agile Alliance with its speakers unwittingly created a theme for this conference.  The idea was outcomes of real features and progress are more important than outputs of stories, unit tests or story points.  Countless presentations emphasized working code delivering real-world value.  My presentation about the Cobra Effect reflected this dynamic as well.  When we measure outputs, we get perverse incentives.  When we measure outcomes, we get a better perspective of performance. 

Facilitation and Radical Candor-

The life of an agile coach or scrum master is a life of responsibility without any authority.  It is paramount to successful organizational change coaches develop superhuman skills of persuasion and facilitation.  I attended several sessions on how to be more credible and persuasive.  Many of these sessions pull from the insights of Kim Scott, a former Google Executive, who authored the book, “Radical Candor."

I learned plenty of valuable lessons at #Agile2018, and I look forward to the next conference in 2019 in Washington D.C.  I better start working on my presentation outline. 

Until next time.