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.

Understanding Estimation for the Misinformed

When I speak with business professionals, they often struggle to understand the basics of the agile reformation.  For example, when I hold someone accountable for not doing work, they are shocked I am expecting results.  Many times, I feel like am discussing a round planet with people who still think the earth is flat.  These kinds of misunderstandings often lead to dramatic blow-ups as the agile coach expects one result and the business a different outcome.  This week and over the next few weeks I will try to explain some of the basic ideas agile practitioners use.  Today, an overview of why the agilest use story points.

One of the most controversial activities in business is project estimation.  The reason why is many estimates for creative projects is a lie.  The company is lying to itself about what it wants and how much it is willing to pay for it.  The creative team usually lies about how long it is going to take to complete the work.  To any objective person outside this process, it looks like madness.  Everyone is lying, money is getting spent, and nothing gets into production. 

Project Estimation is farce and tragedy.

The agile manifesto came into being with the twelve principles of agile because the failure of major projects in the business world was becoming unsustainable. The firm spends too much money for too little return on investment; something had to change.  The first thing the agile reformation addressed was estimation. 

A traditional project begins with executives looking at the corporate budget.  After the debt is serviced, shareholders compensated, and payroll met a portion of the money is left over.  Managers then submit requests to spend this leftover money on capital improvements and technology projects.  Based on profitability and political clout, this money is doled out.  For the attentive, you will notice the business executives do not experience the same reality of the front line consumers or employees.  Thus, a software project begins with a pile of money.

The managers and directors once they receive this money then have to figure out how to spend it.  The money comes with plenty of strings.  The project has to meet a deadline which may or may not be grounded in reality.  The plan must work with current technology at the firm.  Finally, the manager must have people who understand how to take that pile of money and turn it into working software. 

What happens next is something resembling a demented game of “Name that Tune.”  The manager goes to consulting companies and internal development teams asking how much time it will take them to satisfy the project requirements. The consulting company will bid a price to earn the business.  The internal developers will offer an amount to remain employed.  It goes on until the bidding ends and the project begins.  The costs are not grounded in reality, and neither are the estimates.

What happens next is both farce and tragedy.  The workers with the limited budget and impossible timeline fail to deliver.  Making matters worse developers are expected to incorporate changes mid-stream and the deadline does not change.  Eventually, the deadlines are missed.  The budget is used up, and cost overruns are rampant.  Finally, people quit because they are burnt out for working numerous hours of overtime to deliver a flawed product.  Quality suffers, money is wasted, and this approach ruins reputations. 

The primary cause for this kind of disaster is many managers equate time with money.  So, if you have $40,000 and it takes 1,000 hours to do something, this means it will cost $400 an hour.  Now suppose you have a consultant who will do the work for $200 an hour.  You can do twice as much work.  It depends on both of the people having the same skills and ability which is not the case. 

Story points for estimates came into being because time does not equal money for complicated projects.  Those projects also feature tremendous uncertainty and are often resistant to automation.  Instead of telling a manager that the team will be able to do the work in 1,000 hours at $400 an hour, a scrum master or product owner will say the team can do fifty story points a sprint and there are roughly 213 story points of work.  The ridiculous game of name that tune goes away and people can start having realistic discussions of time and money. 

Next week I will show you how that works.

Until next time.

More than the Man in the Taupe Blazer

I am a guy from a state school with a
taupe blazer.  I am going to help you
get your software written on time.

I have had a lot on my mind the two weeks.  My day job is getting more challenging and my home business is puttering along as it always has.  The most interesting thing about working in technology is the pace of change.  If you don’t like something it is bound to change in the span of a week.  This week I wanted to devote more attention to the fine article in Bloomberg Business Week, entitled “What is code?”  For the beginner in technology it is a fine read, but it does get a few things wrong and in particular they get wrong the role of the “scrum master.”

In the first chapter of the rather long article they describe a “scrum master” as “The Man in the Taupe Blazer.”  According to the article:

“This man makes a third less than you, and his education ended with a B.S. from a large perfectly fine state university.  But he has 500+ connections on Linked In.  That plus sign after the “500” bothers you.  How many more than 500 people does he know? Five? Five thousand?”

In short, a Scrum master is an eccentric person who understands software development along with project management and if a project goes south they will be able to get on with their lives while the executive who hires them will be forced into early retirement.  At first glance this is not an unfair impression.

