Little Victories

A win is a win.

In the daily grind of business, you take your wins where you can get them.  This week I want to talk about one of those wins and a lesson learned in the trenches as scrum master.

Each quarter my product owner gives a presentation to the executive committee about how the business is doing and how the software development team fits into that vision.  It is dry affair filled with power point presentations and back slapping.  As I was gathering up metrics for the presentation, I noticed something peculiar.  The number or software support tickets had declined over the last fifteen months from an average of 40 tickets a month to 20.  The development team had cut the number of bugs that were in production by half in the span of a year.

I am pretty impressed with this accomplishment but it also taught me some valuable lessons.  First, change and improvement does not happen overnight.  It took numerous refactoring tasks, late nights, and admonitions to do things the right way in order to reduce the number of defects in the applications I was responsible.  Next, change requires everyone to change.  In this case, the developers, the business team, and I had to learn how to work in an agile process together.  It was not easy and everyone had to sacrifice a little of themselves to make it happen.  Finally, measuring results in a concrete fashion puts in perspective what you think might be happening.  I knew that we weren’t having as many support tickets but thanks to the metrics from the ticket system, I could quantify my hunch.

This means what has felt like a long slog for my development team and I is really the continuous improvement that business leaders always talk about.  It is not glamorous but over 15 months we have cut defects in half and are improving the products for the business.  I need to learn to be more patient with myself and others.  Small things do make a difference like asking that bugs get written up in the backlog and always asking why we do things the way we do.  It can feel like repetitive work and be very frustrating but if you keep at it there is a payoff.

Like many scrum masters and business leaders, I suffer from what is called “Impostor syndrome” that feeling that I am not good enough to do what I am doing.  What I have discovered is that I should learn to ignore that voice.  I am not an impostor.  I am a scrum master and servant leader to my team.

Finally, I realize that this improvement did not happen in a vacuum.  It took the efforts of my software development team and the hard work they put into the project.  They were the ones who wrote the code.  They were the ones who worked weekends and late nights.  They were the ones who saw me saying, “There has to be a better way,” and they found that better way.  They are the reason we had this happen.

It is not perfect by any means.  There is still a great deal of work to do but I do not feel like I am swimming against the stream as much as I did.  It is a little victory on the way to bigger victories and I will take it.

Until next time.

The Passion of Microsoft

This was the moment Microsoft learned to change.

Technology is a weird thing.  It creates heated passions and religious devotion.  I am not immune to these passions.  This week I wanted to talk about Microsoft and what I see from the outside is it is becoming a more agile company.

When I first became a technology professional, in 1998.  Microsoft was divisively referred to as the “Evil Empire.”  Internet explorer has won the browser wars, Visual Basic 6 was about to debut, and my company was scooping up copies of Windows 98 like no tomorrow.  It was before the dot com crash and it was a great time to get into developing software.  It was also the start of Linux movement and a general sense of discontent in the developer community.

This discontent came from projects in the enterprise sector getting more bloated and companies like Microsoft not being responsive to developers who wanted to improve their skills.  I think the final straw came with the release of the Apple iPod device.  This music player took the technology world by storm and it made Apple and substantial amount of money.  When Microsoft decided to release its Zune music player an entire two years later, it was too little too late.  I loved my device but it never had the wide appeal of the iPod.

By 2012, the Zune was discontinued and Microsoft was going through numerous changes.  They were now losing the browser wars to Google Chrome.  The Android operating system threatened to shut Microsoft out of the mobile phone market.  Finally, as PC sales slumped people were openly asking if Microsoft would survive.  Notes of the company’s death have been greatly exaggerated.

In a little over three years, with a new CEO and its focus on agile practices the company looks like it is turning around.  The focus from sales and marketing to engineering is refreshing to me.  I am looking forward to the release of Windows 10 and hope that the company continues its efforts to build more loyalty to the people who help build their brand.  As someone who has been building with Microsoft for over fifteen years, I have no illusions about the company’s shortcomings but it is nice to see an organization fix itself.

