The Sky is Not Falling in the Technology Sector

The internet is a beautiful place. At any moment, you can look up any piece of information. For instance, if you want to learn about penguins, you can visit this Australian website to get the latest news. Likewise, if you are searching for a different kind of wildlife, you can check out a furry convention in the American mid-west. The volume of information is so staggering that it can often induce a feeling of paralysis. The reason for this paralysis is that high-quality information usually exists side by side with rumors, speculation, gossip, and outright falsehood. It takes a skilled eye to tell the difference between a meaningful piece of information and something you can safely ignore. The current economic news out of the technology industry is another example of this information tsunami. Today I want to put the hysteria in context. 

It has been a bad week in the technology sector. Google's parent company Alphabet laid off 12,000 employees, and Capital One gave 1,000 agile employees notice this week. The news was so bad that it became a topic of conversation at my company's lean-coffee meeting. What is going on and why?

The easy answer is that technology companies were over-hired during the COVID-19 pandemic. The workers needed to accommodate binge shopping and streaming with people stuck at home. As things began to return to usual, those people were no longer necessary, and capitalists decided to shrink their workforces. We also witnessed companies paying the price for making poor decisions. For example, Amazon grew its warehouse operations too quickly and now must cut back. Another poor choice was Mark Zukerburge creating a fifteen billion dollar money pit called the metaverse. Sooner or later, companies have to face economic reality and cut back on jobs, particularly if they lose money. 

It is easy to get caught up in the gloom and doom. In the wake of this bad news, the internet and social media have been filled with plenty of poor takes on what is happening. Most people need to understand that even with these layoffs, there is a shortage of people who know how to write software and maintain the complex networks and databases that run the global economy. The prospects of these people who are collateral damage in the economy today have the skills and expertise that many companies today demand to be competitive. It stinks to get fired or laid off, but they will bounce back better than before.

A worse take is that it is payback for years of employee entitlement in the technology sector. I even see articles claiming CEOs rooting for Elon Musk and his desire to transform the Twitter workforce into a 'hardcore' team. As a survivor of the dot.com crash of the early 2000s, what is happening is a natural cycle of boom and bust in technology. Venture capitalists want to earn money from their investments, and shareholders need to receive dividends. The cutback in staffing and perks is a natural result of the tension between the demands of workers and business owners. As the talent pool becomes more shallow, I expect bonuses and perks to come back. 

The final lousy take is the layoffs at Capital One represent a rejection of Agile as a way of delivering software. I am not on the inside of the organization, but it was clear to me that the company was paying lip service to agility while not doing what was necessary to be successful. I liken it to a person unwilling to exercise and eat better with the expectation that they will lose weight. Sjoerd Nijlan points out on Medium that the callous nature of laying off the entire agile staff at Capital One looks more like an admission they were unwilling to change than a failure of agile. Frankly, I want to hear from people on the inside to understand the experience of attempting to transform a company that was unwilling to change. 

These layoffs take a severe toll on the people who used to work for those companies. Layoffs impact not only the former employees but also their families and communities. Empathy and understanding are necessary for these folks going through a difficult time. We also need to acknowledge that while they are suffering, these workers will be back in the workforce because they have skills that are in high demand. The sky is not falling for the technology industry and agile; instead, it is one of the many cloudbursts in the turbulent atmosphere of technology and capitalism. People will get rained on, but the good news is that most of us have umbrellas and a place to find shelter until the storm passes. It will pass.

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. 

How to write a good user story.

Tell a story and get work done. 

When you are working as a scrum master or agile coach, your biggest challenge is getting others to understand the concepts of agile.  It is like teaching young children to read.  The concepts seem natural to an adult, but to a six-year-old, it is an alien skill to master.  It occurred to me this week I have written numerous blogs about the different aspects of agile development, but I have never written a blog about authoring user stories.  Today, I want to change that oversight.

Let me begin by saying I am sharing with you how I teach others to write stories.  Each coach and each environment is different.  Feel free to treat this blog as an informed suggestion of how you can do things at your organization.

In the early days of agile, a user story could fit on a post-it note.  Team members would see the story ask the product owner for some discussion about what to do and then the work would get done.  The early approach assumed the development team was in the same room and the product owner was always available to answer questions.  Today with team members scattered around the globe, product owners focusing on customers, and countless tools to track work items, it is not realistic to rely on just post-it notes.  Regardless of what system you use to track user stories, the first thing you should do is boil the work down to one sentence.  I use the following format.

As X I want/Need Y because of Z.

The template is easy to follow and works in most situations.  Here are two examples.

Example #1 – As a sales manager I want the background of the shopping cart page to be blue because it reduces the number of dropped shopping carts.

Example #2 – As a user, I would like the website to save my customer information because I do not want to retype information. 

In both examples, the subject of the sentence is the person who needs the work done.  The predicate of the sentence is the actual work.  The modifying clause is a credible reason why the work needs to get done.  The sentence should satisfy the Who, What, Where and Why of the work.  It is up to the developers to provide a credible answer to When the work gets done.

Once you have authored a user story, it needs acceptance criteria.  Acceptance criteria are important because it removes misunderstanding between a member of the development team and the product owner.  Unlike waterfall techniques which demand long and confusing narratives, I show product owners the Gherkin or Given, When, Then (GWT) formatting of writing acceptance criteria.

Given: I am registered user of the website
When: I check out my shopping cart
Then: My billing information is retrieved
And: My shipping information is retrieved.

Notice the GWT does not say how to do the work; it just says what the product owner expects the development team to deliver.  The team could use session variables, cache objects, or cookies to do the work.  It does not matter.

A user story should look like this in the work item tracking system.

23 – Save shipping and billing info
As a user, I would like the website to save my customer information because I do not want to retype information.
23.01 
Given: I am registered user of the website
When: I check out my shopping cart
Then: My billing information is retrieved
And: My shipping information is retrieved.

The number is usually automatically generated by the item tracking system.  I use a ##.0# numbering system for acceptance criteria for clarity, and I provide a title for stories.  During stand-up meetings, developers refer to stories by saying, “I am working on number 23 save shipping and billing info.”

