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.

Epics are a Big Deal

Epics, like this hard drive from 1956, are a big deal.

It is easy to be philosophical about agile.  I do it and so do other bloggers.  We want to connect our vocation to broader trends in business and economics.  This week, I will concentrate on the basics of agile because you cannot be philosophical all the time.  Today, I want to focus on epics and what purpose they serve.  

According to the Agile Alliance, an Epic is a recent innovation.  Mike Cohn introduced the concept in 2004, and epics represent larger user stories the team cannot complete in a single sprint.  These kinds of stories are great placemarks to contain similar work.  Business people rarely understood user stories, but they often understood epics because they did not want to deal with too much detail.  A business person would not understand a required field validation for a web form, but they would understand when an entire page was ready to review.  The product owner would create the epic and then place the stories necessary to complete the epic underneath it.  It makes it easy to understand the hierarchy in the backlog, facilitating plenty of helpful discussions.  

When a client or executive asks when something will be ready, with epics, you can have a meaningful conversation about deadlines.  For instance, a data entry epic has ten stories with an estimate of three-story points each.  The team completes twenty-story points a sprint, so you can say with confidence that it will take a sprint and a half to do the work.  If there are similar epics, you can project out the entire length of the project. 

Epics do have a drawback; an inexperienced team or product owner will often use them as hampers to hold unrelated collections of stories.  If this happens, the scrum master or coach needs to step in to make sure epics deliver value and provide meaningful organization to the backlog.  Otherwise, an epic behaves like an empty closet, which can hide clutter when others inspect the backlog.  

Epics are a way to organize the backlog.  Epics also provide a helpful way to forecast out the development for clients, and the judicious use of epics even aides communication with stakeholders.  It is a good practice to use them in your backlog.

I look forward to hearing how you use them.

Until next time. 

 

Pragmatism is the Foundation of Agility

Agile can trace its ancestry to this guy.

I spend most of my life working with technology.  Each day, I rely on the interconnections of wi-fi, electricity, and software to provide me with a living.  Each day, I interact with professional people all over the globe.  It is an intellectually demanding career as I attempt to help others innovate and meet the challenges of the global economy.  It is a career grounded in the Agile manifesto and empirical thinking.  It is also a career grounding in the American philosophy of pragmatism.  Today, I want to discuss the influence of pragmatic thinking on the agile reformation.  

Pragmatism arose out of American Universities in the aftermath of the civil war.  Diverse thinkers like Charles Sanders Pierce, William James, and John Dewey outline the main ideas of this mode of thinking.  According to pragmatism, the truth or meaning of a statement depends on its observable practical consequences rather than any metaphysical attributes.  It became a famous school of thought and guided many of the reforms which were part of the progressive movement during the early Twentieth century.  Dewey, in particular, believed in the power of education to make America a better nation.  

Pragmatists are not motivated by lofty ideas or tortured trials of logic.  Instead, they are experimental, testing out the practical consequences of ideas and comparing them to each other.  Today, this idea lives in the agile manifesto when we say, “individuals and interactions over processes and tools.”  Each organization is an ecosystem with different people, processes, and challenges.  It means that coaches and scrum masters need to avoid out of the box solutions for each problem.  An early morning daily scrum may not be practical for a team divided between two time zones. It is up to the team and coach to find a time that works for everyone.  Current structures may prevent people from doing estimation well.  It is up to every agile professional to find a way to size work.  Sometimes it requires no estimates or using billable hours instead of story points.  Thus, each organization is different, and it is up to us to be pragmatic about how we work.  

It is possible to apply the principles and values of the manifesto without being dogmatic and inflexible.  We must adapt, inspect, and be transparent without decision making.  We keep saying working software is an accurate measure of progress because anything else is a waste.  The work of any good scrum master should be creating software that delivers value to a client.  

It is why I think that the Agile reformation has its roots deeply sunk into the fertile soil of American Pragmatic thought.  We want to see the practical consequences of our work and the value we deliver to our customers.  Each scrum master and coach inherits from the legacy of the early pragmatists.  I am glad I am part of this club. 

Until next time.  

Agile Requires a Different Kind of Leader

The office has not changed since the jazz age.

The American office has not changed much since the jazz age.  At first, they were modeled after the workshops of cloth weavers.  Soon clerical work was mimicking the factories which grew out of the industrial revolution.  Before today, an army of office workers manually copies documents, did spreadsheets by hand, and processed payments.  Seated at long tables, these workers toiled under the supervision of bosses who micromanaged and made sure work was compliant. An office worker from the 1920s may not recognize the technology of today, but they will remember the command and control structure along with the micromanagement.  We have been managing our businesses the same way for over one hundred years.  It is about time we change.  

I joined the agile reformation because I believed there was a better way to do work.  Countless overtime, unrealistic deadlines, bureaucratic structures that guarantee nothing gets done, and poor leadership is rife in the modern workplace.   I suspect that this kind of toxicity explains why the use of anti-depressant drugs has increased so much in the last twenty years.  I promised myself when I was in a leadership role; it would be different.  

