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. 

Can Someone Give me a Call!

It is a familiar aphorism in intellectual circles that history does not repeat, but it often rhymes. Last week, I talked about how technical debt and poor maintenance helped ground Southwest Airlines during one of the year's busiest travel periods. This week, the FAA software, which helps maintain air traffic safety, crashed, causing planes to halt for the better part of the morning. 

The system in question is called the NOTAM, which stands for "notice to Air Missions." It is a general-purpose system that tells pilots about hazards they might encounter moving commercial flights from place to place. An air show could fill up the airspace around Wichita, or a flock of birds could clog up a flight path to Cleveland. Air traffic controllers and pilots count on this system to avoid accidents. When the system went down, air traffic came to a crawl, and customers were grounded. 

As the crisis unfolded, it became clear that a software update caused the crash and upset the system. Someone uploaded a corrupt file, killing the central NOTAM system and the backup. The responsibility for uploading that system was with an outside contractor, not an FAA employee. My heart sank when I learned this because I made a mistake like this on a much smaller scale. I broke 56 credit card transactions out of 1800 for TOMS shoes during the holiday shopping season in 2008. It was a fraction of a single day's business, but it was enough of the hassle that TOMS shoes threatened to stop paying the consulting company for the trouble caused. Our company was withheld payment from TOMS for December even though we fixed the problem within twelve hours. A week before Christmas, my company fired me, and to this day, I still harbor some ill will toward TOMS and its brand. 

I imagine a consultant is looking for a new job after making a similar mistake. Unfortunately, I think that mishaps like this happened because the FAA and the contractor created a NOTAM system that was fragile and easy to break. According to John Cox, an aviation safety expert, an outage like this has not happened in 53 years. Fifty-three years without an outage is a mighty impressive record in the IT industry. Reliability like this gets CIOs extensive bonus checks. Still, it looks terrible that air traffic controllers and pilots are grounded because a software update did not go well. 

Delta airlines CEO Ed Bastian called the shutdown unacceptable but said that the incident was not the fault of the FAA but instead the result of a lack of funding. Senator Maria Cantwell of Washington said that Congress would hold a hearing on the subject. In my last blog, I said moments like this were necessary to point out system problems and call attention to maintenance and technical debt. A moment of clarity should focus the minds of members of Congress and members of the executive branch toward improving the system.

So far, the FAA website has one update on January 11th about the outage, and the news has moved on to other subjects. Transportation Secretary Pete Buttigieg has said that they have made some changes to prevent this from happening again. Still, I suspect it will take more than changing the procedures to ensure something like this does not happen again. I am suspicious that decades of technical debt and outdated servers are at the heart of the NOTAM system. It looks like the perfect project for an Agile coach and change agent to make a difference. Secretary Buttiegieg, give me a call, and we can talk about how I and CAPCO can help update your systems. 

I must confess that I am a little glib about the subject, but technical debt is a big deal. We have spent plenty of time and energy making systems efficient, so they are not resilient when bad things happen. Making systems faster, better, and cheaper is essential, but it undermines our trust in those systems if they are not resilient. Eventually, that lack of confidence will hurt the airline industry and the country. That is something that no one wants. 

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. 

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. 

Agile Slowing Down the Corporate Merry-go-round

The business world is a merry-go-round

The business world is cruel.  It is a perverse merry-go-round of glittering success and spectacular failure.  Billions of dollars are created and lost with a handshake.  Someone in the finance department has the power to destroy the livelihood of thousands with a spreadsheet. It is a world filled with fear and uncertainty.  I belong to this world.  I am an agile coach and scrum master.  Each day, I get on the merry-go-round to make sure others do not get hurt.  It is because the ride does not stop and spins faster each day.  As part of the agile reformation, I have a responsibility to make business better.

The three main pillars of agile are inspection, adaptation, and transparency.  Each day we should be able to understand what is happening around us.  Once we know what is going on around us, we should be able to adjust to the current conditions.  Finally, we should be transparent with information with no agendas or secrets so that we can start the process anew.  For those used to playing political games or hiding in plain sight, these values are dangerous.  Transparency means information flows freely in an organization.  Inspection demands we look at that information with healthy skepticism.  Adaptation means we take action and hold others and ourselves accountable.

Agile is not hard to explain to others, but it is challenging to execute.  People need to be vulnerable and trust each other.  The Harvard Business Review calls this psychological safety.  In cutthroat business cultures, this safety is absent; it is up to the coach to create these pockets of safety.  Once these pockets form, they must grow within the organization.  To borrow from the French philosophers Gilles Deleuze and Felix Guattari, agile becomes a rhizome which rises through the organization and inspires change.

Business people have been comfortable with how they ran large organizations since the 1980s.  Shareholders were more important than customers, and as long as they had priority, everything would be fine.  The digital revolution of the last twenty-five years has upset that equation.  Businesses are being created and crushed at an increasingly fast rate.  Bureaucracy once designed to increase corporate value is now interfering with the customer experience.  Poor customer experience hurts the organization.  The realization is creating anxiety among workers and executives.  A coach needs to step in and point out the importance of customers, and speed to market.  The corporate headquarters lose sight of these simple truths.