I hope this is a good starting point for how to write user stories.  With practice, it will become natural just like reading.

Until next time.

When you lose a bet on your career.

Boy, did I fail.

It has been a crazy week.  I made the transition from working on a gigantic waterfall project to unemployment in the span of an afternoon.  I was feeling a flurry of emotions.  At first, I was ashamed and disappointed.  My feelings then migrated to anger and bitterness at how cheaply was thrown aside.  Currently, I am feeling determination and resolve to get back to work.  Through all this process, I have been overwhelmed by well wishes and support from the agile community.  It is this support which is keeping me going during this difficult time.

I joked glibly; I was betting my career that the project I was on could benefit from my agile knowledge and approach.  In less than seven business days, I was rolled off the project and laid off.  I did not receive any feedback from peers; I was just marched into the HR office and let go.  I should be angry and bitter, but that is not going to help me get back to work.  Fortunately, my colleagues on social media and #Slack came forward.  I received comfort, coaching, and support.  I also took some time to think.

It is not comfortable looking at failure.  It is necessary if I am going to grow and develop as a person.  It is one of the main postulates of agile is, “…to fail early and often.” In that respect, I was successful.  I failed, and now I have to take that failure and learn from it.  I am going to do a better job vetting employers to make sure they want the agilest working on their staff.  I am going to change the notifications on my mobile phone, so I am not distracted during the workday, and I can concentrate better.  Finally, I am going to focus more intensely on Radical Candor and Non-Violent Communication.

I have plenty of free time, and so I am going to use this opportunity to decompress and spend with family and friends.  I will live through this and would not be this brave without the help and support of everyone around me.

Until next time.

Agile and the Toxic office

The Open office plan circa 1960.  

A modern office resembles the dark vision of Jean-Paul Sartre’.  In his play “No Exit,” he traps three characters in a room.  The characters psychologically torment each other.  The lights never dim and no one can escape.  To Sartre’, “hell is…other people,” and they are impossible to escape.  It sounds like a perfect description of the modern office with cubicles and open floor plans.  By design or neglect, the contemporary office has become a toxic hell which white collar workers navigate each day.  As an agile coach and scrum master, you need to fight this toxicity and make work better. 

The open office is not a new concept.  As business expanded, hundreds of people were needed to perform necessary clerical work.  Captains of industry required contracts typed, checks deposited, and in a time before computers numbers crunched.  Many of these jobs became obsolete with the advent of computers and photocopy machines.  Today, an employee with a laptop can be more productive than an entire 1950’s office pool.  It is impressive when you think about how office work has changed over the last seventy-five years.

It is also surprising how little has changed.  Alcohol abuse is still a problem in the corporate world.  The “Peter Principle” which promotes people to their level of incompetence is still in practice.  Finally, according to Gallup, two-thirds of workers in the United States are disengaged.  I feel strongly Agile came into being because competent, hardworking people thought it was possible to do better.

The reason offices converted too open plans is the combination of perverse economic incentives and naive notions of what it takes to build a collaborative team. In cities with large business communities, rent is at a premium.  In Chicago rent increased by 20% in 2016 and currently leases at $50 to $60 a square foot.  Based on the price pressure, business owners have the incentive to get the maximum amount of use out of each square foot.  The open office makes that possible and managers can squeeze more people into less space.  The open office plan began with Frank Lloyd Wright and his Johnson Wax office building; it also has an origin in German design from the 1950’s.  The open office would facilitate conversations, collaboration, and innovation.  The reality of open offices is an environment employee’s loath.   

It does not help the shareholder value theory of business motivates many managers.  To these managers, the only thing which matters in increasing the share price or dividend for the company stockholders.  Thus, the open office and the shareholder model of business creates a fiendish replication of Sartre’s hell.  We are trapped economically in a space which is designed to torment us.  It is this combination of poor work environment and leadership which ignores stakeholders, customers, and employees are why I think we have such a severe problem with disengagement and alcohol abuse in office culture.  When there is a disconnect between your work and your wellbeing, something has to give; for many, it is their self-esteem and enthusiasm for work. Marxist philosophers call this “Labor alienation,” and it is just as bad today as during the sweatshops of Dickens.

Agile came into being because people doing the work of building the world economy through there was a better way.  These people were project managers and technologists.  None of them were Fortune 500 executives.  Individuals and interactions, responding to change, customers collaboration, and working systems were more important than everything else at the office and embracing these values we say we are trying to make the office less toxic. 

Many of us feel we are powerless to change things in the office.  Agile gives us the tools to expose dysfunction and reduce alienation.  We have to be brave and smart enough to use those tools; otherwise, we will continue to have the same office as we have had for seventy-five years and there will be "no exit," for us. 

Until next time.

Talk to People Instead of E-Mailing Them!

Instead of sending an e-mail pick up the phone.

I have been a business professional for a long time.  I have been working in technology for two decades.  In that time, the world has changed radically for good and ill.  What has not changed is the time suck which is e-mail and how it is cancer for many organizations.

E-mail is as old as the internet.  Before the creation of the World Wide Web, the most common use of the internet was swapping files and sending e-mail.  Business organizations saw the utility of the application and used it as a means to create a way to cut down on the number of business memos.  What happened is the creation of a flurry of messages through companies as people used the tool to improve communication.  With the advent of e-mail and voice mail systems, managers hoped the worker bees in the cubicles would not ignore important information.  According to my experience, the cobra effect raised its venomous head.

The information did move more smoothly, but it created an incredible amount of noise which drowned out the necessary information. Instead of business goals; office gossip, invitations to lunch and memes began to clutter up inboxes.  The torrent of information became a tsunami as network systems were tuned to send SMTP messages.  Today, every file dropped into an FTP folder, or work item changed in JIRA or help desk ticket created generates an e-mail to provide you with a friendly reminder.  Today, a business professional has to act on hundreds and thousands of e-mails – daily.

The ocean of e-mail both trivial and critical is overwhelming.  It has created the inbox zero phenomena and a perfect storm of professional apathy.  All e-mail has the same relative importance, so it is easy to ignore messages equally.  Managers have used the folder routing features of Outlook and GMail to ignore inquiries and information from subordinates skillfully.  Help desk people with a particular form of sloth will ignore complaints for days.  The ability to use email as a tool of deflection seems, to me a credible reason why productivity has been relatively stagnant over the last decade.

