Tuesday, April 13, 2021

Two Leadership Themes

My leadership will keep on sailing.

I spend plenty of time with other professional people.  We often discuss many subjects, and we often talk about our family lives, careers, and what motivates us.  Occasionally, we talk about deeper topics, but the main topic of our conversations is leadership.  How does a person lead a group of people?  What does a leader do when faced with incompetence or insubordination?  Today, I want to discuss my feelings on leadership.  

The main focus of my career is helping others avoid the mistakes I have made in my career.  I want people to avoid the hardship and disappointment I have encountered during my adventures working as a software developer and project manager.  Failure is the best educator someone can experience in a career.  I want to share the hard-earned wisdom of failure with others so they can avoid the roadblocks and setbacks I have encountered.

Along the way, I have discovered two main themes which have guided my leadership.  The first is servant leadership.  I was exposed to this as a teenager with the help of Marine Corps JROTC.  I discovered leadership is lonely.  It required being a servant for the people you lead.  It also forced me to put my needs on hold while things got done.  I gravitated to leaders who practiced this ethos, and it further shaped me as a person and leader.  

The other is the discovery of Kim Scott and her book Radical Candor.  Her writing and efforts' central thesis is that leadership requires a combination of honesty and empathy to be successful.  Truth without compassion is obnoxious aggression.  Empathy to hide the truth is ruinous.  Kim Scott brings plenty of experience to her writing, and it is bracing to hear her talk honestly about her mistakes.  

I combine Radical Candor and servant leadership to guide how I work with others.  It is not a straightforward approach, but it has given me tremendous satisfaction over my career length.

Until next time.


Monday, April 5, 2021

Foucault and the Power Inside an Agile Business.

 Foucault can teach us a few things 
about power and agile.


When you work as a professional person, objectively, your life is better than many others.  You work in environmentally controlled conditions, you get paid more than most workers, and you have the social cache of being an office worker.  In reality, being an office worker has plenty of risks.   Professional people do not unionize, so they are fired “at will.”  White-collar workers deal with high levels of stress and deadline pressure.  Finally, many of your colleagues are damaged, neurotic, or plain mean.  The reality of this situation should not be happening, but it often does. I was thinking about it more seriously this week and decided to write about it. 

As a professional person, I spend most of my time on LinkedIn learning about industry trends, keeping tabs on my colleagues, and finding informative bits of information.  Ville Pellinen posted an interesting nugget this week when he shared the satisfaction survey results from the banking and investment firm Goldman Sachs.  The news was a damning inditement of the company culture.  See for yourself.  

Employees were working on average 96 hours a week, and they were suffering physical and mental health problems because of the pressures to perform.  Managers were not respecting mandated time off over the weekend, and associates were expected to make last-minute changes to presentations and reports up to 20 minutes before discussions with clients.  As one associate said, “ What is not ok to me is 110 to 120 hours over the course of a week!  The math is simple. That leaves 4 hours a day for eating, sleeping, showering, bathroom, and general transition time.  This is beyond the level of ‘hard-working,’ this is inhumane / abuse. “

Compare this information with the company mission of Goldman Sachs, which proclaims, “our people are our greatest asset…” and you can see a severe disconnect between what the company says and what it does.  It occurred to me that a few factors are forcing these employees into these abusive situations.  The first is the notion of workism. Derek Thompson from the Atlantic magazine says working long hours becomes an “arms race” between talented and hard-working people who want to advance their careers.  The next is Karl Marx’s theory of labor exploitation.  Business people know that they can force people to work longer hours for less money because their competitors do it, so they are forced to squeeze harder on their workforces.  The most intriguing notion came from one of the other coaches on the thread who shared a quotation from Michel Foucault.  

He said,

“He who is subjected to a field of visibility, and who knows it, assumes responsibility for the constraints of power; he makes them play spontaneously upon himself; he inscribes in himself the power relation in which he simultaneously plays both roles; he becomes the principle of his own subjection.”

In other words, there is no difference between the prisoners and the guards in prison; they have to live by the same awful rules of surveillance when they are together.  I then joked about if M.B.A’s are being taught Foucault in business school.  It appears that business schools in Europe are sharing Foucault and his unusual philosophy with the future masters of the universe in their business programs.  What do business people have to gain from a radical French philosopher with a colorful history?  