I am now a business leader, and each day I struggle to keep that promise. One of the critical skills is approaching people with curiosity instead of judgment.  Another necessary trait is emotional control because when things go wrong, others are counting on you to hold it together.  Finally, coaching others means letting them make mistakes and learn on their own.  The last trait is the hardest because the client and customer are unforgiving.  

It occurred to me many people advance to leadership roles playing office politics instead of delivering solutions to customers.  Hiding information, having personal agendas, and authoritarian styles of leadership are natural in toxic work environments, and poisonous people thrive within them.  Spread it around countless organizations, and it is clear to see why the business has not changed much over the last 100 years.  It is why the agile reformation is so powerful; it exposes this toxic behavior and makes business more successful.  Toxic people hate that and in large bureaucratic organizations spend plenty of time strangling these initiatives.   

The elevation of different kinds of business leaders will signify the growing maturity of agile in the business world because, without these new leaders, agile will fail.  If agile will grow in the next twenty years, we need a different kind of business leaders.  Someone who embraces coaching, servant leadership, and grace under pressure is necessary for scrum to survive further into the twenty-first century.  We better get started.  

Until next time. 

The Authentic Self is the Only Self a Leader Needs

We are all a little weird,
might as well bring it into the office.

We spend plenty of time discussing leadership on this blog.  I have spent most of my life learning lessons from a colorful group of mentors.  I have learned from marines, casino managers, technocrats, and creative professionals.  I have also spent time coaching young people in speech and debate.  The other day, one of my former students decided to blog about her experience working as a grade school principal.  I strongly recommend you give it read.  Something struck me in her prose and it was her observation that each day you have to bring your authentic self to work.  

Working in a global business can be dreary.  I had experiences of managers taking stuffed animals off desks because they did not look “professional.”  I vividly remember a vice-president saying, “I want the rest of the business to treat us as professionals instead of propellor heads.”  It meant that nerf guns, plush toys, and pictures of significant others came off desks.  It was sterile and depressing. Under fluorescent lighting and open office plans, we muddled through writing software.  It was joyless.  

I remember a plastic dinosaur left in a planter.  An administrative assistant adopted the creature and put a ribbon around its neck for a little color.  Six months later an executive having a bad day wrote a memo and instructed security to remove the planter because it did not reflect the professionalism of the firm.  The subtraction of the dinosaur did not increase the company dividend or share price.  It did not win a new customer contract or improve company morale.  It was a petty exercise in authority and power.  The experience stuck with me.  

Since childhood, I have always been a square peg in a round hole.  I was bullied mercilessly as a child by my peers.  I spent most of my middle school years getting beat up by others.  It was only in high school that I learned to begin the process of self-acceptance which continues to this day.  I found refuge in speech and theater.  I learned discipline from JROTC.  Writing allowed me to express myself in deeply personal ways.  I was a weird kid but that weirdness informed my personality and made me the person I am today.  

I bring that weird kid into the office each day.  I do not take myself too seriously but it took me about 25 years to learn the difference between being self-deprecating and negative self-talk.  I idolize goofy people like Bill Murray and Ernie Kovacs but discovered there was a time and place to be goofy and when to focus.   I have the perspective of a journalist in a business environment and I like calling out non-sense when I see it.   Naturally, my career has been very difficult because I am not a cookie-cutter executive.  I speak truth to power which is difficult for people unaccustomed to hearing “no”.  No one would accuse me of being a sycophant.  

Today, people still consider me a little weird but I try to be loyal to the people I serve.  I want to listen to their concerns and needs.  I am willing to tell a joke or wear a silly hat if it breaks tension on the team.  I will make bets with my team for them to surpass themselves which explains why there is a video of me somewhere on the internet dancing to the song “Happy” by Pharrell Williams.  I work for an organization that lets me be my authentic self and it makes me a better leader.  Being vulnerable and authentic is what makes leadership work.  I remember learning the term “mask of command,” in college.  Over my career, I have discovered the mask falls away and in times of crisis, you are exposed as the person you are.  It is better to have others know you as you are rather than as you want them to perceive.   

Being a leader is a life-changing opportunity.  To be successful, you need to put away your mask and bring your authentic self into work.  The people you serve will respect you.  It is the only way to make this opportunity worthwhile.  

Until next time. 

Curiosity is Greater than Judgement

Avoid Judgement and Try Curiosity 

Leading others is never easy.  It takes emotional maturity, wisdom, and credibility with the people you serve.  It is easy to be judgmental.  You can treat people doing the work like inanimate objects to be used up and thrown away.  In truth, if you are attempting to innovate in a global economy, a leader needs a different set of skills.  

A common phrase in all types of coaching is to approach others with curiosity instead of judgment.  It feels counter-intuitive. Suppose you see someone who is always late or who fails to deliver results to clients.  It is natural to pass judgment on these people.  We might discipline them for delinquent behavior or give them different responsibilities because of their lack of performance.  It is a natural reaction to conduct in the workplace.  