What makes e-mail so insidious is that it is a written record of the conscious and unconscious mind of an organization.  An e-mail gives an employee an alibi creating the impression they spoke up about important issues even if management ignores that information.  Sexual harassment and gossip exist in the company e-mail database like an improvised explosive device waiting to dismember.  Finally, criminal and unethical behavior are spelled out for prosecutors and the journalists to expose.  It is why the e-mail database for Enron is still used by software companies to test e-mail products.  The criminal conduct and general idiocy of the Enron organization live forever.  Technology, human resources, and public relations professionals use the Enron e-mail database as a simulation of what might happen in an actual corporation.

To me, e-mail is not a tool for clear communication but a device for obfuscation.  It is the written equivalent of snowflakes coming together to create a blizzard of awfulness.  Individuals compensate with text messages sent between private phones, executives and other essential people having multiple phones to have conversations.  It is critical information being harder to share and keeping secrets for personal gain.  Finally, business professionals spend three to five hours each business day according to Forbes monitoring and authoring e-mails.  I think this is crazy.  Instead of helping customers, innovating the business or solving problems we are doing ticky-tacky work monitoring e-mail.

One of the agile principles says that face to face communication is preferable to other forms of interaction.  So my warning to any scrum master or agile coach is to pick up the damn phone, call people, and speak to them.  Get up from your desk and walk over and talk to people rather than hide in your office.  Use video conferences and insist that everyone turn on their camera so that we can read body language and know they are paying attention.  A lousy organization is not going to change if we insist on doing the same thing redundantly.  It is time to reconsider e-mail and how we use it.  It cannot hurt to try.

Until next time.

How I became a Pirate Bear

I am a pirate bear. 

If you have been following this blog for any length of time, you understand that I have been an outspoken advocate of Agile and Scrum.  It has become the central focus of my career.  I am one of those eccentric and creative people companies want but do not know how to utilize.  I am an anomaly in the business world, and I am comfortable with it.

Like any other technology professional, I spend my free time learning new skills.  In preparation for the Scrum Coaches Retreat in London, I spent some time learning how to use #slack.  To be honest, I am still struggling with the platform.  It feels alien to me.  I have not mastered all the tricks, lingo or etiquette of a #slack community.  I think the same way I did eight years ago when I started using Twitter.  I was able to master that, and I will be okay with the new platform.

When you join a new social network one of the more important things you do is choose a name where others can quickly identify you and touch base.  The same is true with #slack and since the network does not allow for duplicate names people rapidly get creative coming up with handles.  I decided to give myself the moniker “The Pirate Bear.”  I posted a color picture of myself in a fez and began my journey in #slack.  I was swapping information, slide decks, and gossip with other agile coaches for a few weeks when someone from England asked why I chose “The Pirate Bear.” I did not have a chance to answer the question then but feel compelled to answer it now.

Since I began my vocation as a technology professional, I have been heavy.  I blame this state of being on the nature of the profession and by using food to cope with the pressures most technology professionals confront.  I am both big and tall.  It prompted the woman who loves me to label me her bear affectionally.  Additionally, many of my LGBTQ friends and colleagues say that I would pass as a “Bear” in the gay community. I felt awkward about this at first, but I embraced it as good-natured teasing from friends.

Piracy has been a significant theme in the zeitgeist since Johnny Depp wore the costume in the first Pirates of the Caribbean movie.  Piracy has been the banner many rebels and outcasts have embraced since the age of sail.  Illegal radio stations sailed the North Sea offering programming the BBC would not provide. It became a pirate radio which has been copied by numerous radio stations around the world.  When Steve Jobs put together the product team of the first Macintosh, he told each of the engineers, “It is better to be a pirate than to join the navy.”  The secret pirate crew then changed personal computing forever.

It sounds very glamorous. The swashbuckling and mythology of piracy is quite appealing.  The reality is that a pirate’s life was dangerous and cruel with significant shifts between poverty and wealth.  A pirate sailor often faced execution if captured and often succumbed to illness at sea.  You chose piracy for many reasons, but the main reason is that you did not fit in anywhere else.

In the sclerosis of most corporate environments, if you are going to make a change, you will have to be a pirate.  You will have to be smarter, nimbler, and more unconventional.  You will suffer from being an outcast.  You may also fail in an embarrassing and ignoble fashion.  On the off chance none of that happens, you will cut a romantic figure in front of black sails and wallow in gold and rum.

Given a choice between the routine and tedium of a professional career and being a pirate; I choose to be a pirate.  It is why I am the pirate bear on #slack.

“Roar!”

Choose a Growth Mindset

Growth is not easy in this business.

One of the major features of agile is its emphasis on continuous improvement.  Teams, people, and processes can always get better.  If you do a 1% improvement each sprint and perform three-week sprints over the course of a year that equals a 17% improvement by the team.  Many times, small improvements are equivalent to significant increases over the long term.  What works with software development teams also works for scrum masters.  A scrum master should consider continuous growth to be a personal goal in their practice of agile.

I am currently working on becoming a Certified Team Coach.  It has been a time-consuming process with me logging hours and filling out forms.  I reviewed the five dysfunctions of a team and practiced SOLID code development.  I was about to file the first part of my two-part application when someone suggested that I get a pre-screen.  I was deeply disappointed by what happened next.  My screener said the first part of my application would be accepted, but I would ultimately be rejected in the second round because I did not have a “coaching mindset.”  I was disappointed.  It was as if the last five years of blogging, coding and being a scrum master were an empty exercise.  I was given a verbal pat on the head and sent on my way.

After doing some reflection, I went over my notes, and there were some suggestions for graduate-level courses in coaching.  I also spotted a class from the Harvard Business Review on coaching for leaders.  The pre-screener was even kind enough to recommend some graduate-level course in coaching which was local.

