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.

  

Don't Go Fishing in Jira

I am currently working on a gigantic project with over twenty software development teams.  It isn't straightforward and contains numerous surprises for everyone involved. Projects like this are emotionally exhausting and require focus and attention to detail which can humble the best professionals.  Along the way, I have learned a few things about myself and the SAFe scaling framework.  Additionally, I have discovered an anti-pattern which I need to expose to my fellow coaches and scrum masters.  

One of the base requirements of any project is to have a source control system to manage code and a kanban board to track user stories and defects.  The board can be as simple as post-it notes on a whiteboard or as complicated as an elaborate software package.  Like many organizations, our project uses Jira.  The company uses the tool to keep track of the numerous teams and the thousands of product backlog items completed each iteration.  I will not waste my readers' time critiquing the merits of Atlantasan's project management software.  You can find better discussions about the subject elsewhere on the web. 

What I have noticed is an ugly anti-pattern that is taking place on this large project.  One of the technical leads called it "Jira-fishing," and if you want to deliver value quicker to customers, it needs to stop.  Jira can help an organization or transform it into a bureaucratic cesspool of evil like any software development tool. If software developers or product owners engage in Jira-fishing, you are fighting corruption.  

Jira has a powerful feature known as linking product backlog items.  It allows a developer or product owner to connect other product backlog items to the original story.  So if you are building out a web service and the front-end developer will use it, you can link your story to the front-end developer's story and say they are either dependant on each other or related.  The feature makes it easy to track dependencies and establish relationships between different pieces of work.  Things become evil when multiple teams in the same repository create defects and "analysis" tickets that block other work.  A product owner or developer is "fishing" around multiple tickets to understand dependencies and stopping a work item. 

For example, we have a team building APIs, but another team is working on the database, and a third-team is constructing the UX/UI for the customer.  The front-end developer on the UX/UI team has a story to edit a record, and they rely on an API to work correctly.  For the API to work, the developer on the API team needs to have someone on the data team properly update the database.  During testing, the front-end developer discovers the data is not updating correctly.  Naturally, the developer or the quality person on the team creates a defect, links it to the front-end development team, and then assigns it.  The Product Owner on the development team is then aware of the fault and assigns a developer to fix it.  During debugging, the API developer discovered a database problem and raised a defect to the database team, and the process repeats.  For the Product Owner of the UX/UI team to understand what is happening, they have to go fishing through a minimum of three Jira tickets.  Each defect can have a different priority for each group, and the original story for the UX/UI team will not get completed during the sprint because of those dependant defects.  Timelines slip, and the customer does not see any business value.   

The previous example is a simple illustration of the problem.  I see stories that have taken sixty days to resolve because of numerous dependencies between teams. Deadlines are out of the team's control, and work is held hostage by another team that does not have the same priorities. To anyone who works in the agile or SAFe world, it is a prescription for anxiety.  

The easy answer to this problem is organizing the development team, so a front-end developer, API author, and database person work on the same team to address the original ticket.  Dependencies vanish, and work moves through the system in a smoother fashion.  The practical reality is that splitting up teams and reorganizing them in the middle of a massive project guarantees the project will go over budget and be late.  The team's reorganization won't work because it violates Brook's law which says, "adding staffing to a late software project makes it later.  If adding a new person to a late project makes it later, I will expand that postulate and say reorganizing a software development team on a late project will obliterate any reasonable deadline.  I call it "Wisniowski's First Theorem of Project Management." 

What is a coach to do when confronted with Jira fishing and dependencies which resemble a series of Russian nested dolls?  I always return to the notions of empiricism and transparency, which are central to agile.  The Product Owner must explain each link or dependency in the story along with the acceptance criteria.  It should look something like this below.  

This story is dependant on story 123 from the database team >> which depends on story 345 from the API team >> which requires a change request 678 from the claims team.  

The point is that the Product Owner and the team can clearly see the dependencies and mitigate them.  

Each day I have a standing meeting with product owners who have dependencies with my team. Next, it will become apparent where the dependencies are happening.  It is then up to the Product Owners or scrum masters to create a steering committee or scrum of scrums to address these situations.  Finally, when all else fails, get executives and stakeholders involved.  Often these individuals get in the way of progress with micro-management, but when priorities do not align and work is stalled, they can step in to clear out a blockage.  In most organizations, the Executive Vice President of Development has more authority than a product owner, so when the Executive Vice President asks why something is lingering for sixty days, it becomes a priority for the organization.  

Jira fishing is an ugly by-product of a large project with numerous dependencies.  It is also a symptom of agile teams which are not cross-functional.  To mitigate these challenges, make sure all dependencies are linked to stories and are explicit.  Next, create a scrum of scrums or steering committee to deal with those dependencies.  Finally, have executives and stakeholders get involved to break down obstructions to work.  I enjoy going fishing.  I don't want to do it in Jira. 

An Agile look at the Olympics.

The Olympics bring out the sports nerd in me.  I can sit for hours watching events I never get a chance to see.  I fell in love with curling watching the Olympics, and I never miss an opportunity to watch fencing when the summer games come on.  My fantasies of being an Olympic athlete are unrealistic, but I learn lessons of determination, leadership, and character from these elite athletes.  Today, I would like to share a few of those lessons.    

As a coach, listen to your team members.

Simone Biles was having concentration issues when she was qualifying during the games, but something was wrong when she got lost in the air during a vault.  Biles talked it over with the coach and said she could not go on.  The coach listened and agreed.  When someone comes to you with performance issues or problems with focus, the best you can do is listen.  Once you have heard someone out, take the best action for that person and the team.  I believe Biles coach did that, and Team U.S.A. won a silver medal.  

Being a champion is more than finishing first.

Kevin McDowell ran the race of his life in the Men’s Triathlon.  At one point, he was leading the race.  The cancer survivor gave it his all and finished the race in sixth place, the best Olympic finish by any U.S. male.  While running the race, he grabbed water for other competitors who could not reach it.  His battles with cancer and the sportsmanship he showed on the course make him a champion to me.  A person like that on your team is going to inspire and elevate everyone around them.  If you had to choose between winners and champions – pick the champions.  

Leave everything out on the field.

I watched U.S.A. softball play Japan in the gold medal match.  Everything which could go wrong for team U.S.A did.  One player hit into a freakish double play to end a rally.  When it was over, the U.S.A. won silver instead of Gold.  Pitcher Cat Osterman’s interview moved me after the game.  She said she left everything out on the field and was proud of the team. She encouraged younger players to stick with the sport and aspire to become future Olympians.  Your team needs to take pride in their work and do their best each time, even if the results do not lead to immediate success.  

Excellence is everywhere

We often have a skewed version of success.  Top salespeople sell more than others.  Broadcasters with ratings are more respected than those with personal integrity.  We value the winners who are the most visible and public with their accomplishments.  A person has spent years perfecting air pistol at the Olympics, someone has been weight lifting anonymously in the Philippines, and a mathematician peddled 85 miles for a gold medal.  The quiet dedication to craft and excellence is everywhere.  As coaches and agile practitioners, we need to encourage and recognize this kind of accomplishment. 

I have another week to nerd out about the Olympics, but the lessons will last a lifetime.

Until next time.