I am starting to feel more passion for Microsoft and I am not afraid to say so.

Until next time.

Obstacles to Agile

Courtesy of the Harvard business review.
Being a change agent is hard even for a King.

The life of an agile profession both in the corporate world and as an entrepreneur is filled with uncertainty.  Big wins are offset by frustrating losses.  Efforts to keep an even keel are quickly undermined by others and setting aside some time for lunch seems like a herculean effort.  This week I want to postulate a few things I have encountered that make the success of an agile implementation doubtful.

 Cultural Inertia-

If you run into employees or members of management who say, “We have always done it this way,” you are facing cultural inertia.  Human beings need ritual and consistency to make them feel like they belong.  Rituals also produce a sense of certainty in an uncertain world.  When an organization or individuals are afraid to change they are really asking for certainty in an uncertain world.  This is why bad processes and procedures linger.  People are invested in these bad processes and rewarded for perpetuating them.  Thus, as most agile leaders try to instigate change they are going to receive push back.

 Quid Pro Quo behavior-

This term is used in sexual harassment training but is also go for anyone attempting change management.  This is a Latin phrase which means, “tit for tat.”  Another way of explaining it is, “You scratch my back and I will scratch yours”.  A business operates through the countless interplay of people and often they do favors and collect favors from others in order to do their job.  For instance, accounts payable depends on the format of a report being a certain way and in excel.  As a favor a manager makes this happen so when they have to do an expense or provide a bonus to a valued customer, accounts payable with go along without any conflict.

This is maddening behavior for technology professionals and ageists because the obvious answer to the situation would be to automate the report with a script or some reporting software.  This solution may save time and money from the firm but it takes away influence from the manager who is doing the favor for accounts payable.  Thus, they will do what they can in a passive aggressive means to undermine the effort.  For the agilest it makes sense to understand how these little power games are played in the organization.

 People getting by on Charm-

This week, I had a conflict with an employee with seven years more tenure in my organization.  I held him accountable for poor performance and undermining a project.  I later learned that he has some protected status in the organization because of a favor he did for a vice-president five years previously.  Since then, he has been using his charm and charisma to instigate projects.  He never finishes those projects but he is always first in line for the next highly visible project which he can scapegoat on to someone else.

I did what I could and pointed out the facts which explained why a project is twelve weeks behind.  I will not be working with this person in four weeks as I am transferred to another team and group of developers.  He is now someone else’s problem and I hope that his continued negligence is pointed out.  Being charming is no substitute for knowing how to do your job or getting results but it amazes me how many people survive in business because of it.

Be on the watch for these three things in your organization because knowing about them is going to make it easier to create positive change.

Until next time.

Disappointment is not the same as defeat

Learning a few lessons during the Easter week.

The life of the agilest is filled with manic depressive episodes.  This week what was supposed to be a client meeting and a possible business opportunity fell apart because a technical constraint I had not accounted.  It was a very bitter moment and it undermined over a year’s worth of development.  I was furious.  After settling down, I took some time to reflect.

One of the sayings of agile is, “fail early and often.”  This is easy to say when your business has regular customers and has steady billing.  It is not so easy when you have been working hand to mouth for five years writing code in your spare time and pitching clients when you get the chance.  Each pitch, opportunity feels like the last one that comes along.  So to call up a client and tell them that a product is not ready, is heartbreaking.

Failure hurts.  Failure is a deep blot of ink which covers up your reason and makes you feel defeated.  I have always been a sore looser so to fail always grates on me.  It made it hard for me to sleep and affected my mood.  I am still not over this failure this week.

I feel like a kid who was winning at Snakes and Ladders only to be denied in the last roll of the dice.  As the initial disappointment started to fade, I came to a realization.  I am not back to square one but rather few steps back.  I can choose to quit the game or I can pick up the dice and go again.  That is what I am doing.  The next few days are going to be learning new coding techniques and trying to build my product to accommodate the clients very particular technical specifications.

I am disappointed but I am not going to be defeated.  I think that is not a bad lesson to take into the Easter Weekend.

Until next time.