The Benefits of a Good Backlog.

My career is an adventure. Each week, I face new challenges as I attempt to help organizations deliver working solutions for the last ten years. I have experienced the Good, Bad, and Ugly of the technology business. I have never been a significant player, but in my small way, I have attempted to make life in the cubicles of your local office park a better place to work. Last month, I concentrated on creating a quality product backlog, and today, I want to summarize my thoughts on the subject. 

A product backlog is nothing more than a fancy list of work to accomplish. It should focus on delivering value to customers. Finally, it should obey the principles of Roman Pitchler's DEEP model. If these simple requirements are satisfied, your project and organization will be more successful than many attempting an agile transformation. 

The business exists to provide goods or services to customers. If done correctly, it is a mutually beneficial relationship where the customer gets what they want while the business makes a profit. It is up to the business to minimize waste and keep the customer happy. I am always amazed at how often this idea gets lost during a project. 

Inefficiencies and dysfunction reveal themselves during projects, and many of those issues are not engineering issues but are instead the products of human frailty. Ego and insecurity stalk the cubicles of many business organizations. High-paid executives throw their authority around to justify their existence. People will claim credit for work they did not do. Finally, pressured for time and short-staffed, people are expected to create complicated software solutions. It is no wonder that burnout is so rampant in the industry. 

I consider a healthy product backlog to be vital to success. Prioritization pr
events the highest-paid person in the room from overriding the organization's goals. By pointing out the importance of work to the organization and customers, questions of ego and authority fall away. If priorities are out of line with market demand, then the organization can pivot because the product owner and leadership team have an emergent backlog. We are empowered by estimation to make informed predictions about when work will be finished. Instead of an entire file cabinet of requirements that no one reads or refers to, the level of detail is sufficient to create working solutions. 

A simple structure of Bugs, User Stories, and tasks obeying the same workflow reduces conflict within a team and the larger organization. I wasted ten hours of billable time getting a development team to accept a product backlog item as a defect instead of a change request for one client. Because they were not paid to fix defects, the team treated everything as a change request, wasting time and avoiding the need to mitigate their poor code quality. A more straightforward backlog structure and clear expectations would have saved everyone involved time and money. 

The most crucial part of having a clear product backlog is that it is a public and transparent way to communicate how work moves through the organization. If someone wants to add work, they have to go through the product owner, and they can see the story move from creation to development to production. The organization sees how work flows through the system, and the organization can use the theory of constraints to help make necessary improvements to the system. Just like there are no secrets at a crap game, a good product backlog does not have any secrets. 

Each week is a new adventure, but with a proper backlog, most surprises are not career-threatening. 

Until next time. 

It Is Never a Ten Minute Fix

Being a technology professional is filled with ups and downs. It is a well-paid profession, but it comes with plenty of trade-offs. I can cite many examples. I remember getting a tech-support call when celebrating my anniversary dinner with my ex-spouse. One time, I was referred to as the "nerd boy" in the office by the Vice President of marketing. My company fired me a week before Christmas because I made a mistake after working sixteen hours the night before to fix a problem with the credit card billing system. The compensation is excellent, but the job security is harsh, considering that business people think what we do is easy. It explains why software professionals are cranky because each change could introduce a catastrophic failure that can cost people their careers. To save a few hair follicles for business and technology professionals, I am talking about why a quick change is anything but fast. 

I cannot speak for others, but my training in agile has taught me that I should be responsive to change as a technology professional. Plans and the business world transform with frighting regularity, so it makes sense that an intelligent business professional can pivot from their current situation to a different one. What drives technology professionals crazy are what we call ego-ware requests. An ego-ware request is a change made to a system that delivers questionable value but satisfies the ego of the person making the request. For example, a UX designer demanded a text box on a mobile web page move a tenth of a pixel because it created more harmony on the page. Such a minor change took three developers at a rate of $75 an hour three weeks to figure out, which cost the business $18,000. The money did not have any impact on the revenue of the firm. It only achieved one thing: the designer's ego gratification. The now infamous Superbowl meltdown of Elon Musk is also a classic example of ego-ware taken to the extreme. 

Besides the ego-ware request, you often get a "quick change" from colleagues who mean well but do not understand the ramifications of that request on the overall systems. I remember someone asking me to add a field to an HTML web form and make it optional so the call center could use it for notes. The call center supervisor said, "Come on, Ed, it should only take ten minutes." I firmly believe that statement is a sign pointing toward hell. 