Each day, I see good people working in dysfunctional situations, and they inspect and adapt.  As a coach, you have to point this out to people who can make a difference and get them to inspect and adapt.  It is this process which makes the organization more transparent and effective.  If employees can respond to change, then business leaders can do the same.  It takes a coach to make this message clear.

The merry-go-round of business keeps spinning.  It is a relentless machine, but the agile reformation makes the ride less scary.  Using inspection, adaptation, and transparency, you can improve the business culture and leadership.  It is not an easy job, but it is mine.

Until next time.

The Strength of Technology Pros

No rest for technology

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

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

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

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

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

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

Until next time.

Transform at the speed of the Team

Coaching is more than presentations.

Software development is not rocket science; it is a branch of engineering but, it is not rocket science.  I say that because rocker science depends on the laws of chemistry and physics which have not changed since the big bang.  Software development is changing daily.  Javascript libraries are constantly being updated and going in and out of fashion.  Versions of PHP change and open source code is in constant flux.  Finally, software development is dependent on the fickle demands of consumers who use it.  The level of chaos and change are staggering.  It is why software development is such a challenging profession.  As a scrum master and coach, you must understand those challenges and guide development teams through the process.

One of my favorite pieces of journalism is Bloomberg’s weighty essay entitled “What is Code?” It talks about the person in the taupe blazer and the frustrations of software developers.  It also does a great job talking about the headaches the executives who manage software developer face.  The essay captures perfectly how smart people struggle daily to get dumb machines to act intelligently.

The world of software has tremendous power, but that power belongs in a small subset of the world population.  I calculated that less than .05% of the global population of 7.4 billion could maintain software and computer networks.  Many of these individuals work in the quiet recesses of government and business keeping things running.  They go home to families and friends.  They pay bills and try to live their lives as best they can.

Because of the laws of supply and demand, computer professionals receive large compensation, but the compensation comes with a trade-off.  The trade-off is long hours on uncompensated overtime and business leaders expecting them to perform magic.  It creates conditions which lead to poor quality and burn out.  I have experienced this situation as a developer and as a manager.  As a customer, I have stumbled on numerous situations where fatigue, complexity, and unrealistic expectations have combined into a poor product.  The history of the internet contains plenty of companies which had a few pixels and an unhealthy dose of hype.

Technology professionals have lived in that world since the early 1990s, and you can excuse them for being suspicious of new approaches to doing things.  For every Amazon.com there are hundreds of companies like Pets.com.  So bringing ideas like Test Driven Development, S.O.L.I.D. programming and Agile is going to face resistance.  As a scrum master or coach, I recommend you begin slowly introducing concepts letting people test out an idea to get comfortable with them.  It also helps if you understand and recognize the pressures the team faces.  Are they distracted by requests which are urgent but not important?  Do you have a healthy cadre of product owners or is the role being performed by a manager?  Finally, are they working with a brittle technology stack? Answering those questions will determine how fast you can go during your agile transformation.

Software development is not rocket science.  It is a challenging field prone to error and burn-out.  Only by paying attention to individual challenges each software development team faces can they be coached into an agile way of doing things.

Some thoughts on personal change

A typical day for a scrum master; doughnuts and coffee

I have called working in the business world bipolar, toxic and an excuse for mental illness.  I still feel this way, but along the way, I have encountered numerous pockets of decency and professionalism.  I have made plenty of friends along the way.  This week, I took a massive step in my professional career and resigned from my present organization.  I will be joining another firm on November 19th.

When I was growing up in the 1980’s, my parents and teachers spoke about how a career was a pathway or process.  You would join a company and throughout your career advance up the organization.  Your loyalty to the organization came with a measure of job security, and a means to support a family.  I was instructed people succeeded and failed based on individual merit.   The recession of the early 1990’s and over twenty years of being a technology professional have proven those ideas false.

I have spent plenty of time around the damaged, neurotic, and mean people who make up a significant minority of business professionals.  In my worst moments of vulnerability, I have choked back tremendous amounts of rage and bitterness.  In my better moments, I have forced myself to see the good in others.  I was disappointed from time to time, but often my optimism was rewarded.  I leaned on colleagues to muddle through the long days and lack of support, and I relied on my fellow agile coaches who saw something in me I did not.

It is easy to see the bad in the world and wallow in nihilism.  Creating a reformation is going to be hard work.  A modern shareholding company is the closest thing contemporary society has to medieval feudalism, and those in power will do anything to remain in charge.

Fortunately, there are others like me who are agitating for change and a serious business case for making those changes.  Developers, agile coaches, scrum masters, product owners, and random strangers want these changes.  Together, we will work to make the modern corporation more sustainable, sane, and satisfying place to work.  I have spent five years learning to be a great scrum master and coach.  It is now time to put that experience to use expanding the agile reformation. 

Until next time.

Agile Exposes the Bad Boss

A bad boss is just toxic.

I was getting on an elevator at the office and I decided to make small talk with someone as we were heading up to our respective floors.

“Ready to set the global economy on fire,“ I joked.

My fellow traveler got a gleam in their eye and said, “The flames are so colorful.”

