Looking Ahead to 2022

Happy New Year!

It is the end of the year, and everyone will be in full Christmas mode when this blog is published.  Each year, I blunder around attempting to make predictions of what will happen in the world of technology and agile.  Last year, I skipped that exercise because I was moving into my new home.  I am comfortably settled in, so it is time to look at future trends. 

Nothing is going to be easy. –

The year is a textbook example of the insecure nature of the modern global economy.  I was fired from my position as a director of delivery and then went into the world of consulting.  The social contract where you are loyal to an organization and, in exchange, they are dedicated to you is gone.  Now each person must build a brand and skills to convince employers to hire you to generate value for them.  It is exhausting and aggravating because it forces you to prioritize your career for survival reasons instead of family and community.  It also grinds down the self-worth of everyone because security and status depend on maintaining valuable skills for the employment market. 

Career, family, and community are never easy, but it will become increasingly difficult to balance these forces with this present situation.  It is no wonder birth rates are declining in the United States.  

Ending Humiliation at the Office. –

The year 2021 features an open insurrection against a freely elected president and the prolonged effects of the COVID-19 pandemic.  Both of these stories are important, but in my mind, the big story is the “Great Resignation.”  The job market is hot, and the upheaval of the last two years has made people reconsider priorities.  I also suspect that many professionals working from home realize how awful and humiliating it is to work in an office.  Petty leadership, microaggressions, and lack of advancement are finally coming to a head, and it is natural for people to tell organizations to stuff it.  I joined the agile reformation because I knew that this situation would not be sustainable.  If your organization wants to survive, it pays to help people find dignity, flexibility, and opportunity at work.  Give me a call, and I might be able to help you with that process. 

Money What is that? –

All of our ideas about money are changing.  Bitcoin has been around since 2008, and now we have other types of cryptocurrency floating around the internet, including DogeCoin.  I believe that most cryptocurrency is a high-tech version of blue-sky stocks from the 1920s.  However, we can not ignore that blockchain technology will change how we treat things like money.  Banks are getting involved in cryptocurrency, and governments are taking regulation of it more seriously.  I think these are all good things. 

Non-Fungible Tokens or NTFS are becoming interesting because they look like they are a new way of paying for digital content.  I am not convinced, but NTFS might help move the internet away from an advertising model of content and toward something more sustainable.  I will try to experiment with this in the new year.  Who knows, I might make some money in the process.  What is clear is that attention and time spent with content will be more critical than ever.  

Death to Disinformation! –

Being online can get dispiriting with trolls, bullies, and self-aggrandizing grifters dominating discourse.  Misinformation pedaled by bad actors is poisoning the promise which surrounds the rise of the world wide web.  With the rise of virtual reality and augmented reality in the tech sphere, I will volunteer and help create defenses against misinformation in these new internet territories.  Expect to see me in the Sensorium virtual world attempting to make sense of it and act as a sage, helping prevent the spread of misinformation.  I hope I will be welcome.

So those are my predictions.  I want to wish everyone a happy new year and look forward to seeing everyone on the other side. 

Until next time. 

Embrace the Pain and the Progress of Agile

I am busy with my work commitments and researching a book.  As part of my research for the project, I have spent time reading about topics outside my comfort zone.  One of the topics is an understanding of Lance Armstrong and his doping scandals.  While doing this research, I discovered the deep wells of endurance and dedication it takes to be a professional cyclist.  Each cyclist has masochistically embraced pain and suffering.

Reed Albergotti and Vanessa O'Connell described three-time Tour de France champion Greg LeMond book in their book "Wheelmen,"

"He'd hit 5,000 feet, and the air would get thin. He'd feel light-headed. He'd breathe hard. So hard he couldn't think anymore – couldn't feel anything.  And LeMond liked it that way.  He was happiest when he was suffering when he was in total pain."

LeMond was an abused child, and he would get on his bicycle and ride.  The physical pain and adrenaline were his escape mechanism.  

What many people consider masochism was a typical day's effort for a professional cyclist.  With little fanfare and attention riding, six, eight, ten hours a day, the rider would climb steep mountain trails at altitude and pursue a constant diet and exercise routine.  The routine of suffering had few guarantees because everyone else we doing the same things to remain competitive.  

After a call with my development team in India, it occurred to me that the life of a technology professional is similar to a professional cyclist.  Most people do not see the hard work and attention to detail software developers and quality assurance professionals put into their work.  The hours spent tweaking algorithms, troubleshooting bugs, and tuning database tables are invisible to the software users.  It is a grind, and it resembles the suffering of professional cyclists. 

As the coach and leader of your team, it is your job to put that suffering and grind into perspective.  Measure things like defects, lead time, number of stories getting done per sprint.  Spot trends and point out improvements.  Show your team that the hard work is paying off.  Finally, expose the team to the people using the software.  It will allow the people doing the work to see how all the effort is paying off. 

The emotional labor it takes to lead a software team is challenging, but if you put in the effort, there is a big chance that it will pay off with a victory lap or two when you complete the project.  I hope all of my readers have a fabulous Christmas holiday, and I look forward to more adventures in 2022.  

Until next time. 

Emotions Mater to Your Agile Leadership

People describe business people as cold and lacking emotions.  The classic Christmas story by Charles Dickens, “A Christmas Carol,” is a prime example of an emotionally stunted person who needs a supernatural intervention to live a better life.  My personal and professional experience is different.  I have witnessed fits of rage, emotional breakdowns, and plenty of narcissism.  Technology features numerous emotional highs and tragically deep lows.  When people base their identity and ability to support a family on work, you cannot help but get emotional.  As an agile coach or leader, it is up to you to deal with your own emotions and the emotions of others.  Let us take some time to discuss it. 

A common phrase you hear in any office is, “Don’t take it personally; it is just business.”  Ironically, this line comes from gangster movies from the last fifty years.  I firmly believe that business people should be better than typical gangsters.  Many people depend on business to feed their families and provide themselves with a sense of self.  It entangles the personal and professional, which are bound to have emotional implications.

In her book “Radical Candor,” Kim Scott talks about the emotional work of being a leader.  She emphasizes that you should care personally about the people who work with you.  Additionally, it would be best to challenge people directly by praising and criticizing when necessary.  Both praise and criticism should come from a place of genuine concern for the people you lead.  It is a skill that does not come naturally, but it will take your agile skills to the next level with practice.

