Looking Ahead to 2022

Happy New Year!

It is the end of the year, and everyone will be in full Christmas mode when this blog is published.  Each year, I blunder around attempting to make predictions of what will happen in the world of technology and agile.  Last year, I skipped that exercise because I was moving into my new home.  I am comfortably settled in, so it is time to look at future trends. 

Nothing is going to be easy. –

The year is a textbook example of the insecure nature of the modern global economy.  I was fired from my position as a director of delivery and then went into the world of consulting.  The social contract where you are loyal to an organization and, in exchange, they are dedicated to you is gone.  Now each person must build a brand and skills to convince employers to hire you to generate value for them.  It is exhausting and aggravating because it forces you to prioritize your career for survival reasons instead of family and community.  It also grinds down the self-worth of everyone because security and status depend on maintaining valuable skills for the employment market. 

Career, family, and community are never easy, but it will become increasingly difficult to balance these forces with this present situation.  It is no wonder birth rates are declining in the United States.  

Ending Humiliation at the Office. –

The year 2021 features an open insurrection against a freely elected president and the prolonged effects of the COVID-19 pandemic.  Both of these stories are important, but in my mind, the big story is the “Great Resignation.”  The job market is hot, and the upheaval of the last two years has made people reconsider priorities.  I also suspect that many professionals working from home realize how awful and humiliating it is to work in an office.  Petty leadership, microaggressions, and lack of advancement are finally coming to a head, and it is natural for people to tell organizations to stuff it.  I joined the agile reformation because I knew that this situation would not be sustainable.  If your organization wants to survive, it pays to help people find dignity, flexibility, and opportunity at work.  Give me a call, and I might be able to help you with that process. 

Money What is that? –

All of our ideas about money are changing.  Bitcoin has been around since 2008, and now we have other types of cryptocurrency floating around the internet, including DogeCoin.  I believe that most cryptocurrency is a high-tech version of blue-sky stocks from the 1920s.  However, we can not ignore that blockchain technology will change how we treat things like money.  Banks are getting involved in cryptocurrency, and governments are taking regulation of it more seriously.  I think these are all good things. 

Non-Fungible Tokens or NTFS are becoming interesting because they look like they are a new way of paying for digital content.  I am not convinced, but NTFS might help move the internet away from an advertising model of content and toward something more sustainable.  I will try to experiment with this in the new year.  Who knows, I might make some money in the process.  What is clear is that attention and time spent with content will be more critical than ever.  

Death to Disinformation! –

Being online can get dispiriting with trolls, bullies, and self-aggrandizing grifters dominating discourse.  Misinformation pedaled by bad actors is poisoning the promise which surrounds the rise of the world wide web.  With the rise of virtual reality and augmented reality in the tech sphere, I will volunteer and help create defenses against misinformation in these new internet territories.  Expect to see me in the Sensorium virtual world attempting to make sense of it and act as a sage, helping prevent the spread of misinformation.  I hope I will be welcome.

So those are my predictions.  I want to wish everyone a happy new year and look forward to seeing everyone on the other side. 

Until next time. 

Call out Trolls Before They Destroy Your Business

Spot trolls before they hurt your business

The biggest challenge in Servant leadership is working with the disinterested, dishonest, and disrespectful.  Each organization harbors these individuals like weeds in a field of grass.  People like this seem to revel in their bad faith efforts to undermine others, avoid work, and act as parasites to everyone around them.  Throughout my career, I have confronted these individuals, and it never gets easier.  We should be brave enough to call out poor behavior.  

I spend plenty of time on LinkedIn. It is an excellent service because I can catch up on colleagues, get the latest news from the business community, and many of my fellow travelers share information about what is new. I was surfing along and read the following post from a coach and scrum trainer. The emphasis is mine.  

“I am a project manager having 15 years of experience and 5 years exclusively in project management. I do hold a PMP certificate too. My company is adopting Scrum-based delivery and it seems there is no role for the project managers. There are 3 roles in Scrum but none of them is for me. 

I can’t be a Product Owner because it will get filled from the business/customer side. I am not hands-on so I can’t be a part of the Development Team.

Scrum Master seems to be a very junior role for me. Many Scrum Masters are just a part-timer or working previously as Team Lead/ Tech Lead etc. There was a point when these people were reporting to me on my projects.

I also have an issue with the Servant Leadership style. It is not that I am a command & control person and you can ask my colleagues. Everyone will say how good I am with empathy, situation leadership, and self-reflection. But servant leadership sounds to me either head of the Servant or becoming Gandhi and Mandela. 