Long story short, I made the change. I did some testing and then deployed it to UAT. I was a hero in the afternoon. Three weeks later, I was fired because the change created production problems, preventing customers from making payments. The extra field broke the payment API, and customers were ticked off. The development manager looks at source control and the last production push with my name on it. My boss told me to pack my desk and go home. Stories like this are familiar in the technology business, and it is why developers do not like to make arbitrary changes. 

What looks like a ten-minute fix to the business is a series of events requiring time and attention to detail. The actual code change will take ten minutes. Updating all the unit tests for the application might take four hours. Quality assurance can finish testing in a day if they are not busy. After testing, it will be deployed to a UAT environment so the business can test deployment to production. If anything goes wrong, the entire process starts over again. A ten-minute fix is a whole week's worth of work. It is another reason software engineers get cranky because the change may not be significant, but the implications on the system are. 

To recap, software engineers, are grumpy about system changes because it could first put their careers at risk if something goes wrong. Murphy's Law impacts technology more than any other part of the business, so the risk is higher than most professionals will accept. Second, to avoid those risks, the organization creates test-driven development, quality assurance people, and stage gates to software release. The deliberate friction between the idea and the actual costs, time, money, and the frayed nerves of the IT staff means that if you change a system, you better have a damn good reason. 

Software is one of the few human professions that can not be automated. So the next time you ask a technology person to make a minor change and they tell you to jump into the lake, the software engineer is not being insubordinate; they are responding rationally to something which might threaten their career. It takes real people time to make each technology dream a reality. 

Until next time. 

Some Thoughts About the Great Flattening

Returning to work is a powerful emotional experience. My friends and colleagues were glad to see me, and a pile of work awaited me upon my return. The time away gave me a deep feeling of gratitude. Of course, I had to kick some rust off, but it did not take long to gain my bearings and return to the usual flow of work. My body had other plans, and I had to rest as the healing process continued. It was a strange week in business news. The late reports about technology layoffs pointed out that discharges disproportionally targeted managers at companies. News also surfaced that Meta was attempting to “flatten” its organization. I have spoken about management and leadership on this blog, and I need to share more. 

I always disliked the term manager. In my experience, leadership at any level is more significant than official management titles. It implies an act of authority over others which is short of leadership and greater than building customer value. Serving in a management role also includes plenty of responsibility with none of the corresponding authority. It creates awful paradoxes where people are being pushed and pulled in two different directions, first by executives above and then by the people they serve below. It explains why recent surveys of middle managers show that 43% suffer from burnout. 

It also does not help that many executive suites have the characteristics of the VIP room at an exclusive nightclub. Many executives come from similar MBA programs and have yet to spend time working with customers or employees. When this happens, tunnel vision takes over, prioritizing what the executive team wants versus what the customers might be demanding. It is all fun and games when interest rates are low and business is good, but increasing interest rates and venture capitalists looking for the next big thing trigger over-reactions. The recent tech layoff is an example of these over-reactions. 

So with executive leadership looking out for themselves during difficult economic times, middle managers and front-line employees bear the burden. Naturally, those left behind in the aftermath of layoffs must take on the duties of those who are gone. It is a significant problem in the technology industry because work outstrips the number of competent people to complete that work. It explains why Meta is attempting to flatten by forcing its managers to code with their teams. 

To an executive, this seems logical, but it is fraught with peril. First, programming is a creative skill like music or dance. It is rare for a choreographer or conductor to return to the performing company because they often need help to physically perform the skills. Next, asking technology managers to code and perform their typical management duties means they must improve their skills. Requiring a manager to code means less time for meetings, performance appraisals, and transmitting messages from executive leadership. Executives might say those functions are unimportant but will be when raises and vacations are late for line employees. Finally, managers are connective tissue within the organization because much of the work is too specialized for executive leadership. Someone needs to make sure the network engineers keep the network running. A good accountant must keep accounts payable up to date. Human resources people understand the law and can prevent both strikes and lawsuits. Without this specialized knowledge, most modern businesses would collapse like a house of cards. 

I lived through two downturns in my career. It is not pretty. However, the executives who try to flatten organizations often discover that they need the managers and specialists they depend on to run the organization. You should expect sanity to return to corporate offices in twenty-four to thirty-six months. Let's all tough it out in the meantime.