The most challenging part of being in a leadership role is dealing with your own emotions and how they affect the team because pressure can build up in the office, and it creates one of four reactions; fight, flight, fawn, or freeze.  Our evolutionary legacy has taught us to react to danger with a fight instinct or a flee response.  Running away from trouble is always an intelligent course of thinking when escaping.  Fighting is also natural when we think we can overcome the danger.  You can see the flight response when people do not want to see or speak to you in an office.  A person who picks fights is a typical response to danger, and so to create a better working environment, you need to help remove the threat from a situation so you do not trigger a fight or flight response. 

The fight or flight response happens when the power dynamics are roughly equal.  When there is a big difference in power, fawning and freezing happen.  When someone is scared, that person will freeze.  The response allows the person to access danger and the stillness acts as a form of camouflage when someone is threatening them.  I see this happen all the time in meetings when an executive asks a question.  Everyone freezes because they want to provide an answer which will please the executive.  The fear is that they will be punished or ostracised if they give a wrong answer—situations like this demand psychological safety, and people are allowed to speak.  A messenger with terrible news should never worry about getting shot.  

The fawn response happens when someone decides that false flattery is the only way to deal with someone creating a perceived danger. Fawning is a way to advance within an organization or deflect attention.  In reality, it is manipulative and an example of toxic relationships in the workplace.  The leader being fawned over will crumble at any sign of adversity, and the person doing the fawning will lose respect from their peer group.  Being charming and cute is an excellent short-term strategy, but fawning behavior will undermine credibility in the long term. 

If you witness any of these behaviors, it is clear that the office environment does not have psychological safety, and you need to address it.  Business is personal.  People do feel strong emotions at the office.  As a coach, it is up to you to create an atmosphere of psychological safety because if you do not, people will exhibit fight, flight, freeze, or fawn behavior.  It is better than living like a gangster. 

Until next time. 

Communication is the Key to Agile

Gigantic enterprise projects require thousands of developers and countless hours of work.  I am working on one of these projects, and I have learned a few things along the way.  Today, I want to discuss the importance of communication if you are going to be a successful agilist. 

When working with extensive enterprise applications, you should understand that no one will know how the system works.  A person will understand how a particular portion works but not how the entire system operates. Today's giant software applications for business are so big and complex that it is impossible to comprehensively understand how information flows through the system.  Confronted with this reality requires numerous people's collaboration to outline how a system operates.  

The collection of experts in a room will hash out how the system operates.  Once they have a general idea, they start creating user stories to flesh out that operation and assign work to different teams.   With software teams scattered around the world in different time zones, questions are bound to come up.  Product owners and scrum masters then attempt to bridge the gap between the various teams to get the work done.  It is a tedious and painstaking process. 

I use a technique I learned in my undergraduate days as a speech and debate person.  I tell people what I am going to say to them.  I tell them and finally tell them what I just told them.  These techniques sound redundant, which is the point of the entire exercise because repetition aids in the retention of information.  

For instance, we are adding extra fields to an API, so I call a meeting to discuss it with the vendor and the team consuming the vendor's API.  I send out a meeting notice with a brief plan.  During the conference, I said, "We will cover the new fields in the API and how they are going to be consumed."  The next portion of this meeting talks about the fields and how the team will consume them.  At the end of the session, I review what we talked about and, if necessary, follow up with an e-mail and some user stories the teams need to finish.  

Notice the goal of the meeting is clear and stated up-front with a clear purpose.  We work toward that goal.  Finally, we restate how we are going to achieve that goal.  It helps to leverage the communications systems used in the office, including e-mail, instant messaging, and project management tools.  It is a way to hold people accountable and make sure they understand. 

Checking for understanding is essential.  It is one thing to say something, but understanding is a different skill.  It is why you should ask others to repeat back what they know.  When there is a disconnect, you can clarify the misunderstanding.  For a busy person, communication like this can be exhausting, but checking for understanding will improve the quality of work on the team.  The time spent talking now is going to save time doing rework later. 

On gigantic projects, it pays to over-communicate.  Tell people what you are going to tell them.  Tell them, and then tell them what you just told them.  You can thank me later when the level of misunderstanding decreases and quality improves.  

Until next time. 

INVEST in Agile

I have spent much of 2021 working as a product owner.  I receive new insight each day into the role.  I have developed empathy for the people who do the job and the unique pressures they face working on a large-scale project.  I have noticed in my tenure that writing user stories does not appear to be a consistent skill among my peers.  From time to time, when I point out ways to make stories better for the development team, I get testy pushback from my peers.  This time on the blog, I want to cover story writing and the INVEST model.  

Readers of this blog will appreciate that I am a fan of Roman Pichler and his D.E.E.P model, and I have written a few blog posts about the subject over the years.  Lately, I am noticing that some product owners are struggling with the basics of authoring user stories.  I spend plenty of time sharing my blog posts on how to write better stories with my colleagues.  

Lately, some of my peers have asked what makes a good user story, and I did not have a good answer until I learned about the INVEST model.  First proposed by Bill Wake in 2003, the INVEST model has become the gold standard for user stories.  Once I understood its purpose, I became an enthusiastic advocate of its application in story writing.  INVEST is an acronym that stands for; independent, negotiable, valuable, estimable, small, and testable.  Following this model will make your stories better, require less work for the development team, and make like easier for the product owner. 

Independent, when we say a story is independent, it can be worked on individually and not rely on someone outside of the team for completion.  The development team can work on separate user stories in any order.  Finally, if a story does rely on dependencies, it can be easily mitigated with mock data.  User stories should not create constraints or bottlenecks in the overall project.  

A negotiated user story is not a contract or recipe to follow slavishly; instead, it is a conversation.  The product owner and the development team should give and take to know what to build but not how to do it.  In my experience, the most significant area of conflict is when a front-end developer and a UX designer clash over the implementation of a design.  The UX designer often wants the developer to match the graphics file pixel per pixel.  The realities of CSS, HTML, and JavaScript can make that like jamming a square peg into a round hole, so it will require negotiation to get everyone to agree on how the page will look and behave.  

When a story is valuable, it means that its completion will add value to the customer or the project.  The development team or product owner should scrap any user story we cannot explain how it helps a customer or drives revenue for the project.  It is hard to do in hierarchical organizations because the highest-paid person in the room often makes project demands to have work done that delivers no value but satiates their ego.  When in doubt, provide value to the business and customers, the executives will have to pay for their ego gratification with their own money. 

Each story in the backlog should have an estimate.  The team should take time and ask how complexity, risk, effort, or uncertainty surround a story.  It then allows the team to make an educated guess about how long it will take to complete the work.  An estimate is not a quote for work because it may be off. Still, if the team cannot estimate a story, the product owner will need to refine the story further to allow the development team to provide an intelligent estimate.  