What will you suggest? Should I look at some different roles if yes then which one? I have also heard a lot about Agile Coach though I don’t know much how is this different than Scrum Master.”

I had a lot to unpack in this message.  It is an excellent example of how NOT to do Servant leadership.  I have said in the past, that ego is the enemy of good leadership.  Additionally, Servant leadership is more about leading by example than attempting to behave like a saint.  Scrum mastery requires kindness, and it often requires going beyond the call of duty. 

Being a scrum master is not a junior role.  It is a managerial role with tremendous responsibility and little authority. You are the person in the Taupe blazer who must inspire others to get work done.  At times you are a therapist, and at others, you are doing code reviews.  Often you are a square peg in a round hole.  Scrum masters are not junior; instead, they are essential to the success of your organization. 

The arrogance associated with the post was very telling.  What made it shocking was that it came from an instructor from Scrum.org.  I could expose this individual, but that would make me no better a coach or scrum master.  I am sensitive to harassment and doxing concerns on the internet.  I want the satisfaction of calling out a troll and exposing them to shame and ridicule.  The reality is they do not care.  A troll does what they do for the attention and outrage.  Instead, I would rather point out the attitude of these people so that we can be on the lookout for this behavior.  People like this are going to hurt your organization, so it is best to make you aware of them and not give them a chance.  

I take a great deal of pride in what I do.  As I continue to advance my career, I do not want to forget where I came from and the lessons I gained along the way.  Being a scrum master and product owner is hard work.  Developers and people in the organization are under tremendous pressure to deliver value to their customers and organization.  In the global economy, we are all servants, whether we like it or not.  Insulting other professionals as junior or beneath you is not how you participate in the agile reformation.  It is a form of elitism that has sparked backlash around the developed world.  

Today, I wanted to call attention to an attitude that will hurt your organization.  It is elitist, and it comes from a position of arrogance.  Do yourself a favor, find these people, and make sure you never hire them.  

Until next time. 

Three types of failure in an organization.

When it all goes wrong

I have been spending plenty of time looking at best practices and patterns in software development.  The more I learn, the more I discover knowledge in the field is growing logarithmically.   Thanks to the web, developers and scrum masters can share hard-won wisdom.  Sharing this knowledge makes everyone better at what they do.  We can also gain understanding taking a look at bad practices and seeing how they hurt an organization. 

A maxim in the agile reformation is everyone should be allowed to fail early and often.  Failure is an early building block for future success and innovation.  I see failure as an excellent teaching instrument.  It means an agile practitioner should take a fair and empathetic view of failure and see what we can discover.  Agile practitioners need to call out what works and what does not.  Reviewing bad practices and business failure educates in ways success cannot.

The Cargo Cult

A cargo cult comes into being when individuals create totems and rituals to mimic success without understanding how to achieve that success.  I have blogged about this topic, and it came from South Pacific tribe who built faux airports and vending machines in the hope cargo planes, and Coca-Cola would return.  I see it with businesses who begin a digital transformation but do not want to change their command and control structure.  The open office movement is another excellent example where business leaders hope to improve collaboration and instead ruin employee morale.  The lesson is to discover the “why” and “how” something works before implementing anything in your organization.

Cultural Inertia

If you work at an organization where people introduce themselves by how many years they work for the organization instead of what they do for the firm you are dealing with cultural inertia.  The term inertia comes from the field of physics. An object can remain still or in motion as long as outside forces do not act on that object.  Complex business organizations exhibit this trait.  These organizations get accustomed to doing things a particular way.  These organizations hire and promote specific people.  Thus, when confronted with change they treat is like heresy or deviance.  Managers or executives kill ground-up initiatives.  Digital transformations fail because line employees have no buy-in.  As a coach or scrum master, inertia is going to be your biggest obstacle.

Software Samurai

Software development is a human activity which resists automation.  So far, no Artificial Intelligence can write C# code or take vague business requirements and turn them into working software.  Human beings are messy, complicated creatures.  Smart and talented people are messier than standard employees. Making matters worse is the glorification of the “Hacker,” or “Brogrammer” culture of software development.  It is a worldview which is misanthropic and sexist.  The glorification of a software developer as a disruptor, visionary, alpha-male, shaman and deity has a few consequences.  It creates a toxic stew of smart people who are smug and contemptuous of business partners.  It also makes developers behave like lonely samurai willing to show off their skills only to other developers in battles for supremacy.  By following “the way of the samurai,” these developers ship poor quality code which does not meet business needs and impossible to maintain.  When called out for this conduct a samurai will say, “If they were good enough a developer they could maintain that code.”  Samurai coders are why agile fails at the team level, and it is up to a coach and scrum master to help these individuals reform their ways.

