Don't Hate Agile, Hate Bad Agile

The internet is awash in pixels about the trend of “quiet quitting.” Plenty of talented people have sounded off on the subject online.  I do not think I can contribute anything more substantive to the debate.  Instead, I want to talk about another trend popping up on the web.  Many people are talking about poor agile implementations, and I think we need to discuss it.   

Agile is a growing paradigm in the business world, and as an early adopter, I have seen a few bothersome trends.  Allen Holub on the Continuous Delivery YouTube channel gave some strong opinions about agile and how it is failing organizations.  I am an outspoken critic of poor agile implementations and dark scrum, so when I heard Holub bemoan the state of Agile, I found myself chuckling along in agreement about most of the things he had to say.  

The first trend is the shift from technology professionals becoming agile advocates to project management professionals advocating agile.  It is a standard survival strategy for business people to pivot when they see changes in the market.  The cohort of PMP-certified professionals witnessed the changes in the market and then retrained to become scrum masters and SAFe professionals.  It is not an alarming trend, but they took the values from traditional project management and business leadership and attempted to dress them up with agile terminology.  The effect was the worst of conventional project management combined with the frantic nature of iterative development.  Not to over-generalize, but these people are dogmatic and accustomed to enforcing rules instead of the pragmatic delivery of solutions.  These people enforce laws and generate outputs, but customer value is an afterthought rather than a central focus.  

Next, business leaders feel that their problems will evaporate if they do agile instead of having an agile mindset.  Jeff Sutherland points out that agile and scum hold a mirror up to the organization.  It is then up to the organization to effect change based on what they see.  Often problems are hiding in plain sight.  Philosopher Slavoj Zizek calls this unpleasant part of human nature Unknown-Knows.  We can ignore evidence when confronted with it.  I have witnessed many business leaders act this way because they cannot effect change or feel the necessary change might impact them negatively.  A manager loves the rapid cycle times, feedback, and transparency that agile offers but only sees accountability pushed down to the teams as valuable instead of accountability, which percolates into the organization as part of the agile mindset.  I liken the situation to someone who wants to get into better shape but can’t seem to quit smoking.  

Finally, the licensing and training for agile professionals are creating what Holub calls “a priesthood that does not understand the scripture they are professing.”  I am a big supporter of formal training in the technology business.  The pace of change requires any good professional to relearn their job every eighteen months.  The proper training and curriculum by the various organizations like SAFe, Scrum.org, and the Scrum Alliance are exceptional at teaching the formal theory of Agile, but in the trenches work of delivering software is often ignored.  It creates a situation where people trained in this manner fall back on the processes they were taught instead of concentrating on the individuals and interactions necessary to get work done.

A classic example is my recent interaction with an agile coach with a PMP certification and SPC credentials.  This person never wrote a line of software or delivered value to customers.  The only experience they had was providing reports to upper management.  Suffice to say; they failed spectacularly.  

The agile reformation is over twenty years old and is starting to show growing pains as the initial enthusiasts become supplemented with careerists and ticket punchers in organizations.  Don’t hate agile; instead, let us hate the people diluting and undermining its effectiveness.  I fight that lonely fight each day. 

Until next time. 

Source Control and the Rookie Software Engineer

The summer months are a strange time in the technology business.  Executives and project people take vacation time.  It creates an anxious, lazy experience where work stops while people wait for instructions from people in authority.  The profession floods with recent graduates eager to impress and begin their careers.  I am always impressed by the desire of these new graduates to do good work and make a difference.  Unfortunately, I do not think that colleges, engineering programs, and boot camps are doing a good job preparing these individuals for the work world.  Today on the blog, getting entry-level developers to understand source control. 

During a daily scrum meeting, I welcomed some new developers to the team.  The scrum master scheduled a knowledge transfer session.  The team also created stories so the new developers could pair program with the more experienced engineers.  It shows a level of maturity on the team to which most agile coaches aspire.  In that moment of supreme confidence, I made a hasty assumption.  I asked if all the developers were comfortable with the source control system.  The scrum master pulled me aside and said that none of the new engineers had source control experience and that the senior team members would have to teach them the basics.  After the shock wore off, I thanked the scrum master and pondered how it was possible to have newly minted computer programmers and engineers who do not know how to use source control.

Reflecting on my education and subsequent technology journey, it occurred to me we train people to work as individuals rather than on teams.  The reason developers out of college do not understand source control because their training does not require it.  Assignments are small and self-contained, where a student learns to master particular skills like looping code, decision trees, or variable arrays.  Instructs have hundreds of students to grade, and plagiarism is rampant as numerous code examples exist online.  Checking code into and out of source control is unnecessary in an academic setting.  When those students graduate, they enter the world of enterprise systems and interdependent code.  Source control becomes a necessary survival tool in your career. 

A good understanding of source control should be mandatory if you graduate with a computer science degree.  Universities and colleges should set up source control repositories using open source systems like .git.  Students check out repositories for assignments and check them back in.  A teaching assistant can act like a senior developer doing code reviews, and then grades can be based on how easily the instructor can check out code and run it.  More advanced classes can attempt to work on mutual systems and learn how to avoid overwriting each other's work.  

