Monday, August 15, 2022

Empathy is Superior to Self-Confidence.

Some of the biggest mistakes a person can make are those made with absolute enthusiasm is confidence.  Blissfully they indulge in activities that they are going to regret significantly.  In my experience, alcohol is involved, but the more toxic substance is ego.  Nothing is more dangerous than a leader with a messianic vision and the self-esteem to match.  These people lack self-doubt and emotional intelligence and are responsible for destroying millions of dollars in wealth and countless organizations.  This week, I want to have a necessary discussion about humility.  

The web is crawling with numerous research papers talking about the Dunning-Krugar effect and how we promote incompetent people into positions of authority.  Unfortunately, I have witnessed this dysfunction firsthand, which undermines your confidence in the business community.  The leader promoted on looks and charm becomes a high-priced disappointment as a rule rather than the exception.  Treating confidence as a force multiplier often eclipses competence, empathy, and experience.  The harsh truth is the best leaders need the above mixture of skills to be successful. 

A leader who listens with emotional intelligence and empathy is superior to those who only exude self-confidence.  In the face of challenges, these two tribes of leaders differ significantly.  A charismatic leader will see an obstacle as something which must be trampled or bludgeoned into submission.  This approach works in the short term but often creates more problems down the road.  A leader with emotional intelligence sees an obstacle as a means to pivot and change directions.  The ability to adapt and shift focus when necessary makes these leaders superior. 

Edward Deming said survival in business is not mandatory.  The world of commerce requires us to be adaptable to change.  Thus, being flexible is a powerful business trait.  Another reason the emotionally intelligent leader is superior to charismatic leaders is the ability to change.  When confronted with a compromise or trade-off, a charismatic leader will become stuck, while emotionally intelligent leaders will focus on a pragmatic way to accomplish work.  

The business world is a chaotic place.  It feels like you are traveling in a run-a-way train, and no one can ensure it does not fly off the tracks.  We have plenty of passengers on the train and people willing to shovel coal into the boilers, but a steady driver is hard to find.  The person who asks, “who is driving this train?” is often conscripted to take charge and attempt to bring order to the chaos.  It takes an extraordinary leader to take control of a run-a-way train.  These reluctant leaders approach their jobs with humility and pragmatism because they know mistakes could cause the metaphorical locomotive to plunge into a bottomless cliff.  

The ability to listen to others, exhibit emotional intelligence, and put themselves in the shoes of others is a necessary skill to be a successful leader in a complicated world.  It is not the traditional form of leadership but one we need today.  

Until next time. 

Monday, August 1, 2022

Don't Make SAFe Tool of Mass Destruction

The last week was a whirlwind.  I muscled my way through Sprint planning with my development team.  Then, I studied for and passed my Lean Portfolio Management test from the SAFe organization.  Finally, I found myself reading David Foster Wallace and spending time with my family in the Wisconsin Dells.  Yes, it was exhausting, but it was worth every moment.  Since I have earned credentials from SAFe, I feel compelled to say a few words which will contribute to the debate about scaling agile at large organizations.   

It is no secret that the agile community has some deep schisms.  The no-estimates and the estimates cohorts are bitterly divided.  The debate has become so toxic that people who used to be colleagues no longer speak to each other.  People have closed Twitter accounts, and attacks between the two factions are personal and filled with abuse.  It is a shame because most of us involved in the debate want to deliver better software. 

The other major fault lines in the agile reformation are those who practice the Scaled Agile Framework for the Enterprise, or SAFe for short, and those who use a different approach to apply agile to large organizations.  The debate between these factions is just as toxic as the no-estimates debate.  I understand why so many people are hostile to SAFe.  First, SAFe lacks credibility in the engineering community, with software engineers in a survey saying they are dissatisfied with SAFe.  Next, credibility with the Agile community is low because none of the original signatories to the Agile Manifesto have endorsed SAFe as a way to address agile for large organizations.  Finally, the popularity of SAFe in large organizations creates a counter-cultural backlash.  

These three factors combine to create a powerful feeling of contempt and resentment in the agile community.  It is rare to hear SAFe people speak at either the Scrum Alliance Gathering or the Agile Alliance conferences.  Instead, they have their conference separate from other organizations.  It is a clear division that is reinforced by money and pride. 

I have embraced Agile since 2009.  I earned credentials in Scrum in 2013 and SAFe in 2017 before letting them expire.  I know enough about agile to realize it is not a magic bullet to cure the dysfunctions at large corporations.  As Aristotle said, there is a difference between right and wrong, and people will choose the right path if they know the difference and are educated about it.  Over twenty-five years of working in the business world have provided me with numerous counter-examples to Aristotle's thesis.   People can be callow, selfish, uninspired, and destructive; a toxic culture will defeat even the best agile implementation. 

