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.