I got off on my floor and breathed a sigh of relief.  The metaphorical pyromaniac was too eager to be pulling my leg.  The experience brought into stark contrast how tired many of us have become in the business world. The daily frustrations of working in a modern office force many professionals into the cynical behavior of inflicting harm on others as a means of satisfaction.  It is perverse, and it is wrong. The cynicism in the elevator is one of the reasons I have been such an enthusiastic proponent of agile.  I firmly believe there must be a better way to structure work so that it is sustainable, sane, and satisfying.

Inc. Magazine and Monster.com pointed out this week that 76% of bosses in business are “toxic.”  This toxic leadership is why so many people rely on jaded cynicism.  It is crucial as an agile coach and scrum master to break this cycle of toxicity.  According to the article in Inc. magazine, a toxic boss exhibits some or all of the following traits.

1. They are power-hungry
2. They micromanager
3. They are absent
4. They are incompetent

It is up to people like me to expose these bosses to the organization and coach them to be better.

The Power Hungry

Working for a power-hungry boss is a little like being a supporting cast member in Game of Thrones; you are going to wind up suffering a cruel ending to satisfy someone else’s ambition.  It surprises me how many business leaders think servant leadership is similar to the game “Masters and servants.”  The reality of servant leadership is much different.  In the end, what everyone needs to understand is a power-hungry boss is concerned about one thing; themselves.  A power-hungry boss will put personal interest over the needs of the company and employees.  Agile exposes the power-hungry because they often become impediments to shipping solutions.

The Micromanager

The hardest part of leadership is the lack of control we have over our fellow humans.  A leader can spend years training people to do the right thing and meet a certain performance level, and they can still disappoint at critical junctures.  To combat this helplessness, managers create processes and steps which they expect people to obey like robots.  It creates an illusion of control where employees do what they can to avoid hassle rather than what is necessary to succeed.  Thus, reports have perfect typography and proper tab spacing, but the data within that report shows lead conversion is falling.  The emphasis on working solutions instead of comprehensive documentation in agile should expose micromanagers.

The Absent

Over the years, we tell countless stories about military leaders who “lead from the front,” instead of from behind a desk.  I am currently reading one about William Slim who commanded the 14th Army of Burma during the Second World War.  It is easy to get caught up in the trappings of authority.  In an office of cubicles, having your office is a status symbol.  It gives you the power to shut people out and focus on administrative duties.  The autonomy and control over who has access is a powerful motivation for people to advance into leadership.  In reality, a leader has to be more visible to the people they are leading.  A leader should know about the people who make them successful.  If the leader is not around and they become distant figure the people who make them successful will ignore them in time of crisis.  Agile attempts to counter this kind of toxicity with its emphasis on face to face communication.

The Incompetent Leader

A leader should not be able to do your job, but at the very least they should understand what it takes to do your job.  What I have discovered over the years is people who have never managed a computer network or written a line of code often lead technology teams.  These people know how to manipulate budgets and control the project, but they do not know how to direct technology professionals because they think they are no different than shipping clerks or factory workers.  Agile with its emphasis on cross-functional teams and delivery exposes the incompetent.

I am a big believer in the idea that you should tell and expose the truth wherever you find it.  Sooner or later, someone in a position of authority is going to act on that truth.  I feel this way because it is how we defeated leaded gasoline and paint.  It is how we have reduced smoking in the United States by half since 1964.  It is an approach which led to the birth of agile.

If we are honest with ourselves, we should acknowledge the power-hungry, micromanagers, the absent, and incompetent and expose them so their toxic effect on the workplace can be mitigated.  It matters, and if we are not successful, all we can do is watch the pretty colors as the world burns.

Until next time.

Looking back at Agile2018

Spending time with fellow
 speakers Michele Sliger and Erika Lenz

This year is a personal and professional adventure for me.  I journeyed to the Scrum Alliance coaches retreat in London.  Last week, I was a presenter at the Agile 2018 conference.  Each of these experiences has made me a better scrum master and agile coach.  Now, that I am back home and have a more stable schedule; I will be blogging on a more regular basis.  This week a few take-a-ways from the #Agile2018 conference.

Data and Metrics-

The Wednesday keynote was Troy Magennis who spoke passionately about data and agile.  He proposed that agile professionals find a better way to present data to others and that data should inform decision making rather than reinforcing existing prejudices. 

He also provided data showing notions of teams being smaller than nine people may be counterproductive in larger projects.   He pointed to studies where groups of eleven to nineteen people are less efficient by a fraction compared to seven to nine-person teams.  He then argued that fewer handoffs between teams would make up for this difference.  It was provocative, and I look forward to people testing out his thesis. 

Presenting for the first time. 

The conference featured numerous presentations on metrics and data in agile.  I believe the use of quantitive data rigor in project and business management is a good thing.  For the remainder of the conference, numerous sessions covered the use of data and metrics in Agile. 

Outcomes are better than output-

The Agile Alliance with its speakers unwittingly created a theme for this conference.  The idea was outcomes of real features and progress are more important than outputs of stories, unit tests or story points.  Countless presentations emphasized working code delivering real-world value.  My presentation about the Cobra Effect reflected this dynamic as well.  When we measure outputs, we get perverse incentives.  When we measure outcomes, we get a better perspective of performance. 

Facilitation and Radical Candor-