Small stories require less time to complete, and these types of stories are easier to understand and provide a swifter path to success.  I talk about the importance of smaller stories here.  

Finally, a user story must be testable.  Suppose you cannot quickly test a user story with either a unit test or easy-to-understand instructions. In that case, the story is overly complex, and it will generate further delays to the project because no one understands what the story is supposed to accomplish.  Keep things simple, and to keep them simple, they should be testable. 

That is the INVEST model.  A user story should be independent, negotiable, valuable, estimable, small, and testable.  Following this rubric will make writing user stories easier and will help get work done more efficiently.  

Until next time. 

Being Grateful is Part of Leadership.

It is Thanksgiving week in the United States, and it is a uniquely American holiday with its origins in the American Civil War.  The family gathers together to have a big meal and make plans for the Christian holiday in December.  The Thanksgiving holiday weekend is also a great opportunity to emotionally reset and take stock of the things in life which make you grateful.  In the lonely world of leadership, gratitude is the only thing that can keep you concentrating on long-range goals. 

General Collin Powell died this year, and this imperfect patriot had plenty of things to say about leadership.  I have plenty of respect for Powell and his style of leadership.  One of the things he says in his book on leadership is being in charge is a lonely activity with others second-guessing decisions.  A leader deals with negativity, hostility, and apathy each day, and it can make even the most enthusiastic to a cause feel crippling levels of exhaustion.  In those moments of fatigue, being grateful for even the most minor things in life make it possible to move on to the next day.  

Even in the dark moments, it helps to take time to show gratitude for what good you can find in the world surrounding you.  First of all, I am grateful to the CAPCO organization.  I was feeling discouraged about my career, and they hired me as a Senior Consultant.  Since I have joined the organization, I feel like I now have a tribe of people as my colleagues.  We are eccentrics, innovative, and want to make a difference in the business world.  Being the lone agile person in an organization is isolating.  To be part of a group of agile professionals going through the same struggles make the fight worth it. 

I am grateful my parents are alive, and I get to enjoy them in their old age.  Life expectancy has doubled in a century, and my family has benefited.  I see my mother and father grow old together.  Our family will spend the Thanksgiving holiday together, and we will catch up and love each other as an immediate family can.  I get to enjoy the wit and wisdom of my parents for a while longer.  

Four years ago, a woman entered my life, and I have been a better person for the experience.  My partner Carol is warm, empathetic, and kind.  She puts up with my crazy career and the emotional ups and downs which come with it.  She is a teacher of young children, so I am learning how to relate better to small children.  She and her grown children have accepted me into their family, and I am grateful for that acceptance.  

I could go on, but I am most grateful for many things.  It helps push away the despair and darkness.  It is a chance to reflect on gratitude which helps make our workday struggles seem less consequential.  I am grateful to you, my readers and I look forward to more agile adventures in the future.  Happy Thanksgiving, everyone.  

Until next time.

Taking Agile One Day at a Time.

The most significant moment in any project is the ribbon cutting or product launch.  It features executives, politicians, and other VIPs cutting a ribbon or giving a splashy PowerPoint presentation before a crowd of adoring fans.  Many people do not understand that those moments of public triumph required many days of sacrifice, frustration, and suffering.  Technology is hard work, and it requires focus, intelligence, and unhealthy levels of concentration.  As an agile coach or scrum master, it is challenging to navigate these long periods of grinding work.  Today, I want to take some time to discuss how an agilist can navigate this period author Lewis Carroll labeled between the idea and reality.  

One of the most important books a technology professional can own is Fred Brooks' "The Mythical Man-Month" it outlines some principles of project management that remain applicable today.  It includes Brooks' Law, which says that late projects become later if you add more people.  Brooks talks about the importance of architecture in software development and how the division of labor between different specialists makes it harder to lead a project.  The most significant insight was the idea that a project falls behind schedule one day at a time for me. 

Each day the team attempts to get its work done.  If you are digging a hole in the ground, the task is straightforward.  Software professionals look at problems that resemble getting square pegs to fit into round holes.  Data from one system must be displayed differently on a mobile device than a web browser while traversing trillions of data points to obtain meaning.  Each day, engineers, developers, and project professionals slog through those problems and more.  It creates pressure that builds over time because many of these problems that need to be solved do not have easy answers. 

Chicago Sports columnist Bob Verdi would joke weekly when football injury reports were published.  A famous player often is listed as day-to-day.  With a comical tone, Verdi would tell his radio audience, "… aren't we all." As technology professionals, we are all living day to day, solving problems and building solutions.  It means that we should not concentrate on where we are in the project's overall life; instead, we should focus on what we need to finish that day.  It makes the emotional ups and downs less severe.  

Taking the work day-by-day allows you to filter out the politics around projects and the petty displays of status you see in corporate environments.  When problems linger, you gather together with others to find solutions.  It is hard to do because the people who begin enterprise-level projects are not around when they finish.  It is why you look at each day as a single unit and judge your success or failure on how you meet the goals of that particular day.  You build up good days and attempt to shrug off the bad ones to create a body of work that meets the project's long-term goals.  Brooks is correct projects do fall behind day-by-day, but they also succeed daily.  

If you are a coach or scrum master, instill this notion in your team.  The team is building big things, but they create many small items, adding up to something spectacular.  Improving one percent a sprint means an improvement of over twenty-six percent over a year.  Improving team performance like this often gets people promoted in corporate environments.  It makes working on the team more satisfying and lowers the stress levels of everyone on the project.  

Lewis Carroll said, "…between the idea and the reality lies the shadow." Taking work day-by-day allows you to handle better the darkness which occupies the shadows of your project.  It is not easy, but nothing worth doing is. 

Until next time. 

Smash Dependencies on Large Agile Projects

Working as a technology professional does not have the working-class credibility of being a plumber or ironworker.  We do not get dirty, and we do not pay a physical price for our work.  The worst injury we can suffer on the job is a repetitive stress injury or the occasional heart attack caused by chronic stress.  The biggest challenge in the profession is coordinating numerous savvy professionals to work together to accomplish a goal.  Today on the blog, I want to take time out to review dependencies for agile teams and mitigate them.  

When a project is small enough to require one agile team, dependencies are not a significant problem.  Often, the scrum master or a team member will take the initiative and address the situation.  At most organizations, a different team manages the production servers,  so when it is time to promote code into production, someone from the agile team makes arrangements with the server team.  Dependencies are simple on these projects. 