Maybe I was not ready.  During this time of reflection, I was exposed to the work of Stanford University professor Carol Dweck.  Her most influential idea is people to be successful need to move from a fixed mindset to a growth mindset.  This very positive idea is one which postulated that everyone is capable of growth and improvement.  Having a growth mindset means that development only happens if people actively seek improvement.  Traditional command and control methods of leadership are less effective than asking questions and having people find solutions rather than having them provided for them.  As I said, it is optimistic.  Professor Dweck can fail students who do not turn in the homework.  Me, I am stuck with product owners who will not write user stories.

I can see a few scrum masters and executives shaking their heads.  Authoring user stories is a fundamental part of being a product owner.  A leader with a fixed-mindset would take disciplinary action or try to teach that product owner to write stories promptly.  A growth mindset leader would ask questions, guide mindset, and follow up with the product owner to get them to improve on their own.  It is touchy-feely and genuinely optimistic.  It also runs counter to how I learned in the field of media and technology.

I was skeptical, but I decided to give it a try.  What happened next was a surprise.  A person responded positively.  They got better at what they did.  They did not improve as quickly as I would have liked, but they did enhance so after four weeks I noticed a difference.  Furthermore, when the person did things which usually triggered in the past, I saw a different motivation.  Now, instead of seeing them attempting to undermine my credibility or authority; I saw them checking for understanding and holding others accountable.  The situation is not entirely sunshine and rainbows, but it is improving.  I should embrace improvement over stagnation.

So here I am attempting to adopt a growth-mindset and continuously improve one small step at a time. Taking a growth-mindset is the next step in my agile journey.

Until next time.

Some Thoughts About the Holiday Rush

A little holiday rush

It is the final rush of 2017.  The business is pushing to squeeze as much profit out of the holiday season while the technical professionals are scrambling to bring on-line systems promised by the executive team.  It is a busy time and filled with pressures both personal and professional.  I find it hard to cope with this strain.  You spend time keeping the commitments of others and struggle to use the difference supporting family and friends.  This week I want to make sense of the holiday rush. 

For as long as I have been a business professional, the one motivation I have seen in business is fear; visceral, cold, unforgiving terror.  It is the anxiety that you are not hitting your sales figures.  It is the panic of the payroll system not interfacing with the accounting software.  It is a shame that comes with a sixty hour work week not being enough to deliver what your manager promised. 

The reason I became so enamored with agile and scrum is I wanted to work without fear.  I have been fired the week before Christmas.  My spouse left me because I finished up a consulting contract early.  Each meeting with quality assurance or my manager triggered spasms of fear.  There had to be a better way.  Agile and scrum provided a means to do things differently and escape that fear.

I have been in the agile practice for eight years.  I have had tremendous successes and bitter failures.  I have lost countless hours of sleep and overeaten junk food.  I have struggled against organizational inertia and corporate indifference.  I would not change a thing because the changes I have made mean that one less developer is living in fear.  That makes it a worthy goal. 

So as I fight crowds to get my shopping done and stay up late to ship software on time; I understand the sacrifice and frustration I put in for 2017 is worth it.  There is a little less fear in the office.

Until next time.

Experience Matters in a Scrum Coach

Leadership experience is not pretty but necessary

Plenty of issues crop up in the day to day life of a scrum master.  Impediments need to be resolved and each day you are a living example of how Scrum is supposed to work.  As a fellow coach, Ryan Ripley remarked on how some individuals with little experience with agile are marketing themselves as coaches.  Ryan feels pretty strongly about the subject, and so do I.

There are two lines of thought about leadership.  The first school is called the “great man theory.”  This school firmly believes that great leaders are not made but are born.  This notion has been used for generations to support monarchs and other forms of tyranny.  For each leader born into greatness, there are numerous counterexamples of individuals who fall woefully short.  There is also an elitism and snobbishness associated with this school of leadership which says that only specific groups can aspire to leadership.  I also find this type of thinking has plenty of sexist and racist baggage associated with it.

The second school of thought is the notion that leadership can be taught just like any other skill.  I am a firm supporter of this idea.  When I was a teenager, I benefited from leadership training from Boy Scouts of America and Marine Corps Junior Reserve Officer Training Corps.  I had the Boy Scout Law ingrained into my personality at an early age.  The outdoor activities forced me to learn to help younger scouts cope with being alone and away from home for the first time.  Being caught in a rainstorm surrounded by wet and tired twelve-year-olds is a good measure of your leadership skills.

Marine Corps JROTC taught me self-discipline, my left form my right and that leadership is more about credibility than shouting at people.  I met some remarkable people.  David Ogle was a survivor of combat around the Chosin reservoir and a USMC boxing champion.  He served in Vietnam and became a Sergeant Major.  Richard Weidner was a company commander in Vietnam and taught me about the less than glamorous things leaders have to do.

Together, Boy Scouts and Marine JROTC gave me a good foundation from which to build.  I took that knowledge with me into the sales profession, the casino business, radio, and finally into technology.  I am entering the fifth year of being a scrum master.  The experience of shipping software at the end of each sprint changes a person and their style of leadership.  Working with offshore teams changes how you relate to others.  Those experiences make you a better scrum master and coach.

We can teach leadership, in my opinion.  I also feel experience acts as a multiplier of leadership skill.  A good leader does not ask someone to do something which they would not do themselves.  That means if you ask a developer to write a unit test you better be willing to write a few of your own.  An agile coach who has not led a retrospective or shipped code is not a coach because they lack the practical skills to make agile successful.  They are faux coaches, and you should steer clear of them.  An agile transformation is like performing a heart transplant on a person running a marathon; you would not trust that job to a first-year medical student.  Anyone can call themselves a coach, it takes time and experience to be a valuable coach

Until next time.

I would have fired him too!

Freedom of expression is not a license to be an asshole.

Plenty of pixels have been expended on the diversity memo from a Google engineer who argues that efforts to improve diversity were a waste of time.  I have been following the arguments and spoken with friends about the dust up.  It dawned on me that this is not a question about diversity versus political correctness.  The entire affair is really about teamwork and being a jerk to you colleagues.  The author of the memo is not free thinking but using pseudoscience to justify biased views.  As an agilest and leader, there is no room for these individuals in your organization.