Foucault and all of his writing were concerned with two principal issues.  The first was power, not the power to control but rather the ability to influence.  Peer pressure, new forms of learning, standard means of coercion, and social factors all mix together to create power structures that influence how people think and behave.  This kind of power is what executives and human resources people label as corporate “culture.”  The other thing that Foucault is interested in is how people’s knowledge and perceptions change over time.  In his books, “The Birth of the Clinic” and “Discipline and Punish,” he shows our perceptions of hospitals and prisons have changed over the last 300 years. 

As agile professionals, we can learn plenty of wisdom from Foucault.  We have to see how power flows through an organization, including the less formal means of control like peer pressure.  Next, we need to know how those systems of power affect the people doing the work.

As Foucault says in “Discipline and Punish,”

"In a disciplinary regime, on the other hand, individualization is ‘descending: as power becomes more anonymous and more functional, those on whom it is exercised tend to be more strongly individualized; it is exercised by surveillance rather than ceremonies, by observation rather than commemorative account, by the comparative measure that have the ‘norm’ as reference rather than genealogies giving ancestors as points of reference by ‘gaps’ rather than by deeds."

We improve individual performance, but to do so, we need to exercise more surveillance, and the nature of the administration should be more anonymous than personal.  Employees are worried about letting their fellow team members down than upsetting the boss.  

Finally, we need to understand that the business practices that exploit people are just as destructive to the business because exploitation will extend to clients and shareholders.  People working 110 hours a week are no good to anyone and for a CEO to tolerate something like that is short-sided.  

So pushing people to exhaustion is not intelligent, and it is not agile.  Why people work long hours and tolerate abuse, and poor conditions need examination.  Finally, leaders need to look more clearly at their business and what it does to the people who work there.  The clock is ticking for Goldman Sachs.  

Until next time. 


Monday, March 29, 2021

Put a Spike in It

Spikes are part of agile.

People outside of the software business think technology is magical.  People compare developers to magical elves from the fairy tale "The Cobbler and the Elves." At the drop of a pin, developers can create solutions and generate mounds of money from their efforts.  The reality is different.  Software development requires smarts, but it also includes constant pressure to meet deadlines and frustration as you try to solve problems.  It is not magic. Instead, it is grinding work.  The most misunderstood part of that work is the prototyping, research, and analysis necessary to create working software.  In agile, we call this work a "spike," and we will discuss it today on the blog. 

When you first learn agile, you realize the product owner writes user stories, and the stories reside in the product backlog.  The team then pulls those stories into a sprint, and work gets accomplished.  When we look at that work, it typically falls into two main categories: user stories and bugs.  A user story covers improvements or new functionality.  A bug or defect covers broken behavior in the application.  These two types of product backlog items make up most of the work done by the team.  The approach worked well for the construction and maintenance of a project but was insufficient for research and development. 

The realization that analysis and research are not adequately captured in the product backlog led to the spike's creation.  A spike is a special kind of user story in agile.  It represents proof of concepts and research.  The output of a spike is more user stories that contribute to sprint goals. 

Here is an example of a spike:

[Spike] Research PDF creation from License form

As a developer, I want to understand how to create a PDF file once a customer saves a license file because this is an upcoming requirement. 

-Use a third-party tool to create PDF's

-Then, save PDF as an attachment and email it to the customer.

This is a spike!  The outcome should be a proof of concept and more user stories.

As you can see, a spike looks similar to a user story.  The only difference is the acceptance criteria are vaguer to make it possible to conduct research.  It is also clear some tangible learning must result from the work.  The person assigned the spike should do the research and then help the product owner write the other user stories to meet a future sprint goal.

During the daily scrum, the team reports on what it is working on and what they are learning.  The spike also explains why the group may be working on fewer story points than usual because the research is taking up the team's mental bandwidth.  Thus, the three main items in a backlog should consist of stories, bugs, and spikes. 

A spike helps the team track research and development.  Using spikes allows the team to explain slow-downs in work.  Finally, a spike enables the team to prepare for future work without blundering into a mistake.  Spikes are a helpful tool in your agile toolkit; give them a try and see what you can accomplish.

Until next time.

Monday, March 22, 2021

Spring Cleaning for Agile

Keep the dust off your agile practice.

Late March is a strange time.  The weather is getting warmer, but the conditions alternate between sprint sunshine and winter mix, which is a depressing combination of rain, ice, and sleet which can drive a person to insanity in the space of an afternoon.  It is a time of transition and a perfect opportunity to think about spring cleaning.  

Spring cleaning is a tradition in northern climates where people throw open their windows and use the fresh air to dust and clean up the debris which settles in the house during the fall and winter months.  My mother and I would dust every surface, clean the windows inside and out, and we would wax floors and shampoo carpets.  It seems we were constantly cleaning this time of year.  