A larger project quickly becomes a tangle of dependencies.  For instance, an extensive enterprise application might have an AS/400 team working with enterprise data, a group writing a web interface, and finally, a group writing middleware to connect the two.  At this point, dependencies grow on a logarithmic basis.  Add an extra team, and the number of dependencies jumps from three to six.  Add a fifth team, and you get ten and so on until you get a tangle of communication channels.  The PMBOK guide has a fancy mathematical formula to calculate how these systems get out of control.  

Doing the math, a team of ten people or groups has forty-five different connections.  It is clear to see that the number of links and dependencies will be a problem for people to follow.  

The solution to this problem is to isolate those lines of dependency to make a clear connection between groups.  In my previous example, the middleware team is connected to the AS/400 team and the web interface team.  Upper management wants to add a team to write a mobile application.  Instead of linking the mobile development team to the middleware team and giving them more dependencies, the new team should collaborate with the web team because they already understand how to connect to the middleware already generated, saving cycle time and distractions. It seems counter-intuitive, but the knowledge from the web team will be more valuable than the middleware team attempting to educate the mobile application team on how to consume the web services.  Organizing your groups in this fashion prevent your dependencies from looking like the bedroom wall of a conspiracy theorist.  

To address dependencies, isolate them into narrow paths to reduce the number of connections between groups.  Not only does this conform with the PMBOK Guide, but it conforms to the theory of constraints because it allows a scrum master or coach to isolate and exploit limitations in a system.  Doing this will help remove complexity and lower your stress levels below heart attack severity.  

Until next time. 

Agile and Leadership Means Pissing People Off.

I am a fan of military history and wargaming.  The stories of veterans and the high stakes of combat have informed my worldview.  This blog even featured an article on how Dungeons & Dragons helped me become a better scrum master.  A fascinating thing about military history is the stories of personal heroism and leadership which occur when everything is on the line.  Stories of grace under pressure are an inspiration for me, considering I work in the intense world of technology.  Earlier this month, one of my heroes died from complications from COVID-19, Colin Powell.  His legacy is complicated in American history, but his insights on leadership are something people in the agile community should emulate.  

Powell did not have an impressive pedigree when he became an officer in 1958.  He spent the early years of his career learning his trade, and it was only in Vietnam that Powell’s career took off.  The young officer had a knack for solving problems and turning around dysfunctional units.  His superiors considered him competent, hard-working, and loyal.  Powell’s superiors fast-tracked his career.  

Where Powell distinguished himself, he was chairman of the Joint Chiefs of Staff under President George H.W. Bush.  Taking lessons he learned throughout his career, Powell innovated warfighting by toppling Manuel Noriega’s Panamanian government in 1990 and leading the Pentagon during the First Persian Gulf War.  I remember his collaboration with theater commander Norman Schwarzkopf and his declaration that the allies in the first gulf war would “…cut off and then kill.” Saddam Hussein’s forces in Kuwait.  

When he retired from the military, Powell wrote a best-selling memoir and spent his time public speaking.  Before being named Secretary of State by George W. Bush, he was a best-selling author and gave numerous workshops on leadership.  During the intermission in his public career, he continued to provide leadership speeches, and one of my favorites was in 1996, where he outlined some observations of a lifetime career.  The most important was, “Being responsible sometimes means pissing people off.”

To Powell, getting the job done is more important than being popular.  Building consensus and attempting to please everyone is a sure-fire way to mediocrity.  Often there are too many cooks in the metaphorical kitchen, and someone needs to make a decision.  When someone is in charge and makes a choice, it is going to get second-guessed.  Others will be unhappy with the decision because they will exert themselves more than they usually would.  Finally, a decision might expose someone as unable to do the work to the level of quality demanded.  Someone will always be pissed off with a person showing leadership.  

Agile makes this doubly accurate as the rapid cycle times and demand for working solutions are required.  People who get by on charm and a smile can no longer hide in plain sight.  Items missed are visible for everyone to see.  Technical debt which is missing during a demo shows up in testing or production environments.  All of these things are great at pissing people off.  

So as a leader and agilist, pissing people off is a natural consequence of the job.  It is asking why a deadline promised ninety days ago was missed.  A coach will ask powerful questions about server configurations and testing plans.  Leadership can be such a lonely job because if you are doing it properly, some portion of the people you serve will be pissed about a decision you make.  Once I internalized that message, I found leadership to be less lonely.  

I do not want to make Powell into some demi-god.  He has a complicated legacy which includes involvement in stonewalling the investigation of the My Lai massacre.  He also tarnished his reputation with his advocacy of the Second Persian Gulf war.  It is why biographer Jeffrey J. Mathews calls his biography of Powell “Colin Powell: Imperfect Patriot.”  We can learn from this imperfect man the principles of his leadership style, which served him well over his career.  The most important to me is that a leader pisses people off.  

Until next time. 

Southwest Airlines and the Gremlins of Technical Debt

It is Halloween season, so I indulge in a few monster movies when I have downtime.  I am partial to the old Universal monster movies with Bela Legosi and Boris Karloff.  I also enjoy anything with Vincent Price, and I consider his film “The Abominable Dr. Phibes” one of the most frightening things I have ever seen.  There is something about monsters lurking in the shadows which always gives me a great scare.  One of my favorite monster movies comes from director Joe Dante entitled “Gremlins,” which is a fantastic popcorn movie and a parody of entertainment culture at the same time.  Today, on the blog, I want to discuss a different kind of gremlin lurking in the shadows and how it has been fouling up air travel.   

The term gremlin was invented by the British.  In the early days of aviation, airplanes were not mechanically reliable; engines would jam, flight controls would snap, and canvas would tear without explanation.  Mechanics and pilots often blamed these mishaps on “gremlins,” nasty elf-like creatures who liked to cause mischief on an aircraft in flight.  By the Second World War, pilots from the United States and Royal Air Force had stories about gremlins.  If anyone has stories about these creatures from the German, Russian or Japanese Air Forces, please share them in the comments.  Suffice to say, gremlins were an excellent alibi for poor maintenance, bad design, or dumb luck.  The gremlin became a part of aviation culture. 

I keep thinking about these critters the more I work in technology.  I wish I could invoke them during a debrief of a poorly executed project or use them to explain a server outage.  Unfortunately, gremlins are mythical creatures, and if I use them to present a technical problem, the CIO of my client would laugh at me and then ask me to pack my desk and leave the building.  

Gremlins are comforting, compared to the problems technical professionals face with increasingly complex systems.  Earlier this month, Southwest Airlines could have invoked the little monsters during a three-day weekend when it faced a severe shortage of flights.  Some pundits on the internet spread the false rumor that the slowdown was a strike created by pilots who refused to receive the COVID-19 vaccine.  The reality is less about the civil disobedience of pilots than the negligence of Southwest Airlines and its Information Technology systems.