Until next time. 

Southwest and Lessons of Technical Debt

Kicking over an ant hill resembles an Irwin Allen disaster movie. It is a frantic and desperate scene. Insects scurry in all directions attempting to make sense of the catastrophe and repair the damage. Some ants try to bite or sting the offender who upset their home. It constantly happens in nature, and the scene is repeated in business as unforeseen events conspire with neglect to create desperate situations for professionals. The latest example is the recent trouble at Southwest Airlines as it attempts to recover from bad weather and worse software. Today, we kick over a metaphorical ant hill and look at how to avoid this catastrophe. 

News stories circulated over the holidays about Southwest Airlines and countless passengers stranded in the middle of holiday travel. The press was so bad that Southwest offered 25,000 free air miles to its passengers as a sign of goodwill. How on Earth did this happen, and why? 

While working on my MBA, Southwest Airlines was a thorough case study on how to run a business properly. Flight attendants worked with management to understand scheduling. The organization and its labor union have a collaborative relationship. A reality TV show featured Southwest gate managers highlighting customer service challenges. Seeing headlines featuring incompetence and dissent within the Southwest organization was discouraging. 

How did such a great business fall so quickly? The answer became clear when Business Insider shared an open letter from the head of the pilots union, which pointed out that the former CEO, Gary Kelly, did not invest in updated software for pilot scheduling. Kelly also packed the organization with cronies with a common background from the accounting program at the University of Texas. Discussion about how to run the business moved from the pilots and other employees to the executives' leadership surrounding Kelly. It was great for the organization's profitability, which made money when other airlines faltered, but it was a situation where the qualities that make Southwest unique atrophied. Most damming was the deliberate neglect of technical debt in the company's software scheduling of pilots. 

I talk about technical debt as an agile coach and consultant. I have written about the subject on several occasions. Software and data are as vital to customer service as adequately trained people and well-maintained aircraft. As software continues to eat the world, it is incumbent that business leaders pay attention to the operation of their software systems because if they do not, they will experience expensive and embarrassing episodes of business interruption. It appears that Kelly, who is still the chair of the board of Southwest, is being exposed to that costly lesson.

Technical debt in a business organization point to deep organization failures. If a business fails to update its systems, it shows it does not care about the proper operation of the company. Somewhere, someone calculates that updating systems does not have an immediate financial benefit, so they neglect it. Over a series of years, the systems become more brittle and unable to deal with changing conditions. The result is ill will from customers, lawsuits for poor service, and a large financial hit to the organization. All of which could have been avoided if leadership had paid attention to the technical debt sooner. The east coast snowstorm around Buffalo was the final straw, and it took Southwest longer to recover. 

I am not surprised by this story. Many organizations have this problem, and it takes an event like this to make it relevant to business leaders. In truth, having your organization experience something like this is an excellent way to avoid inertia and complacency. By having your metaphysical ant hill kicked over, you pay attention to the operational issues that matter. Southwest will pay for this; I hope they have learned their lesson.

Until next time. 

Software is NOT transcription!

One of the most challenging things about working in technology is explaining what I do to others outside the business. A chemical engineer at a food company can explain they help create flavors or ensure the potato chips we eat are consistently crispy. A petroleum engineer transforms crude oil into gasoline and other valuable petrochemicals, making modern life worth living. An agile coach, scrum master, or software developer has difficulty explaining what they do. Sometimes it looks like magic, and other times, it resembles tedious bouts of frustration. There are plenty of ways to describe my profession, but today on the blog, I want to explain what it is not. 

Nothing is more frustrating for me professionally than interacting with executives who earn their leadership in their organization by mere survival. These people look like leaders but do not exhibit leadership characteristics because survival in a dysfunctional organization is the only accomplishment they can proclaim. They were mediocre people who were unremarkable employees. Eventually, these people are promoted by someone because they do not threaten the status quo and the leaders above them. These executives are allergic to risk and innovation because it would threaten their position.  

Countless times I have been in the office of these individuals and their faux leadership. One ordered me not to speak to other departments because he did not want the different departments to learn about our challenges with software releases. Another explained that we were not a technology company, so to expect us to behave like a technology company was foolish. I even had a vice president pat me on the head and call me ‘son’ before explaining how I did not understand modern branding. Naturally, when layoffs came, these paragons of leadership remained, and I was made disposable. 