Keeping the house neat and organized was always important to my family. The world of business should also think about spring cleaning.  A business person should ask about the clutter around the organization.  As an agile coach, you should survey the chaos and inefficacy in your organization.  Ask questions and find out what is working and what needs to change.  The agile manifesto says teams and organizations should be responsive to change over following a plan.  Having a spring-cleaning mindset allows you to see what should change and then make that change happen.  

It is never fun to do housework, but once spring cleaning was complete, the house always felt shiny and new.  Doing what is necessary for your business will give you that same feeling.  So take a look around, grab a dust rag and do some spring cleaning for your agile.  

Until next time. 

Monday, March 15, 2021

Action Items Make the Retrospective Real.

Henny Youngman
can teach us scrum.

The most fundamental activity in agile is inspection and adaptation to changing circumstances.  A retrospective is a principal tool used by the agile team to respond to change.  Over time, a team can get stale in using the revelations of the retrospective to improve.  As I continue to talk about agile basics, I want to highlight an essential part of agile retrospectives; action items.

Legendary borsht belt comedian Henny Youngman would tell a joke about a man who goes to the doctor and tells them it hurts when they bend their arm a particular way.  The doctor always replied, “Stop doing that.”  Behind the simplicity of this joke is a bit of wisdom.  We are often hurting ourselves.  Many of the things breaking the team often originate from the individual members of the group.  Patrick Lencioni called many of these injuries the five dysfunctions of a team: inattention to results, avoidance of accountability, lack of commitment, fear of conflict, and absence of trust.  Many of the issues which come up during a retrospective have their origins in these dysfunctions.  

Recognizing a problem is only half the battle.  Improvement happens when recognition combines with sincere effort to fix the problem.  A scrum master then steps in, holding the team and its members accountable for making the change.  

The following is an example of a dialog between team members.  The team is struggling with quality and defects rollover from sprint to sprint.  The retrospective points out this problem, and the group agrees to get better at quality assurance.  Someone points out a spelling error in form validation, and it lingers two hours.  

Scrum Master: “Did anyone fix that spelling mistake? It is defect-123.”

Developer #1: “What spelling mistake?”

Scrum Master: (checking the Kanban board) “The one we found two hours ago.  Who worked on that page?”

Developer #2: “I did last week.”

Scrum Master: “Cool, do me a favor and write a unit test and fix the spelling mistake.”

Developer #2: “Developer #1 has the branch checked out.”

Scrum Master: “Ok, Developer #1 gets to write the test and fix the code and do the commit.”  (points to Developer #2). “You can pair with them until it is done and meets the standard of care.”

Developer #1: “Ok, give me about thirty minutes.”  

Scrum Master: “Thanks, and let me know when you merge the code.” 

When fixing a spelling mistake on a web page, whether JavaScript or text, should not take a developer much time.  It will take longer to write a unit test and have someone review the changes.  It is up to the team members to point out these quick fixes and hold each other accountable.  On a more mature team, developer #1 and developer #2 would have taken care of the defect when first spotted.  The difference between the two scenarios is a significant improvement in code quality and fewer defects rolling over from sprint to sprint.  

Only through constant attention and friendly reminders to the team will they internalize the lessons from the retrospective.  It is up to the scrum master to be that force of change.  Action items are nothing more than commitments the team makes to change for the better.  Instead of reducing bugs, the team should strive for better quality, eventually leading to fewer bugs.  Unit tests will not reduce the number of defects in a system, but they will reduce and spot future flaws before they become embarrassing.  

Henny Youngman was right.  If the team thinks it is doing something wrong, stop doing it.  Taking action on an item from the retrospective will improve the team and save time and energy.  

Until next time. 





Monday, March 8, 2021

The Ugly Duckling of Agile Rituals

Get your ducks in a row with a sprint review.

The scrum guide
talks about how you should run the flavor of agile, known as scrum.  As part of the empiricism of agile the development team inspects and adapts depending on market conditions.  Some people feel that the most important meeting is the retrospective, where the team reviews how the sprint is going.  The sprint review meeting is the most important because the customer gets to see the development team's progress.  Today, we continue to talk about agile basics but take a closer look at the ugly duckling of scrum rituals – the sprint review.  

According to Scrum.org, a sprint review is when the scrum team presents the results of their work to customers and clients.  The meeting allows everyone to discuss how close they are to meeting product goals.  It can be as formal or informal as the team needs as long as it has three characteristics. 