Over the years, I have been critical of the “brogrammer” culture.  I have also been critical of engineers who think gender is a disqualifying factor to work in technology.  Last week, I further bemoaned the lack of women in the development profession.  I placed much of the blame on a feedback loop of men pursuing computer science careers and providing a leg up to other men in the industry.  It is also apparent to me that working in technology gives certain individuals the license to be an asshole to others.

One of my favorite business books is “The No Asshole Rule,” by Robert I. Sutton, Ph.D.  Sutton does a fantastic job providing a scholarly definition of what an asshole is and reasons why you do not want them in your business.  I think it should be required reading for any business person along with the “The Five Dysfunctions of a Team,” by Partick Lencioni.  

According to Sutton, an Asshole has two traits:

• Test One: After talking to the alleged asshole, does the “target” feel oppressed, humiliated, de-energized, or belittled by the person?  In particular, does the target feel worse about him- or herself?
• Test Two: Does the alleged asshole aim his or her venom at people who are less powerful rather those individuals who are more powerful.

Based on the above criteria, it is evident to me that the author of the Google memo is an asshole.  The author considers himself and those like him intellectually and morally superior.  Since they are superior, they should not have to debase themselves by having to educate, mentor, or collaborate with those people.  This"other" could be women, ethnic minorities, and people living different lives.

A modern office is not an environment for this kind of thinking.  Women make up a large percentage of the work force and are filling senior leadership positions.  There are also countless people of color working as professionals.  Finally, individuals who are gay, lesbian, bisexual or transgender are collaborating with those who are not.  Anyone who considers themselves superior to others not like them is going to create tension and undermine collaboration in the office.  Eventually, behavior like this is going to trickle down to the bottom line.  From an agile perspective, individuals who feel this sense of superiority are going to be resistant to continuous improvement.  It is not a surprise the author of the diversity memo wrote this after attending a workshop on the bias.

As a manager and agilest I would have fired the author of the Google memo.  He was a distraction to the firm and advocating for a direction that the company had openly rejected.  Finally, his attitude to co-workers different than him would undermine any project he was assigned.  Better to remove a polyp than deal with cancer which could kill your organization.

Until next time.

I am taking next week off to attend the Gen-Con game fair. 

Developing the professional scrum master

If you think this is ugly try
hiring an amateur plumber to fix it. 

The business world has a saying, “If you think hiring a professional is expensive, wait until you hire an amateur.”  The obvious meaning being a poorly trained amateur will cost the company more money than someone who is more expensive but better qualified.  This week I want to talk about the minimum standards of professionalism you should expect from a scrum master.

I am a big believer that with enough time and training anyone can develop a useful skill.  If I devoted ten years of my life learning to be a plumber I could become competent.  Unfortunately, I know myself well enough to know that I need to call a professional when my water heater breaks.  A bonded plumber is worth the time and expense for me to have hot water.

When you get into other activities training is only a small part of the equation.  You can practice piano for years and still not be good enough to entertain an audience not composed of parents.  Jazz musicians refer to the quality of being able to improvise and perform in front of an unpredictable crowd as “chops.”  The idea is that anyone can learn to play the notes, but a real musician has chops.  Hard work, combined with talent makes a jazz musician successful.

I feel the same way about scrum mastery.  Everyone can be trained to do the job, but only a minority can do the job well.  It is the difference between having a high school student perform at your night club and having Elton John setting up a residency.  Fortunately, there are plenty of good programs to train scrum masters.  I am particularly fond of the Scrum Alliance Certified Scrum Master certification because it teaches the basics of the job along with the more touchy-feely skills which come with the job.

Once they have received some training, they can then lead a scrum team.  I recommend putting a rookie scrum master with an experienced product owner. This way the scrum master can gain experience with someone who can show them the ropes of the business and the particulars of a project.  With a year or two of experience, a scrum master can help a product owner learn their trade.  Much like the ideas proposed in extreme programming an experienced veteran should partner with a rookie so they both gain from each other’s experience.

With a little luck, you will find someone who is outgoing, a good communicator, empathic, has grace under pressure and can act as team therapist.  Then and only then do you have a scrum master with chops who can take your team to the next level.  So take the time to train your scrum masters.  Next, pair them with experienced developers and product owners, so they gain confidence and experience.  Finally, make sure you find people who possess the talents which will make them successful in the job.  If you do this, you will not have to pay extra for an amateur managing your scrum teams.

Until next time.

The Messy Nature of Software Development

Software is messy

I have been in the software business for nearly twenty years.  I began as an entry level programmer and made the transition to scrum master and agile coach.  It was not pretty or heroic.  It was a journey filled with personal and professional setbacks.  Sometimes, I wonder how I didn’t wind up begging for change on the side of the road.  Somehow, every setback I have faced has led to a larger and better opportunity.  This week on the blog I wanted to discuss something which we do not discuss often; the messy nature of software development.

If you are not already following Angela Dugan’s blog, “The TFS Whisperer,” you should.  One of the posts struck me for its honesty and courage.  She talked about how application lifecycle management and DevOps are “messy.”  I add that everything involving software is messy.

The creation of software is a new trade.  It began in the days of vacuum tubes after World War Two and had grown into an activity employing a total of 11.5 professionals worldwide.  The term bug came from a moth trapped in a box of the first vacuum tubes of the ENIAC computer.  Today, bugs represent any of the defects or mistakes we perpetuate in code.

In the seventy-plus years since the beginning of professional programming, the activity has not fundamentally changed.  Smart people work in isolation writing software code, and business people take it for granted that is works.  The reality is software is one of the few activities which has not been taken over by automation.  It is a creative and manual process. It is both an art and science.

Unlike construction which has a set rules for engineering and gravity software development lives in a strange world where the rules do not matter or change with each release.  Deadlines are either fluid or hard as stone.  People work late nights and early mornings to get the product out on time.  Personal relationships suffer as support calls intrude on anniversary dinners and you are asked to release software on Sunday afternoons.

The people who do this work are smart and creative.  Too often the demands of the business community force leaders to treat these people like machines which run on caffeine and pizza.  The people who write software have children, significant others, and aging parents.  They have felt and experience the entire range of human emotions.  They are more than points of data in an Excel spreadsheet or a line item in a project plan.

