Change Happens, Damn it!

Change is never easy.

This week I experienced tremendous change in my agile team.  A technical profession was made an offer they could not refuse and they left my development team.  It was bound to happen sooner or later but I was not expecting it so soon.  It made me think about many things and put into perspective the last part of the agile manifesto which is responding to change over following a plan.  This week I want to talk about change and learning work within it.

I have mentioned the philosopher Heraclitus said, “No man can step into the same river twice.”  This pre-Socratic philosopher could be considered the intellectual god-father of Agile because a central portion of his philosophy is concentrated on change.  Other philosophers have discussed change, but Heraclitus was the first so he has a special place in my heart.

The initial founders of the agile movement when they created the manifesto were also concerned with change.  The world of technology changes too quickly to use old methods of software development.  When President Obama took office there were 150 million Facebook users.  Today, that figure is at over 1.1 billion.   The only way that Facebook could accommodate that kind of growth was revise how it did things from publishing code to managing its servers.  It takes an army of very smart people but Facebook has been able to do it because they have been able to embrace change.  This is why the web site can accommodate the blind and have over 50 different designations for gender.

Human beings evolved intelligence in order to better adapt to change however since we are evolved creatures we still have some more primitive traits in our behavior which makes it hard for us to accept change.  This is why Spencer Johnson made so much money with his book “Who Moved My Cheese?”  In the book he creates a modern fable about two mice named “Sniff” and “Scurry” and how they respond to the cheese in the maze they work in being moved.  Once he is done with the fable, Johnson sets about some concrete examples on how to deal with change in an organization.  The book was an instant smash and inspired a parody called “Who Stole My Cheese.”  I like both books.  I enjoy the original because it has some practical guidance about change and I enjoy the parody because it is a necessary to point out that change management never works in corrupt or greedy organizations.

As an agile professional, you are going to have to deal with cheese being moved and being the person moving it for you agile teams.  For instance, I was in a meeting and an executive was issuing orders on how we were to name things in the backlog.  Everyone in the room smiled and nodded like sycophants while I was openly frustrated.

“What’s wrong, Ed?” the executive asked with the empathy of a hangman.

“My cheese is being moved,” I replied throwing my pen down on my note pad, “I have been trained to name these things a certain way for six years and you expect me to change overnight by fiat,”

It was hard but now I have embraced the change and now I find myself correcting other people in the office when they do not name things in the same manner as that executive.

Change is not easy but admitting you have a problem with a type of change or the pace of that change is a step closer to embracing it.  You can then rationally step back and learn to work with that change in your situation.  Sometimes that means changing your behavior and other times it means changing how you do something.  In a world of constant change, you either adapt to those changes or you will be left behind.

Until next time.

The High Stakes Poker Affecting your Agile

Business is not like poker,
but many in leadership think it is

Before I worked as a technology professional, I worked in a casino as a pit boss.  Each night, I would see fortunes come and go based on the flip of a card or the fall dice.  It made an indelible impression upon me.  I met plenty of fantastic people and I also learned a great deal about myself and leadership.  Some of the lessons I gained on the casino floor still linger with me.  This week I noticed something as stocks were falling and the business news was discouraging, business leaders see what they do in the same high end poker players play their game.

When you watch poker on television it looks glamorous and sophisticated.  The reality is much more pedestrian.  What looks like two hours of key decisions is really six to eight hours of grinding action punctuated by a few interesting hands.  The producers of these poker programs make sure that the action is properly edited for television.  Getting to the final table is also a marathon which could last a week sitting grinding out hands of poker eight to ten hours a day until the final eight players are left.

Many of the people who are in senior leadership positions are like those poker players.  They are survivors of your corporate culture grinding out their positions by taking calculated risks when necessary and sitting out a majority of the action.  They are not innovative or creative people by nature.  They know when to bluff, bully, and calculate the odds when they have a promising looking set of cards in their hand.  They also understand the old adage, “If you can't spot the sucker in your first half hour at the table, then you ARE the sucker.”

This is why it is so hard for agile initiatives to happen at some organizations.  The constant experimentation, transparency, and risk taking necessary to innovate are an anathema to people who have spent their entire careers keeping their metaphorical cards close to their chests.  Poker is also a zero-sum game where there is always a winner at the table and a loser.  Someone succeeds and someone fails or gives up.  This gives failure an additional stigma which is something that business leaders which to avoid.

Agile is about the opposite of this kind of mind set.  It resembles a bunch of grown people playing with Lego pieces rather than a serious high stakes card game.  It requires creativity which many people find alien and scary.  Finally, it means trust and transparency which is the last thing you will ever find at a poker table until this last card is turned over.