These leaders are toxic and insulting to the professionals who keep the global economy spinning. By far the worst was a salesperson who said, “Software is easy; you just transcribe our order forms into the inventory system.” At that moment of emasculation, I knew it was a matter of time before I would quit the organization to do something else. Software development is not transcription! It is a complex process of taking business artifacts like forms and turning them into strategies that deliver value for the firm. It is not a transcription but countless creative decisions that developers make that have numerous implications for the business and the software development process.

The dismissive notion that software is just transcription is self-defeating. For example, how does an order form behave once a customer fills it out? Developers will ask about the impact of the order on the inventory and accounts receivable system. Software engineers worry about what happens if an item is missing from the warehouse. Can a data team use the inventory to track trends and determine how to serve customers better? Finally, what else should the ordering system do to deliver value to the business? It is a game with thousands of questions, and developers need to answer them to make the software work.

The technology world overflows with intelligent and talented people. Despite layoffs, the technology world has an over-abundance of work and needs more people to do it. Business leaders want to throw as much work at employees as possible because their labor is expensive. It is this crazy ratio of supply and demand which drives much of the dysfunction in the technology business. Instead of creating a cycle of productivity, there are episodes of burnout and failure to deliver. 

Over the years, I have been profoundly disappointed by business leaders who do not understand technology or how to lead others. I joined the agile reformation because I know that there are better ways to lead others and deliver working software. The business world needs reform, and it is up to people like me and you to speed that process along, so now, when a toxic leader says software development is easy, I know what to say to convince them otherwise.

Until next time. 

Agile defeats Brutality on the Battlefield

War isn't about the brutality

Since the beginning of this blog over ten years ago, I have been an advocate of working differently.  The IT world was and still has plenty of talented jerks.  Women and people of color are underrepresented in the ranks of Software Engineers.  Finally, LGBTQ people labor under a cloud of etiquette in the technology business, which is a shame because much of the business would not exist without the contributions of Alan Turning.  Over my career, the situation has improved, but we have significant improvements yet to achieve.  I have fought for this change my entire career.  Reform is difficult in the best of situations.  Even so, it's even more complicated when people fetishize the past that did not exist or feel threatened by people involved in decisions or creative processes.

The most exciting thing to happen in the last fifty years of American history is the gradual acceptance of the variety of people who make up the United States.  The law and public opinion witnessed the approval of the religious and those who do not believe.  Gay people can live their lives openly, and that acceptance has led to a debate about the commercialization of the gay rights movement.  Technology workers from India and Pakistan have exposed American to Muslim and Hindu cultures.  We even see women participating in politics on a level not seen before.  

The progress generates a vocal and sometimes violent backlash.  Individuals in our society struggle with dealing with different types of people with who they do not understand or identify.  Both politicians and media figures have embraced this backlash to make money and gather political power.  This week pundits Ben Shapiro and Tucker Carlson lamented the state of our military for being too 'woke.' Never missing an opportunity to call attention to himself, Texas Senator Ted Cruz joined the public debate.  The conversation was so disingenuous that republican representative Adam Kinzinger decided to call out Shapiro's bad faith arguments.  I decided to share the tweet below.  

Good point Ben. What branch were you? https://t.co/DA8o17zY90

— Adam Kinzinger🇺🇦🇺🇸✌️ (@AdamKinzinger) September 25, 2022

I am not a military veteran and do not even understand the daily sacrifices our service members experience.  I do have a strong background in military history and war gaming.  It gave me some insight into the changes which happened to the United States military since the war in Vietnam and the shift to an all-volunteer army.  Shapiro, Carleson, and Cruz are wrong.  Brutality and firepower do not make a military successful; instead, it is diversity, intelligence, and agility.  I have first-hand knowledge about this subject because I am hosting two Ukrainian refugees in my home.  The stories they tell about the brutality of Russian troops are chilling.  There is also widespread evidence of war crimes committed by entire Russian units.  

A modern battlefield is a place that demands grace under pressure, the ability to improvise, and finally, a will to fight, and based on what we see in Eastern Ukraine, the Russian army lacks those values and skills.  The reason is that the Russian military still thinks it is fighting the Second World War despite its tanks, artillery, and planes. 