The life of an agile coach or scrum master is a life of responsibility without any authority.  It is paramount to successful organizational change coaches develop superhuman skills of persuasion and facilitation.  I attended several sessions on how to be more credible and persuasive.  Many of these sessions pull from the insights of Kim Scott, a former Google Executive, who authored the book, “Radical Candor."

I learned plenty of valuable lessons at #Agile2018, and I look forward to the next conference in 2019 in Washington D.C.  I better start working on my presentation outline. 

Until next time.

Scrum does not have too many meetings

Each reform in society is confronted with a backlash.  The Protestant Reformation spawned the Inquisition.  It is natural that those threatened by it would oppose progress.  It is happening in businesses across the nation with the Agile reformation.  A common objection many have toward agile or scrum is there are too many meetings.  This week I want to discuss agile and meetings.

According to the scrum guide there are four events in scrum, they are:

• Sprint planning
• Daily Scrum or Stand-Up
• Sprint review 
• Sprint retrospective.

In the span of a work week, these meetings should be brief and informative.  A stand-up meeting should take approximately fifteen to thirty minutes.  If it takes longer, you should review how you are facilitating this meeting.  A sprint review is a demonstration to the business users and should take no longer than an hour.  Retrospectives allow a team to inspect and adapt their process.  Typically, this meeting is about sixty to ninety minutes in length.  Finally, there is sprint planning where the development team estimates stories and plans the next race.  Sprint planning can take as little as an hour and as much as six.

Based on this rough estimate we can determine how many hours the agile team is spending in meetings.  Based on a three-week sprint where is how it break down.

• Typical work week 40 x 3 = 120 hrs.
• Standup meeting – 0:15 x 15 = 3:45 hrs.
• Sprint Planning – 6 x 1 = 6 hrs.
• Sprint Review – 1 x 1 = 1 hrs.
• Retrospective – 1 x 1:30 = 1:30 hrs.
• Total Time budgeted in meetings = 12:15 hours of a 120 hrs. sprint.

Thus, a developer at worse case scenario spends just over ten percent of their time in meetings.  The remainder of the time is devoted to writing software and creating value for customers.  It is significantly less than in the world of waterfall project management with its numerous meetings to cover everything from architecture to problem-solving.

The scrum master and product owner spend their time in meetings, but it is to protect the team from being distracted from delivering value.  It is why I attend meetings about I.T. governance or architecture so that my team does not have to.  It is why the product owner is answering customer inquiries and meeting management.  We attend the meetings so the development team can concentrate on what is important which is shipping code.

It is why I find the argument that agile has too many meetings disingenuous.  People who are opposed to agile are not opposed to the meetings they are opposed to the routine nature of the meetings and the expectation to ship working code at the end of each sprint.  Transparency of this nature quickly exposes the unwilling, incompetent, or invisible people in an organization who do not deliver value.  When we discover these individuals, it creates a backlash in the organization.

So, scrum and agile does not spend too much time in meetings; it concentrated on what is essential.  An agile team’s first and foremost duty is to deliver value to the business; anything else is waste.  I am looking forward to hearing from you and knowing what you have to say.

Until next time.

Machiavelli knows agile.

Machiavelli, knows some things about agile.

The agile reformation is all about satisfying customer needs, improving product quality, moving quickly and maintaining a sustainable pace of work.  These differing prerogatives require changing the way we think about work and looking at problems differently.  It means for agile to be successful a scrum master or coach must lead change.

Many times, I feel like Don Quixote jousting at windmills around the office. During a down period, one of my product owners pointed out a quotation from Machiavelli.

“It ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success than to take the lead in the introduction of a new order of things.” 

Leave it to the prince of political manipulation to provide me with some fodder for my blog.
Change is hard because people prefer to have routine and ritual in their lives.  Also, people who benefit from the way things are will resist change because they might lose authority, money or status.  It is easy for individuals to see reform as a zero-sum game with a gain for someone else equal to a personal loss.  It is a pathology which I see in both technical and business professionals.

On the business side, it is a huge culture shock to work side by side with technical professionals.  Now they discover the systems and technology they take for granted is not the result of magic.  They collaborate on the authoring of requirements, and they have “skin in the game,” when it comes to the success or failure of an initiative.  No longer will the alibi of, “…it is technology’s fault,” work in an organization behaving in an agile fashion.

The rapid feedback is a benefit to both the business people and technology staff.  It avoids “death march” projects.  The days of building software which does not drive value to the business disappear with each iteration.  A software project can quickly pivot to new regulatory or market needs.  Finally, the CFO will see a reduction in cost overruns and failing projects.

Agile not only changes the business professionals who practice it; agile changes technology professional who follow it.  Developers begin to understand the challenges the business faces.  An engineer sees business partners as equals and worthy of respect. Writing unit test and performing automated deployments build trust with business partners as bugs and defects decrease.  The arrogance of software professionals being the smartest people in the room gives way to the humility of helping others succeed.  The hacker ethos of development gives way to a more professional perspective.

Agile is not perfect.  The reformation is only eighteen years old, but it is growing and improving.  It is starting to become the de-facto technique of doing new software development, and it is spreading to other areas of business.  Change is perilous.  Getting knocked off your horse is not fun, but nothing worth doing is easy.  The reformation is not going to stop and you either lead, follow or get out of its way.