This approach comes with a few bits of overhead.  Address security concerns need to, so students don't deliberately sabotage each other's work.  The numerous branches in the student repositories will need maintenance at the end of each semester.  Finally, instructors will have to manage their course work like an open-source project.  More graduates would understand the importance and necessity of source control if these factors were accounted for, making them more employable. 

As a coach and scrum master, I want a rookie developer to succeed and avoid the mishaps I experienced in this profession.  To be a success, all developers need to understand source control. 

Until next time. 

Cheering on the Butterflies on Your Team

Working on large projects has a way of grinding down the best professionals.  The list of things to do is endless.  Deadline pressures mount, and technical challenges can take the most realistic timeline and transform it into a tar pit of despair.  I experience these emotions just as much as the next person.  Taking some time for myself this weekend, I stumbled on a metaphor that will help me manage the stress and strain which will build up over the next four weeks as I prepare to get ready for a new release.

Anyone who leads a team needs to learn how to tell stories.  The ability to tell stories helps you put situations into context, inspire others, and make the bad times less terrible.  Good leaders know how to read the team and what stories to tell to help them get to the next point.  Over the years, I have collected some of the better stories from literature and philosophy to help make sense of the chaos that swirls around me as a technology professional.  

After a relaxing weekend with my partner, I watched her grown children participate in the Brookfield Zoo 5K race.  It is a casual affair where you will see parents pushing strollers around the race route next to runners looking to earn prize money.  At the start of the race, cheering people on, we spread out over the course to clap and provide support to our family members.  The runners appreciated the support from family and friends to a person.  The runners went a little faster and kept pushing, thanks to the encouragement of others.  As a leader, you need to be on the sidelines, helping push people to keep running and provide the support they need when tired or running out of energy.  

In many respects, a significant software project is like a long-distance race.  The difference is with a technology project, the endpoint is unclear, and the racecourse changes difficulty as the race progresses.  It is frustrating and can undermine the confidence of anyone.  After the race, the family and I decided to enjoy a leisurely tour of the zoo via tram.  Our driver mentioned that many species of animals and insects migrate as part of their natural behavior.  The monarch butterfly is one of those species.  A common misperception is that a butterfly will travel across the United States to Mexico in the space of a year.  The tour guide mentioned that it takes four generations of butterflies to make the trip to the breeding grounds in Mexico.  The butterfly in Minnesota will never experience the warm sun of Mexico.  It is up to the butterflies' descendants to make the trip.  

Throughout four generations of butterflies living, breading, and flying, they make the trip across the continent one flap at a time.  It struck me this is the perfect metaphor for a large enterprise software project.  Often, people come and go on the project doing necessary work and then moving on to other things.  What keeps everything moving forward is the instinctual desire to finish the project and the muscular memory of the organization.  A good coach or scrum master should support this process and make sure that work gets done.  An agile leader should also point out that it will take numerous people to work together over long periods to get the job done.  It is like standing by the side of the road and cheering on people you want to succeed.  

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.  

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.  

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. 

Use Clear Language in Agile

Clear Language Matters.

The business world is a strange place.  Being a white-collar professional is different from more traditional jobs.  A plumber fixes broken sinks, and a firefighter prevents your house from burning down.  You can explain these careers to an elementary school child, and they will understand.  In a global company, job titles are opaquer.  Business Analyst, Programmer Analyst IV, and Programmer Analyst III are popular titles.  You cannot explain to small children and most high school students what these job titles mean.  I still cannot tell the difference between a programmer analyst III and programmer analyst IV other than the paycheck.  The jobs are complicated, and the language we use is involved.  It is also a language that is easy to parody and creates confusion for people who have never experienced it.  As an agile coach or scrum master, it is up to you to make sure the language is clear and informs.

I began to think more seriously about this topic when Molly Young wrote a great article about “Garbage Language,” which crops up in business meetings.  Young exposes lots of phrases used around the office, including; level-set, key-learnings, and complexify.  It is a fun and nasty read which had me chuckling about the dumb things I have often heard in meetings.  It quickly became a divisive topic, and business people defended their use of language as a way to save time and communicate with peers.  To people watching the argument unfold, it seems like a pointless discussion about something which does not have much impact on daily life.  The truth is more complicated. 

How we use language is critically important. It is particularly notable how we use language at work because misunderstanding can cost millions of dollars, ruin reputations, and kill careers.  I also have a more fundamental reason for being careful with writing; I studied communications and debate.  My training required me to learn how to use language clearly to inform or persuade.  With either the written or spoken word, a communication major is trained to the level of instinct to use easy to understand language.  If you use jargon, acronyms, or business-speak, you had better explain it.  When someone is not telling the truth is better to call them a liar than to say they are “insincere.”  Unfinished work is not “In-process,” it is incomplete.   The lack of flowery language is the strength of people educated this way.

Clear and understandable language is excellent if you are a journalist.  In the modern cubical farms of most offices, clear and unambiguous language is fraught with peril.  The contemporary office contains mediocre people with big egos.  Power balances between office workers and executives are cavernous.  Finally, the uncertainty of working at a corporation means saying the wrong thing to the wrong person could undo a career that spanned decades.  Thus, using the phrase, “put a pin in this conversation,” is safer to say than, “you don’t know what you are talking about, and you should talk with me after the meeting.”  The phrase that forces me to grind my teeth is, “…it is what it is.”  It is a verbal surrender to the status quo, thinking, and justification for apathy.  I spent too many years hearing it muttered back to me like some zombie mantra. 