According to the Southwest Airline Pilots Association spokesperson, “I point to how they (Southwest) manage the network and how I.T. supports that network.”  It seems the union has been complaining about the reliability of I.T. systems for over four years.  Company officials have not commented on the claims but based on the events of the long holiday weekend, it is easy to see how an outage can ground an entire fleet of planes.  

I understand why something like this could happen at a large organization.  The internal system which schedules flights is buggy or unreliable.  Debate within the organization happens, and a decision is made not to fix the system because the cost and inconvenience are greater than dealing with the flawed system.  The conscious choice to do this is called technical debt in the agile community.  It sits in the organization like a time bomb waiting to explode the business at the least convenient time.  I suspect that is what happened to Southwest Airlines. 

Having technical debt in your organization is like having a box of gremlins and tossing them into a swimming pool.  Bad things are going to happen.  It is why everyone in an organization needs to regularly look at technical debt and give it a serious evaluation. Otherwise, your organization will get grounded.  To avoid a horror movie corral the gremlins of technical debt, you will be glad you did.  

Until next time. 

Let Your Employees Work from Home

From time to time, I like to call out bad behavior in the business community.  I don't particularly appreciate doing it, but when people behave poorly or say things that need challenging, it is the responsibility of people like me to call attention to it.  This week, billionaire hedge fund manager Ken Griffin gave a speech at the Economic Club of Chicago and said young people are hurting their careers by not returning to the office.  I respectfully disagree and want to point out that a net worth of 21 Billion dollars does not equal wisdom. 

Mr. Griffin is hugely successful, and he has offices in Chicago, New York, and across the globe.  He has one of the most significant hedge funds in the United States, so when you have that level of wealth and power, people like the Chicago Economic Club are going to give you a forum to speak.  According to Bloomberg News, he said, "So for our youngest members of our workforce, I'm gravely concerned that the loss of early career development opportunities is going to cost us dearly over the decades to come." I disagree; if we work in the global economy, we need to think differently about asking people to work at a corporate office.  

Workers are going to time-shift working with teams in India and Asia.  Thanks to tools like Zoom, Microsoft Teams, and Slack, they do not need to come into the office to have those meetings.  In addition, people who work at home can avoid commuting expenses, and the savings in both time and money tends to increase productivity from the workforce.  Finally, the last 18-moths of work have proven that professional workers can do what they do from anywhere in the world.  

I suspect that Mr. Grifin is more interested in exercising control over his workforce than the personal development of younger people in his organization.  Why?  Because he runs a multi-billion dollar hedge fund and thinks it gives him absolute power over the people who are delivering value to his organization.  It is a common form of arrogance that the wealthy have regarding the people who work for them.  

Griffin can run his business, however, he chooses, but it is clear that it is a conformist place that stifles innovation and creativity.  I am confident he enforces a dress code in the office and likes to keep up appearances for his clients or competitors.  The offices he is eager to populate with his workforce are a stage to show off his wealth and power to future investors.  

Mr. Griffin then chides other CEOs for being soft because they are not mandating their workers to return to the office.  The reality is companies are struggling to retain workers because they want to work from home. The great resignation is a reaction to businesses that will not allow them to work from home.  Workers are voting with their feet, and CEOs are not being scared; they are smart.  The global talent competition is such that if you do not offer a hybrid model for working, your competition will poach talent from you.  

I have repeatedly said that workers are not resources, and treating people like machine tools who can be used up and thrown away is a recipe for failure in the 21st century.  Mr. Griffin's wealth insulates him from that reality, but that does not mean people like myself cannot call out his lack of vision.  It will only be a matter of time before that reality catches up with him or his descendants.  

Until next time. 

Dealing with the Darkness of Dependencies

As agile professionals, we learned early in our careers that agile is easy to explain but difficult to practice.  For instance, agile talks about individuals and interactions in the manifesto but does not discuss how to help a development team member going through a contentious divorce.  The manifesto also does not talk about deadline pressure or the weirdness of the project budget process.  Lewis Carroll, who wrote "Alice in Wonderland," said, "Between the idea and the reality lies the shadow." As a coach or scrum master, you spend plenty of time in the shadow.  Today, I want to discuss a particularity dark subject in agile: dependencies.  

The scrum guide is clear about the organization of work.  With the help of a product owner, self-managing teams should work with the business to deliver value in rapid increments.  Backlog items are created, prioritized, and worked on during a sprint.  If everything goes well, then the team should have working code to go into production at the end of the sprint.  It is a fantastic concept, but the organization of most corporate systems plunges teams into shadow.  

People outside the purview of the scrum team often control the web or database servers, and the group becomes dependant on others who have a different set of priorities.  These priorities do not align with sprint goals.  A developer or scrum master then wades through the politics of getting servers provisioned with the correct configuration and security permissions.  The experience is a hassle and often throws off the team's timeline, undermining the rapid delivery of value to the customer.  

I hate dependencies like this with a passion that borders on pathological, and it was a hatred that blinded me to mitigate these situations for five years of my career.  Once the rage and frustration wore off, I discovered that a dependency is a story in the backlog; if it is incomplete, the team can escalate to leadership.    

I worked on a project where the server team did not configure the webserver to allow Azure DevOps to deploy code from a pipeline.  It is a mighty cool feature from Microsoft and saves loads of time deploying code to different servers.  One day a sprint ended for my team, and the server team did not configure the webserver.  Instead of showing code in a development environment, we demonstrated the software on the test environment, which returned an HTTP 404 error.  The leadership was scandalized and asked why nothing got done during the sprint.  I produced a work ticket with the need for the configuration of the server. The team shared e-mail messages, text messages, and corporate paperwork to get the server online.  We also showed that the server team did not respond to our inquiries for three weeks.  Based on this information, leadership made a few phone calls and addressed the problem.  The server team configured our server correctly the next day.  

The moral to this story is document dependencies in the product or sprint backlog.  The approach creates a quantitative technique to measure how long it takes people outside the team to complete work.  Transparency and openness are tools to help the team and its leadership better address organizational impediments. It works for small projects of one group or giant enterprise solutions with hundreds of developers.  

Dependencies are a shadowy subject, but if you document them in the backlog and are transparent about their impact on the project, you will have a way to overcome these organizational hurdles.

Until next time. 

Using Agile to Save an Organizational Shipwreck