I feel a similar way about SAFe.  In the hands of a newly minted SPC who only worked as a project manager, SAFe is a tool for mass destruction.  However, with skilled scrum masters, trained and knowledgeable product owners, and an executive team willing to learn new ways of leadership, SAFe is a tool that can improve a business's ability to deliver value to customers. 

Agile is growing.  The growth means that there will be debates and disagreements about how to help organizations do it properly.  I am not arrogant enough to proclaim one authentic way to help organizations achieve agility.  I am sufficient enough as a servant leader to understand that at the end of the day, success is not following a set of rules but rather delivering value to customers and helping the people we work with improve.  Anything else feels like a toxic debate.  

Until next time. 

Monday, July 25, 2022

Coming back from Vacation.

For the last two weeks, I have traveled and attempted to get caught up at the office.  Vacations are fraught periods for professionals.  The business world continues to churn as we try to disconnect from the office.  It has a nugget of anxiety built into the experience because, if things run smoothly, you look unnecessary to the organization.  If work goes sideways, you have not organized your teams correctly—either potential is a way to undermine your enjoyment of your time away from the office.  I had the good fortune to spend time with my life partner touring the natural sights of Kentucky and Tenessee.  Taking time away from the office makes you reconsider a few things.  

Spending time in caverns, caves, and rivers enjoying nature allows you to appreciate how trivial the conflicts at the office are.  It takes hundreds of thousands of years for water to create a cave.  Caverns require the labor of countless humans to excavate.  Caverns and caves become a strange combination of darkness, cold, and dampness, which with the help of water and limestone, create fantastic structures which look like abstract art.  The experience is humbling, and everyone should enjoy a little humility courtesy of nature. 

It takes a long time for nature to construct its wonders.  Thanks to gravity, time, and water, a fifty-foot waterfall was carved into the middle of the Tennessee wilderness, and I was fortunate enough to witness it.  It brought to mind the work of Lewis Walter on the “Then and Now” YouTube channel.  He has discovered how to make philosophy interesting for the internet age, and his documentary on Spinoza should be required viewing for any college kid learning about philosophy.  Spinoza is so interesting because he talks about looking at the world from a global view of nature.  We have only fleeting moments in this world, and we must appreciate our lives as we live them.  Taking some time off has a way of discovering that appreciation.

I am sure regular readers are wondering why I am talking about an experience so transient as insight gained while on vacation.  The answer is simple.  If we are ever going to do our best in the office and create organizational change, we need to spend time away to recharge, enjoy nature, and gather some philosophical insight.  Read a book that is not work-related.  Rent a kayak and go a few miles down river.  Do something anything because the reality is that work will always be there, but we will not, and we should draw some measure of enjoyment from our lives.  Not everything needs to be toil and struggle.  

I am a dedicated supporter of the agile reformation.  I will continue to dedicate my life to making the workplace better.  However, I must accept that I have a family who loves me and needs me to be present in their lives.  It is a tricky balancing act but one I am willing to try.  It is good to be back, and I look forward to more blogs about the agile reformation.  

Until next time.  

Monday, July 4, 2022

The Slow Road to Agile

Organization change resembles the story of Sisyphus.  As punishment for cheating the god of the underworld Hades, Sisyphus was doomed to spend eternity rolling a heavy boulder up a hill.  It would move back to the bottom when he brought it to the top.  The futility of the effort was the punishment the ancient gods inflicted upon Sisyphus.  Each day, as an agile professional, you struggle with similar challenges.  The stone gets further up the hill, and an executive or vendor will knock it down for spiteful or selfish reasons.  It is frustrating.  Today, I want to discuss why the struggle is worth the effort. 

It is easy to get discouraged when leading organizational change.  It is easy leading a crowd of people who are enthusiastic and committed.  The hard work comes when you have to motivate others to set aside their selfish needs for the greater good of others.  Cultural inertia will always be an obstacle to progress.  Still, the biggest challenge is the profound feeling of loneliness that comes with putting yourself in front of others who are doubtful of your mission. 

Agile began when a group of hard-working and committed people got together to point out that traditional approaches to work were not working.  These people created the Agile Manifesto and principles.  Since then, the agile reformation has become inclusive of each nationality on the planet.  Women are some of the most respected proponents of the approaches agile uses.  Finally, agile has earned the respect of executives and business people because it delivers more value to customers.  It is a slow road of progress. 

