Give A Little Thanks to Help Your Agile Practice

Give thanks and let others
know you appreciate them.

The agile reformation does not happen by itself.  It requires numerous people working daily to deliver value to customers.  Scrum masters, product owners, and technical professionals come together each day and do the hard work of building new things.  It requires discipline and intelligence.  Each day, I am amazed at the new and innovative things the people I serve do.  We need to take time and express gratitude for the work we do for each other.  

The holiday season starts with Thanksgiving, which began formally as a holiday during the American civil war.  The Union was starting to turn the war's tide and hundreds of union and confederate dead were littered across battlefields from Pennsylvania to Georgia.  President Lincoln wanted to celebrate union victory but used the occasion to create an opportunity to reflect on what we were grateful for.  To our 16th president, being thankful and grateful was a means to unite a bitterly divided nation.  I like Lincoln’s sentiment; it shows his leadership was well ahead of its time.  

The Christian season of Advent and Christmas follow this season of gratefulness.  It is joined by the Jewish festival of lights and then Kwanzaa.  What unites all of these holidays is their focus on concentrating on what matters, especially during difficult times.  It is a shame that we need ethnic and religious holidays to remember this wisdom. 

As a coach, leader, or scrum master, it is up to you to let people know that you appreciate the work they do.  It is not touchy-feely goodness that inspires this sentiment, but detailed research by the Harvard Business Review and Forbes magazine.  Business researchers are discovering the common-sense notion of treating people with dignity can improve work performance.  A more humane office creates better results.  

Each day, I use the words 'please,' and 'thank-you.'  I refer to people by the names and pronouns they would like used.  I also want to pronounce the names of the people I work with correctly.  I have a funny-sounding foreign name, so I try to pronounce all the developers' names correctly.  It does not matter if someone comes from India or Chicago’s Oldtown neighborhood. You should be respectful of their name.  Respecting a person’s name respects them as a person and their culture.  Finally, before going home, try to meet your team members and thank them for a job well done.  I learned this at Harrah’s over twenty years ago, and it builds comradery on a team.  

The next few weeks will be a blur of work, shopping, stress, and COVID-19.  With all this flurry of activity, we should take time to express gratitude toward others and build respect, which will help us build a better day. 

Until next time.  

Emotional Effort is Required to Lead Agile.

Feel your feels. 

The software business is filled with plenty of highs and lows.  It is a profession filled with intelligent and mercurial people.  The trade is one of the few which resists automation because it requires humans to wrangle ones and zeros into something which mimics human thought.  You would think the people who work in this profession would be cold bodies of logic.  Instead, software developers are very messy and human.  Today, I want to discuss how we need to embrace the spectrum of human emotions that are part of the agile software development process.  

To learn how to write software, you have to have a unique mix of skills.  You need to understand the logic and how programming languages can execute that logic.  You have to learn how to be creative and manage levels of stress most employees never face.  Finally, you have to deal with frustrations and uncertainty because your first solution to a problem often does not behave as it should.  

The level of frustration combined with deadline pressure does something to a person.  If they seem grumpy or distracted, it is because they are attempting to solve a knotty problem.  When they are working, they are often trying to concentrate and focus.  Concentration is essential, so when someone interrupts them, the natural reaction is to lash out.  Spending time with computers and other inanimate objects creates a sense of isolation, making it hard to transition into social situations.  Finally, pride and ego issues come into play because developers want to look smart to their peers and valuable to the organization.  

Mix all these factors with traditional office politics and team dynamics, and it creates a complicated landscape for a coach or leader to navigate.  Spend time listening to people, both what they have to say and how they are saying it.  When a developer says, “I am fighting with a few bugs,” the tone of voice decides how you should react to the situation.

The office's pressure affects the team, home, and personal life can upset an individual’s balance.  A talented developer was having marital problems, and he quickly devolved into a weird and counter-productive spiral.  I squirmed as he shared very personal details of his marriage and its dissolution.  I should have been grateful that he trusted me enough to share those details.  Unfortunately, the team became front row spectators to their peer’s emotional disintegration.  It went from something which was a personal tragedy to a distraction for the entire team.  The kindest thing we did was take him off the team and work on independent projects.  It was what was best for him and the other developers at the office.  