As a leader, we often think of our business as a machine and the people who work in it as easily replaceable.  The reality is the people who work in your industry are messy and imperfect. People have families, romantic partners, and aspirations.  The employees get sick, have parent-teacher conferences, and deal with traffic and congestion.  

As a servant leader, you are working with people, and you serve them. It means trying to understand them rather than trying to fix them.  It is why most coaching emphasizes curiosity rather than judgment.  To understand someone, you need to be genuinely curious about them as a human being.  Your tardy employee may just need a later start time.  The underperforming one might need more training or guidance.  You will not know the answer to what action you will need to take until you understand why a person is acting the way they are. 

I struggled with this concept for years as a scrum master before I internalized it.  With judgment, I often got into conflict with members of my team because they were not doing their job or resistant to change. I could have saved myself plenty of grief if I approached those situations with curiosity. 

Change is often scary, and when money, position, and power are involved, people become defensive.  A coach approaching the situation from curiosity will understand those dynamics and work with defensive people.  Underperforming people are scared of being found out because it might cost them their jobs. Finding out why they are underperforming might expose them to training and development, which will help them improve.

Coaching from a curiosity approach is not unicorns and rainbows.  It means creating situations where people feel safe to discuss their messy lives.  It is hours of listening.  It will require money for training and development.  Despite all this time and energy, a person may not meet expectations.  Numerous disappointments will proceed victories.  It is hard work and a bit of a slog.  However, treating the people you serve with curiosity will yield more loyalty to you and the firm over time. The performance will improve. 

It is not an easy lesson to learn, but if you withhold judgment and approach people from a position of curiosity, you will be a better leader.  

Until next time. 

Constant learning begins with you.

It is never too late to learn

I have spoken before about how technology changes quickly and that to be successful you need to be a continuous learner.  A software developer has to relearn their profession every eighteen months.  When you lead these individuals, you should foster an environment of constant learning.  The global economy and technology field depends on the forward momentum of learning. 

The world we live in today is radically different from the start of the internet era.  Do it yourself videos are everywhere on YouTube.  Today, anyone with a video camera and an opinion can behave like a network pundit.  In the world of technology, the hacker ethos and open source community have won the debate about how enterprise systems should operate.  It is a world of open source, cloud computing, and mobile devices.  Business leaders are struggling to understand these changes.  

With change happening so quickly, it is easy to see how people can fall behind.  It is why there are so many training conferences, continuing education courses, and ongoing programs in business to keep the skills of professionals up to date.  It is why I continue to dabble in software development even though I spend the majority of my time in a coaching role.  It allows me to understand the challenges and opportunities that developers face each day.  It also gives me a chance to kick off the rust and stretch myself creatively.  

I am working with .NET Core technologies for the past week, and it has been a valuable learning experience.  Instead of XML configuration files, .NET Core uses JSON.  The Bootstrap CSS system is now on version four, and communicating with Restful APIs is like connecting to a database.  I felt like a child learning to program again.  I watched a few training videos on YouTube and made the typical mistakes someone learning does.  I also had the experience of satisfaction of getting something to work correctly hours of tinkering.  

Now when I am making technology decisions, I can make a more informed choice because I have worked with the systems in question.  It is a better approach than sitting passively behind a desk and waiting for a consultant to whisper something in your ear.  It is my experience that the best leaders are the ones who lead from a position of expertise and empathy.  These people understand the day to day struggles of the business and market forces they are facing.  

It is why I attempt to kick off the rust and do some programming.  I learn new things and do some programming.  I know new things, and it provides me with insights into how people I serve work.  To foster an environment of learning, you must be willing to learn new things.  

Until next time. 

Self-Care is no joke

Ike learned a few lessons about self-care.

We live in interesting times.  The economy for working people is a mess.  A pandemic is making it impossible for schools and businesses to operate in a typical fashion.  Finally, the social isolation necessary to fight the disease creates a feeling of anxiety and alienation.  Combine the above with the responsibilities of work and family, and you have a recipe for disillusionment.  I am aware of the privilege I have working from home and providing value to my customers remotely.  It is still challenging to maintain the energy and focus I need to get through the day. Exciting times are exhausting times.  Today on the blog, I would like to take about self-care.  

Servant leadership is difficult.  It ties up your energy and focus because you concentrate your time on others.  A leader can easily ignore their own needs and effectiveness.  Eventually, you fall into a cycle of failure as your body forces you to rest.  Eisenhower was famous for his chain-smoking and bouts of insomnia.  Napoleon struggled with hemorrhoids and gout.  The number of bankers who abused cocaine is too long to mention.  The physical ailments and addictions are a symptom of not taking care of your health. 

We spend time talking about success and accomplishment.  We often do not discuss the price people pay.  A leader is only as good as they are physically able to do the job.  Thus, it is crucial to take care of yourself because people are counting on you to be in the moment when they need you.  I am conscious of the reality that I have the privilege of taking care of myself.  I set my work schedule instead of having someone else do it for me.  I can work from home instead of at a factory, field, or construction site.   Compared with many workers, I have much more control over my day to day activities.  It means taking care of yourself is often a luxury that other people do not possess.  People with this privilege need to avoid squandering this benefit because others count on us to lead when times are tough.  