So if you are leading an agile effort go to your local poker room and take a look at the players around the table.   The reality is they are going to look much like the business people you are going to have to convince to try a new way of doing things.

Until next time.

Are these factors holding back your agile adoption?

When the emperor has new clothes we need to speak up.

Once in a while I see something and it inspires me.  I get fired up and feel like ranting into the night like some kind of crazed deviant looking for windmills to joust.  This week I had one of those moments and it steeled my resolve.  I am an Agile professional and I want to help change the way people work.  

It all began when I read a fantastic blog post from Isaac Socolick, talking about Legacy thinking versus Agile thinking.  This got me thinking.  It has been fifteen years since the agile manifesto and plenty of business organization are struggling to adapt to the new paradigm of how business works.  I have been part of this effort for the last six years.  Why is change so difficult for these organizations? I have a few hunches.

Legacy Funding of projects-

At large organizations products are funded on a limited basis.  Teams are funded, spun up and then they are wound down once the project is completed.  This is a standard water fall approach.  Once the project is completed then it was folded into the support stack of the organization to be forgotten.  No consideration for Net Present Value is made.  Often input for what the customer wants is ignored and the project is seen as a test for a project manager or executive who wants to advance.  Finally, the process is managed not by operations people who understand the business but by accountants and CPA’s who understand pushing money around the firm.  So projects are funded with a thrown together team, with a defined deadline, and with limited input from the customers.  No wonder projects fail so often in corporate settings.

Quid Pro Quo behavior –

I have mentioned this before in this blog but bureaucratic organizations are organized around rules and favors.  The rules are covered by regulatory compliance and common practices in the organization.  Favors are people deliberately circumventing those rules in order to accomplish something.  This sets up a system of favors which makes the Tammany Hall politicians of the nineteenth century look like pikers.

This forces business leaders to trade favors with each other to accomplish personal and business goals.  Many of these favors happen under the noses of leadership because to expose these favors would open the firm up to scrutiny from regulators or worse upper management.  So what happens is a “Tit for Tat” or Quid Pro Quo culture were executives do favors for each other rather than focusing on the customer.

Ego Driven leadership – 

Since Lee Iacocca took Chrysler in the early 1980, a new kind of business leader has emerged.  This was the business person and celebrity.  They were in the company commercials.  They spoke for the company when asked to testify to congress and they behaved like monarchs running their business empires with imperial control.  Unfortunately for every, Lee Iacocca there were numerous failures such as Carly Fiorina, Al Dunlap, and the most infamous Ken Lay who transformed Enron into securities fraud and criminal organization.

People seeing this trend in business decided to jump on this bandwagon.  These executives in training began worrying about their own personal brand rather than how they were going to run the business.  They discovered with a few accounting tricks they could cover up, poor sales, a lack of customer service and poor innovation.  They further burnished their credentials by leading legacy style projects which improved their brand but did not help the business.  Developers have had a name for this for years, they call it "ego driven development".  Well ego driven leadership is the byproduct and it is hurting businesses all over the world.

I got involved in Agile and the reformation it is leading in business for six years.  I have the enthusiasm of a new convert but I know that trends like the above are going to hold back the necessary progress which we are trying to achieve.  We need to expose these obstacles in order to remove them.

Until next time.

How my agile is changing.

Those of us in the agile community spend a lot of time talking about building software and helping our business partners.  What I have discovered over the last six months is that for a large organization like mine agility is a relative concept.  What I am discovering is that the business is struggling to keep pace with the developers.  This week I want to provide a few helpful tips to explain how you can help your pals in the business keep up.

Have a release plan – 

Software projects in my organization have a budget along with a beginning, middle and end according to the executive leadership.  To the suits at corporate, they don’t know or care about sprints, iterations, and burn downs.  So we have been forced to come up with a bridge document between the backlog and what the leadership expects.  This is the release plan.  Since my leadership does not understand the terms epic, theme and story; we substituted the words milestone, feature, and story.  This made it easier for the executives to follow along.  In our backlog we organized everything by milestones then placed features under them and finally had stories under those.  What happened was a revelation.  The business owner knew what was expected to be completed and then wrote stories to accommodate that structure.  Sprints were now planned around delivering features and we were doing better at delivering what the business wanted instead of what the business owner wanted.

Metrics –

