Trunk based development is the agile way forward.

Software development is a complicated and detail-oriented process.  It requires hours of focus daily.  The profession also requires near inhuman levels of patience as you spend most of your time with broken systems.  Developers who build those systems are a special breed.  Creating software is more challenging when you add deadline pressure and the collaboration of numerous creative people.  This week, I want to discuss another obstacle to software delivery: the use of source control to create versions.   

Software is in a constant state of construction and revision.  Each day code is revised, and developers create a shorthand for what they are working on to keep track of these changes.  Software developers call this shorthand version.  Microsoft uses the following terminology for versioning software: major, minor, hotfix, and build number.  A major number represents a significant improvement in the look or performance of the software; thus, version fifteen is superior to version fourteen.   A minor modification is a minor version number.  For instance, a new software version allows for alphabetically sorting columns, becoming version 15.2, which is superior to version 15.1, which did not have that feature.  Version 15.2.1 is superior to version 15.2.0 because it addresses errors created by German or Russian characters.  When we talk about hotfixes, a development team often deals with defects.  The final number is the build number, usually a date stamp of code compilation.  Version 15.2.1.20220925 is a day older than version 15.2.1.20220924.  By glancing at this numbering system, a software developer, product person, or executive knows which version is in any development environment.  It is an elegant and transparent way to understand the progress of a software development project.   

Unfortunately, the business world is not elegant or organized.  A version can exist in production, and a different version will live in the User Application Testing environment.  In situations like this, most source control tools can branch code, so the main version of software exists in the trunk, and a version can live in a different branch.  It is supposed to segregate code into two lines, which developers merge once the software is released.  The ugly truth is that software is being manipulated in source control by hundreds of people creating branches and combining them.  This situation is filled with entropy as developers are making fixes to one component and ignoring the other.  In cases like this, code in one branch can exist, and code that creates critical errors might exist in the other.  The team will not know until the code is merged into source control or pushed to a testing environment.  Merge conflicts like this are expensive to fix and often happen publicly, hurting your credibility with customers. 

As a result of vague promises made to the business, product managers insist that the updated code find a home in the previous version.  It is called backporting, and it metaphorically resembles placing a rocket engine on a bicycle and expecting it to behave like a spaceship.  When a development project requires backporting, it introduces further fragility and technical debt, which shows up in expensive ways.  Instead of source control adding focus to a project, it creates more entropy.  

There is a proven way to fight this problem.  It focuses on developers keeping their code repositories up to date, and the business focuses on the next release instead of prior ones.  If something needs to go to production, the team promotes code, knowing that the company is not introducing technical debt.  It is a practice known as “trunk-based development.”  If you are using trunk-based development, you are forbidden to create branches.  The developers on the project check in and check out of the same branch, known as the trunk, guiding development.  At any point, the most recent version of the software is in the trunk, and the need to perform mergers becomes unnecessary.  Backporting to the previous version stops because the most recent version is the only one.   

Source control is a powerful tool, but so it s a chain saw.  You can use it to cut firewood or create sculptures.  It is also possible to maim and kill others with it.  The difference is training and intent.  So if you use source control in your project, use a trunk-based approach.  You will be glad you did.

Until next time. 

Agile is all about Trust

Since the end of World War Two, increasingly complicated systems have developed to make our lives easier.  Complexity creates many of the biggest challenges we face in the business community.  It creates a cycle of expectations known as the luxury trap when one generation's luxuries become the next generation's essentials.    The rapid technological change makes this trap more dangerous as industries struggle to remain competitive and build increasingly more customer-focused products.  It is challenging to stay on top of these demands.  We need a way to approach rapid change with a healthier perspective.  The good news is that we can create that healthy environment if we develop trust as leaders. 

Yuval Noah Harari points out that a modern economy requires two things for growth.  The first is easy access to credit, and the second is trust that things will improve over time.  The credit will keep flowing while there is confidence in the future.  Trust maintains this cycle.  If you cannot trust others to pay back loans or do good work, then you will not part with your hard-earned money.  When trust breaks down, then economies seize up.  It happened during the 2008 sub-prime loan crisis because the banks were freighted to loan money.  