So here are a few things leaders can do to maintain health and improve their leadership.  The first practice all leaders should indulge in is getting sleep.  The global nature of the economy and the needs of off-shore business units means we need to sleep.  Software teams can be half a world away, and it means disrupted sleep schedules and plenty of early mornings.  I recommend seven to nine hours of sleep nightly.  When that is not possible, take naps so that your body does not do strange things.  According to doctors, a lack of sleep creates behavior patterns similar to drinking alcohol.  A sleep-deprived person has less judgment than a well-rested person, which makes the difference between success and failure.  

As for chemical substances, practice moderation, alcohol, nicotine, speed, and cannabis are legal and easily accessible.  Avoid using them because they can become addictive and act as a crutch during stressful times.  When I worked in advertising, I was staggered by the use of alcohol.  Most of the time, I ignored it, but often enough, someone would be drunk at an inconvenient moment, and disaster would follow.  Nothing is sadder than a middle-aged man slurring his speech during a sales presentation. 

Finally, detach from the office and expect others to do the same. It means not checking your e-mail over the weekend.  Do not bring your power supply home with you, so your laptop runs out of power.  It will prevent you from working long hours at home.  An e-mail in the middle of the night can wait until you get into the office.  We spend a third of our life working.  The other portion we spend sleeping.  Spend the remainder with family, friends, and loved ones.  Setting healthy boundaries is part of being a leader.  Playing with your children and taking a Saturday afternoon nap is a great way to recharge your mental batteries.  

The practice of self-care is not a luxury for leaders.  It is a necessity.  Get some sleep, avoid chemical substances, and detach from the office.  The people you serve will thank you. 

Until next time. 

The Agile Pirate

 

Where the wind and the sea take me.  

As a scrum master or coach, it is important to tell stories.  Stories can be used to explain abstract concepts and reasons for decisions.  These stories are just another tool to spread agile through the firm.  Today, on the blog, I want to talk about a story I often use to explain agility to an organization.  

I have been a big fan of the book "Teach Like a Pirate," from Dave Burgess.  It talks about the off-beat techniques one teacher uses to get high school students to learn.  It includes plenty of useful advice to maintain enthusiasm, deal with challenging students, and set up a learning environment that is accommodating. He uses the term "teach like a pirate" because it is a non-standard way to educate children.  I have taken Burgess's guidance and merged it into my coaching practice.   I have also authored a blog on how it informs my outlook.  

I learned a story in the press about Steve Jobs.  In 1983 the engineering team for Macintosh was struggling.  Jobs then brought the team to an off-site leadership meeting where he gave a pet talk saying, "it is better to be a pirate than to join the navy." After the weekend meeting, the engineers returned to Apple headquarters and raised a modified pirate flag over the office.  It was the traditional skull and crossbones with a twist.  Instead of a conventional eye patch, it has the Apple logo with rainbow stripes.  The flag would fly over the engineering building for Macintosh for over a year.  Jobs would point it out to visitors.  When the company celebrated its fortieth anniversary in 2016, Jobs had been dead for five years, but the pirate flag flew again; the buccaneering spirit he inspired in the organization still lingered.  I imagine his approval in the afterlife at this gesture.  

The story has stuck with me ever since I discovered it.  The pirate of Robert Louis Stevenson and contemporary Hollywood is a colorful rebellious creature who lives outside the rules of conventional society.  Pirates are outlaws beholden to no one but themselves.  A pirate is an ultimate survivor willing to fight and die for their shipmates.  It is a lifestyle that often ended at the end of a noose or the point of a sword, but while alive, a pirate was living a way of life that few people could imagine.

I do love the swashbuckling nature of pirates.  I also see it as an inspiration for the teams I serve.  I often joke the development teams are a merry band of pirates attempting to make a living on the high seas.  I encourage people to take calculated risks to innovate and please the customer.  It is not the precise control of a corporate environment.  Instead, it is the collegial environment of skilled professionals working nimbly and collaboratively for swift rewards.  

So here I am, leading an agile transformation and a group of talented people.  I did not expect this out of my career ten years ago, and certainly not when I graduated from college.  It is the life of a pirate, and I will go where the wind and the seas will take me.  

Agile Coaching Requires Walking Away.

The path of the righteous man requires walking away.

I have been focused on plenty of goals in my career.  I have spent time coaching teams and individuals.  Often, I have to work on projects and help the team turn them around.  Other times, I discover the more esoteric points of my job, like putting together training videos.  This week, I found another necessary part of my career.

I have been working with a large project for twenty weeks.  We went from getting nothing done to pushing releases every two weeks.  The developers were fighting with the QA people on the team, and morale was low.  This week, I walked away from the group and let them stand on their own.  It was a difficult thing to do, but if the team was going to grow, I had to walk away.  

Being a coach means that you have to make your role obsolete.  Teams can only improve with outside help for only so long, and then you have to step away.  The team needs to be able to grow and stand on its own.  Ziran Salayi wrote an excellent paper on this subject in 2019. 