As a coach, be clear and informative with language.  Agile, Scrum, SAFe, LeSS, and Test-Driven Development contain plenty of acronyms and jargon; skip them.  It may be shorter to use TLA, but saying “Three Letter Acronym” is more easily understood.  I know I use the phrase “stakeholder,” often, but I still take time to explain its meaning.  Finally, be transparent, candid, and truthful. It is better to admit something is broken instead of “underperforming.”

So today, our learnings were to circle back and discuss the knowledge use of language from a ten-thousand-foot perspective.  My ask is that you internalize that precise language is a win-win and can build synergies in your brand. 

Until next time.

Be a Kind Scrum Master

The lonely life of a great scrum master.

It is hard to talk about being an agile coach or scrum master.  It is both an art and science.  The science understands computer programming and technical systems.  The art is listening to others and coaching them to address their challenges.  The profession is easy to learn, and it is a hard one to master.   Many of the aspects of being a good coach or scrum master appear to be touchy-feely skills and that is because the difference between a good and great scrum master and coach are those skills.

When I became a scrum master, I thought I understood the skills, and I would become a raging success.  My first few sprints squashed those delusions.  Teams have conflict, they confront deadline pressure, and individuals inside the group have messy emotional lives.  It is up to a scrum master to deal with all of these issues and more.  In the words of Kim Scott, “It is management and it is your job.”

It is a job that requires listening and empathy.  It means not only talking about agile but living the values of agile daily.  It is about courageousness when you are tired or scared.  It is about being focused when you are in your worst moments.  You respect others and their different perspectives when you want to tell them to take a flying leap — openness to the secrets and vulnerability of others and to try out new ideas.  Finally, a good coach or scrum master must show commitment to the shipping product and the people doing the work.  The values are hard to do which makes them more necessary to the performance of each team.

The business world has plenty of damaged, neurotic, and mean people.  These individuals were not born that way; the dysfunctional cultures of many businesses created them. Companies promote the mean because they appear to get work done.  Years of unrealistic deadline pressure, lean budgets, and lack of advancement opportunities created the neurotic.  For the agile community, this is what we face.

To counter the sickness which resides in the corporate office, the agile coach or scrum master walks a lonely road.  It is choosing to be kind over being snarky.  When they see exploitation, a coach needs to point it out.  Finally, it is doing the right thing when other people are not watching.  It was not easy which is why so few people are good at it.

If you are looking for an opportunity to create “healthy ownership” in an organization, a scrum master or agile coach needs to practice the values of scrum, they need to listen, to show empathy, practice kindness and do the right thing.  I continue to walk this path and I hope you join me.

Until next time.

The Profession of Software Development

Software developers are much like plumbers. 

The stereotypes surrounding software developers are numerous.  Sandra Bullock was the shut-in hacker in the 1990’s film “The Net.” The cast of “Silicon Valley,” embodied the “move first and break things,” ethos of the rise of Facebook.  Finally, the frat brother atmosphere of gaming companies is legendary. Software developers are many things, but not many people outside of the business consider them professional.  Today, I would like to take the time to discuss professionalism in software development.

Many of the things we use operate on code.  The turbochargers in our cars are computer operated.  Trains rely on computer algorithms to run on time.  We can shop for groceries from the comfort of our sofa.  The reason this is possible is the combination of increasing computer power and the work of smart people who write the software code to exploit that power.  It is a detail-orientated and challenging task.

Software development is custom work with little automation, so each piece of software is made by hand.  Each phone application or web site we see today began as a blank slate that needed data, graphics, code and business processes. Line by line, a software developer wrote what you see.  As the site became more complex Database administrators, user experience experts and network security specialists will add their contributions. It is like the manufacture of a hot rod with all the mechanics hammering out the individual parts and then attempting to assemble them into a working car.  The complexity and challenges are difficult for people who do not do it to understand. 

People understand the pressures doctors endure.  Each day doctors are making decisions that might affect the life and death of patients.  Attorneys are responsible for up to billions of dollars in money during civil suits.  In criminal trials, they have to power grant or deny a person their freedom.  Likewise, bankers must make an informed decision about how to invest and loan money to protect their depositors. Finally, teachers educate and look after the wellbeing of children.  Our culture understands these pressures and rewards a particular level of respect and deference to these individuals. 

Software professionals are in that gray area.  What they do is essential but it is invisible until something breaks. The story of the Boeing 737 is a tragic example.  Software developers compensated for an engineering flaw in the aircraft.  Given the time pressures, they were able to create a control system that prevents planes from crashing.  What was not taken into account was the way pilots would behave in critical situations.  The flaw in logic would cost the lives of over 300 people in airline crashes.  It also cost the CEO his job because people no longer wanted to fly on 737 aircraft.  No one knew what the standard of excellence for software was until planes began to fall from the sky.

The software profession has a youth bias; many of the contemporary programming languages have been around for less than twenty years.  Less than five-tenths of a percent of the entire world population know how to write code. Caucasians and Asian people dominate and it is an overwhelming male occupation.  The attire is comfortable, and software professionals are more interested in getting things to work than being likable.  Compared to other professionals, software developers do not look the part.

