Communication is Necessary for Agile

Leadership is a complex subject to discuss in a business setting.  Many people wrongly believe that leading others is an inborn trait.  Others have backward views about who should be in positions of leadership.  Over the years, I have discovered that leadership is like any other skill; it must be practiced.  Today, I want to cover a simple craft that gets lost in gigantic organizations and improve your leadership skills – communication.  

I pointed out an article in Forbes magazine saying managers need a better job description.  The main argument of the blog is contemporary organizations discourage the creation of leaders because of the ambiguous nature of the information within their corporate cultures.  The decisions have to be correct instead of fast.  Paralysis forms because no one wants to stick out and call attention to themselves in this environment.  In the current global economy, it is a prescription for failure because market conditions are changing faster than the decisions process in many organizations.  

Personal initiative, taking responsibility for decisions, and taking action when required are discouraged in organizations with this retrograde culture: another characteristic that suffers is communication.  In an unhealthy organization, managers do not want to hear bad news from subordinates.  Unhealthy organizations also discourage the free flow of information.  Information comes from the top of the organization and filters down to employees.

Organizations with a more healthy culture embrace the value in the agile manifesto, which prefers “Individuals and Interactions, over processes and tools.”  Thus, information moves both up the hierarchy of the organization and down.  The terrible news is communicated accurately, and leadership acts on it.  Finally, we see fewer meetings and more action taken by people doing good communication.  

It means having a rapport with your development team as a product owner.  A good product owner acts as a bridge between the business and the development team.  As part of the job, you need to regularly communicate with the organization and the software customers.  It is vitally important to communicate with the development team. 

Writing user stories and giving them to the development team is only part of the job.  The developers have questions, so you need to be available to answer those.  Finally, the development team is a source of valuable information for other development teams.  Often front-end developers need direction from other teams who write APIs or middleware.  On large enterprise projects, you can ask your developers to answer questions for different groups.  A product development team can answer a simple question then share that information with other groups.  Even better, they can facilitate a face-to-face meeting to share information. 

Traditional project management approaches treat information communication as a one-direction process.  The people doing the work communicate the progress, and then the project manager acts as a scorekeeper.  Agile requires communication to be a two-way street where information moves both up and down the chain of command so that people can make educated decisions.  In an agile organization, secrets and unshared information are risks that undermine a project. 

Communication is not easy.  It takes effort and humility to listen to others, particularly those with less power.  Listening and conveying information helps avoid surprises.  Learn about your team, and get to know them as people.  Take time to listen and accept bad news when it is delivered.  It takes practice, but anything worth doing requires effort.  

Until next time. 

Disagree and Commit is the Agile Way to Resolve Disputes

Presently, I am working on a gigantic project.  It is the replacement of a forty-year-old enterprise system.  Teams reside over three continents, and conference calls have hundreds of participants.  Projects like this require millions of dollars and the patience of Job.  I exist as a product owner who intersects with the organization's remaining units.  It is a tremendous amount of responsibility.  Today, I want to discuss a vital work component on a gigantic agile project. 

When working on a massive project, the biggest challenge is making sure the work is completed quickly and with sufficient quality.  Teams hand off work to each other, and those are usually the pain points as one group takes over the work of another.  It is why scaling frameworks like SAFe, LeSS, and Scrum at scale have become so popular in enterprise-scale projects.  The additional artifacts and rituals of scaling frameworks are supposed to prevent botched handoffs and production environment problems. 

Disagreements are going to happen.  Large agile projects are strange because there is a tension between the need to manage hundreds of people to get a job done and the desire for those people to be empowered and autonomous to get the job done.  How we handle those disagreements can make the difference between success and failure.

I received a directive from an executive to do something, contradicting over twenty years of my experience as a technology professional.  I objected and said it violated both the letter and spirit of agile.  The response was terse, "We are a SAFe project, not an agile project." At that point, I had some choices.  I could be insubordinate and not carry out the order.  My other choice is to follow the directive unquestionably.  I chose a third path that agile coaches embrace called "disagree and commit."  I explained the foolishness of estimating research spike and then said, "You are in charge of this project, so to save time, I am going to disagree with you but commit to this course of action."  You are not being insubordinate, and you are pointing out a future complication or challenge which the team can resolve when deadline pressure is not severe. 

Six years ago, Jeff Bezos, in his letter to shareholders, said the disagree and commit approach is how Amazon was able to create Amazon studios.  It is also a decision that can easily be reversed.  Any discussion about the merit of a process can get vetoed.  Fortunately, you can change most decisions, so the quality of a decision is not what matters but the speed.  

In my brief tenure on this project, I have delivered software and improved the process for the team.  I believe that my approach will be vindicated, but for now, I will commit to the other one because it is easy to reverse when the time is correct. 

