Through the looking glass regarding agile and the unwriten rules of work.

Being a business person, I was stunned by the sheer amount of non-business stuff that filled my days. An executive often forced me to watch their pre-teen child while they negotiated a deal over beers at the baseball game. A vice president ordered me to be silent because the CIO did not want other departments to know about our delivery problems. My illusion as a college student was that business people would be grown-ups who valued execution and results. As Lewis Carrol said in The Adventures of Alice in Wonderland, "… between the idea and the reality lies the shadow." As a coach and scrum master, you must navigate this shadow realm. Otherwise, you will be lost, like Alice in Wonderland.
My experience as a business person is simple to describe. I have been a square peg in a round hole my entire career. I was a great retail salesperson, but it made me behave like a compulsive gambler and burned me out within a year. As someone who struggles with moral ambiguity, I had to look the other way as a boss was conducting an indiscreet affair with someone other than their wife. Finally, I did not understand what Anna Kallschmidt calls the unwritten rules of work.
Dr. Kallschmidt points out that corporate work relies on friendships and what she calls contextual skills. Not only must you do the job, but you must also act out the part according to the cultural expectations of the business. So, a salesperson must be able to sell to customers and be the life of the party at company functions. IT people must accept unrealistic deadlines and workloads because they are highly paid and better be worth the money. The list goes on, but it reminds me of Peter Drucker's statement that culture eats strategy for breakfast. The unwritten workplace rules are the principal pieces of culture; if you are unaccustomed, you risk failure and unemployment.
Agile encourages empiricism, transparency, and pragmatism, but you will fail if that conflicts with the business's unwritten rules. For instance, I demonstrated Azure DevOps to integrate continuously and perform deployments. I was greeted with appreciative feedback from everyone until the director of network engineering chimed in, stating that it was nice, but could the system be configured exactly like the current legacy system? I assured him it was better because you knew which software version was deployed to each environment. The manager then said that he did not want continuous integration on weekends. I said it was possible if he instructed his staff not to do deployments on the weekend. Howls of disapproval greeted me. Engineers, let alone software developers, were not permitted to do production deployments, and only the manager or director could allow a deployment. My DevOps solution gave the engineers and developers too much power and responsibility. I might have eaten a grub in the conference room because I suggested that development teams and engineers knew when to deploy better than managers and directors, which was considered disgusting by anyone at the director level or higher. The DevOps initiative went nowhere.
I was transparent and pragmatic, wanting to delegate decision-making to the people doing the work. However, the leadership saw me as a heretic attempting to destroy the precious control systems they had built up over decades. Despite working at the company for five years, I still did not understand the directors' demands for control.
So take time to learn the unwritten rules of your office; otherwise, your career will wind up like the many people who displeased the Queen of Hearts in Alice in Wonderland.
Until next time.
Comments ()