Simon Sinek has a great video discussing the concept of trust in greater detail.  He talks about how the elite special forces unit SEAL Team Six chooses its members.  To a sailor, the SEAL team member prefers team members they trust over those with an outstanding combat record.  The reason is apparent to me.  When things go wrong, and they go horribly during combat, they want to know that the other members of the team will back them up.  It is a type of trust earned over the years and is why those of us outside the SEAL community see these warriors as clannish and insular.  

In business and life, this is important because people want to work with people they trust, and it is up to business leaders to foster this among their team and others.  You can be the top salesperson in an organization, and if you do not have the trust of others, your sales will eventually evaporate. 

So how do you build trust?  It is not a simple answer because you earn the trust of others over time instead of making significant splashy actions.  It is countless small behaviors that build trust.  It is starting meetings on time.  It is being honest when it is inconvenient and respecting people.  Leaders build trust by doing what they say and saying what they do.  Embracing the grind of the team and acting in good faith with your interactions with others.  Earning trust is the hardest thing a person will do in a leadership role.  

The agile manifesto states that we should value "Individuals and Interactions over processes and tools." This value is central to developing trust— your team and colleagues want to count on you.  In turn, the group wants someone to be their advocate and protect the team from the impersonal forces outside.  It is a problematic task, but if done correctly will pay huge dividends.  We do not talk about trust and leadership often enough, but a business will become more agile if we do it. 

Until next time. 

Not just coders

I have spent the last few days hiding from cable news.  The death of the Queen of England and the mourning and celebration it generates is overwhelming.  I have spent my time reading David Forster Wallace's essays and working on white papers focusing on creating cross-functional teams.  It has been a welcome respite.  As I was writing, I stumbled upon some online forums discussing the role of developers in an agile team, and I felt that I needed to make an important point.   

I have commented on the attitude of a minority of people in the project management profession that the only role of a development team is to write code.  It is an incorrect assertion.  A development team not only includes people who write software code but quality professionals, data specialists, user interface professionals, and business analysts.  Each team member has a say in delivering value to a customer.  The combination of these diverse skills makes an agile team so powerful.  

Leaders with command and control mindsets think that developers are interchangeable.  A developer understands a computer language and can take business requirements and translate them into that language.  What these leaders do not understand is that developers are people.  Developers have children and spouses.  Like all human beings, they are struggling with emotional and existential challenges.  Software developers deal with deadline pressure and problem-solving differently than others because each is unique.  A software developer is not some nameless worker bee working for the company hive; they are flesh and blood struggling to get along in the world just like everyone else.    

Along with Marx's observation that work alienates people from themselves, I believe the dehumanization of people keeping the global economy spinning is the biggest challenge of our time.  People should take pride in what they do, and saying a software developer is just a coder dismisses all the intelligence and effort they put into mastering their craft.  Influential bureaucratic organizations often make the work process impersonal and anonymous, whether in government or business.  

A competent software developer requires creativity, attention to detail, intelligence, and the ability to deal with oppressive levels of frustration and doubt.  The middle ground of healthy self-esteem is elusive when you are on deadline with a gnarly problem to solve.  Some days you feel like the dumbest person on the planet, and other days you want to revel in your intelligence.  It is emotionally taxing, and treating these people like mindless drones is insulting.  

Treating people like people instead of nameless cogs in a global machine is the key to success in a global economy.  I have come up the technology ranks as a hobbyist, student, entry-level developer, and finally, a scrum master.  This experience in the trench of software development makes me a better leader and agile coach.  

Until next time. 

Anyone can lead change- a lesson from Gorbachev

In the United States, a barbecue and family time seems more urgent than the latest hot take on business transformation.  It is hard to be inspired when confronted with a three-day weekend.  The last official weekend of summer is more appealing than sitting down and focusing on something to say which has meaning to many people.  Something happened this week that you might have missed.  Mikhail Gorbachev died at the age of ninety-one.  For those who don’t remember Gorbachev, he is a Nobel Peace Prize recipient, Time Magazines Man of the Decade in 1990, former president of the Soviet Union, and, oddly enough, the star of a vintage Pizza Hut commercial.