While attending training as a product owner, the instructor said something interesting to the class.  He said, "The largest agile organization is the U.S. Army." I chuckled a bit at that notion, but he reassured the class that it was true because everyone spends time in training to do their job.  Soldiers in the field are constantly tinkering around to do their jobs better.  Finally, after a mission, military people have "after-action reports," where they attempt to understand what they can do better.  "There is no way you have a volunteer army without an Agile mindset," he said. 

It brings me to a few articles on the web.  The first is from the Atlantic this week from Phillips Payson O'Brien.  I will include his article here, but he points out that the brutal army of Russia is getting its head handed to it because the Ukrainian military is more flexible, technologically conversant, and willing to learn.  Additionally, unicorn soldiers prove that LGBTQ troops are as deadly and heroic as heterosexual troops.  

The more informative article is from agile coach Dmytro Yarmak who became a Ukrainian Military Officer overnight and February 24, 2022.  Commanding a Ukrainian artillery battery, Yarmak says many of the skills he has as an agile coach make him a better leader of troops.  Empathy, pushing decision-making down to ranks, and giving people purpose and mastery instead of orders is how he runs his unit.  It is a powerful lesson that victory belongs to the agile instead of the brutal in war.  

This blog is a bit of a departure for me.  I do not like to talk about current political events and would instead focus on the ups and downs of the business world.  The Ukraine war has lasted six months, and I can no longer ignore it and its impact on the planet and my family.  It also reinforces my belief that we can have a more sustainable, sane, and satisfying work world if we abandon notions of brutality and ignorance for something more agile.  

Just as the Cultural Support teams of the United States Army proved that women have a role in combat during the Afghanistan War, it is evident that agility on the battlefield is more critical than brutality.  Something I doubt Shapiro, Carlson, or Cruz would understand.  

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. 

We need fresh blood in technology

It is a new year, and after all of the parties and gatherings, it is time to roll up our collective sleeves and get back to work.  The global economy requires plenty of labor, and we do not have enough trained people properly to maintain it. Today, I want to talk about this challenge.

Less than five-hundredths of a percent of the world population know how to write software and maintain computer networks.  All of the global economic data and information travel through those networks, so recruiting new people each year is essential to help maintain and improve those systems.  I think we have done a poor job in this regard.  It is why I will always support people looking to get into the profession. 

In many respects, being a software developer is like being and musician.  Practitioners can be self-taught or have years of classical training.  Each approach has its merits, but a musician needs to develop “chops” to succeed.  It is when a musician learns to improvise and interacts magically with an audience and other musicians. 

Thus, writing software is not learning a particular programing language; it is a way of working with others that maximizes quality and delivers value.  It requires attention to detail and learning how to write a unit test to know that something will work the same way each time it is in a production environment.  It is not an easy process, and it took over ten years of trial and error to consider myself competent.  The profession has a way of humbling the best of us.

Support others who are attempting to get into this crazy business.  Encourage people to set up GitHub accounts and experiment with new coding tools.  Encourage women and people of color to join the activity because their presence will help improve quality and deliver value to a broader audience.  Agile is a significant movement, and the more people we have creating quality software, the stronger it will become.

Until next time.

 

 

Agile Coaching Requires Walking Away.

The path of the righteous man requires walking away.

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

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

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

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

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

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

Until next time. 

Failure is the Fertile Soil for Growth

Failure happens

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

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

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

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

Until next time. 

Professionalism and Developers Part 1

Developers see the world differently.

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

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

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

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

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

Look forward to seeing you then.

Until next time.

 

When Culture Eats Agile for Breakfast.

Bad Culture is like canoeing over a waterfall.

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

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

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

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

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

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

Until next time.  

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.

Be on the Look Out for Workism

Even Elves need some rest.

The Christian holidays are close and it is easy to become caught up in the bustle of parties, shopping, and family gatherings.  The biggest challenge is weighing the exclusive demands of family and career.  Derek Thompson wrote an excellent article about the subject earlier this month.  As a member of the agile reformation, I want to remind my fellow professionals of the danger of workism.

Speaking for myself, I become a software developer for two reasons. The first reason was I was chasing the hype and wealth of the first internet boom.  It was a giddy and stupid time where Bill Clinton was president, and anyone with a “.com” at the end of their company name wasted millions of dollars.  I wanted to be one of those twentysomething or thirtysomething millionaires writing code instead of being told to smile more while casino patrons blew cigarette smoke into my face.  The other reason was I was good at it.  I became a wizard with Microsoft Office and was soon glancing at Visual Basic code like I was reading the morning news.  My dream of working afternoon drive at a classic rock radio station evolved into becoming a web developer.  The pay was better and it gave me a career that I did not enjoy in my twenties.