It matters because software is one few activities in business which is immune to automation.  It is manufactured by hand by these creative human beings.  So software is “messy” because people under great pressure author it every day.  Software development is “messy” because people make mistakes.  It is “messy” because people have emotions which are hard to control.  Finally, software development is “messy” because business people treat software professionals as interchangeable “staff” instead of skilled artisans.

I have spent numerous nights questioning my ability and worth thanks to the messy nature of software development.  I am sure that other software professionals have done the same. This business is humbling.  Angela and I agree; software development is messy because very human people are involved in every stage of its creation.

Until next time.

Everyone has a bad day.

Everyone can have a bad day

Everyone is entitled to a bad day.  We live in an imperfect world where directions are not followed, colleagues don’t have the same sense of urgency, and the printer is out of toner.  It is worse for agile teams because they are expected to deliver at the end of each sprint and a few bad days can pile up into a failed sprint. As a scrum master it is up to you to accept bad days and help you team avoid future ones.  This week on my blog the emotional work necessary to make it through to bad times.

Each agile team depends on a scrum master.  It is part of the scrum guide and is a necessary to help teams improve.  When the team is having a bad day it is particularly important the scrum master is around to listen team member’s vent.  Listening is one of the most important skills of a scrum master.  It will help you diagnose problems with the team and learn about the obstacles which are creating that bad day.  Some of the issues are interpersonal, in this way it is up to the scrum master to play therapist and counselor to the individuals having problems.

This work is hard and emotionally draining.  Some of this work can be futile.  One employee spent most of their time not doing work instead of completing projects, it drove me insane.  If they spent as much effort doing what was expected as they did attempting to avoid work they would have been a valuable team member.  Instead, deadlines were missed and the morale of the remaining team was brought down.  I spent much of my time doing HR work documenting this individual’s malfeasance and senior leadership could not or would not remove this individual from the development team for cause.  It would take the entire team turning over and a series of layoffs before this individual would be let go.  It took three years to manage out a bad team member from a scrum team when it should have been a matter of weeks.

Other times you have members of your team who are whiny, entitled, and unable to follow directions.  The project management tool is too complex.  People are not returning phone calls and they can’t get work done on time because they won’t work more than forty hours.  When you attempt to coach these individuals they have an alibi for their behavior and ignore your direction.  These are people who are not good enough to keep and they too good fire.  You are going to spend most of your time working with these individuals.

Sometimes, I have to let down the mask of command and let the team know that I am sick, tired or angry, otherwise it will come out in a spasm of unprofessional behavior.  I am constantly on guard of mansplaining to a co-worker.  Sometimes it gets to the point where I have to say, “I am very angry with you and in order to be professional with you I have to walk away and cool off.”  It isn’t pretty, but for me it is necessary if I am going to do my job properly.

Sometimes I skip lunch with my team members so that I can collect my thoughts.  Other times, I leave the office to take a walk or go to the barber shop to try and improve my attitude.  The point is you cannot always be upbeat and inspirational every working day of your life.  You are allowed to have bad days.  This might explain why psychotherapists always have a professional therapist to speak with.  Dealing with all that mental illness and human suffering takes an emotional toll and they need to speak with somebody who understands.  I wish there was a service like that for scrum masters.

So don’t worry.  You are allowed to have a bad day.  What you are not allowed to have is that bad day effecting your long term effectiveness or your team.  Take time out to unwind and de-stress.  Walk away from situations which trigger anger and remember that the scrum team needs you in order to be successful.

Until next time.

How do you fund these Agile projects?

Software professionals are not Lego bricks.

I had the good fortune to finish a training course by Benjamin Day about scrum master skills.  I highly recommend you visit Pluralsight and take his course.  One of the more interesting things about his training was the conversation about how to do annual budgeting with Agile and Scrum.  This week I want to discuss my observations on the subject.

Isaac Socalich wrote a blog post taking about “Legacy thinking” holding back agile adoption at organizations.  He cites the way projects are funded saying accounting practices lead organizations to fund and allocate resources only once around a product, project, or process improvement.  In short, a project has a start, middle, and end.  The people, funding and output of the project are cells in a spreadsheet which manages the project.

This legacy financing model is short sided, counterproductive and the antithesis of the agile movement.  The Agile manifesto stresses “Customer collaboration over contract negotiation,” with legacy financing of projects every activity is reduced to contract negotiation.  The project is conceived with unrealistic expectations.  The deadlines for completion do not reflect the opinions of those doing the work.  Customer considerations are ignored and the funding is at best a guess done by an accountant.  It is no wonder so many software projects fail.  

The most aggravating part of legacy thinking is that treats consultants and people who do the work as machine tools which can be replaced when they are no longer useful.  Teams are created and disbanded based on funding formulas rather than business needs.  This means technical professionals are being treated like mercenaries to build software.  This also creates technical professionals who have no personal investment in the products they are creating.  They are temporary workers billing hours and doing work with no real concern for quality.  

For example, an off-shore team is working on software and because of a lack of funding they are disbanded.  Four months later, the finance department restores funding and a new team is spun up.  The original developers are gone along with the two years of experience they had on the project.  The organization now has to spend the first six months of the project training the off shore team about the business and navigating the legacy code.  The remaining six months of funding is spend attempting to do a year’s worth of labor.  Quality suffers, deadlines are missed and the customer is dissatisfied but the project was correctly funded by the business.

Software teams should be professionals invested in the business and each other rather than disposable Lego bricks.  Projects should be spun up and spun down being given to these project teams.  These teams should remain constant while the projects come and go rather than the other way around.

This is why I like Benjamin Day’s approach so much.  Instead of setting arbitrary deadlines and features to be done by the development team which has no investment in the success of the project, the team is permanent with growing business knowledge and technical skills who take on projects as they are funded.  The business people also concentrate on setting priorities of what gets done.  The project is not thrown over the wall for IT to figure out or fail.  Finally, the business has the right to cancel the project if it is not working.  The team remains to take on the next challenge.  The business either discovers it has working software for the customer and does not need as much funding saving money or has been making a poor investment and can cut its losses.