Until next time.

Smoke detectors explain technical debt

Should have checked the smoke detectors.

Since the holidays, I have made a point to spend time with people outside the technology field.  This experience has been beneficial because I spend my time explaining what a scrum master does and how we do it.  This review of the basics is allowing me to reflect on work and how to make it better.  It is a fresh perspective which has allowed me to look at old concepts in a different light.  This week I want to revisit technical debt.

I own my own home.  Since I am a homeowner, I have smoke detectors.  These little battery powered devices warn me when there is a fire or when I am burning a roast on the stove.  So smoke detectors offer protection to a homeowner so they can escape the house quickly and call the fire department.  Smoke detectors are so useful you receive a discount on your home insurance if you have one, and, in some municipalities, you are required to have at least one in your home.

Smoke detectors have one significant drawback; they are battery operated.  When the batteries run out, and a fire breaks out you are helpless.  The smoke detector companies fix this by forcing the alarms to “chirp” which is a friendly reminder to change the batteries.  This week, I awoke to my smoke detector “chirping” at 2 AM in the morning.  Like many men my age, I attempted to roll over in bed and ignore the situation.  Ninety minutes of insomnia later, I wandered the house searching for batteries to replace the faulty one in the “chirping” detector.

The next morning over an extra cup of coffee, it occurred to me that I treated my smoke detector like many organizations treat technical debt.  I do not change batteries until I have to and usually it is at an inconvenient time.  Fortunately, being a former boy scout, I was prepared with batteries in an easy to find location.  I swapped out the batteries and went back to bed. 

If you are a homeowner, you have four strategies to deal with smoke detectors.

1. Change all the batteries at once typically during daylight savings time.
2. Change individual batteries when they run out of charge and begin chirping.
3. Ignore chirping smoke detectors until you get fed up and change the battery.
4. Remove and disconnect all the smoke detectors and hope you never have to deal with a fire.

As a homeowner, I use strategy two and three.  I know others who use the other two approaches.  Swap out smoke detectors and batteries, and you have the four classic strategies companies use to address technical debt.

The most efficient way to deal with technical debt is to follow the first strategy by changing batteries and updating systems on a regular basis.  By doing this, you reduce expected outages.  Agile and scrum encourage this approach.

Many CIO’s and managers I know consider this madness because there is a not enough time, money or people to keep updating systems.  It means they rely on strategies two and three.  It may be suitable for a chirping smoke detector on a cold night but is lunacy for a multi-billion dollar enterprise.  It creates situations where firms could lose millions of dollars while they wait to bring systems back.   

So the next time someone looks are you funny when you talk about technical debt just explain it to them like changing the batteries in a smoke detector.

Until next time.

Eat up

I feel like a shark!  "Chomp!"

Social movements and organizational change are difficult to measure, and it is particularly hard to do in the world of business.  The business press concentrates on investing and accounting.  Since the beginning of the agile reformation, those of us involved in the change have openly wondered if we are making an actual difference.  As 2018 begins, it looks like agile is becoming mainstream and successful.

In 2011 a famous editorial appeared in the Wall Street Journal, It was titled, “Software is eating the World.”  The principal thesis was for companies to succeed they have to behave more like software companies.  It was a daring argument.   The seven years which followed have vindicated that notion.  Google, Tesla, Amazon and a funny project called Bitcoin are dominating headlines and the business community.

Tesla is still struggling to meet its production commitments and Bitcoin, to me, feels like a blue sky stock but what all of these firms have in common is a willingness to innovate, iterate, and move fast to satisfy customer demand.  Even companies who lost their way are embracing blockchain technologies, cloud computing, and rapid software development. 

It is satisfying to know that my career choices have mirrored changes in the business.  While business is changing business leadership is struggling to keep up.  Organizations charts still matter in many places.  Command and control measures which existed for years are difficult to discard, and inertia prevents most organizational change.

It has created a quandary and spawned an entire industry of coaching and consultants, who are attempting to show others how to do business with the agile paradigm.  What these coaches discover, is a business is a social construct along with a business entity.  The ego of a director may be more important than the needs of the company.  Board members excuse a lousy quarter because they golf with executives.  Whole industries condoned sexual harassment and assault as long as the abusers generated revenue.  

Which is why I find the turnaround at Microsoft so fascinating.  They went from a sales culture under Steve Balmer to an engineering culture under Satya Nadella.  After product failures like Zune, Vista, and Windows Phone, the organization decided to place its future in the hands of a software engineer who felt building better products was the path to commercial success.  It is a gamble which has paid off handsomely.

Microsoft has embraced Agile, and it is paying enormous dividends.  That is why this week an article appeared in Forbes called, “Agile is eating the World.”  The reformation is growing, and the success is getting noticed.  It is a satisfying development to me.  I am no longer a lonely missionary in the wilderness, but a professional at the table is making a difference.  It is nice to see the times change.

Until next time.

It is time Agile crushes magical thinking in business.

Working in Technology is like taming a dragon.