Coaching a team is challenging and a profound emotional commitment.  Walking away from the team breaks emotional attachments, but it is necessary to help the team learn to improve without outside intervention.  As a parent, you place training wheels on a bicycle and run alongside to show them how to ride.  Inevitability, those training wheels come off, and the child learns to ride without adult supervision.  Along the way, the rookie bicyclist will take a few spills, but they will develop a sense of independence.  

Letting go and walking away is critical to the success of a team you are coaching. An organization coached correctly will take ownership of your instruction and bring them into new and more powerful directions.  For instance, if you impress on people the importance of quality, when you leave the team, the team should be eager to create their ways of improving software quality.  Leaving a team is like taking off the training wheels.

A good agile coach is like a character from popular culture.  It is the type of character who rides into a dusty town in the west to restore law and order, like Cleavon Little in "Blazing Saddles," or a mysterious woman who opens a chocolate shop in the 2000 film “Chocolat.” I take inspiration from Samuel L. Jackson’s character Jules Winnfield from “Pulp Fiction.”  At the end of the film, Winnfield abandons a life of crime and foils a robbery without firing a shot.  I am never going to be as cool as Samuel L. Jackson, but I do know how to exit.  Walking away from a team is not giving up on them; it is encouraging them to thrive on their own.  Walking away is part of being a coach. 

Until next time. 

It is never about you.

Serve others it isn't about you.

The best part of being part of the agile reformation is the community of supportive professionals who inspire each other.  I can rely on the experience and wisdom of thousands of people who are on a similar journey attempting to make work saner, sustainable, and satisfying.  Currently, I am training at Chicago State University to improve my credentials as a certified agile coach.  It is an excellent experience with people from all over the globe.  Someone from the Philippines has the same challenges I do when leading change.  It is always nice to know that we are all facing similar struggles and challenges. This week, I learned a rather important lesson, which often gets lost as we become more experienced in agile. 

 

One of the critical foundations of agile is the notion of servant leadership.  The best leaders often are those who see themselves as servants helping the people; they lead rather than viewing the people under their authority as people who serve them.  As you gain experience and credibility within the profession, it is easy to let the certifications, recognition, and respect go to your head.  We are scrum masters, and people look to us for advice and guidance.  It is intoxicating.  

The reality is that being an agile coach or scrum master is about service to others.  It is not about us and our journey.  We should remember that success in this profession is when others take the lessons we have learned and apply them to their challenges.  If we are doing our jobs properly, our wisdom will help build success for others.  We should celebrate the achievements of others and the growth of people under our charge.  Unlike other areas of business, being a coach or scrum master means taking the focus away from yourself and directing it at the teams you are working.  

It is nice to learn from others.  The most important lesson is discovering that to be a servant leader, you need to remind yourself it is not about you but the people you are leading.  It is a lesson worth repeating.  

Until next time.  

Dream the Big Dreams

Every Leader should have a dream

Like many scrum masters, I spend plenty of time learning new things about my profession.  I am participating in the Chicago State University, Certified Agile Coach program to brush up on my coaching skills.  We have been discussing a wide range of topics, from active listening to servant leadership.  This week, something struck me during class, and it was the observation a servant leader needs to dream big dreams.  You do not usually think about leadership requiring big ideas, but imagination is a necessary component if you are going to lead in a global economy. 

Begin labeled a dreamer is often considered a stigma in academics and business.   It implies a lack of seriousness and an inability to recognize the practical realities of the world around us.  To be a dreamer is to be either a rock star or a hippy.  I beg to differ.  People who are dreamers have a vision about how things should be.  Having the imagination to see things differently and the determination to make it happen is something that makes investors swoon and makes innovation possible. 

Being a dreamer is positive.  It looks forward and asks, “Why not?”  A leader replies, “Not yet,” when they hear something is impossible.  It is not mindless optimism; instead, it is a quiet determination to look ahead and see a better future.   In addition to seeing that better future, a servant leader needs to share that vision to provide meaning and purpose to others and yourself in this absurd world.  The ability to dream helps you gather strength in bad times and excel when the opportunity comes along. 

A dreamer is someone each organization craves because much of the business world contains drudgery and monotony.  People crave purpose and want to feel the effort they put in daily is worth the struggle, so a good vision helps fulfill this role.  As a servant leader, dreaming big dreams is necessary. 

Until next time. 

Failure is the Fertile Soil for Growth

Failure happens

A common theme in business writing is the mythologizing of success.  It is an easy narrative to promote.  People enjoy reading about the success of others, and wealth is always intoxicating.  The struggle, failure, and sacrifices necessary to achieve that wealth have a glossy sheen in popular culture.  For me, the most exciting part of the story is how others deal with failure and crushing disappointment.  It interests me because my career has numerous episodes of frustration.  A setback proceeded with each significant improvement in my career and life. Defeat is a teaching tool for me, and now I incorporate it into my coaching practice.  