The trends above make the profession seem clannish.  The time pressure often forces these professionals to take shortcuts.  Finally, the skills are in such demand that compensation is a powerful incentive for people with mediocre talent to join the profession.  Taken together people outside the business see developers with the same respect as mechanics or plumbers. The funny thing is these professionals lack respect until we need them.  It is then we will pay big money to use their expertise and services.

So software developers deserve respect because they keep the contemporary world working.  The world runs on code.  It is a shame we needed planes falling out of the sky to understand that reality.

Until next time.

Agile Pushing the Limits of Productivity.

100 Years ago the Great War came to an end.

November marks the centennial of the end of the First World War.  The Western Front of Europe was a muddy ruin.  Germany transformed into a republic in the aftermath of defeat.  Communists took control of Russia, and the old order of world affairs, unchanged since the collapse of Napoleon, was turned inside out.  I doubt any of the survivors of the “Great War,” could imagine what the world would look like in a century.  To us, life during the First World War would look familiar.  Machine guns, anti-biotics, and automobiles existed and played an essential part in the war.  To people from that time, our contemporary world resembles science fiction with our smartphones, air travel, nuclear weapons, and medical advances.  One hundred years is a long time and the pace of change is moving swifter.  We live in an agile world, and we better start adjusting. 

If you look at consumption figures since the First World War, the United States and the rest of the world can feed, educate and clothe more people than any other time in human history.  We are awash in money, and the global economy makes it possible to manufacture more wealth today than at any additional time in history.  The main reason for this explosion of wealth and prosperity is twofold; first, technology and automation have made it possible to manufacture items at the cost of pennies, the other reason is productivity per worker has increased geometrically.  We live in a world where Moors’ law trumps Marxist theory or the wealth of nations.

It is possible to create products around the world with teams in India, Ireland, and the United States.  In a global economy work no longer sleeps as it can shift around the world.  Our communications and technology are outstanding.  The way we manage technology resembles the time of the Pharaohs.  Large groups of people were forced to collaborate, often against their will, to satisfy the desires of a monarch.  The management of projects has not improved since the pyramids.  Glance around a contemporary corporation, and you see projects being managed in the same primitive fashion.  Instead of whips and drums to motivate workers, spreadsheets and Gantt charts are used to keep the labor moving forward. 

Smart people gathered together to write the agile manifesto as a way to come up with a sustainable, sane, and satisfying way to do work.  Waste is slashed, and more value delivered to customers as a bonus.  It was a merger between the needs of the business community and how humans work.  The alliance is imperfect.  Dark Scrum and Fake Agile are everywhere.  The distribution of the productivity surge is uneven.  Finally, we have bumped up against the upper limit of automation and technological advancement.  The productivity figures for the last twenty years will reveal this challenge.

Modern corporations are the last vestiges of feudal culture in our current society.  Executives act like royalty and increasingly perpetuate their privilege through networks of wealth and education for their children.  Culture considers the middle managers or professionals who make these whims a reality waste.  Finally, we squeeze every drop of productivity from the people doing the work.  It is a cycle of abuse which is self-reinforcing.  It is also an obstacle to increasing productivity.

Agile and Scrum do not promise to get people to work faster.  Instead, agile techniques promise to interact with the customer in more rapid cycles.  Personal agendas, waste, and bureaucracy disappear as the people who do the work come in contact with the people who purchase the product or service.  It is a threat to the current way corporations operate.

The structure of a large global business is becoming an impediment to the productivity of the people who work for them.  If we are going to match the growth of the last 100 years, we must change how business works.  It is why I joined the agile reformation and why I continue to fight my lonely struggle to make work better.  I want my descendants to have the same wonder I have over the progress we have made in a century.

Until next time.

A Year in the Life of a Scrum Master

Sharpen the saw, regularly.

Any scrum master worth their weight in salt, should take time out of their busy careers and take stock.  The book, “Seven Habits of Highly Effective People,” calls this practice “sharpening the saw.”  It is a chance to review the successes and failures of the recent past and see if you have gained any wisdom along the way.  I do not do it as often as I should.  The last year has been a crazy ride, and I want to share with you a few things I have learned.

A year ago, I left LSC communications. I was profoundly unhappy and filled with rage and contempt.  During my fifth anniversary, my manager joked, “Ed has been dragging this organization kicking and screaming to become more agile.”  I was an effort I was often fighting by myself. I was self-medicating with alcohol and over-eating to deal with the stress.  I was also making below-market rates for my profession.  I took the first opportunity offered to me to leave.  Three weeks later, I was cast aside like a used piece of facial tissue.  It was a valuable lesson.  If an offer is too good to be true, it probably is.

In the first quarter of the year, I worked for a non-profit which wanted to become agile.  I was hungry for a fresh start.  I let my hunger blind me to some distinct realities.  The organization was not serious about agile.  The firm would not hire or appoint product owners.  The managers would not share power with their teams.  Finally, my immediate manager wanted me to shut my mouth and maintain the Jira board rather than coach.  The second lesson learned, do not let hunger blind you to a no-win situation, which will further stunt your career.