The agile reformation has been my passion and livelihood for over ten years.  I strongly believe in making work more sustainable.  The global economy is highly complicated, and it takes intelligent and conscientious people to transform it one cubical at a time.  I spend my time writing extensively about agile and corporate culture.  Over the years, I experienced many of the ugly realities of being a business person; the lack of job security, erratic behavior from vendors and clients, regulators with good intentions, and plenty of colleagues who act in bad faith.  

The business world resembles being shipwrecked and trapped in a lifeboat.  After days of hunger and thirst, each survivor attempts to cannibalize the others or throw them overboard to the sharks to save themselves.  Rescue is elusive, and the ocean threatens to destroy everyone.  The agile movement is a friendly shore to find refuge.  Unfortunately, I see business organizations ignore this kind of relief and remain adrift.  I have given this plenty of consideration, and I have a few informed opinions about why organizations prefer to be shipwrecked.  

Inertia is a concept from physics, and Issac Newton first described it as the ability for an object at rest to remain at rest or an object in motion to stay in motion.  You expend energy to overcome the force of inertia.  In business, this energy equals the expenditure of time and money, which are precious resources.  The corporate culture of most organizations attempts to minimize the wasteful use of time and money, so inertia builds up and acts as a weight on the organization's ability to change.  People are content to avoid rocking the boat and terrified of risk, and being shipwrecked is preferable to rowing to safety.  

Fear is another factor.  Companies have to generate a profit and meet the expected profits of their investors, creditors, and shareholders.  It puts pressure on leaders to wring as much money out of the organization.  Lay-offs and outsourcing are necessary tools in this process.  What it does is create a level of uncertainty and fear in an organization.  It forces people to ignore inefficiency or waste because exposing it might lead to unemployment.  Thus, agile with its rapid cycle times and inspection heightens fear in the organization. People who are afraid have two choices;  they flee the company, or they fight.  It is the people who remain behind who throw sand in the gears of change.  To them, the status quo at an organization is preferable to changes that are threatening.  

Fear and inertia create a cycle of dysfunction within an organization.  I must also point out poor leadership as the third piece of the triad.  Those individuals struggle to keep promises and prefer hoarding information and resources.  You point out problems to this kind of leader, and they politely ignore them and often like to fire the messenger who brings them those problems.  It is about control for those people, and anything which is a threat is resisted.  Using the Pareto rule, 20% of your leadership team creates 80% of your waste and inefficiency.  Agile is good at finding these people, but out of self-interest, they will fight back.  

Combined, fear, uncertainty, and poor leadership create an environment deeply resistant to agile.  It is just like being lost at sea.  I will continue to educate and train others about making work more sustainable, satisfying, and sane.  With a bit of luck, more of the shipwrecked will find friendly shores.  

Until next time. 

Agile Cultivates Success

Software development is a strange world of science, technology, commerce, and deadlines.  Presently, the people who keep these robust systems working represent less than one-hundredth of one percent of the total world’s population.  It means we have more work than people who can do it.  The Wall Street Journal notes that it is creating weird situations in the job market and business community.  Leadership must change to meet this new reality.  I knew over ten years ago that the current path would not be sustainable and joined the agile reformation.  It was a strange decision, but it makes sense because changing the world requires traveling differently.

The online comic “The Oatmeal” has a fantastic cartoon about high school and popularity.  We sort young people into so many categories.  Elite academic and athletic starts float above the student body.  What remains are masses of students attempting to get by and find a niche in life.  Among their ranks are the hard rock kids trying to escape with music and drugs and striving theater kinds and band members using performance as a path forward in their lives.  Finally, there are meek and unknown people looking to find anything which might provide purpose and direction to their lives.  

The upper crust of sports and academics occupy leadership roles in many schools.  Teachers and administrators find these individuals and provide them a path to college.  I was lucky and singled out in this fashion, but not fitting in gave me a different perspective and approach to leadership.  High school became a fertile soil to grow a personality.  

I would spend college learning to run a newsroom, work at a radio station, and interact with very different people.  The time I spent preparing for a career showed me how to retrain myself when economic and personal conditions change.  Funnily, my exposure to liberal arts and media made me more adaptive to the peaks and valleys of a modern economy.  

Businesses need strange, creative, and resilient people to lead change.  More than ever, to solve complicated problems, we need individuals who see things differently. These personalities look at issues and try outrageous approaches to solving these problems: more freaks and geeks calling the shots and fewer prom queens and homecoming kings.  

I am very proud that the agile movement has these eccentric characters.  People who are attempting to improve diversity among the ranks of developers.  Project people who understand that nine women cannot create a baby in one month and leaders that get their hands dirty with the teams doing the work instead of giving orders with no grounding in reality.  Each day, they are attempting to rebuild trust in the business world.  It is a struggle, sacrifice, and frustration.  Nothing worth doing is easy.  

It is why you need to look for those people who don’t fit in and give them some room to make a difference.  Instead of promoting a rising star, make them a scrum master and work across the organization building teams and clearing impediments.  When you promote these individuals, they will be better equipped to lead others because, as scrum masters, they must lead without any authority.  Teaching people to lead without authority is going to be an essential skill in business.  Many problems today require collaboration and systems thinking instead of power and hierarchy.  It is why traditional paths of leadership and looking increasingly obsolete.  

As a business person, success depends on looking at problems from a different perspective.  Organizations decouple leadership from authority.   Finally, collaboration is essential to solve business problems.  To find people who excel in these areas, you should direct your attention to the fertile soil of the agile movement and the colorful characters who make it unique.  

Until next time. 

 

Cheering on the Butterflies on Your Team

Working on large projects has a way of grinding down the best professionals.  The list of things to do is endless.  Deadline pressures mount, and technical challenges can take the most realistic timeline and transform it into a tar pit of despair.  I experience these emotions just as much as the next person.  Taking some time for myself this weekend, I stumbled on a metaphor that will help me manage the stress and strain which will build up over the next four weeks as I prepare to get ready for a new release.

Anyone who leads a team needs to learn how to tell stories.  The ability to tell stories helps you put situations into context, inspire others, and make the bad times less terrible.  Good leaders know how to read the team and what stories to tell to help them get to the next point.  Over the years, I have collected some of the better stories from literature and philosophy to help make sense of the chaos that swirls around me as a technology professional.  

After a relaxing weekend with my partner, I watched her grown children participate in the Brookfield Zoo 5K race.  It is a casual affair where you will see parents pushing strollers around the race route next to runners looking to earn prize money.  At the start of the race, cheering people on, we spread out over the course to clap and provide support to our family members.  The runners appreciated the support from family and friends to a person.  The runners went a little faster and kept pushing, thanks to the encouragement of others.  As a leader, you need to be on the sidelines, helping push people to keep running and provide the support they need when tired or running out of energy.  