I have made numerous references to how failure is an exceptional learning tool.  Instead of failure, I should barrow the mindset of Carol Dweck and her Ted Talk from 2014.  Instead of saying, I failed, I should say that I have not yet succeeded.  It is the classic growth mindset which motivates people to figure things out and improve.  It sounds noble, but it is difficult for people to do because it challenges an individual’s self-worth.  

Thus, I spend lots of time taking the sting out of the everyday failures and mix-ups which happen in an office.  It means being kind in moments where your lesser self would like to snicker.  It means saying, “not yet,” and “what could we have done differently.”  It is holding others accountable without being mean about it.  I struggle just like the next business leader, but I have noticed that people respond to this approach.  Instead of beating a drum, a leader needs to show the way and get a little dirty in the process.  

Failure is real, but how we react to it makes the difference between a fixed mindset and growth and continuous improvement.  I choose a growth mindset any day of the week.  

Until next time. 

Professionalism and Developers Part 2

Software Developers are not hooligans.

Last time, I wrote about the three main factors which contribute to a lack of professional behavior among software developers.  For management which does not come from the ranks of engineers, it can feel like you are attempting to organize a group of soccer hooligans.  The good news is there are some simple techniques you can use to improve the professionalism of these challenging employees.  

Since developers are creative and intelligent, a pivotal approach to leading them is to show them what to do and let them take ownership of the details and deliverables.  For instance, we had a client that need to track bakery ingredients.  I said we are required to monitor the elements in a database and that some restful APIs in C# should be able to do the trick.  The development team asked about how they would enter data in the system. I said that we should be flexible and we should use the technology we already have. With that information, the team constructed an AngularJS application that wowed the client and earned us additional business; because I left the details and deliverable up to the team, they took ownership of the process.  

Next, developers crave autonomy.  The reason they specialize is so they can have mastery over a subject.  The ability also translates into others, trusting them to do the correct thing technically for the project and the business. Ability becomes autonomy to a software developer.  Giving team members freedom is going to be a challenge to business leaders accustomed to micro-management, but it will pay dividends.  Set clear deadlines and then allow developers to meet them.  Reward success with more autonomy.  It will become a positive cycle.  

Another proven technique is to allow engineers to automate everything about their jobs they hate.  If they do not like filling out time cards, ask them to write a macro to do it for them.   Instead of scolding people for not writing release notes, have them use the git repository to generate the notes based on pull requests automatically.  I was amazed when a developer created a build pipeline, which creates an excel spreadsheet with unit test results.  I asked them why they did it, and they said it was because they hated to do it each time a build happened. 

Finally, dole out perks and privileges based on professional conduct.  Let people go home an hour early on Friday if documentation is complete, timesheets submitted, and the build is working.    Perks do not have to cost money, and they can be an excellent way to encourage more professional behavior.  

By rewarding professional behavior with perks, allowing engineers to automate parts of the job they hate, granting increasing levels of autonomy, and giving people the flexibility to solve problems, you are creating an environment where developers want to become more professional.  Software engineers are some of the hardest employees to lead, but if you follow my suggestions, it will be much more comfortable than attempting to control a bunch of soccer hooligans. 

Until next time. 

Professionalism and Developers Part 1

Developers see the world differently.

I have spent a long time working in the software business.  I was not very good as a software developer until I did it professionally for ten years.   Today, I still consider myself a mid-level developer in terms of skill.  What set me apart later in my career was the professionalism I brought to the job.  Documentation would get written, time cards would get filled out, and I spent a lot of time over-communicating with management and stakeholders.  As I moved into project management, scrum mastery, and leadership, I noticed that software developers struggle with professional behavior patterns, which other business professionals have internalized.  We should discuss this.

The subject of professionalism is a touchy one in software engineering.  If you look at the history of the profession, it is easy to see why.  Bill Pflegin and Minda Zetlin, in their book, “The Geek Gap,” points out business people and technology people see the world from two different frames of reference.  A business person wants to be likable and profitable.  If you are agreeable, others are more receptive to your product which you are selling.  Thus, business people are very focused on being likable.  Engineers are not concerned with being likable.  The most important thing for an engineer is to make sure things work.  An engineer spends most of their time wrestling with the rules of physics or computer science to get things to work faster, better, and more reliably.  Something works, or it does not, and this binary view of the world and their career is often disorienting to business people.

Next, developers since the 1950s have a deep affinity for counter-cultural movements.  Beatnik, Hippie, Anarchist, Libertarian, and Punk mindsets permeate the culture of programming.  The let it all hang out attitude of developers is similar to the approach of Jazz musicians.  Hair color or politics does not matter; what matters is technical ability and the respect it generates.  It is why we have engineers with “UNIX beards” because they honor other engineers for the work they have done, and they do not care what business people think.  Someone like this does not have to care about being likable because they build things that work and keep the organization going. 

Finally, developers are more creative and intelligent than the average business person.  Creative people are alienating to people who are not.  Creative professionals are deeply suspicious of authority and rules.  Combine these two factors, and it is natural to see how business people and engineers distrust each other.  It is also why engineers chafe at the rules, regulations, and notion of professionalism.  To the engineer, professionalism is the curtain that hides the inability to solve problems and make things work.