Looking back, I realized I joined the technology during a dramatic period of expansion.  I was one of the numerous anonymous workers who helped construct the contemporary internet we enjoy today.  I was an early consumer of social media with a MySpace page.  I was using a smartphone before the birth of Android.  I witnessed the evolution of Microsoft from an evil empire to an innovator in Cloud computing.

It was not an easy road to travel.  I failed numerous times, working for every type of business imaginable.  I became an entrepreneur and failed, and each setback and disappointment set the stage for more significant success.  These experiences helped me coach other professionals so that they avoid the mistakes I made in my career.

It is also a profession where less than one percent of the world population can do it successfully.  It often means cramming various amounts of work into a single workweek.  Developers and network engineers work long hours keeping the global economy working.  It is intellectually demanding and detail-oriented.  Imagine a world where checks do not manifest, or shopping on-line comes to a stop. It is a nightmare world I would not like to live in.

The lucrative work and the shortage of people who can do it successfully translate into long hours.  Thompson in his essay in the Atlantic talks about workism.  It is a career focus that puts family, friends, and community at arm’s length.  High skill workers benefit from long hours in ways that low skill workers do not.  If you work in technology, you are expected to work long hours because it is cost-prohibitive to find people who can do the work.  It is also the only way for a professional to advance in their career.  As Thompson says in his essay,

“At many firms, insanely long hours are the skeleton key to the C-suite and partner track.  Thus, overwork becomes a kind of arms race among similarly talented workers, exacerbated by the ability to never stop working, even at home.  It’s mutually assured exhaustion.”

Executives enjoy exploiting this arms race to get more out of their employees.  In the agile world, we need to push back against this exploitation.  Countless studies point out overwork is counter-productive.  Workism has severe consequences for employee health.  It hurts morale.  It also undermines the quality of the work.  Agile is about “Healthy Ownership,” a sustainable pace and delivering value to customers at a more reasonable pace.  Anything else is waste and exploitation. As an agile coach or scrum master, please be on the watch for workism.  It is a path that leads to poor quality and burnout.  The better way is Agile which is a more sustainable, satisfying and safe way to work.

I want to finish this blog by wishing all of my readers a Happy Hanukkah, Merry Christmas, and a joyous Kwanzaa.  I am sure I am missing some other holiday but I hope each of you enjoys time with your families and take some time for reflection.  I will back next week with my end of year predictions.

Until next time.

Requiem for a Software Developer

I use this blog to discuss two principle topics; software development and software developers.  It is an exciting topic, and the people who build software represent some of the best traits in the human species.  Today, I want to talk about one of them. 

Carla Robinson was an anomaly in the technology business.  She dedicated most of her career to one company.  Carla spent the bulk of her career at R.R. Donnelly, and when the company split, joined one of the spin-offs, LSC Communications.  She worked with AS/400 systems and wrote RPG code.  It was hours of staring into green screens and sorting through reams of sequential code.  She kept a legacy system alive, and as the technology business changed, she rolled with these changes. 

I knew Carla as her scrum master.  She was learning how to write C# code and unit tests.  What made her invaluable to her team was her manual testing skills and her business knowledge.  Often, she was able to answer questions about the product and how it helped the business.  She was a person of good spirits when times were tough.  Finally, she would not accept grief from anyone and demanded respect. 

She loved Bessie Smith, vintage Prince, and anything to do with dusty radio.  She was a colleague and to many a friend.  The world is a little less fascinating without her.  I imagine her enjoying some step dancing in the afterlife and feeling a sense of pride about a life and career well lived. 

Fair forward and not farewell, Carla.

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.

The Development Team Must Be a Shark

The development team is like a shark.

As a boy, I thought sharks were the coolest creatures alive.  They were ultimate predators who created panic at beaches across the nation.  Steven Spielberg made one of the biggest movies of all time featuring a shark.  Sharks were a staple on public television, and today we can enjoy an entire week of shark programming on Discovery.  The more I have learned about sharks the more I respected and admired them.  As a scrum master, I have used sharks as a metaphor for the operation of a good scrum team.