In the contemporary business world, one of the things which surprised me the most is how divorced people are from the technology which their careers depend upon.  Arthur C. Clark, the author of “2001: A Space Odyssey,” said, “…and sufficiently advanced technology is indistinguishable from magic.”  Today, in a world moving at the speed of the internet, tens of millions of people are wandering the world behaving like magicians.  I want to talk about what this means for you the scrum master or agile coach. 

At the click of a smartphone, a human being can summon a ride, book restaurant reservations, order clothing, and find potential romantic partners.  News and gossip travel around the globe.  We can even live in virtual spaces reshaping our bodies ignoring concepts or gender and aging.  Thanks to the world of technology and algorithms we can live in a curated rich world where there are no opposing opinions and everything is quick and convenient.  It is a seductive world. 

The world I describe is the product of millions of hours of labor and the application of fifty years of merciless engineering to make systems better, faster and cheaper.  It is the application of silicon wafer technology, advanced mathematics, and smart people doing smart things.  It is the unwritten story of our time.

Now imagine people who live in the magical age who want to implement a new payroll system or create a better way to get products to customers.  Since they are accustomed to systems which are quick and compliant, they think it is possible to spin up systems which behave the same way with the speed of downloading a phone application.  These magicians take it for granted that the data will always be correct and they do not need to proofread the work. 

This is not the reality of technology.  Developers need to get involved, and they need to be managed, so the code is clean and scalable.  Data needs to be placed on Oracle or Microsoft SQL servers.  Network accounts need to be created, and all of this costs time and money.  It is not magic.  It is hard work.

As a former web developer, it always troubled me when people told me how they expected a website to look and behave without understanding a lick of HTML code.  It is my experience these individuals rise in organizations and get budget authority.  So you have the ignorant paying the bills while someone more ignorant is giving orders to the development team.  It falls to a technology lead or scrum master to transform ignorance and magical thinking into code.   It is just as disheartening as it sounds. 

It is also why so many technology projects fail because the people involved do not conceptually understand the labor it takes to get the job done.  A construction project is easy to understand compared to a software project because the people paying the bills realize what is happening.  A typical business person does not understand the difference between Java-script and JAVA; so how are they going to know what it takes to successfully construct a web application.

As a scrum master, it is your responsibility to crush magical thinking.  Tell the truth about how long it is going to take to get something done.  Show people work in progress and ship code periodically so if adjustments need to be made they can happen in a timelier manner.  You will have to say no, and you will have to create trust between the development team and business.  This means enforcing one of the central tenants of Agile; their business sets the project priorities, and the development team says how long it is going to take.  If this social compact is not upheld, then any agile implementation will collapse into dust. 

So in this magical world, it is up to the scrum master to create a much-needed dose of reality.  Otherwise, you are confronted with an evil magic act which does nothing but disappoint. 

Until next time.

Fix Technical Debt NOW!

Technical debt is a lot like leaky pipes

I am very fortunate to spend time with smart people.  The day goes by faster when you spend it with intelligent and capable people.  One of those talented people is a former colleague of mine, Larry Gassik.  He was asking me a few questions about technical debt, and it occurred to me that I have not shared many of my thoughts about it on the blog.  Technical debt is becoming a growing concern in the agile community as more teams expand into enterprise systems and confront legacy code.  This week a brief conversation on technical debt.

When I think about technical debt, I use the metaphor of plumbing.  Indoor plumbing has existed since Roman times, but its innovations only became global in the 20th century.  Thanks to plumbing, the spread of cholera have ended.  Indoor plumbing has given millions of people clean drinking water and helped reduce pollution.  Plumbing is so ubiquitous that the only time we notice it is when it is not working.  When a toilet backs up or a pipe bursts, we become very aware of the effects of plumbing on our lives.

The “if it isn’t broke don’t fix it,” attitude we have about plumbing is prevalent in the business world.  Many business professionals in the corporate world are focused on shareholder value and profitability.  When business professionals think about technology, it is either an expense or inconvenience.  It is why many organizations have not made the switch to cloud-based systems and use old versions of Microsoft office.  To them, the investment of money is not worth the rate of return.  The reality is that not paying attention to older technology systems is just as negligent as ignoring the maintenance of your home; you risk broken pipes and greater expenses caused by water damage.

The technology of pipes and plumbing has changed over the centuries to be safer and less expensive.  In Roman times, pipes were lead.  The contaminated drinking water caused outbreaks of “Saturnism” which was a polite term for lead poisoning.  Terracotta pipes followed, but those broke down over time thanks to tree roots and natural decay.  Iron pipes came along, but they were brittle and caused water to be rusty.  Copper pipes came along and have been a good solution, but they are expensive and require welding which creates maintenance a problem.  Today, most new construction relies on PVC pipes because they do not corrode, are inexpensive, and easy to maintain.  If the materials of plumbing can change so radically, image what is happening with technology moving at the speed of the internet.

Forty years ago, while the Sex Pistols were singing “Anarchy in the U.K.” there was no personal computer market in the United States.  Microsoft and cellular phones did not exist, and a modem was fast if its speeds were 300 bits per second.  Mainframes dominated computing, and most business transactions were done over the phone or in person.  Compare that business environment to smartphones, personal computers, and Gigabit speed internet we have today.  There is no credible way the technology of 1977 could support the needs of business today.  The difference between the needs of the firm and the ability of the technology to support the business is something agile professionals call technical debt.