There are three key reasons why developers and engineers do not behave as professionally as other business people.  First, they see the world differently and judge their value from a different frame of reference.  Next, developers embrace sub-cultures that do not respect authority.  An engineer or developer appreciates accomplishment or skill.  Finally, developers being more creative and intelligent, often chafe at rules made by others.  These three ingredients combine into a perfect stew of unprofessional behavior.  I will talk about how to work with these realities in my next blog.

Look forward to seeing you then.

Until next time.

 

Motivate Others Instead of Bossing Them

Motivation is Powerful

The biggest challenge for a coach or leader is motivating others.  If anyone could do it, the world would be a different place.  Problems like hunger, climate change, and a properly fitting pair of slacks would quickly happen because people would want to address those problems.  In reality, we struggle with these challenges because it is hard to motivate others, and there is an entire group of people who want to discourage people from thinking there are solutions to these issues.  Motivation is getting people to swim against the current of conventional wisdom. 

 

Motivating others is a full-time job.  It requires the application of soft techniques of persuasion and other times the blunt force of human resources.  People want to feel useful and challenged, but often they settle for security and routine.  A leader needs to work with these messy people and give them a chance to rise to their circumstances.  I struggle with this because I come from a command and control environment.  I would discover later in my career; this approach does not work with technical or creative professionals. 

 

The global economy has shifted from building things to creating experiences, services, and ideas.  It is a complicated process, and it requires more than following orders.  It requires looking at things from different perspectives.  The creative process requires a sense of craft.  Finally, it demands that people look at problems and question established answers.  People who excel at these skills are rarely the type to follow orders.  

Because we rely on information and creativity more than ever, leaders need to convince people why things need to happen instead of what needs to happen.  Give a problem to a bunch of creative people and tell them why it needs solving; you will be surprised by the effort they will put into solving it.  Telling people why something is essential creates a common cause with the team.  Explaining the urgency and necessity gives importance to work.  People with purpose are better than those with a plan.

So as a leader, you need to show others where you want them to be rather than telling them. Act as an example by listening to others and avoid asking someone to do something you would not do yourself.  Support others as they struggle to come up with solutions and listen to what others have to say.   It is surprising what you will learn.  

I do not have a magic recipe for motivating others.  Each day, I do my best to explain why certain things should happen.  The team should be concerned with how it should happen.  Finally, try to be an example for others to emulate.  Motivating others is not an easy process, but if you can do it right, the results are deeply satisfying.  

Until next time. 

When Culture Eats Agile for Breakfast.

Bad Culture is like canoeing over a waterfall.

I am very fortunate to have family and friends who are into musical theater.  For an aging high school theater nerd, it is always fun to sing along with a show tune while driving.  The funny thing about musical theater since the Second World War is that it has tried to tackle social issues.  “West Side Story,” addressed gang violence and racism.  I remember “A Chorus Line,” exposing me to gay characters.  Finally, “Hair,” had a rock-and-roll soundtrack and a fiercely anti-war message.  Over the weekend, I was running an errand, and the family was listening to the “Hamilton,” Broadway cast album.  I had an unusual emotional reaction, and then I began to think about my agile journey.  

One of the essential songs in the show, “Hamilton,” is “The Room Where it Happens,” where the characters Alexander Hamilton, George Washington, and Thomas Jefferson make backroom deals and compromises to keep the American republic moving forward after the revolution.  It is an excellent song about power and the practical matters of running a country.  It is also an ironic song because Hamilton’s rival Arron Burr jealously wants to be in the room where those compromises happen.

I thought back to a previous position where my manager would joke that I attempted to drag the company toward agile “kicking and screaming.”  The last two years of my career were so frustrating because I would propose solutions and fixes, but because I was not in the room with the decision-makers, my expertise was ignored or actively discouraged.  I would even complain to my manager that I wanted to be in the place where the decisions occurred.  Naturally, when I had my exit interview, I cited the firm’s lack of agile adoption as the reason for leaving.  Looking back at the experience, I realized my efforts were not going to gain traction because the culture of the firm was not going to value agility.  It valued tenure and experience over actually getting work done.  The stock market has rewarded the organization appropriately.  I was never going to be in the room where it happens because I had not paid the twenty-year commitment of time and adequately ingratiated myself with the other leaders.  Shipping software and delivering value was considered a threat rather than a virtue in that organization.  

The rough learning experience helped me grow and develop as a professional, but it reinforced the notion that culture is more influential than agility.  A dysfunctional culture or organization is going to actively fight against agile because agile quickly exposes the rot in the organization, and that threatens the careers of people who professionally benefit from that inefficiency.  People will quickly ally against any change, which is threatening.  The 14th State of Agile report echoed this state of affairs when they said cultural acceptance of agile is lagging because of leadership, not understanding it, and the organizational culture resisting its improvements. 