A shark is a living fossil.  It has not evolved substantially in 200 million years.  When you are the top predator in the ocean natural selection is not a powerful influence.  It does give a shark several disadvantages.  The brain of a shark is smaller than the brain of a dog.  Sharks do not breed quickly, and the creatures plunge into irrational frenzies with the presence of blood and prey.

The biggest disadvantage sharks possess they have primitive gills.  Unless a shark is swimming with its mouth open, it cannot breathe.  It is a significant disadvantage because most fish today have gills which can filter oxygen out of the water without swimming.  Thus, a shark is doomed to swim from the moment of its birth.  A shark must swim, or it dies.

Software development teams should use the shark as a metaphor for how they should operate. Organizations need to keep swimming and moving forward.  A team needs to gain new knowledge and techniques continually.  A team has to deliver software regularly.  A team has to respond to a changing environment.  A team must keep swimming forward.

As a scrum master, it is up to you to keep the team swimming.  You need to ask compelling questions.  You must insist on delivering software into production at regular intervals.  Finally, a scrum master should encourage the team to pursue “Healthy Ownership,” with collective responsibility of outcomes.

If you cannot inspire the team in this fashion, you will have a drowning shark, and you will be dead in the water.

Until next time.

Working with Kanban

Two different ways to be Agile.

When you are working as an agile coach and scrum master you are dealing with innovation at the speed of the internet.  New concepts are constantly coming into being.  It is overwhelming at times.  Luckily, I have plenty of colleagues in the profession who have experience with these ideas when they crop up. 

I was introduced to Kanban when I was training in the Scaled Agile Framework for the enterprise.  I did not think much about it at the time.  It just seemed like a variation on a theme for managing work.  I was wrong.  Kanban is agile, but it is not a subset of Scrum.  It is a different way to meet the principles outlined in the Agile Manifesto. 

For those not familiar with Kanban, I strongly recommend Eric Brechner’s book on the subject, “Agile Project Management with Kanban.” Brecher is not some crazy theorist; he is responsible for the development of the Microsoft Xbox.  In the book, Brecher not only provides basics; he provides the administrative know-how to make it work at your organization.

Unlike scrum which limits work with a timebox known as a sprint; Kanban uses something called WIP limits.  WIP is an acronym for work in progress.  The team can only do so much at a time, so WIP is the limit of that work.  The team then moves work through a queue based on WIP limits.  For example, if the team sets a WIP limit of five for development and a limit of three for QA when work meets the definition of done in development, it is moved over to QA as long as they are working on three or fewer elements.

It is obvious why Kanban would appeal to the “No Estimates,” crowd.  Work breaks down as it moves through the queue and it does not require any estimates.  Scrum rituals like backlog refinement and sprint planning fall away.  Comparing Scrum and Kanban, it is obvious to me that Kanban is well suited to exist in architecture and software applications.  Scrum is perfect for a greenfield project where rapid cycles show stakeholders how the project is evolving.  I am glad that Kanban is another approach in the agile toolbox. 

The agile manifesto says, “Individuals and Interactions over processes or tools.”  Kanban is just another process and tool you can use to help your client achieve agility.

Until next time.

Crazy little thing called Jira

Old School Scrum board.

As an agile coach, I have learned to consult the agile manifesto whenever I get stuck on how to proceed.  When I changed firms, I moved from a company which used Azure DevOps to one which used Jira.  It was a bit of a shock.  Fortunately, after working with the tool and reading the book “Agile Software Development with Jira,” I feel comfortable enough to work in a busy software shop which uses Jira.  The experience gives me additional insight into the differences between the two tools.  I want to talk about that insight this week on the blog.

Before I begin, it is necessary to have full disclosure. I have spent a majority of my career working with Microsoft products.  In 2008, I made the switch from Visual Source Safe 2005 to Team Foundation Server.  I have worked with the tool as it has grown and changed into its current incarnation Azure DevOps.  I also know members of the DevOps “Blackshirts,” at Microsoft and one of my mentors for the last ten years in this business runs a blog called “The TFS Whisperer." In short, I have a serious professional and cognitive bias toward Azure DevOps.  I have even authored a blog defending TFS from a blogger who considered it “destroying development capacity.”  If I were the CIO at a company, I would prefer Azure DevOps vs. Jira.