It is hard to explain to young people today the terror you felt growing up in the 1980s during the end of the cold war.  The nuclear arsenals of the United States and the Soviet Union confronted each other with a hair trigger.  Planes were flying round-the-clock missions, so the launch codes for a counter-strike would be ready if the other nation attacked.  The number of nuclear missiles ready to extinguish all life on the planet numbered tens of thousands.  A misunderstanding could kick off a series of escalations each day, eventually ending all life on the earth.  It was a scary time with the future promised to no one, but you still had to do your algebra homework if you wanted to go to college. 

The Soviet Union was communist and, between 1982 and 1987, had gone through three presidents.  Brezhnev was corrupt but wanted to get along with the west.  Yuri Andropov was a hardline communist who made his reputation in repressing freedom movements in Hungary.  Andropov was confrontational, but his poor health meant he spent most of his time in a hospital bed.  Andropov’s successor, Konstantin Chernenko, was in even worse health and died of emphysema and heart disease less than thirteen months after he replaced Andropov.  Gorbachev was young by communist party standards, in good health, and the ultimate insider, rising through the ranks of the communist party with smiles and handshakes instead of bullets and threatening to deport people to Siberia. 

When he took over, Gorbachev confronted a colossal mess.  Crops were rotting in fields.  The Russian computer program could not compete with western systems run with a new-fangled technology called microchips.  The war in Afganistan had devolved into a stalemate.  Finally, the Soviet Union faced destruction at the hands of the United States.  If it wanted to survive the cold war, the nation had to be protected from attack and provide basic economic necessities to its people. 

According to people who work with alcoholics, Gorbachev had “a moment of clarity.”  The nation would starve from within or face a nuclear attack from Americans unless something changed.  If it were any other person, they might have picked fights with the west and ignored the situation at home while enjoying the trappings of power.  Gorbachev wanted to put long-term fixes into place to preserve the Soviet Union for future generations.  It meant reforming the communist party to be more accountable to the citizens, creating an economy that could meet the basic needs of its people, and foreign policy, which reduced the likelihood of war.  It would be the ultimate transformation project of the Soviet Union into a modern power. 

It was an incredible gamble.  If anything went wrong, the entire nation would collapse.  What made this gamble more spectacular is that Gorbachev was born and raised in the system and advanced through the ranks, saying the right things.  The intimacy with a corrupt system and the power it gave him could have blinded Gorbachev to what he needed to do.  Instead, he decided to institute reforms hoping to save the only way of life he knew. 

Glasnost and Perestroika are footnotes to history, but they represent a reasonable faith effort to reform a flawed system.  I have no illusions about Soviet Communism, which killed millions of people and enslaved half the world in the aftermath of World War Two.  Nations under communism required over thirty years to integrate with the World economy, and Russia today behaves more like a corrupt petro-state than a great power.  

If you are wondering what any of this has to do with agile, it is this; to make a change in corrupt systems takes courage, and it is up to all of us to have moments of clarity and incite change.  Influential people need to experience moments of clarity, and the agile movement has the moral credibility and technical experience to make the change.  Corruption and failure happen if we allow them to happen. 

The world is a better place, thanks to Gorbachev.  The number of nuclear weapons has decreased by a factor of six.  A war that will extinguish the human species is still possible but will be a conscious decision instead of an accidental blunder. The world has faced a global pandemic with halting success, and the war in Ukraine has not boiled into a worldwide confrontation. We are concentrating on more long-term problems like climate change and wealth inequality.  

It is the legacy of Gorbachev.  A safer world with fewer nukes and more cooperation.  It is far from a perfect world but allows us to concentrate on longer-term problems and make reforms.  People can, in good faith, institute change, and it is up to each of us to act.

Have a great labor day, and until next time.