The easy thing to do is fire the employee and not deal with the chaotic behavior.  Working with people is messy, and we should embrace that reality.  We welcome it because of the interaction of emotions, ideas, and people creates friction, generating the heat and light of new ideas.  A person I respect very much says, “you just need to feel your feels.”  

We need to respect and understand our emotions.  We also must respect and understand others' feelings if we are going to lead and coach them.  It is both the human and logical thing to do.  

Until next time.

Delivery Counts in Agile

You are successful when you deliver.

One of the most common misconceptions about agile is the belief most of the time and energy of an agile team is spent talking about creating software instead of building it.  Plenty of articles have been written about the subject.  I disagree strongly and this week, I want to talk about it. 

At the scrum gathering of 2014 in New Orleans, one of the Keynote speakers joked about deadlines not being real.  He said flippantly there is always another sprint and work is never finished.  The rest of the room chuckled because each of us had heard this sentiment echoed by a developer or testers.  I have said it myself in jest.  The truth is deadlines matter in agile.  If a team is not delivering software at a steady cadence then it is not a good team.  

The empirical nature of software development with agile demands the delivery of software for customers.  If the team is struggling to deliver a shippable increment at the end of a sprint it is up to the team during a retrospective to figure out how to do better.  Instead of solutions being imposed from above, it is up to the team to come up with answers.  

The team coming up with solutions to problems is called self-organization.  Experienced developers mentor junior developers.  Business people provide meaningful direction about how the software should operate.  In the middle of it, all is the scrum master who helps remove impediments and forcing the team to become better.  It is a process that requires plenty of conversation and experimentation.  The bo-product of these efforts is working software in a production environment.  It is why the agile manifesto says, “Working software of comprehensive documentation.”

Software professionals are not successful unless they are delivering value to stakeholders and customers.  In the consulting world, you are not paid if you do not ship software.  In the enterprise systems world, shipping software affects pay-raises and promotions.  Being flippant about being able to deliver working software is a lousy career move.  

The process of Scrum requires the team to deliver value to customers.  Each iteration the team does show off what the team has delivered and gives them a chance to prepare for the next series of work.  The customer sees each step of the way and they can make corrections if necessary.  

I am touchy about this subject because the accusation that agile does not deliver value has no merit.  An agile team delivers each sprint, and if they cannot they self-organize to find a way in which they can.  We still spend plenty of time talking about software but in the world of agile all of that conversation is focused on the delivery of working software.  

Until next time. 

Resolve Matters More Than Ever

Resolve is fun and difficult!

Four years ago, I wrote a rather glum blog in the aftermath of the election of 2016.  I struggled with plenty of feelings and the realization I had a skewed vision of my fellow citizens.  In that darkness of the soul, I over-ate and did some reflection.  Today, the election results are different, but I do not feel any big jolt of joy.  Instead, I feel a deep sense of resolve.

I said the following in 2016, “Even in darkness, we can find resolve and purpose.”  Today, I feel more committed to that sentence.  We are in the middle of a terrible pandemic, the economy is deeply dysfunctional, and political polarization creates a toxic brew of resentment.  Fixing these challenges is daunting.  I have naïve faith that collectively, we can overcome these difficulties.  I feel this way because it is up to people of good faith to do the hard work to help unify the country and deliver value to its people.  People like me.

I joined the agile reformation because I felt there was a better way to work.  The toil and struggle of working on technology projects could be fixed and agile with four values, and twelve principles showed the way.  It was easy to learn the ideas of agile but carrying them out in the real world is complicated.  You cannot host a meeting with a slide deck and expect people to start leading their businesses differently.  Agile requires technical excellence, servant leadership, psychological safety, and putting in the extra effort.  

The goal of agile is to make the workplace more satisfying, sustainable, and sane.  If people like myself can make work better for others, then we can slowly begin to neutralize the poison which exists in society.  People who can support families and who work in healthy environments are less likely to support authoritarianism.  I am working to make the world a better place, one cubical at a time. 

We are still in a dark time.  The world is not going to fix itself.  It requires smart people working hard to create reasonable solutions that people can embrace.  It is not going to be easy.  Agile and servant leadership will provide direction and purpose.

I look forward to continuing to lead change and help make work better one step at a time.  I am proud to be part of the reformation, and I hope you will continue to follow me as I share nuggets of wisdom I gather along the way.

Until next time.