Now that I have confessed my bias, I am going to attempt to set it aside and try to compare the tools.  The first thing which sticks out to me about Jira is the ability to configure it.  When you create a project in Azure DevOps you have three off the shelf templates; Scrum, Agile and CMMI.  The templates can be customized, but it is clunky and requires a developer to do the work.  In my ten years working with Azure DevOps, I have not been able to do that task.  With Jira, they have the concept of workflows, and they are configurable.  I have witnessed project professionals’ fight about the configuration of workflows.  Azure DevOps allows you to configure boards with custom status columns referred to as “board columns,” but to update them, you have to view sprint backlogs or product backlogs to change them.  I consider this a serious limitation of the product and hope someone from Microsoft can show me how to do that inside a story or bug form.

The next issue is Jira has three types of backlog items; bugs, stories, and issues.  Azure DevOps only has two.  In Jira issues and stories behave in the same way.  I find this confusing, and I am observing my development community creating “tickets,” with no preference for them being stories or issues.  Off the shelf, Jira does not have tools to track git push/pull data.  You need to install a “hook.”  Build automation, and CI/CD features are also absent.  I find this absence to be a major stumbling point for Atlassian.  I should be able to track a story with code changes and build information seamlessly.

Finally, Jira appears to be very good at an individual project with one team, but it struggles at scale.  Issues, Bugs, and stories can fit into Epics, but there is no concept of a “feature,” or “area,” in Jira.  It makes it hard to “roll-up” stories into Epics for the business to easily see.  It also makes it hard to manage large backlogs because a backlog can only accommodate one team.  If you are attempting SAFe or LeSS you struggle to see dependencies between teams and how they time to larger product.  I am sure this is my lack of experience showing.

I do not consider Jira an anti-pattern or a necessary evil.  It is just a tool.  Like any tool, it can be used in a harmful manner and create serious damage.  As a coach, I need to be able to respond to change over following a plan.  Jira is certainly a change from how I am accustomed to working.  Fortunately, my agile coaches and mentors have given me a good working knowledge of how to manage a backlog.  If the stories and vision are clear, it does not matter what project management tool you use.  Jira is good enough, and I will accept it because working code in production is more important than the work item tracking tool which manages the process.

Until next time.

The Art and Science of Getting Stuff Done.

If it was easy we would figure out how to automate it.

It feels good to be back.  I left my old firm and joined a new organization.  I took the week off to get accustomed to my new surroundings and sleep schedule.  I also had a holiday week, so I used the opportunity to catch up with family and friends.  Now that I am getting comfortable with my new role, I wanted to talk about the biggest challenge we face in agile and scrum.

The creation of software is one of the few modern products we produce which is nearly impossible to automate.  We have figured out how to automate plenty of things related to software development.  Testing can be automated.  DevOps demands the software building process to be automated.  Anything which is repetitive and tedious can be automated.  Writing software requires plenty of skill and practice to do it well.  Someone needs to take the vague ideas of the business and turn them into something concrete so that the software developers can create something valuable.

It means authoring software is a human process.  Human beings are notoriously messy and prone to error.  If you accept the reality of human messiness, it is easy to understand why projects fail and work does not get done.  A colleague of mine put it best when he said, “It all comes down to people, you can have the best process, but if the people can’t or won’t do it you are lost.”

Specialized professionals have come into being to help make sure the organizations keep going and the processes work.  These people have plenty of different titles and roles.  These people are scrum masters, project managers, and bosses of every conceivable size and strip.  What united them all is they need to be good with people and have strong leadership skills.

The good news is there are plenty of good programs which teach leadership skills.  Combined with practice and desire; anyone can become a competent leader.  Thanks to the Agile Alliance and the Scrum Alliance, we can train skilled people to become Product Owners and Scrum Masters.  These courses and training programs represent the science of project management.  The art combines the technical aspects of scrum mastery and putting it together with the messy nature of human beings to create something new.  It is not easy, and it is emotionally draining.  If done right, it can generate millions of dollars in value.  If done poorly, it resembles a tragically executed piece of performance art.

So leading projects is both an art and a science.  The science understands the things like testing paradigms and the art enters the picture where you have someone with gout working late hours and not getting the work done.  It is not easy to be nothing worthwhile is easy.  So remember the art and science related to your role.  You are going to need both.

Until next time.