It occurred to me that unless you have senior leadership working alongside agile coaches and scrum masters, the rest of the organization will continue to do what it has always done through the force of inertia.  Even if I were in the room for decisions, at the old organization, it would not have made a difference because the leadership would not have understood a word I was saying.  So as a coach or scrum master, pay particular attention to culture because if they do not value the agile manifesto or principles, you are going to paddling against the current.  If the senior leadership does not understand agile, then you might as well go over a waterfall in a barrel.  

Agile works, but if you don’t have the right culture, you are up a dangerous creek.  You do not need to appreciate show tunes to get that message.  

Until next time.  

Call out Trolls Before They Destroy Your Business

Spot trolls before they hurt your business

The biggest challenge in Servant leadership is working with the disinterested, dishonest, and disrespectful.  Each organization harbors these individuals like weeds in a field of grass.  People like this seem to revel in their bad faith efforts to undermine others, avoid work, and act as parasites to everyone around them.  Throughout my career, I have confronted these individuals, and it never gets easier.  We should be brave enough to call out poor behavior.  

I spend plenty of time on LinkedIn. It is an excellent service because I can catch up on colleagues, get the latest news from the business community, and many of my fellow travelers share information about what is new. I was surfing along and read the following post from a coach and scrum trainer. The emphasis is mine.  

“I am a project manager having 15 years of experience and 5 years exclusively in project management. I do hold a PMP certificate too. My company is adopting Scrum-based delivery and it seems there is no role for the project managers. There are 3 roles in Scrum but none of them is for me. 

I can’t be a Product Owner because it will get filled from the business/customer side. I am not hands-on so I can’t be a part of the Development Team.

Scrum Master seems to be a very junior role for me. Many Scrum Masters are just a part-timer or working previously as Team Lead/ Tech Lead etc. There was a point when these people were reporting to me on my projects.

I also have an issue with the Servant Leadership style. It is not that I am a command & control person and you can ask my colleagues. Everyone will say how good I am with empathy, situation leadership, and self-reflection. But servant leadership sounds to me either head of the Servant or becoming Gandhi and Mandela. 

What will you suggest? Should I look at some different roles if yes then which one? I have also heard a lot about Agile Coach though I don’t know much how is this different than Scrum Master.”

I had a lot to unpack in this message.  It is an excellent example of how NOT to do Servant leadership.  I have said in the past, that ego is the enemy of good leadership.  Additionally, Servant leadership is more about leading by example than attempting to behave like a saint.  Scrum mastery requires kindness, and it often requires going beyond the call of duty. 

Being a scrum master is not a junior role.  It is a managerial role with tremendous responsibility and little authority. You are the person in the Taupe blazer who must inspire others to get work done.  At times you are a therapist, and at others, you are doing code reviews.  Often you are a square peg in a round hole.  Scrum masters are not junior; instead, they are essential to the success of your organization. 

The arrogance associated with the post was very telling.  What made it shocking was that it came from an instructor from Scrum.org.  I could expose this individual, but that would make me no better a coach or scrum master.  I am sensitive to harassment and doxing concerns on the internet.  I want the satisfaction of calling out a troll and exposing them to shame and ridicule.  The reality is they do not care.  A troll does what they do for the attention and outrage.  Instead, I would rather point out the attitude of these people so that we can be on the lookout for this behavior.  People like this are going to hurt your organization, so it is best to make you aware of them and not give them a chance.  

I take a great deal of pride in what I do.  As I continue to advance my career, I do not want to forget where I came from and the lessons I gained along the way.  Being a scrum master and product owner is hard work.  Developers and people in the organization are under tremendous pressure to deliver value to their customers and organization.  In the global economy, we are all servants, whether we like it or not.  Insulting other professionals as junior or beneath you is not how you participate in the agile reformation.  It is a form of elitism that has sparked backlash around the developed world.  

Today, I wanted to call attention to an attitude that will hurt your organization.  It is elitist, and it comes from a position of arrogance.  Do yourself a favor, find these people, and make sure you never hire them.  

Until next time. 

The Road to Damascus and Agile

Enjoy this holiday weekend.

Each day millions of people go to work.  A person spends a third of their lives working to provide for themselves and their families.  In the modern economy, it means being adaptable and finding value in any situation.  It is challenging and filled with anxiety because, at any moment, forces outside our control could threaten our livelihoods.  With the upheaval caused by the COVID-19 pandemic, we should reflect on work and how it should be. 

I became a member of the agile reformation over ten years ago when I discovered agile could be a better way to work.  I was tired of the drudgery of a project which had no payoff.  Technology leadership exhibited the worse traits of authoritarian management, and your best was never good enough.  I felt something had to change.  Since that “road to Damascus,” moment, I have devoted myself to the agile movement.

The manifesto has four simple values and twelve principles.  Professionals have used this tool to help make work better and more humane.  Now we understand how to eliminate waste, deliver value, and improve quality without being callous or working people to death.  Along the way, I have grown exponentially and met plenty of great fellow travelers. 

As we settle in for a long weekend, take some time to relax and spend time with the people you love.  We have a global economy to rebuild and a business community to reform.  We need to put people back to work, and I look forward to being with you during the journey.  

Until next time and have a happy Memorial Day Weekend.