The industrial revolution and modern corporations have only existed for two hundred years.  The agile reformation has only lived for twenty, and businesses have come around to the values and principles of agile.  My work and countless others are starting to make a difference.  It feels good to be part of a social movement like that.  

As an agile coach or scrum master, it is essential to look at the progress made over the last twenty years.  Businesses are beginning to understand the old ways of operation are hurting profitability and customer satisfaction.  This realization points them toward people like myself to help show them a better way.  I can't think of a better calling for one's career and life.  The struggle is worth the effort.  

Thanks for following the blog.  I look forward to more writing when I return.  We will be taking time off next week for a vacation with the family.  

Until next time and have a happy Independence Day.  

Monday, June 27, 2022

Why I Don't Use a Definition of Done Anymore

Each business and client is different.  When you join them to help with their business agility, they will have unique pathologies and dysfunctions which interfere with their ability to help their customers.  As a scrum master and agile coach, it is up to you to guide these clients through their journey toward satisfying, sustainable, and sane business outcomes.  This week I want to take some time to discuss how I approach the completion of work in an agile enterprise.  

When agile and scrum were in their infancy, one of the early concepts was called the "definition of done." Often developers and business people say work is complete when it wasn't.  It would lead to conversations like the following: 

Project Manager: Is the defect for the surfer account fixed?

Developer #1: It works on my machine and database, so it is done, but I still have to check it in and deploy it. 

PM: So it is not done.

D1: Well, it is done, but it is not done, done. 

Conversations like the above have caused me no shortage of gray hair and triggered numerous binges on pizza.  So when agile and scrum created the concept of the definition of done, I was an eager convert.  A developer had a checklist to follow.  It was a significant improvement. 

Over time I noticed that the definition of done was necessary for quality development, but it was not sufficient for quality work.  Something was missing: a sense of ownership and craft in work.  For instance, some errors were changes not made to configuration files.  A definition of done does not cover that when it is not in the same environment.  A checklist does not apply in that case.  My experiences showed me the rules do not always apply.  Agile people use the Japanese phrase Shu Ha Ri to describe this.  

At a training session, I heard the phrase from the medical field used to describe how developers should approach work, and it was called "standard of care." Standard of care means that patients can expect certain things when they receive treatment.  Instead of a checklist, it is a form of preventative actions and ideas which guide work.  Doctors, dentists, and physical therapists use this approach.  For instance, all medical professionals take an oath where they promise to "do no harm." It means that a patient cannot be more injured by the care or get sicker.  In other words, you cannot bask someone on the head with a mallet so that the swelling stops the bleeding from a cut.  The expectations can be as simple as clean sheets on the beds and nurses and doctors washing their hands to more severe concerns like making sure they receive the correct medication and blood type if they receive a transfusion.  

From a development perspective, it means using source control for all development, putting together unit tests, and ensuring that everything works in a different environment than the developer's local machine.  It is a conscious decision that when you touch a system, it does not become a problem for someone else.  The implication of this is that you communicate changes to others and make sure you do not do any harm to the overall system.  It is a small step that will help build trust in an organization.  

Now discussions at the office can resemble something like this:

Scrum Master: Did that defect get fixed?

Developer #1 Yeah, and it meets the standard of care.  I even reminded DevOps that a configuration file needs to change.

SM: Thanks.

The goal of a standard of care in development is to improve the quality of the product.  Instead of using a checklist for development, instill values of quality and consideration for others on your team.  We all have work to do; by following a standard of care, we guarantee the work is done correctly and with maximum value to our customers. 

Until next time. 

Monday, June 20, 2022

The Pragmatic Way is Agile.

Lewis Carol said, “Between the idea and the reality lies the shadow.”  It was a wise observation from the author of “Alice in Wonderland,” particularly for people in the technology business.  Each day developers are taking ideas from others half-formed and transforming them into web pages, mobile applications, and complex data systems which keep the economic world spinning.  The theoretical becomes a reality in my line of work.  

I am working on a professional credential for my profession, and something has occurred to me.  To be a good scrum master or agile coach, you must balance the academic skills of the trade with the real-world challenges of working with people and business.  Not only must a scrum master know things, but they must be able to put those things into practice when the knowledge counts.  It means agile must embrace pragmatism.  