Over the last fifteen years the Agile Reformation has made great strides in making software development better but it appears that business suites and finance teams are not changing their processes to accommodate this new approach. They do so at the risk to their own business.  Survival is not mandatory and these legacy finance issues will be a cancer in many businesses in the future.  It is up to us in the agile movement to try and help those worth saving.  Otherwise, technologists will be condemned to careers of temporary employment, failure and frustration.

Until next time.

Making a Difference

How does a scrum master describe his job at the
office party?

The other night I was having dinner with someone who worked as a nurse.  I understood what they did for a living and when they discussed their work it was easy to understand their frustrations and successes.  Then I told them I was a scrum master and they gave me a blank stare. It seems the world of technology has not filtered out to the fly-over country and so I spend a lot of time explaining to people what I do for a living.  This week I thought I would help others have that awkward conversation about what you do for a living.

At first, I struggled with metaphors to describe what a scrum master does.  In a way, we are coaching helping software developers and business people do their work faster, better, cheaper, and with less hassle.  It did not seem adequate.  Then I thought about Stephen Ambrose and his book, Band of Brothers.  A scrum master is like a platoon leader for a group of para-troopers.  They lead, look after the well-being of their people, and are on the front lines of the software development action.  It seemed a stretch because I do not jump out of planes or get shot at by enemy troops.  May-be a scrum master is like an orchestra conductor getting developers and the business to play together.  Again not very good because classical music does not have a culture of improvisation that developers use to get the job done every day.

May-be I should skip the metaphors.  Each day, I work with developers from Chennai, India.  Then I go into the office and try to work with the on shore developers.  Next, I help my product owners learn to write business stories.  I spend a few minutes being demeaned by my project manager and try to stay positive for my software developers and my business leaders.  I manage up setting expectations and receiving one-word e-mail replies from vice presidents who don’t have time for me unless something is wrong.  I am sweating deadlines, answering awkward questions, and pushing the people I am responsible for to complete deadlines.

I have to be a cheerleader staying positive in some of the most discouraging situations.  I have to be an actor because I have to receive abuse and condescension from business people and say that I like it.  I am a business consultant showing people how to do things a better way and I am a therapist as I help my developers get through personal problems and business frustrations.  It is also a calling like being a member of the clergy because we are pushing people to see a better way.

The best answer I can give is that a scrum master makes a difference.  Many of the software products you use and the apps on your phone are built by software developers.  The scrum master makes sure that construction gets done.  The scrum master keeps the wheels of the global economy spinning as they take numerous conference calls and sitting through endless meetings.  We are not middle managers; we are on the front lines making things happen.

So the next time someone at a holiday party makes a remark about what they make, smile and given them a steely stare and say you make a difference.  It is the only way I can describe what a scrum master does.

Until next time.

Product Owner Anti-Patterns

If your product owner behaves like this
way they are doing it wrong: very wrong!

Every scrum master needs to be on the lookout for some anti-patterns in how product owners do their jobs.  In a perfect world, the product owner and the scrum master are like siblings working toward the same goal.  The reality is that mismatched business priorities and lack of cooperation by business partners can happen in any organization.  So this article will help you recognize the smells which you should look out for as a scrum master.  I hope a few of you will be kind enough to provide some suggestions of how to deal with these anti-patterns.  Many of these examples come from Roman Pichler’s excellent book on product ownership.

The Under Powered Product Owner

We have all seen this product owner.  They have the look of an abused animal.  They are not empowered to say “no” and they when they say that they speak for the business you know what they are really saying is they speak for their boss who will overrule them when it is convenient.  The under-powered product owner is a figurehead who is their because the scrum process says so.  The people with the real say will not abdicate their authority to let this product owner do the job.  The authoring of user stories consists of being called into the boss’s office to take dictation from the boss.  Priorities are set by the boss and if something goes wrong it is the fault of the development team rather than the boss.  Everything is a priority so nothing is a priority until something goes wrong which triggers a spasm of unsustainable development. 

The Over Worked Product Owner

According to Certified Scrum Master training, each software project should have a product owner and a scrum master along with a group of developers ranging in size from five to seven people.  Executives look at this as a waste of resources and often assign multiple scrum masters over many development teams and do the same with product owners.  The by-product is the over worked product owner.  Currently, at my firm I work with a Product owner with his work divided among four software development teams.  What this does is that it forces the Product owner to only spend the minimum amount of time necessary to get stories written and to make sure that priorities are getting fit into the sprint. The stories are rewritten by the scrum master or another developer so they are clear enough to be understood by the other developers.  Stand up meetings, retrospectives, and demonstrations are missed because they are not considered critical by the product owner.  The only time they turn up is when something goes wrong or when upper management is paying attention.  Quality suffers, and the notion of sustainable development is nothing more than a sick joke.

The Absent Product Owner

Sometimes projects are kicked off and the executives who demand the work can’t find or won’t hire a product owner.  The software is still expected to get written but no one can be bothered to write the user stories.  Software developers and scrum masters should just be smart enough to find out what creates user value.  This creates situations where what is constructed is often not what the business wants. Fortunately, the failure process is faster so the executive can ask questions like “what is wrong with you people?” and “this is a simple business process why am I paying you so much money to screw this up?” 

The Product Owner by Committee

Some projects have a great deal of visibility and multiple project teams; this creates the product owner by committee.  These are individuals who are all empowered to write stories in the backlog and they are also equally empowered to set priorities.  This pulls the development like taffy and forces the scrum master and the development team to juggle priorities with dexterity of chain saws.  One mistake creates, the loss of a limb and the destruction of a career.  In addition, the horrific aftermath generates meetings which are outside the scrum process and cut into the productivity of the team.  This is why many of us in the agile community are discussing how to scale large projects because multiple development teams and product owners leads to this situation.

The Rogue Product Owner

This is a product owner who has his own personal interests in mind rather than the needs of the business when creating work for the development team.  You know when you work for a rouge product owner when your boss comes to you and asks what your team is working on.  This is because the team is making life easy for the product owner but new customers are not being generated because the features to attract those new customers are not prioritized as highly by the product owner.  This undermines the agile process because the only value being created is for the product owner instead of the business. 