In many respects, a significant software project is like a long-distance race.  The difference is with a technology project, the endpoint is unclear, and the racecourse changes difficulty as the race progresses.  It is frustrating and can undermine the confidence of anyone.  After the race, the family and I decided to enjoy a leisurely tour of the zoo via tram.  Our driver mentioned that many species of animals and insects migrate as part of their natural behavior.  The monarch butterfly is one of those species.  A common misperception is that a butterfly will travel across the United States to Mexico in the space of a year.  The tour guide mentioned that it takes four generations of butterflies to make the trip to the breeding grounds in Mexico.  The butterfly in Minnesota will never experience the warm sun of Mexico.  It is up to the butterflies' descendants to make the trip.  

Throughout four generations of butterflies living, breading, and flying, they make the trip across the continent one flap at a time.  It struck me this is the perfect metaphor for a large enterprise software project.  Often, people come and go on the project doing necessary work and then moving on to other things.  What keeps everything moving forward is the instinctual desire to finish the project and the muscular memory of the organization.  A good coach or scrum master should support this process and make sure that work gets done.  An agile leader should also point out that it will take numerous people to work together over long periods to get the job done.  It is like standing by the side of the road and cheering on people you want to succeed.  

Until next time. 

The Virtue of Rest

It is the end of the Labor Day weekend in the United States, and I have been thinking about America's unusual relationship with work.  We are the most prosperous and productive nation on the planet, but there is a price to pay for this accomplishment.  Workers in the United States take fewer vacation days, and they suffer from burnout at a higher rate than other western nations.  If we want to continue being the leader in the world economy, we must have a conversation about the virtue of rest.  

Max Webber, in his book, "The Protestant Work Ethic," argues that America is uniquely situated to be an economic powerhouse because many of the founding members of the American nation came from the Protestant denomination of Christianity. According to Webber, since work provides people with dignity and purpose, creating wealth, capitalist societies' virtues are predominantly Protestant.  It is a nice counterpoint to Karl Marx and his thoughts about how economies fit into the culture.  

Today, America is more diverse than at any time in its history.  We have Christians of all denominations, Jews, Muslims, and Hindus.  It is also common to find Buddhist temples and neo-pagan shrines in many big cities around the United States.  It is a significant strength of our nation.  While we have many religious faiths, American workers have embraced the protestant work ethic first described by Webber, and I see it among the professional people work with each day.  

The notion that work provides dignity and purpose slots conveniently with the laissez-faire approach to our economy in the United States.  We have fewer vacation days and national holidays than other countries.  Labor laws are more favorable to business owners than workers.  Finally, any support for working families comes from private businesses instead of from a government safety net.

Lost in this situation was the idea that you should rest.  Olympic athletes need to rest between bouts and include recovery time in their training.  Lack of sleep has similar effects to being intoxicated with alcohol.  Problem-solving declines the longer individuals look at a problem.  Finally, constant pressure to perform creates stress which leads to health consequences.  The biggest paradox of productivity is that the more productive we try to be, the less effective we become.

It is why the labor movement pushed for a forty-hour workweek one hundred years ago.  It is also why banks are paying extreme salaries for entry-level workers.  People, to be productive, need to rest.  The agile principles explicitly talk about sustainable pace.  It is impossible to get work finished if the workforce is too exhausted to accomplish it.

I am a firm believer in Webber's Protestant work ethic, but without rest, it isn't very sensible, something we all need to respect on a Labor Day weekend.

Until next time.

Management in the Digital Age

Anyone who tells you that being a business person is easy has not spent much time in an office.  Customers demand more value, and the pressures of profitability squash and stretch the organization like a piece of taffy. You have to navigate market pressures, office politics, industry regulation, and deadlines as an individual.  Often these factors combine to create a toxic stew that undermines your sense of self.  It is why I embraced the agile reformation as strongly as I have.  This week there has been plenty of conversation in business literature about severe problems in the agile movement.  Jurgen Appelo is promoting a new book entitled “Agile 2.0.” As someone who works on the front line of the reformation, I have seen some of these challenges firsthand on the blog this week, I want to discuss them.  

This week, Steve Denning published an article in Forbes magazine proclaiming managers need a new job description.  He points to a 1977 Harvard Business Review article entitled, “Managers and Leaders Are they Different?”  The article is so popular that it has been reprinted twice since its original publication.  In the article, the author points out three characteristics of a manager in a business organization. 

1) The manager focuses attention on the procedure and not substance – it is more important to concentrate on how decisions are made rather than what those decisions are.

2) The manager communicates to subordinates indirectly by “signals.” - The only safe way to use procedures is to send indirect “signals” that obscure personal viewpoints.

3) The manager plays for time.  Self–protective routines are done up and down the hierarchy to avoid being on the wrong side of a decision.  

To anyone who has read the agile manifesto and understands agile principles, these three management practices are what we are attempting to overcome in the business world.  Self-managing teams were better than managers dictating work.  Playing for time disappears when you are working with the customer to provide value to the organization.  Finally, “signals” disappear when you are emphasizing individuals and interactions over processes and tools.  Software is eating the world, so the manager class should disappear as companies move from an industrial age mindset to a digital one.  

In reality, the frozen middle of the management class is alive and well in most organizations.  Banks, Insurance companies, manufacturers, and other businesses have existed for years, and managers have used that time to cling to the organization like barnacles.  Playing for time, using signals, and following procedures work for these people if they keep them employed and feed their families.  When faced with a new way of doing things, they react like saboteurs.

Thus we need a new style of manager who can succeed in the digital economy.  The first characteristic of a new manager is to embrace speed.  Instead of playing for time, they follow the cadence of a sprint.   Every two or three weeks, they release products to customers and hold others accountable for those goals.  It means getting out of the way of the teams when they are attempting to meet those customer needs.  It means learning to ask questions instead of giving orders. Finally, teams need to know how to self-manage, so scrum masters and the development team might need help and training.  

Instead of signals, leaders need to be clear with expectations, and those expectations need to be visible and unambiguous.  It is keeping with the principles of empiricism and transparency public for everyone to see.  Budgets should be transparent, deadlines and requirements should be obvious, and when the plan changes, it should be clear to everyone.  I suspect this will be the most challenging behavior to break because this stinginess with information is self-serving for an old school manager. 