So here are three ways agile can fail in an organization; cargo cults, cultural inertia, and software samurai.  Each of these situations spells doom for your agile maturity.  Be on the lookout for these examples of failure. 

Until next time.

Being a Jerk Does Not Make You a Better Programmer

Can you believe this A@@ Hole.
Image courtesy of Slate.com

It has been quite a week in the technology world.  The big news this week was the firing of Business Insider’s chief technical officer Pax Dickinson for a series of insensitive and sexist tweets.  As someone who has been fired, I really do not like to gloat at the misfortune of others.  I am going to make an exception for Mr. Dickinson.  This week on the blog I explain why people like Mr. Dickinson are a poison to the profession of software development and technology start-ups.

When I first joined this profession, it was male dominated.  Guys wrote code.  It was just the nature of the profession.  Diversity was usually based on experience and ethnic background as programmers from India, Asia, and the United States blended together to form development teams.  I remember quite vividly when the attacks on the world trade center took place that the developers at my firm closed ranks around the lone Muslim member of our development team because we did not want our co-workers hassling him.  People who code together tend to stick together.

As the years wore by it became obvious to me that we needed more women in the profession.  Homosexual slurs were used to describe code that wasn't acceptable.  Developers who couldn't take a joke were called “p#%&ys” and women who worked with us affectionately referred to the development work area as the “pig pen” for all the misogynistic behavior exhibited by the developers.  It was 2009 and I had finally realized that programming had far too much alpha male ignorance associated with it.

Around this time, I discovered the Chicago area application life-cycle management group.  It was led by a woman smart as a whip and tough enough not to take any grief in the profession.  It was also here that I met many women who were managing projects and in the trenches writing code.  To me it was a revelation, women not only could write software but they could teach and provide proper instruction to their fellow developers.  It was a breath of fresh air and it was at that point I realized that if I ever started my own company I wanted to encourage the participation of women in the world of technology.

Pax Dickinson fits into this discussion because he comes from the “brogrammer” school of development.  These individuals are nurtured in the world of game development and the start-up community.  They are defined by their arrogance, intelligence and total lack of an internal filter.  They are not afraid to call an algebra teacher stupid if they know the answer before teacher shows the work on the black board.  They take pride being the smartest person in the room and will make sure everyone knows they are the smartest person in the room.  As it was explained to me once, “a good programmer is smart and he is arrogant enough to make sure everyone knows it.”

Really Mr. Dickinson fits the definition of an asshole as outlined by Robert I. Sutton PhD in his book “The No Asshole Rule” which are people,  “…who consistently aim their venom at less powerful people and rarely, if ever, at more powerful people.”  Dickinson has made a career of making people who are not him feel like dirt.  Women who he thinks can’t code are beneath him.  Developers who don’t understand his mode of operation are worthless.  Heaven forbid you question his business practices or products because that will make you a target as well.

As Mr. Dickinson gained wealth and fame in the world of technology, it merely made a bad problem worse.  Business Insider should have known better than to hire this guy but when they did they gave him the ultimate license to be an asshole to his fellow man.  It is not surprise that he got himself in trouble and soiled the reputation of the organization which fired him.

I suppose that this is an object lesion then in the world of technology.  Sooner or later an asshole is going to get what is coming to him.  They can hide but sooner or later they are exposed as the cretins they are and they are cast aside because people do not want to do business with them.  I have always striven not to be an asshole in the technology world.  It is why I founded my company and why I am looking forward to hiring developers who are going to make a difference in my organization.  I don’t care about gender, ethnic origin or religion.  I just want to make sure they know C# and can code responsive layouts.

So while Mr. Dickinson is packing his desk and protesting his punishment, I am going to get on with the business of running my start-up and helping small and medium businesses work in the cloud.

Until next time.

Why I Use TFS 2010

Team Foundation Server 2010 is not a muscle car.

Developers are a temperamental and combative in nature.  Many business people justifiably treat us like the troll under the bridge due to our gruff and matter-of-fact way of addressing controversy.  Some of us even look and smell as bad as these mythical creatures.  Nothing inspires more troll like behavior than developers debating which technology or tools are superior.  Another chapter in this ongoing discussion came from Derek Hammer and his blog “TFS is destroying your Development Capacity.”  This article is well footnoted, inflammatory, and filled with plenty of reasons not to use Microsoft’s Team Foundation Server 2010 or TFS for short.  I want to take time to answer some of his criticisms and explain why I am sticking with TFS for my business. 