I would spend the summer months looking for work and keeping my spirits up.  I could not have done it if I did not have the support of my friends, my family, and an understanding girlfriend.  Jobs come and go, but when you die, the only people who will mourn you are the people who loved you.  It is doubtful your boss or the VP of engineering will show up unless you neglected to check your code back into source control.

Finally, when I had a new opportunity, I set aside my preconceived notions and took time to learn about what works for my client.  It is not a mistake that the creator gave each person two ears and one mouth.  We need to listen to others with a frequency of two to one.  Learn the names of your colleagues and their children.  Find out how to make coffee that everyone in the office will drink.  Learn where the pain points exist and find out if you can fix them.  Share the values and principles of the agile manifesto and then be an example for others.

Plenty of things can happen in a year.  I feel like a different person. I am older and a touch wiser.  I want to bring that knowledge to other software developers and agilests.  I am grateful you are along for the ride.

Until next time.

Death to Agile-Lite!

Agile has not jumped the shark if I can help it.

I have been working as an agile professional for ten years.  It is equal measures a lucrative and frustrating career.  Servant leadership is hard to teach others and practice, which makes it profitable.  It is frustrating because you are struggling against decades of entrenched thinking inside the business. Fortunately, I have an excellent personal support system and a sincere devotion to what I do.  We are moving into a new phase of the agile reformation, and I would like to discuss it.

Agile is gaining more acceptance in the business world.  Its use has turned around significant organizations, and its application at Microsoft is beginning to create mythology which jealous rivals want to mimic.  Many of these competitors wish to have the success which agile brings to a company without making the necessary behavioral and cultural changes.  In their mind, agile is something you do instead of a goal to strive.  You take a few management consultants in the organization, apply a random scaling network, and then watch the productivity jump through the roof.  It is a foolish short-sided approach to organizational change.

Jack Skeels writes a great blog on this trend in the business world.  People see agile working, and they want its benefits without making the necessary changes.  He calls this, “Agile is anything Management calls it.”  It is no different than working for a traditional organization, except you are working harder to deliver the same disappointing results.  Furthermore, disillusionment sets in as you find yourself working to satisfy the nihilistic and selfish goals of someone else.  Steve Denning has a more polite description of this trend.  He calls it “agile-lite,” which is “…the adoption and tools of agile without necessarily deploying them with an agile mindset.” It is like a cargo cult which will build faux airports out of bamboo and reeds with the hope cargo jets will arrive bringing wealth.

So, what is an agile mindset?  It is an understanding of agile manifesto and the principles of agile.  It is a growth-mindset which is willing to try new things to improve.  It is ruthlessly applying inspection, adaptation, and transparency to the organization.  Finally, it is expending energy getting work done instead of managing up the organization.  To be successful, it requires more than lip service.  You cannot install Jira in your organization and expect it to become agile instantly.  You have to do much more, and you will have to escape your comfort zone.

Agile is eating the world, and it is approaching its twentieth anniversary.  As this movement enters its third decade, it is up to all of us in this community to beat back fake agile and “agile is whatever management wants.” Plenty of positive change has taken place, but more needs to be done.  Otherwise, we will be doing agile instead of being agile.

Until next time.

Four Simple things

It can get lonely.

The biggest challenge as an agile professional is leading organizational change.  Often, you are a lonely voice in an ocean of indifference.  People do not like the daily routines and rituals disrupted, and agile professionals are doing it with frequency.  The resistance is a natural response to change.  Humans have a craving for stability in an uncertain business world.  The situation sets the agile professional up for isolation and loneliness.  I want to discuss the support system you need to overcome the adversity.

Being a scrum master or coach is a difficult calling.  It requires tremendous emotional labor, and you are attempting to overcome decades of resistance to change within an organization.  To be successful, you need to have a support system which will help you get through the rough patches.  Here is my formulation of that system.

An Understanding Significant Other

If you have a spouse, boyfriend, or girlfriend, they need to be understanding.  You are going to have unannounced late nights being with the team fixing production bugs.  As a servant leader, you will confront difficult emotions, and it will take you time to unwind from them.  It helps to have someone in your life who loves and respects you to listen. Finally, they should be willing to work with the ebb and flow that technology professionals encounter daily.  It is like being married to a police officer or firefighter.  The job always finds a way of intruding into the relationship.

A User group or Network of fellow Agilests

Many organizations do not have a large cohort of agilests.  It is why being a coach can be so isolating. It is why you need a regular group of people to meet with discussing current trends and new techniques.  It can be an online group or frequent meetup.  The purpose is to have a peer group which can provide emotional and professional support.  Often a problem you think is intractable is something someone else has solved.  The user group acts as a repository of information, a social circle of peers, and group therapy.

Support from Senior Leadership

Change does not happen, spontaneously.  Often, it requires outside events to force change or an internal mandate to make change happen.  An agile coach without the support of senior leadership is not going to be successful.  Cultural inertia is a common obstacle to change.  Often when you ask why something is done a particular way the response is, “…because we have always done it that way.” Senior leadership can give you a mandate and authority to improve a process.  Executives provide the nudge necessary when things need to change and when people dig in their heels.  Finally, senior leadership is a source of validation which makes the hard work and sacrifices worthwhile.

Allies in the Organization