So there you have it; five different anti-patterns for product owners.  Be on the watch for all of them otherwise your life as a scrum master is going to become very painful.

Until next time.

Agile and Scrum Prevent You From Cutting Off Your Own Hands

You can learn a lot about software from a table saw.

Over the weekend, my father and I collaborated on a woodworking project for my home.  As I have grown older, I appreciate the time I have with him.  Over the last seventy years, he has acquired plenty of wisdom.  He likes to share it with me from time to time.  This week I want to share my father’s wisdom with you.

We were working with a table saw constructing a gaming table for my house.  I am intimidated by power tools.  I am afraid of injuring myself or someone else.  My father said, that my fear was justified but I needed to get comfortable with power tools because, “It isn’t any harder than writing software,” he joked.

After a few hours on the table saw, my father mentioned, “We have plenty of wood son; you only have two hands,” At this moment, I realized this bit of wisdom also applied to software and Agile.

Too often, software developers are trained in isolation learning to work by themselves.  They do not learn to work with others and once they basics are mastered they develop their own “style” of programming which is often incompatible with other programmers.

You also do not see formal training in Test Driven Development and debugging code.  I realize now this is like not warring safety goggles when you are using a power tool.  The “commando code” style many developers learned needs to go away because when something goes wrong it really goes wrong with that style.

Unit tests make sure that if a class changes and functionality is disrupted a developer can find and diagnose the problem.  Otherwise, it could take hours to track down and fix the problem.  Source control systems such as Git and TFS exist to make sure everyone is working on the same code set.  This prevents one developer from overwriting the changes of another developer.  Finally, design patterns like SOLID, make sure that developers have a common reference point to discuss the architecture of software.

As a junior and intermediate developer, I rebelled against these practices.  Now that I am a senior developer and scrum master, I embrace them.  My career is testimony to this change of heart.  I have broken software builds, destroyed production servers, and over billed numerous credit cards.  The results of this carelessness were long bouts of unemployment and financial hardship.  To put it mildly, I have figuratively cut off my hand more times than I can count.

So to my fellow Scrum Masters and developers.  Slow down there is plenty of wood but you only have two hands.  It is advice, I should have followed years ago.

Until next time.

Software is Never Free

Just like the Merchant of Venice
we all need our pound of flesh.

Being a software entrepreneur is a difficult business to be involved with.  I spend much of my time writing software and then the remainder selling it to others.  It is difficult and I could not think of anything else I would rather be doing.  Still I do have one big challenge and it is the same challenge all types of creative people are facing.  It appears that in this internet world of abundance they do not have to pay for books, music, or software.  This week I would like to explain why software is not free.  Someone has to pay. 

I believe that this notion that software should be free was spawned from the Linux movement during the Dot.Com boom days.  Countless pixels have been spent expressing the view that software should be free and that copy writes for things like books, movies, and software were quaint notions from the pre-internet days.  I think it was professionally and culturally poisonous for the software industry.  Please let me explain.  

Software, music and books are the one of the few things we have not figured out how to automate.  The creative process necessary to build them are labor intensive and imprecise.  These processes are also prone to spectacular failure.  This is why when you check the CHAOS report it is clear why many of the software projects are challenged or failing.  It is hard to match the expectations of the people paying for the software to the abilities of the people writing that software. 

Along came the Linux movement with the religious fanaticism of the Opus Dei.  Linux was a version of the Unix software program which was developed by AT&T during its monopoly period of the 1950's and 1960's.  What made it unique is that it was freely distributed over the internet via download.   This meant that instead of paying a license for an operating system for a computer it was free.  Companies sprang up to support this ecosystem of Unix and provide a means to cash in on all the companies who didn't want to pay for software but didn't know how to use it.  So the tradeoff for a company was no cost for software but huge fees for labor to maintain and customize the software.   This spawned a system of software which is used today in the corporate world; Oracle Databases, Java Development, and PHP for web development.

I suspect that the Linux movement had to happen because companies like IBM and Microsoft made a very good living off charging people to use their product.  To software developers who tend to be an iconoclastic lot having free and open software was a nirvana of sorts.  Upgrades were based on the needs of the community and weren't subject to a corporate project manager.  Finally, the open source Linux movement emphasized the technical ability of the developer to make changes to core systems and improve the product.  Thus, free software seemed to be the best of all worlds; developers judged on merit, free products which respond to real needs, and something that was technologically elegant. 

Of course, something was missing.  Since these free products we constructed by engineers for engineers, for non-technical people they were impossible to use.  MS-DOS from Microsoft abandoned command line prompts for the windows interface for a reason.   They wanted more people to use their systems.  The Linux movement still used the command line.  In addition, major manufacturers did not create Linux personal computers so they had to be created by hobbyists and Linux fans who have been affectionately labeled a "priesthood" because of the difficult process of developing technical competence and the religious devotion they have to the Linux world view.  Finally, no one had time to write Linux software.  This is because many of the people who worked with Linux were busy updating the system and working in the corporate sector keeping systems working; in other words, with no killer application that would force people to use Linux people in the consumer realm did not use it. 

Flash forward to today, now an entire generation has grown up with free software.  Piracy is rampant in music and on-line books and when I hand a contract to a client they look at me like I am crazy.  "You expect me to pay that much," they say and I grit my teeth and say yes.  Just like my customers, I have bills to pay and mouths to feed.  They charge for their services so why should they be shocked and surprised when I charge for mine.  I think this has been my biggest frustration as an entrepreneur.   I am charging for my services and many people think I should be giving it away for free. 

I think I have a pretty good service to offer.  I have an inventory management system which works over the cloud and can be accessed via a browser, tablet, or mobile phone.  I am in the process of completing a contact management system for the insurance industry which will make it easier for people to trace sales and leads on-line.  It also works with the cloud via a browser, tablet, or mobile phone.  I am even leveraging QR codes for advertising and contact management for small businesses. 

It is an exciting way to make a living but it requires people to realize that software is not free.   It requires blood, sweat and tears to create.  I have invested most of my life into software.  You should invest a little money into to product I sell you.

Until next time.