Technical debt is cancer threatening to metastasize and kill the business.  Here is how it happens.  Slow or ineffective systems undermine customer confidence.  Weak confidence means less use and less use guarantees less money for the company to maintain the system.  Less money translates into slower time to market for new features and updating the system.  It means employees and IT professionals will take shortcuts to bypass the pokey system.  With the system jury-rigged to address business problems, it becomes more expensive to maintain, and improvements take longer to roll out.  Finally, you create a situation where the system fails, and it does not provide benefit to the business.  If you pay attention to the technical debt, you can avoid this kind of failure.

A business with significant technical debt will have trouble attracting talent.  Computer professionals being smart, know what technologies the market supports, and they are terrified of having skills which are obsolete.  It means they will gravitate to businesses and projects which have a smaller portion of the technical debt.  It also means that college graduates will avoid working for companies with old technologies.

Technical debt is the difference between what the business needs and what they technology systems support.  If you do not address technical debt, it is a threat to the success of the firm.  Finally, the mitigation of technical debt is no different than routine household maintenance.  Do the right thing and focus on technical debt before the pipes burst in your business.

Until next time.

Looking back and forward - 2017

After 2016, I think we
all need a tall glass of wine

Technology is a dynamic industry.  One moment you can be on top of the world and the next you are like Nokia unable to adapt to market conditions.  This week I am going to take a look at some of my predictions from last year and see how accurate I was and look ahead to 2017.

Looking back, it is clear that when I paid attention to technology and trends in the industry, my predictions were accurate.  Apple computer did have a rough year with tax issues from the European Union and sales which dipped for the first time in years.  Microsoft is growing its business with the Azure cloud services and a full embrace of Linux.  It also has surprising sales of its Surface Pro 4.  They are still going to founder in the phone market, but they are ruling in the desktop and enterprise realm.  My prediction that the Scrum Alliance was going to have some growing pains came to fruition.

When I looked at politics in 2016, I was wrong.  I predicted that election season would be a draw with the Democrats retaining the Presidency while the Republicans would keep the House of Representatives and lose the Senate.  Instead, Democrats made slight gains in the House and Senate while losing the White House by the statistical margin of error in Wisconsin, Michigan, and Pennsylvania.  President Trump's mandate is about 100,000 votes in three states which are .08% of the total votes cast.  Please read this great article with lots of wonky footnotes on how this happened from Vox.  Republicans have complete control of all three branches of government since 1929 in spite of their razor-thin margins of victory.

As a blogger and pundit, I need to take responsibility for when my predictions are correct and when I get them wrong.  I also should learn from my mistakes and extrapolate what I need to do to make better predictions.  Here is what I expect in the coming year.

Big Fight over Net Neutrality.  

There are already rumblings in the new Trump administration that net-neutrality is going to open to discussion.  Changing the current net-neutrality rules will be a gold mine for cellular phone providers and cable companies; it will be bad for everyone else. The internet rose up in rebellion and forced members of Congress to drop support for a law which would have made pay to play access to the web law of the land.  This time around the fight is not going to be in Congress but in the FCC and it is going to be harder because political appointees are going to be much less susceptible to public pressure.

Deregulation a-go-go

Many Republicans have a love affair with Ayn Rand.  Now that Republicans control all three branches of government prepare for a full wave of deregulation in technology and business.  Overtime rules will be cut back.  Financial regulations will be revoked, and a worker in this economy is going to have a more difficult time.

Those are the only two big predictions I have for the new year.  The interesting thing about working in the technology world is that change is a big constant.  If you are not paying attention, then you are bound to be surprised by something.  I look forward to being along with you for the ride because 2017 is going to be a challenging year.

Until next time.

The Hero's journey is no substitute for a product

A hero's journey is not a substitute for a product.

Each entrepreneur goes through a sort of hero’s journey.  If they are lucky, once that journey is finished they will emerge out of the other side stronger, wiser, and accomplishing something amazing.  It is no secret the technology world uses the language of science fiction and fantasy.  That is why a company which becomes extremely profitable it is called a unicorn.  As an agilest and entrepreneur, I convince myself that I am lucky and smart enough to aspire to this status.  It is the story I tell myself.  In the dark moments, it is what keeps me going.  This week, I want to talk about when story telling crosses the shadowy line from inspiration to deception.

Carl Jung, one of the founders of psychoanalysis, articulated the idea the human species has a “collective unconsciousness.”  This collective unconsciousness is the common characters or myths humans use to describe themselves.  The collective unconsciousness also describes what the human species aspires to become.

Joseph Campbell then built on Jung’s work in 1948 with his book, “The Hero with A Thousand Faces,” which talks about the similarities between the mythologies of western and tribal cultures.  Roman Gods were compared with the traditions of Native Americans and Australian Aborigines.  The similarities were too hard to ignore.  We had academic proof that the human species has a common story telling tradition.

Now that this knowledge was out in the open it did not take long for others to exploit it.  One of them was a University of Southern California graduate, who just has a hit film entitled “American Graffiti.”  The other was a technology entrepreneur who cultivated the image of a mystic shaman while he sold music players and later phones.