Professional athletics is concentrated on metrics.  How fast you can run.  How high you can jump.  How many interceptions you throw during a football game.  The game of metrics has been transformed by the practice of sabermetrics and “Money Ball.”  Development which is done primarily by engineers has been very poor at measuring performance.  This is why I have started to measure the team velocity in story points.  I am also comparing the amount of work scheduled versus the capacity of the team.  This provides the team with positive reinforcement along with upper management a way to gauge how we are doing.  I will also be doing more advanced things like comparing bugs with velocity and understanding if we have good code quality compared to team morale.
 

Developer and Scrum Master training –

I find it interesting that we are working on software which runs the business but the developers and scrum master do not know a lick about the business.  That is changing.  I am spending about 90 minutes a week learning the business with people on the front line.  This training will become a training program for all the developers on the team.  Each of us working on the project should be competent enough to work as an entry level employee using the software.  This is a new experience for me and my developers.  I don’t know why we did not think of it sooner.

Tender loving care for the business owners – 

My organization has had a spotty record with business owners.  They have taken a training course in how to be product owner and then they have been left to fend for themselves with little direction from their business units or help from the scrum teams.  I have made a point of each business owner I work with giving them a copy of Roman Pichler’s fine book “Agile Product Management with Scrum.”  I also spend time with them helping them groom stories so that the developers know what they are doing and can deliver that in one sprint.  I help them tie stories into the release plan.  The product owner has one of the hardest jobs in an agile organization.  Your scrum team will not succeed if the product owner doesn’t.

The most important part of the agile manifesto is to adapt to change over following a plan.  Well we are changing and this is how we are doing it.

Until next time.

Getting inside your bosses head.

Your boss isn't that bad once you understand them.

As a software developer and scrum master, I have a unique perspective on the world of business.  I am a highly skilled and compensated professional.  I also have had the misfortune to experience the uncertainty of the gig economy, and the abusiveness of contemporary project management.  It took a serious toll on my physical and mental health.  It also pushed me to set up my own business and become part of the agile reformation.  This week, I want to talk about the pressures that our business partners are going through each day and how we techies can help them.

There are two contemporary stereotypes technology professionals have about their bosses.  One comes from the Mike Judge movie “Office Space”.  The boss is Bill Lumbergh, he went to the correct business schools and says all the right things but it is clear he has no understanding how the business works.  In addition, Lumbergh’s leadership skills are of the color by numbers variety which inspires zero confidence and undermines initiative. The other which comes to mind is British television series “The IT Crowd.”  This boss understands the business.  She also has great leadership skills and seems to be able to work with her colleagues but her major fault is that she doesn’t understand a thing about technology and the two technology professionals which work underneath her.  This makes the show very funny as her employees Roy and Moss make a mess of the corporate infrastructure.

The reason these two stereotypes are so popular in entertainment is that they are very common in the business world.  I spent many years of my career working with poor leaders.  This makes working with the good ones very inspiring.  I have noticed these people both good and bad have similar characteristics and are under similar pressures.  Fortunately, Paul Glen wrote one of the better books on technology and leadership called “Leading Geeks.”  He outlined the differences between people who work with technology and the people who lead them.  His thoughtful insight changed my perspective and made me a better developer.  It also made me a better leader.

Glen says that leaders have several characteristics:

• Leaders get paid to influence others
• Leaders see being likable as a key to success
• Leaders care about the product.
• Leaders care about the destination instead of the journey.
• Leaders see technology as a part of commerce not as something with a value all its own.

When I saw this bit of wisdom, it changed me.  To me, the technology worker, I was judged if my code worked in production and was reliable.  My boss was judged on how they can influence others to write that reliable code.  I have known countless developers with autism spectrum disabilities or poor attitudes but they were always retained in the company because their code worked.  These people received more perks and authority because they keep the business running.  A boss is very much like a teen-ager in the high school cafeteria. They have to make friends with the right people at the right time in order to further their careers.  So being likable is a necessary survival skill.

Developers are process focused and see the creative process of writing code as rewarding.  Leaders do not.  They want to see working code in production and software products which solve particular business problems.  They are also under time and budget pressure so they are constantly asking about status updates.  Finally, technology people love technology for its own sake.  Most business leaders see technology as a tool to be used.  This is why when showing off a piece of software developers are more deferential to their peers than a business owner who would not hesitate to call something a “piece of junk.”

These are the things which make your boss different from you.  The time, money and social pressures of leadership at a major business changes people and their perspectives.  You will be a better developer and agilest if you understand these differences.  This way you can help your boss become more successful and in turn you can earn some success along the way.

Until next time.