Hammer’s criticisms are fairly clear:

1)      TFS version control is frustrating to use.
2)      Bug Tracking is hard to use.
3)      TFS is not flexibile enough for Agile project management.
4)      The build system is clunky.
5)      Finally, the vertical integration of the product makes it impossible to use best practice tools.

Let us start from the beginning, if you grew up in the business with Visual Source Safe and Visual Source Safe 2005, you will understand that TFS is a quantum leap forward.  Code can be exclusively checked out to one developer or several developers can work on the same code and merge it together.  Also the ability to branch and merge code is clean and easy to understand.  This makes it possible to have code in development, staging and production environments existing in source control.  This is a huge help if a problem crops up in production and it cannot be reproduced in the other environments.  The label and history functions make things easy to track and using project settings forces developers to comment check-ins and associate check-ins with work items. 

Hammer does have some legitimate gripes.  TFS forces you to be connected to the server via your “workspace.”  This is a bit of a pain for people who think source controls consists of copying and pasting folders.  Fortunately, this criticism will soon be moot because the next version of TFS will allow you to work locally and then connect to the server to synch changes.  He also talks about a simple four window three-way merge.  Personally, I have not seen this and I did not even know it was a standard.  I would like to see an example of this.  Please leave a link in the comments. 

Next, Hammer dislikes the bug tracking system.  This was what sold me on TFS.  Work items, bugs and tasks can be entered via Visual Studio or the web site which is built into the system.  The web interface in no more difficult than SharePoint and customer service reps can easily be trained on how to fill out the information.  Finally, TFS has its own API so if you are not happy with the interface you can write your own web form or MVC application to place bugs into the system. 

Moving on to Hammer’s third criticism, TFS is not suited to Agile management.  My biggest challenge as a developer and consultant has always been having the client adopt any kind of Project Management Operations.    This is particularly true in the organization that thinks project management consists of leaning over a cubical wall and asking a developer to build a website.  Thus, TFS is a fantastic introduction to agile and its principles.  I still use a white board for the project team however; TFS helps creating excel reports for management a breeze.  Also, I create custom reports all the time to view specialized data.  When I was at a client, I act as scrum master entering data into the system and leading the project.  I also spend a lot of time training others on how to use TFS to get the most out of the system.  For a mature Agile teams, TFS may seem like an impediment but for companies just getting started, it is the perfect set of training wheels.

Next, Hammer talks about how the build engine is clunky.  Without any reservations, I can agree with his criticism.  In my nearly two years working with TFS, the build system has frustrated me the most.  Often, I simply rely on Microsoft Visual Studio’s publish tool, web.config transformations and FileZila to get work done.  Fortunately, I see this changing.  The Chicago ALM group had a great meeting on Sept 14^th 2011 illustrating how to customize the build process and I look forward to more people coming forward and sharing their knowledge of the subject.  Until then, I am sticking with FileZila. 

Finally, Hammer criticizes the vertical integration of the product and how it is endemic of “The Microsoft Way.”  It has been my sad experience that most people who make decisions about technology are not technologists themselves.  Thus, they are not thinking about best practices or better ways of doing things.  To this kind of individual vertical integration is a perk and not a defect.  With TFS, they see and all in one package that is easy to install and does what is required of it.  This leaves it up to the technologists to us the tool they have been given as best they can.  If that means we write web apps for the customer service people to put bugs into the TFS system and we run reports each week and send them out as excel, so be it.

Let us compare software to automobiles for a moment, Hammer sees TFS as a clunky minivan which gets people from point “A” to point “B” with little speed or flash.  What he wants is a sport car where he can open the hood and swap out engine parts for better performance.  Talk to any Mom and they will tell you when push comes to shove they will settle for the minivan.  This is why most businesses are moving to TFS as well.   It may not be sexy and flashy but it gets the job done in a way technical and non-technical people understand; this why I am sticking with TFS.  I understand the tool.  I know that I can train other developers how to us it.  Finally, it makes sense to business people who usually pay the bills. 

As someone who used to be a troll under a bridge, I understand Hammer’s perspective.  Now as I begin my own company and transition to working with C-Level executives, I see that there is more to a technology decision that just the technology itself.