As a firm moves along the agile journey, a coach or scrum master is going to gather like-minded people who are allies.  Organizational allies are gold to a coach or scrum master.  The people joining you will spread the message you are sharing. Associates will provide emotional and technical support.  Colleagues will support you during a difficult decision and join you for lunch when times are less stressful.  Cultivation of colleagues will keep the agile transformation going long after you have left the organization.

So to avoid burn out and isolation a coach or scrum master needs; an understanding significant other, a network of fellow agilest, support from senior leadership, and allies in the organization.  Without these things, an agilest will have a lonely run with an organization.

Until next time.

Agile, Story Points and Rock-n-Roll

The Crüe are very rock-n-roll and agile.

Being an agile coach is filled with plenty of touchy-feely moments.  You have to deal with difficult emotions and move change through an organization which is satisfied with the status quo.  Other times a coach or scrum master must deal with the practical matters of scheduling a meeting and facilitating a retrospective.  Finally, you are learning new things and applying them to your clients.  My vision of how story points work has changed over the years.  Recently, I am looking at story points in a new way, and it is good enough to share.

My first thoughts about story point made me think of them as measures of volume.  A story point contained a certain number of hours, and it would be easy to convert the two back and forth.  After my first 18 months of being a scrum master, I saw the folly in that way of doing things.  It became apparent that story points represented something analogous to distance.  An Olympic runner can cover 3,000 meters in under four minutes.  I can walk it in about a half hour.  Story points provided a quantitative way to measure uncertainty and help communicate to upper management.

Now I see a story point as the sum of four factors; complexity, risk, effort, and uncertainty.  We sum all these factors together and round them up to the nearest whole number in a Fibonacci sequence.

So if I wrote it out a math formula it would look like this:

Story Point = Complexity + Risk + Effort + Uncertainty
F_N = [Story Point]

Where F_N is a number in a Fibonacci sequence.

The new acronym for this is CRÜE, after the rock band Mötley Crüe.  By today’s standards, this giant of 1980’s glam metal would flame out in the public eye.  The band was nihilistic, misogynistic, and poster children for the destruction of alcohol and drugs could do to a person.  Finally, the lead singer killed someone in the act of vehicular manslaughter.  In spite of all the baggage, you could count on the band to put on a great show.  You could also count on them to be blaring out of any stereo at a house party during the 1980s. People of a certain age have memories of significant life events happening with Mötley Crüe playing in the background.

As an agile coach, I will let the young people concern themselves with sex, drugs, and rock-n-roll.  It is not my lifestyle.  I prefer agile, story points, and rock-n-roll.  If you are talking about story points, talk about Crüe; complexity, risk, uncertainty, and effort.

Rock on people and until next time.

Start Writing Unit Tests!

It helps when you test your code.

Software development is a difficult process.  It is filled with trial and error.  Developers must contend with vague requirements and impossible timelines.  It explains why the profession has a high failure rate.  I think we can do a better job and today I would like to discuss the easiest way to help reduce failure.

When I first learned about software development, the notion of software testing was primitive.  Often software testers manually went through the software attempting to find bugs.  It was a tedious and time-consuming process.  Automated testing began to pop up in the world of JAVA and then spread to the Microsoft world.  At first, developers chaffed at writing unit tests calling it extra work and unnecessary. 

After the initial resistance, the engineers and developers began to see the importance of unit tests.  Unit tests ensured the code functioned when checked back into source control.  It also made sure a change in one part of the code would not break a different portion of code.  Automated testing had another impact.  Manual testing became unnecessary and if freed up people to deliver more value in the organization. 

Automated testing not only cut back manual tests, but it also makes the release of software faster.  What usually would take three weeks to release could now take as little as three weeks.  Thus, automated unit testing reduced labor overhead improved the quality of software and increased the time to market for software.  Instead of chaffing at writing a unit test, the real question is why you haven’t started writing them.

Until next time.

More difficult than crayons

Crayons are easier to create than software.

When you spend your career helping people deliver software, it quickly becomes apparent that the biggest challenges you face are not technology problems.  The biggest challenge is working with messy people.  Machines can make pencils and crayons by the thousands each hour, but before that happens, someone has to design the product for manufacturing.  The people who do this are engineers and product designers.  Software relies on Scrum Masters, Product Owners, and software developers.  The creative process is the same, but it is much easier to manufacture crayons than software.  Today, I will try to answer why it is so hard to write software.

Software has only existed since the aftermath of World War Two.  The first documented “bug” was a moth which died among the vacuum tubes of the first computer.  In spite of technological advances, the way we write software is still primitive.  Developers continue test code on local machines and then push that code to remote servers to see if they work.  Testing is manual, and the ability to automatically push code through the web or large enterprises is limited.  The software craft movement is making progress in this area along with the DevOps movement are helping with this antiquated process, but it is still a long, tedious trudge to get software written.

The key adverb here is “written.” The writing of software is a creative process.  People take the vague directions of others and translate it into web pages or client-server applications.  Unlike traditional prose, software contains code, markup, and data.  The disciplines working with each is different and filled with plenty of nuances.  Business people compensate software professionals generously because it is such a rare skill to cultivate.  Developers are also under tremendous pressure to ship code and work long hours to do it.  Imagine, Earnest Hemingway, attempting to write “A Farewell to Arms,” with management standing over him demanding updates each day. Furthermore, imagine the Nobel laureate is required to write one character’s dialog in English, another in Spanish and finally hexadecimal code for each letter on the page for a different character.