What the article missed is that a scrum master is just as invested as the executive who hires him.  One of first things a scrum master learns is the difference between involvement and commitment.  To be committed, is to put your career at risk if you don’t succeed.  To be involved, is to be a participant in a project with no repercussions should it fail.  This gets to the classic metaphor about the breakfast shop and pigs and chickens.  In my darker moments, I joke about being a pig because I live on a steady diet of garbage, live in the excrement of other pigs, am treated with contempt by the other farm animals, and when necessary butchered for someone else’s breakfast.

I am not far from the truth.  I don’t know how many times I have had a member of my business organization look at me like I am some kind of insect because I am not as; cool, professional, good looking, or credentialed as they are.  I also spend many moments of my day slopping through the mud of my company bureaucracy and infrastructure to get things done.  I have had people lie to me and get insulted when I point out they are lying to me.  I also remember the week before Christmas 2008 when I was slaughtered because I made a mistake after 14 hours of non-stop coding.

So to be clear my executive friends, many of the scrum masters you face have seen failure first hand and they do not wish to experience it again.  They also know that their success is dependent on the same things that make you a success which is getting the project finished on time and on budget.  We are not some empty shell in taupe blazers.  We are just as invested as you are.

Where we excel is that we understand software and the people who write it.  It is not a pretty job but for every skyscraper built it requires hundreds of people who understand, engineering, construction, and motivating construction workers to get the job done.  The tower may have “Trump” on its marque but it took an anonymous engineer with decades of experience to make it rise.

Unfortunately, software development is not construction in the conventional sense.  While buildings are constructed with steel, glass, and concrete, software is built using languages and systems that often do not play nice together.  We also have differing levels of training and experience which is not taught in schools but rather learned on the job so asking a developer to do something that seems routine can be a huge suck of time and money.  Also software developers, the good ones at least, see themselves as artists.  Which means they cannot be led around like construction workers.  They have to be treated like the smart professionals they are.  Instead, they are treated like expensive pigs ready to be sacrificed when a project goes bad.

Yes, I have a taupe blazer.  Instead of a Bachelor of Science, I have earned a Master’s in Management and I have earned numerous credentials in my field to prove to executives that I know what I am doing.  I also have over 17 years writing software and learning how to adopt to the new technologies.  I am your ally.  I am just as invested in the success of the project as you are.  Finally, if you give me what I need to succeed, I will.  So have a little respect for the scrum master’s in your life executives, we are the steady hands which make software work for your business.

Until next time.

The Power of the Pivot

Sometimes you have to stop getting punched in
 the face to realize you need to make a change.

The life of a Scrum Master or Entrepreneur is filled with uncertainty.  Today’s sure thing becomes tomorrow’s dead end.  This is why I wanted to devote to this week’s blog to the power of being flexible.  In the parlance of Silicon Valley start-ups, pivoting is powerful.

According the Agile manifesto, responding to change is more important than following a plan.  This seems counter-intuitive at first but when you work in the software business for a while you understand why agile people say this.  I can’t remember how many times I have been involved in a course of action is a software project where I have been futility swimming upstream.  A slight course correction or change of approach would have sped up the project and led to success.  Unfortunately, project flexibility was not built into the project and as a developer I was doomed to work on a failing project.

If leadership was more flexible and willing to make changes in light of the current situation the chance of success might increase.  This is where we get the term pivot from.  I learned about it from a fantastic article from Vanity Fair about the purchase of Instagram by Facebook.  I highly recommend the article to anyone willing to learn about adopting to change.  In summary, Instagram’s CEO Kevin Systrom had numerous bouts of failure and frustration.  It was only after he pivoted his firm toward photography and filtering that he was able to find the success he was seeking.

I remember reading this article on a plan ride home from a corporate off site meeting.  I witnessed the new organizational chart and saw five people named project managers who I had personally trained to use Team Foundation Server.  I also noticed that I was not going to lead a software team.  I felt humiliated and my career was at a dead end.  I was filled with anger and frustration.  Something had to give, and it was clear to me that it would have to be my career at my old firm.  I got together with a few of my mentors in the agile community including Alan Dayley and they gave me the support and encouragement which I needed.  Within a month I had changed jobs and become an architect and scrum master at another company.  It is one of the few times in my career I can look back and say I did the right thing.

So my lesson is that sometimes you need to pivot to be successful. Blindly following a plan will lead to nothing be frustration and misery.  If something isn’t working try something else.  We invest too much into the sunk costs of our lives.  By pivoting or responding to change instead of following a plan, we gain a fraction of our lives back and learn to find success.  It is not as neat and orderly as we would like but in an uncertain world it is the only thing we have.

Until next time.