Finally, a manager needs to be less concerned with the process and more concerned with output.  Daily Scrum meetings and sprint reviews are a great place to come up with new ideas.  An idea that originates with a customer or team is just as valid as something that comes from leadership.  We should embrace ideas from everywhere.  Ideas should be tested in public and held to rigorous standards of success.  For the sake of the business, reject ego and authority for outcome and value delivered.  

The management class needs retraining to reject old behaviors and embrace new ones.  Notions of process, signaling, and playing for time should be cast away for outcomes, empiricism, and speed to market.  Leaders and managers who embrace these new values will become agile digital companies.  Those who don’t will see their organizations sink to the bottom of the ocean encrusted in barnacles. 

Until next time. 

Keep Pushing

The life of a scrum master or agile coach contains plenty of ups and downs.  Some days, you have manic energy, and people recognize you are attempting to change the organization for the better.  Other days, you are depressed, feeling the structural problems of the organization crush the enthusiasm out of your body.  The business world brings out the bipolar characteristics of each person.  I am prone to those emotions as much as the next person.  Today on the blog, I wanted to go over the emotional labor we need to be a successful agile professional.  

I am a big fan of Western Philosophy and have devoted numerous blog posts on how different philosophical schools of thought parallel the agile reformation.  I have talked about existentialism, stoicism, the pragmatic nature of agile, and how Heraclitus and his ideas about change affect how we should look at agile.  What has always fascinated me about philosophy is the branch known as ethics.  It is the study of how to live a good or positive life.  Over the last few years in business, I have relied on philosophy to understand what motivates other people and ethics on how to conduct myself when under stress.  

It is a delicate balancing act when you care deeply about something and the daily stress of achieving that something piles up.  The existentialists often talk about how emotions are intentional.  We cannot control the outside world, but we can control our emotional reactions to the outside world.  The stoics also appeal because they teach nothing is ever as good as it gets, and nothing is as awful as it seems.  Both schools of thought offer a healthy dose of wisdom when things time tough in the office. 

Lately, I have been reading the works of Albert Camus.  Since the start of the COVID-19 pandemic, many people have read his most famous novel, "The Plague," which describes the outbreak of pneumonic plague in Algeria.  In the book, we follow the story of an Algerian doctor as he attempts to treat the sick during the attack.  We also see how others react to the suffering and death as the plague follows its natural course.  It is a grim book, but it has moments of hope and decency when people step up to help others.  Camus had no illusions about people in times of crisis, but in the end, he supports the idea that our essential humanity comes through when we help others.  The Plague is one of the reasons Camus earned the Nobel prize in literature.  

I am a big fan of Camus's essays, particularly "The Myth of Sisyphus," where he compares the human condition to the Greek myth of Sisyphus.  The gods punished the Greek king Sisyphus to spend eternity in the underworld, pushing an immense boulder up a hill.  When the boulder reached the top, it rolls down to the bottom, and Sisyphus begins the process again. I look at "The Myth of Sisyphus" as a metaphor for project management. It is both a metaphor for futility and human existence.  Humans toil for futile goals and face numerous setbacks to keep going. Often it is a struggle and toil with a brief moment of success before returning to effort and work.  Camus sees this struggle as heroic and says famously at the end of the essay, "one imagines Sisyphus happy."

In my darker moments, I understand the sense of futility that Sisyphus experiences.  What gets me through is that each day I have a goal to push the metaphorical boulder up the hill.  Each day, I have a chance to make a difference.  It is the slow and steady work that is part of the life of many professional people— the grinding of work and the friction of helping others to collaborate toward a common goal.  I use the story of Sisyphus to explain why I do what I do.  It also helps me manage my emotions better because I can say that I moved that boulder up the hill a few more inches on my worst days.  I get to stand at the top of the mountain when I get the boulder to the top.  Finally, I get a few moments of rest when I walk back down to start the process over again.  It is the source of happiness in my life and why I keep doing it even during the worst moments.  

Until next time. 

Meetings Do Not Have to be Awful

This blog has covered the basics of user stories, spikes, and dependency management.  Each of these skills is necessary to be a good product owner, and scrum masters need to be familiar with them if they are going to coach their teams to success.  I believe that well-written user stories and an adequately managed backlog will make the development process smoother.  It will also make the development team deliver value to customers at a more steady pace.  However, even the best backlog and well-written stories will create questions and confusion, particularly on teams that are not co-located or segregated into silos.  It is a situation where a coach needs to step in and facilitate delivery.  

A common joke in the business world is that you can avoid a business meeting if people learned how to send comprehensible e-mails to one another.  The truth is communication by e-mail is often the least effective way to collaborate on a complex task.  Tools like Slack and Microsoft teams are popular because they provide instant gratification of text and instant messaging.  Video conferencing tools like Zoom and Google Hangouts offer the illusion of being in the same physical space to allow people to solve problems.  These collaboration tools are not perfect, but as more people work from home, these tools are necessary to enable people to work together.  

The global economy is complicated, and the systems which keep it going require more expertise than one person can acquire. Hence, meetings are a necessary evil of the contemporary business world.  Since we spend so much time in meetings, it is up to agile professionals to make sure those meetings are productive.  I wanted to share a few tips to make those meetings more bearable for everyone involved.  

First, a meeting should only include the bare minimum of people needed to decide to get work done.  It is similar to the two-pizza rule which Amazon made famous.  Thus, if you are having issues with data in a database causing errors in a restful web service when you gather people together for a meeting, have representatives from each team who can do the work attend.  Have team members work together to fix a problem collectively rather than write up a defect and have it vanish in the product backlog.  I was borrowing heavily from the notion of mob programming because of lingering problems with differing priorities.  When you bring people together and give them apparent issues to solve, it creates a focus level that allows others to solve problems. 

Next, each meeting should have a simple goal.  If the team stays focused on that goal, the team will be more productive.   For instance, if the team needs to decide, any other discussion outside of the need to make a decision is wasted.  If a meeting is necessary for information gathering and consensus, then the forum's focus is different.  Keep the goal simple and make sure everyone knows what that goal is so the team can accomplish it. 

Finally, tune out distractions and focus during the meeting.  It is difficult to ask others, so lead by example by turning on your camera, putting away your phone, and avoiding muti-tasking.  Keeping the team focused will make the meeting go by faster.  Limiting distractions will also allow the team to concentrate on the meeting's primary goal, which should be part of each meeting agenda. 

One of the vital principles of agile is that face-to-face communication is the preferred means of exchanging information.  Meetings with the bare minimum of people, a clear goal, and few distractions are ideal for this principle.  The proper facilitation of meetings will make them less awful.  It will also help break down the silos which make your organization less agile.  

Until next time.