I have written about pragmatism before on this blog.  It is a uniquely American type of philosophy which more concerned about outcomes than deep philosophical processes.  It is also concerned with what people accomplish than how they get to the accomplishments.  For example, when I was between jobs, I substitute taught computer s science at my local high school.  To my surprise, the high school has a daycare center.  I was a little flustered and asked why a high school would have a daycare.  An understanding woman who was dean of students, Flora Betts, explained that it was for teen mothers so their children could receive care while they finished their diplomas.  My apprehension turned into admiration as the school found a way to prevent women from dropping out.  Instead of forcing young mothers to drop out, the school allowed them to complete their education while their children were in a safe and healthy environment.  If a high school can find a way to address a problem like teen motherhood, then the business world can deal with its myriad of complex issues.  

Part of many of the problems I see in business come from people slavishly following processes and ignoring what those processes are supposed to accomplish.  The customer must fill out forms correctly or obtain approval before receiving a product.  It may be the correct approach for accounting, but in the world of customer service, it undermines relationships and sales.  It is why I am a big supporter of pragmatism at work.  For instance, retrospectives should fall on the last day of a sprint, but what if the last day of the sprint falls on a national holiday? 

Many people would move the retrospective forward a day.  Often it is scheduled after the holiday because the entire office wants to get out early before the holiday.  In my coaching practice, I ask the team when it is time to have a retrospective.  We are still having a retrospective, but the pragmatic approach is to let the team decide when to have it.  The team is empowered, and the bent rules are not broken.  The agile world uses a fancy Japanese phrase for this approach, and it is called Shu Ha Ri.  

Development teams should learn the basics of agile, the Shu stage.  Next, they know which rules can be bent or broken in the Ha phase.  Finally, the team comes up with their own more relevant regulations for work, and this is the Ri phase.  After all the learning and growth, they begin the process again.  Mastery never happens because everyone is learning and growing.  It seems like a powerful, pragmatic way to improve an organization.  

So as I continue to study very formal and prescriptive ways to do my job, I am aware that work gets done in the shadow of the idea and the reality.  I need to understand the rules before I know which ones to bend or before I can create new ones.  Remember it the next time someone quotes practices or processes to avoid doing work.  Being pragmatic gets the job done and leads to change in organizations.  

A good Juneteenth and until next time.  

Monday, June 13, 2022

Microsoft Practices the Agile it Preaches.

A successful business leader should spend time reading and understanding the news.  Sadly, the information over the last six years has featured a dour parade of narcissism, neglect, and missed opportunities for progress.  The language coined a term for this phenomenon and it is called "doomscrolling." It is upsetting and discouraging.  The terrible news is endless, and we can not help but gaze into the nihilist sinkhole via our phones and televisions.  It affects me more than I care to admit.  Confronted with the choice of wallowing in despair or attempting to be a positive force for change, I dug up a positive example of people using agile to improve the world.  Today, I want to highlight some good news from the technology world. 

According to the Microsoft support site, three features are being removed from its spreadsheet program excel.  I had never heard of these features until I read the following article from Simon Batt.  It seems like they were equally obscure to other Microsoft users.  The change to our favorite spreadsheet program highlight how much Microsoft has changed over the last twelve years.  When this blog began Microsoft, under CEO Steve Ballmer, had a reputation for being the evil empire of the technology world.  

The Microsoft organization mocked ideas like open-source software, object-oriented development, and cloud services.  Developers who used the company's product felt alienated because our technologies were stuffy and limited compared to other software development tools.  

When Ballmer left Microsoft and Satya Nadella took over, there was a notable shift in the organization.  One of these first duties was to have everyone in the organization use Microsoft Team Foundation server as its source control system.  In a keynote speech, I remember him saying, "I am not going to sell a product to a corporate client that we are unwilling to use ourselves."  Engineers call this "dogfooding" because you are metaphorically consuming the dog food you sell to others.  The quality of the Team Foundation Server software shot through the roof and soon integrated tools like git into its system because it was what developers requested.  The software transformed into a cloud-based system known as Azure DevOps.  Anything like this would have been impossible if Ballmer was still in charge.  

Nadella's leadership engineering style embraces the principles of agile and Lean-SAFe, so Microsoft removing the feature from Excel makes perfect sense.  According to the agile manifesto principles, "Simplicity – the art of maximizing the amount of work not done – is essential."  An engineering team and organization understand that creating tools with endless features is wasteful and prone to defects.  The product team for Excel looked at the software and decided to drop three components.  Thus, the software can concentrate on things desk workers worldwide need.  In lean-agile, they say, "Organize around value." Since these features did not drive value to customers or Microsoft dropped them. 

It is refreshing to read news about business decisions based on agile principles.  As software continues to eat the world, it is nice to see that software companies are practicing what they preach.  The improvement process requires subtraction and simplicity, so it is nice to see companies using it for everyone's advantage.  It is a small sample of good news in a world dominated by doomscrolling.  

Until next time.