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. 

Don't Hate Agile, Hate Bad Agile

The internet is awash in pixels about the trend of “quiet quitting.” Plenty of talented people have sounded off on the subject online.  I do not think I can contribute anything more substantive to the debate.  Instead, I want to talk about another trend popping up on the web.  Many people are talking about poor agile implementations, and I think we need to discuss it.   

Agile is a growing paradigm in the business world, and as an early adopter, I have seen a few bothersome trends.  Allen Holub on the Continuous Delivery YouTube channel gave some strong opinions about agile and how it is failing organizations.  I am an outspoken critic of poor agile implementations and dark scrum, so when I heard Holub bemoan the state of Agile, I found myself chuckling along in agreement about most of the things he had to say.  

The first trend is the shift from technology professionals becoming agile advocates to project management professionals advocating agile.  It is a standard survival strategy for business people to pivot when they see changes in the market.  The cohort of PMP-certified professionals witnessed the changes in the market and then retrained to become scrum masters and SAFe professionals.  It is not an alarming trend, but they took the values from traditional project management and business leadership and attempted to dress them up with agile terminology.  The effect was the worst of conventional project management combined with the frantic nature of iterative development.  Not to over-generalize, but these people are dogmatic and accustomed to enforcing rules instead of the pragmatic delivery of solutions.  These people enforce laws and generate outputs, but customer value is an afterthought rather than a central focus.  

Next, business leaders feel that their problems will evaporate if they do agile instead of having an agile mindset.  Jeff Sutherland points out that agile and scum hold a mirror up to the organization.  It is then up to the organization to effect change based on what they see.  Often problems are hiding in plain sight.  Philosopher Slavoj Zizek calls this unpleasant part of human nature Unknown-Knows.  We can ignore evidence when confronted with it.  I have witnessed many business leaders act this way because they cannot effect change or feel the necessary change might impact them negatively.  A manager loves the rapid cycle times, feedback, and transparency that agile offers but only sees accountability pushed down to the teams as valuable instead of accountability, which percolates into the organization as part of the agile mindset.  I liken the situation to someone who wants to get into better shape but can’t seem to quit smoking.  

Finally, the licensing and training for agile professionals are creating what Holub calls “a priesthood that does not understand the scripture they are professing.”  I am a big supporter of formal training in the technology business.  The pace of change requires any good professional to relearn their job every eighteen months.  The proper training and curriculum by the various organizations like SAFe, Scrum.org, and the Scrum Alliance are exceptional at teaching the formal theory of Agile, but in the trenches work of delivering software is often ignored.  It creates a situation where people trained in this manner fall back on the processes they were taught instead of concentrating on the individuals and interactions necessary to get work done.

A classic example is my recent interaction with an agile coach with a PMP certification and SPC credentials.  This person never wrote a line of software or delivered value to customers.  The only experience they had was providing reports to upper management.  Suffice to say; they failed spectacularly.  

The agile reformation is over twenty years old and is starting to show growing pains as the initial enthusiasts become supplemented with careerists and ticket punchers in organizations.  Don’t hate agile; instead, let us hate the people diluting and undermining its effectiveness.  I fight that lonely fight each day. 

Until next time. 

Organize Development Teams to Deliver Value

I am working on a large software development project.  By my estimate, we have over one hundred teams working on this project.  Since it is a significant financial client, we use Scaled Agile Framework for the Enterprise, or SAFe for short.  It is a complex process with lots of moving parts and little room for error.  I am also experiencing a common problem with large SAFe implementations, and I want to discuss it today.  

SAFe is the de facto standard for large software projects.   For executives, it helps standardize the process and is a reasonable attempt to coordinate numerous agile teams.  Unfortunately, most business leaders do not understand how value flows through the organization.  The larger the organization, the more difficult it is to know how the firm generates value for customers.  Thus, teams are organized not around value but by technical specialty.  Front-end developers work on one team, database specialists on another, and middle-ware experts on APIs are on a different team.  It is a logical way to organize technical professionals, but it makes delivering software on large projects a headache.  

Specialized teams are fantastic if you organize your business to embrace the status quo.  Still, suppose you are attempting to innovate or build new services to help customers.  In that case, you need cross-functional teams because specialization means no individual team is accountable for getting work finished.  It becomes a deranged relay race where work passes to others, and no one is sure it has reached the finish line.  

For instance, if you are a clothing company offering a new mobile application for customers to customize their styles.  You could do the following: hire a design firm to build the mobile application and take an in-house technology team to hook into the current sales and invoicing system.  Finally, you have a group of manufacturing engineers take that data to reconfigure the factories to address the customer demands.  As an executive, it makes perfect sense, but the reality is that the mobile application developers do not understand how to communicate with the sales system.  The manufacturing team does not have what they need from the mobile application or the sales system to create high-quality products on demand.  They are traveling a logical path along a road to ruin.  

What makes the situation more troublesome is that SAFe has the concept of release trains which says these three teams above should be able to work together, hand off work, and get things done.  The trouble is the decision maker does not understand how the software and system should work, so they do not know how to construct the teams.  A team of mobile specialists, a team of sales and invoicing specialists, and manufacturing engineers is a straightforward way to break down the groups.  Alas, these teams will not work well together.  Instead, reconstitute the units, so mobile developers, sales and invoice specialists, and manufacturing engineers work on the same team.  Condense these three teams into two.  

What will happen is when a mobile developer has a question about the data they receive from the sales and invoice system, an engineer with experience will be able to help on the spot.  Likewise, the manufacturing engineers will understand what the sales and invoice system is doing because they will be working side by side with the necessary technical professionals.  Finally, the three teams blended into two sections, one for standard sizes and the other for children's; they can share solutions to make each group more efficient.  Instead of work being passed around like a hot potato, people work together to deliver value.  

Some of the biggest problems in SAFe happen when work passes between teams.  As a coach and agile professional, it is your responsibility to reduce this dysfunction as much as possible.  Organizes teams around value to the customer instead of technical proficiency, ensuring work when assigned can be taken from beginning to end with zero handoffs between teams.  It will make your release trains more efficient and save you from unnecessary headaches.  

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.