The first characteristic is members of the development team should attend.  The purpose of this is to see how the customer or client uses the software.  For example, on a web application, the browser button allows you to go back.  If the page loads slowly, the user will instinctively click the "back" button.  The back button might change the application state of the data and corrupt information.  If a developer sees the customer's frustrations and challenges, they will program the customer's application in mind. 

The next characteristic is the sprint review should be led by a non-technical professional.  Non-technical people will use the application, so a non-technical person should lead the discussion.  The product owner or client should review the work and improvements to the software.  When this happens, it allows the client to experience the software as a typical consumer.  It also provides the development team with another perspective on how the software should operate.  

The final element is that the demonstration should be as close to a production environment as possible.  Plenty of things can go wrong when authoring software.  Often code that works on a local machine will break when promoted to a new environment.  It is why that code should be strong enough to be demonstrated in a testing environment as close to production as possible.  It avoids oversites of database connection strings, file pathways, and DNS entries not pointing to the correct settings.  It also exposes the team to the displeasure of the client who expects the product to work.  Host the product review in as close a production environment as possible. It will save you the financial and reputation embarrassment of a production failure. 

Having developers present during a sprint review, a non-technical person who leads the meeting, and has the environment as close to production as possible will make your sprint review informative.  A useful sprint review will inform the team retrospective and sprint planning.  It will also build trust between the software development team and the client.  Trust will be invaluable when things go wrong, which is inevitable in any software project.  

The sprint review is the ugly duckling of the scrum rituals, but if done correctly, it will make your agile process more robust and more resilient to change.  

Until next time. 


Monday, March 1, 2021

Navigating the Fog of Uncertainty

The natural state of projects is fog.

Recently, I have been focusing on the basics of agile.  Master those simple skills and rituals and it will make you a better coach and scrum master.  Today, I want to focus on something which is your constant companion in business: uncertainty.  The ability to deal with uncertainty, mitigate risk, and address the unknown are essential business skills. 

When project managers discuss uncertainty in a project, they are all the unknown factors that crop up.  There is no right way to understand all the nuances of a project until you begin work and experience them.  Plans are helpful, but they often rely on assumptions that do not exist.  A plan usually takes for granted the people doing the work are all the same and have the same training and experience.  A plan also assumes that conditions will not change throughout the project.  When confronted with the realities and nuances of a project, the plan often shifts or is discarded.  

It is why project people have come up with the term “cone of uncertainty.”  At the beginning of a project, the estimate of time can vary significantly.  If you are fortunate, completing the work may take a fraction of the time allotted.  Often, a project will run over time and budget because the team did not know the hidden factors involved in completing the effort.  As the team continues to work with the project, the uncertainty narrows, known as a cone.  As time goes on, the team has a more realistic understanding of what needs to get done to finish the work.   

It helps understand the cone of uncertainty because it provides a helpful guide for people outside of the project to understand what is going on inside.   Often the situation is more confusing, and I use the term “fog of uncertainty.”  When the problem is more confusing, and people are fumbling around looking for a horizon or clear direction.  Like backpackers lost in the fog, they are stumbling over the ground, walking in circles, and easily distracted by strange sights and sounds.  As a business leader, you will face these situations.  

When in a fog of uncertainty, the team will fight over which direction to take.  Each stumble could escalate into a major crisis.  Finally, deep anxiety will take hold, and it will undermine the effectiveness of everyone.  It is at this point that a project fails because its goals are most concealed. 

Just like hikers in the wilderness, there are some techniques you can use to avoid getting lost.  One of these methods is to rely on a compass to maintain a direction.  In a corporate environment, executives fill this role pointing people in the correct direction and providing landmarks for people to follow.  An executive cannot banish the fog, but they can provide help when necessary.  Next, the team can do rapid inspections and make sure they are not going in circles.  The developers can rely on known facts and then use them to build out where they go.  It is why database models and UML diagrams are helpful because they behave like maps for the team.  Small common-sense tricks and experience can make uncertainty manageable.  

As the team progresses, uncertainty dissipates.  When the path becomes more evident, the team can move faster toward its destination.  The skills they use to navigate through the fog are still helpful and will further create certainty on the project.  I find these techniques work well with a no-estimates approach or with story points. 

So to navigate the fog of uncertainty, use the tools of agile to find your way.  Do rapid inspections of work and adapt to changing conditions.  Use executives or clients to provide direction and guidance.  Finally, clear landmarks like UML or Data maps can help make life easier for the team.  Being stuck in fog is awful, but you will reach your destination by taking a few simple steps and careful navigation.  

Until next time.