The manifesto says working software is the accurate measure of the progress of an agile project.  Disagreement is a natural part of creating working software.  Saying you disagree with someone is not insubordinate; it is sticking up for your development team, quality of work, and professional ethics.  Committing after disagreement means you want to get the working software into production sooner.  It keeps the bills paid and ensures a massive project does not collapse into a big ball of mud.  

Until next time. 

Agile is Ethical and About Squashing Trolls.

In the early days of internet communities, the conversation was limited to bulletin board systems and the early attempts at instant messaging.  It was a wild and unregulated era.  People got into an intense discussion that would degenerate into personal attacks known as “flame-wars.” Often the online conversation would be a mix of community building and toxic misanthropy.  Other times, communities would sprout up and become repositories for wisdom and trivia in equal measure.  To be an early adopter of the internet, you learn to find the good stuff and avoid the poison.  

The most dangerous people in this new world were called trolls.  According to The Guardian newspaper, they are the type of internet user “…who posts a deliberately erroneous or antagonistic message to a newsgroup or a similar forum intending to elicit a hostile or corrective response.”   Today, social media and the internet appear overrun with these trolls looking to monetize the attention into fame and fortune.  Today on the blog, I want to deal with a troll spreading disinformation about the agile movement. 

Dealing with internet trolls is often like wrestling a pig in a mud puddle.  After lots of exertion, you are dirty and exhausted, and the pig appreciates the exercise.  When a troll is denied the nourishment of attention, the internet troll moves to another topic or potential victim.  It is why a common source of wisdom on the web is “don’t feed the trolls.”  

I spend plenty of time on the professional network LinkedIn.  It is a way to keep in touch with old colleagues and stay on top of industry trends.  Daily, I see articles from solemn people talking about why agile does not work.  Many of these articles follow a similar template and often boil down to organizations being unable or unwilling to apply the information they discover during the agile process to improve.  I liken it to a person who knows they have to quit drinking but journeys to the liquor store because they cannot fathom a life without alcohol.  This week was an exception because someone seeking attention posted an article saying agile was unethical.  I have dedicated my entire career to ethics and agile.  To have someone accuse the agile reformation of being unethical felt like a grievous insult to everything I have stood for professionally.  

Agile, emphasizing transparency and empiricism, is the height of ethical business behavior.  Customers deserve collaboration instead of lengthy contract negotiations.  The manifesto talks about working software being a principal measure of success.  Rather than sticking to a plan, an agile professional will respond to changing conditions and market plans, and being an agile professional means being deadline-focused.  Finally, agile requires you to be good with people and practice radical candor along with dynamic leadership. 

Agile is an accepted part of technology organizations and global business because it works, and its practitioners embrace the highest ethical standards.  The business world is harsh, but it will not tolerate frauds and grifters.  A grifter will alienate everyone and then no one will do business with them, and eventually, a fraud will get caught and go to jail.  

Finding an audience is difficult on the internet.  It does not excuse spreading misinformation or outright falsehoods.  Often you feel like a mime in a mosh pit wanting to express yourself and receive the attention you deserve.  When I made my predictions about 2022, I said I wanted to fight misinformation.  Any accusation that Agile is unethical for business should receive a dose of skepticism.  I have paid a high price to be an ethical technology professional and speak truth to power.  I will not feed trolls by letting them get away with spreading erroneous information.  

Until next time.

We need fresh blood in technology

It is a new year, and after all of the parties and gatherings, it is time to roll up our collective sleeves and get back to work.  The global economy requires plenty of labor, and we do not have enough trained people properly to maintain it. Today, I want to talk about this challenge.

Less than five-hundredths of a percent of the world population know how to write software and maintain computer networks.  All of the global economic data and information travel through those networks, so recruiting new people each year is essential to help maintain and improve those systems.  I think we have done a poor job in this regard.  It is why I will always support people looking to get into the profession. 

In many respects, being a software developer is like being and musician.  Practitioners can be self-taught or have years of classical training.  Each approach has its merits, but a musician needs to develop “chops” to succeed.  It is when a musician learns to improvise and interacts magically with an audience and other musicians. 

Thus, writing software is not learning a particular programing language; it is a way of working with others that maximizes quality and delivers value.  It requires attention to detail and learning how to write a unit test to know that something will work the same way each time it is in a production environment.  It is not an easy process, and it took over ten years of trial and error to consider myself competent.  The profession has a way of humbling the best of us.

Support others who are attempting to get into this crazy business.  Encourage people to set up GitHub accounts and experiment with new coding tools.  Encourage women and people of color to join the activity because their presence will help improve quality and deliver value to a broader audience.  Agile is a significant movement, and the more people we have creating quality software, the stronger it will become.

Until next time.