If the above was not challenging enough, the people paying for the creation of software are not actively involved in its production.  Software projects often begin with a problem which does not have an answer.  A marketing executive blurts out, “I need a client website!” or a Human Resources professional asks if it is possible to manage timecards online.  The business set aside money hired consultants to do the work, and begin writing software with no idea how it should work.  Agile fixes this problem by requiring rapid time boxes.  Often, lack of participation and vision from business partners thwarts the benefits of agile.

Combined with the difficulty of writing software and the apathy of the people how to pay for the software, the final challenge is the hypercritical nature of everyone who cannot write software have for the people who can write software.  It is similar to the Austrian Emperor mocked in the movie Amadeus whose only criticism of Mozart’s opera is, “There are too many notes in it.”  Many people have opinions about software and provide critiques, which is either nitpicking or unhelpful.  As a developer, a color pallet I used for an application caused controversy, and we spent countless meetings reviewing color chips.  It extended the life of the project by three months and made it over budget.  In a different episode, punctuation on a page sparked hundreds of revisions and emails.

The reality is like a committee of proofreaders, executives, and people not involved in the creative process demanding edits to Hemingway’s work.  The final straw might be the demand that “A Farewell to Arms,” not have one of the main characters die at the end of the book.  The entire narrative arc of the book changes because of the “suggestion,” but if Hemingway does not make the changes, he does not get paid or published.  Considering this type of feedback, Hemingway would have consumed more alcohol than he did.

So this is why writing software is so complicated.  It is a creative process.  Next, the people who want and pay for the software are not actively involved.  Finally, if customer partners are in the project, they provide feedback and guidance, which is often removing value from the software rather than adding it.  I have been in this career for a long time, and I know how to write and deliver software.  It is much more complicated than creating crayons.

Until next time.

Goodhart's Law is Going to Get You.

Goodheart's law strikes!

Information technology is hard work.  I have written about it before on this blog.  I have plenty of empathy for others who work in this profession.  I do not have much understanding of poor service or lazy behavior.  I am even less forgiving when large organizations brag about their success in public and struggle to do the basics in private.

I am at a client, and I have the following interaction with someone from the help desk; they said, “Can we close this ticket? If it ages any longer, it effects out SLA.”  My first reaction was surprise.  My second emotion was anger.  The help desk person was asking permission to close the ticket and open a new one because if they did not fix the ticket at a particular time, it would reflect poorly on him and his consulting company.  He was going to lie to make his response time look better than it was. 

It is human nature to please others.  British economist Charles Goodhart coined the maxim, “When a measure becomes a standard, it ceases to become a good measure.”  When you judge or pay people based on a measure, they will game the system in any fashion to make themselves look better.  You see this in economics.  It happens in video games and depressingly at work.  My help desk technician was living proof of Goodhart’s law.

Martin Fowler wrote a great article on the subject, and it outlines how to avoid this trap in agile practice.  Metrics are abused regularly in business.  In a large organization, the only way leadership can track progress is by reviewing these metrics.  Thus, the people doing the work are more focused on the outputs of hitting the metric numbers instead of the outcomes satisfying the customer.

I see service level agreements or SLAs as a necessary evil in business.  You have to hold vendors and third-party partners accountable.  Such a contract controls my current situation.  In a perfect world, my help ticket would age, and someone who could help me would respond to my issue.  The technician was afraid that if the ticket aged, they would receive a poor performance review or get fired.  It is an ugly situation, and if a company is going to succeed, they with have to address it. 

Large organizations need to focus on execution.  To focus on this goal, metrics and SLA’s need to be used judiciously; outcomes are superior to outputs.  It is a message which did not reach the help desk or his boss. 

Until next time.

The Strength of Technology Pros

No rest for technology

Technology is not for the meek.  A software developer is relearning their craft every 18 months.  Technology companies come and go with regularity.  Businesses rely on software to remain profitable and when the software does not work it costs lives.  The men and women who work in this business have to be tough.  Part of that toughness is the realization you have to deal with failure and frustration.  This week on the blog, I will discuss these central conditions of technology.

Many people have romantic notions about scientists, engineers, and software professionals.  The stereotype is that we are super smart and socially awkward individuals who spend their days making inventions and applications which change the world.  The reality of technology is less glamorous; it is hours, weeks, and months of frustration.  It is executives and financers demanding the work to be finished immediately.  It is cold coffee and stale pizza.  It is loneliness and frustration.  In the end, you might have a brief moment which feels like the creator is touching your shoulder but those moments are rare.  Often you will see a solution to a problem which has dominated your life and now you will have to make it work for others.

It means traditional methods cannot measure these workers.  Science is notoriously fickle when it comes to new advancements.  Computer software is a handmade and messy process prone to error and cost overruns.  Software is eating the world, but it depends on a small segment of the world population to build it.  Innovation and invention do not fit neatly into a project plan.  The realities and pressures of technology create unhealthy levels of stress.