To be successful, a company needed a story and a heroic figure to pitch that story to the media and client.  It was a way of cutting through the clutter and getting the message out.  That lesson was not lost on Elizabeth Holms who dropped out of Stanford to found her company Theranos.   She created an image which was a frittata of Hitchcock’s icy blond, Steve Jobs techno shaman, and the elegant intelligence of Meryl Streep.  Her story was simple, she was going to change the world making blood testing affordable and less invasive.  She was smart enough and stubborn enough to found a company and make it happen.

The technology press swallowed the story hook, line and sinker.  Soon she was featured in press write ups, on television promoting her company, and receiving millions of dollars in venture capital.  I will not go into the details of Theranos and the fraud they committed.  Vanity Fair Magazine has already done an outstanding job on that front.  Suffice to say, Elizabeth Holms had a good story to sell but didn’t have a product.  Her blood testing tool was nothing but fantasy.

The lesson here is that every story should have a grounding in reality.  You cannot change the world with your products if your products do not work.  The rumpled engineers have to build something before the myth makers in sales and marketing come along.  Telegenic good looks and a story are not a substitute for business acumen and a product.

Anyone who grew up during the stupid and giddy time of the dot.com bubble should have known how this story was going to end.  They chose to ignore it and suspend disbelief because the story was good.  Instead of a hero’s journey, what the public got was a true crime story of fraud and greed.
It is a sobering lesson for an entrepreneur and consumer.  I hope that we are smart enough to recognize it before it happens again.

Until next time.

Product Owners Have the Hardest Job in Agile.

Listen to Ben, hang together or hang separately.

I have been kicking around as a scrum master for the last three years.  I have been developing software for eighteen.  Those jobs are difficult and challenging but they do not compare to challenges faced by product owners.  This week I want to talk about the hardest job in Agile – the product owner.

The Scrum Guide is pretty clear about the members of a scrum team.  They are the developers who do the work.  The scrum master is the servant leader of the team and helps remove obstacles.  Finally, there is the Product owner.  The product owner sets priorities writes stories, and acts as the liaison between the business and the development team.  What most product owners do not know is the job includes so much more than what the scrum guide says.

A product owner needs to understand the internal politics of the organization so they can work with in it and sometimes around it to get things done.  Product owners need to understand the customer.  Not only understand the customer but be able to differentiate what software improvements will add value and which ones will waste money.  The product owner is under constant pressure to write stories and to create stories which can be transformed into testable code.  It is a grind and they need to practice mindfulness to separate what is important from what is trivial.

It is not an easy job and as a scrum master or coach you need to help them succeed.  This means spending time showing them how to write user stories.  Take time out to explain the agile manifesto and what developers need to succeed.  Take time to listen about the operations of the business and the politics of the organization.

A scrum master and product owner are equal partners.  To paraphrase Ben Franklin, you will hang together or you will hang separately.  When things go wrong it is usually the product owner who receive the blame.  As a scrum master it is up to you to make sure things do not go wrong.

Business today is not easy but a successful product owner can smooth off many of the rough edges to a software development team.  That is why it is the hardest job in Agile.

Until next time.

Getting DEEP with your Backlog Part 4

Prioritization should NOT be stressful

This is the last of our discussions to help product owners manage their backlogs better.  We have covered making a backlog detailed appropriately, estimated, and emergent, this week I want to talk about making the backlog prioritized.

The management consultant Peter Drucker said, “First things first.  Last things never.”  What this means is you do what is important and then ignore the other things.  Since becoming a scrum master, I have lived by that mantra and I think it should also be a helpful guide for product owners.  In my experience, I have seen backlogs filled with hundreds of stories of "nice to have" features.  Many of these stories are never worked on and the backlog gets larger and larger creating a sense of futility on the part of the development team and the product owner.

I am also personally surprised by how many people in leadership roles who can’t prioritize.  For example, I asked a person to pick one of two options.  They were so paralyzed by fear and uncertainty that they instinctively said, “I need to ask my manager.”  When I pressed them to make a choice, they said “…can’t we do both? They are both important.”  The reality is that both choices are not as important.  They both need to get completed but objectively they cannot be done at the same time so which of the two choices should we do first.  This creates spasms of doubt from some people.

What I suggest to some product owners is make a list.  Then they number the items in the list based on priority. No two items can have the same value.  If you can’t decide the value of two priorities because they are similar, flip a coin and give the winner a higher priority.  If they are that similar, then the time spent fretting over which is more important is going to cut into the time you could have spent getting work done.  Get the work done; it is easier than explaining why you didn’t get the project done on time or budget.

A good product owner needs to understand what it takes to get a software product into production and what the business needs in order to make it successful.  They also need to make hard choices and set the order in which the work gets done.  They also need to say which work can be ignored.  If a story has been lingering in the backlog for three years and no one has worked on it then it needs to be dropped.  If it was not important three years ago then it certainly will not be missed today.

Your back log can be organized in numerous ways but the most important is by priority.  Do the important things first and provide business value right away.  Then you can focus on the Vice President's pet project after the sales figures improve.

So there you have it, Roman Picher’s DEEP model of managing your backlog.  The backlog should be detailed appropriately, estimated, emergent and prioritized.  It was fun writing this series and hope you got some value from it.

Until next time.