The heavy intellectual lifting combined with the anxiety caused by deadline pressure creates a toxic stew of emotions which can lead to physical problems.  Obesity and heart disease are common among software professionals.  Self-medication with cannabis and alcohol are also common within the trade.  All of my contemporaries have recounted stores of insomnia and anxiousness caused by grappling with a severe challenge.  For those outside the profession, the levels of stress and frustration are extreme.  To a developer, it is just another day at the office.

Creativity and innovation are difficult.  The pressure we place on people leading innovation efforts is unhealthy.  The repercussions are professional burn out, defective products, and the risk of cascading failure within complex systems which maintain the global economy.  In many respects, we live in a magical age.  Today’s smartphones are more powerful than the computers which put people on the moon.  With a few swipes, we can order food and find a possible romantic partner to share it with us.  Information can swirl around the globe in seconds and we have millions of people using the internet to solve problems only a century ago would have had the attention of a small group of specialists.  It is a fantastic period to be alive, but the cost is that many people take for granted these advances and forget they are the product of the human mind rather than magic.

It is why I say technology is not for the meek. It requires intelligence, training, and the ability to tolerate frustration and failure.  The strength has helped build the global economy, and I have enjoyed a peripheral role in this process.  Technology people are different, but they have to be; otherwise, the magical world we live in would not exist.

Until next time.

Treat People Like People Instead of Resources

Treat others like people.

Being a scrum master is hard.  It is not a dirty job like being a trash collector.  It does not have the danger associated with being a firefighter or an electrical lineman.  It lacks the prestige and respect of being a member of the armed forces or the toughness of being a lumberjack.  Scrum masters make the world a little better one sprint at a time. 

Forbes magazine categorized four types of toxic professionals; the power hungry, the absent, the incompetent, and the micromanaging.  I have encountered these individuals throughout my career.  I have spoken about how those individuals can spoil an organization.  Each of these people are awful in their unique way, but I think one trait unites them; they see others as resources instead of people.

I blame this state of affairs on contemporary project training.  A modern corporation is deeply concerned about profit.  A company is so worried about profit they will do everything in their power to make sure each employee is running an efficiently as possible.  A software developer with downtime is wasting money.  It is why people expect them to perform multiple projects.  A business leader able to meet and mentor junior employees does not have enough to do or is not generating revenue.  Being busy is more important than being productive.  The agile community calls this putting outputs above outcomes. 

Treating the individuals doing the work like people requires downtime, training, and mentoring to provide value to customers.  If individuals are resources, they are office supplies which can be used up and discarded when they are no longer useful.  Treating people like resources is exploitive and antithetical to an agile mindset.  

I joined the agile reformation ten years ago because I felt there was a better way to deliver software.  People deserve to work in environments which are satisfying, sustainable and sane.  When you treat people as people instead of resources to be used and discarded this will not happen.  I have a simple vocation, and this is to help businesses manage people like people.  I suppose that is why it is so hard being a scrum master.

Until next time.

The fight against alienation is real

Don't inflict help

Any time a professional person attempts to change an organization they belong they are going to face a backlash.  Socrates would argue that this kind of behavior was the product of ignorance.  The philosopher would say once people knew the difference between objective right and wrong, people would choose right.  It was an optimistic view of human nature and one which is non-existent in the contemporary office.  Business people can be nasty, cruel and brutish as Thomas Hobbes would call them in “The Leviathan.”  A business person can exhibit the manipulative insincerity of Machiavelli’s “The Prince.”  Worse of all, professionals can exhibit the traits of the “Ubermensch” running roughshod over the “last men,” as Nietzsche would call them.  Backlash, is natural in human progress and it is up to coaches and scrum masters to address it.

Fear and uncertainty dominate the contemporary office environment.  Lots of factors are to blame for this state of affairs, but the principal factor is the shareholder value postulate of business.  In this postulate, shareholders or investors are the most important constituency in a corporation.  Customers, employees, and communities which also rely on the corporation receive secondary treatment because they are not as important as shareholders.  It is how we have educated a generation of business leaders since the 1970s.

Combine this trend with the deregulatory actions of the conservative movement, and you have a recipe for sterile and exploitive work environments.  It does not matter if you are blue collar, white collar or in service industries you are generating wealth for others with little upside to yourself.   Karl Marx called this the “labor theory of alienation.” It is one of the few things which Marx has written which has held up to scrutiny over the years.

So the agile coach is often in an environment where people are alienated.  People work hard enough not to get fired but not too hard because they will be singled out for extra responsibility with no subsequent increase in pay or authority.  The “company way” keeps a person paid and provides a modicum of security.  It is a miserable and uninspiring way to work.  Thus, the coach or scrum master is fighting on three fronts.  The coach must address the apathy of individual team members.  Next, they are changing the perspective of managers who often benefit from the alienation of the workers they are supposed to serve.  Finally, inertia in the organization acts as an easy alibi to resist organizational change. It is frustrating.  You are hired by organizations to help them change, and they actively oppose the change.

What I have discovered over the last few weeks is organizations want to improve; they do not know how.  Companies need scrum masters and coaches to help them.  They are looking for individuals to offer help rather than inflict it on the organization.  Often a scrum master acts as a therapist or pastor to an organization.  A coach needs to practice non-violent language and help others find solutions rather than dictating those solutions.  It is not easy, but anything worthwhile is going to be difficult.  Backlash is natural and it is up to the agile community to turn it back on itself to effect real change.

Until next time.