Postulates for Backlog Prioritization

Today, I am continuing my discussion of backlog management. A good backlog follows Roman Pitchler’s DEEP model. Sticking with three simple building blocks inside your backlog will streamline work, and placing all work that drives value in the backlog will make you more successful than half of the other product owners currently working. This week, I want to discuss something that many organizations struggle with – prioritization.  

As a software developer and agile professional, I spend plenty of time around entrepreneurs and business executives. Many of these individuals are insulated from the hard knocks of life by the success in their careers. Because business leaders are accustomed to getting everything they want every time, they need help when asked to set priorities. People unaccustomed to hearing no are notoriously tricky to work with. 

The cold reality in the global economy is limited time, people, and money to get things done. Bosses who create a climate of terror destroy their organizations. Therefore, priority setting is necessary sooner or later. Confronting this reality requires a few postulates for business people to understand. 

The first postulate of prioritization is if you do not set priorities for work, someone else will. When you give a software developer a list of things to do without priorities, they will work on the most straightforward task or the one that interests them personally. It means employees often spend their time on tasks that are optional to the business. It may not be a big problem at first, but it will create situations where a developer will build something, and it will be radically different from what the person paying the bills asked for. 

The following postulate is that when everything is a top priority, nothing is. In business, there are important things and things which are urgent. Rarely do the two overlap, but business leaders want to create a false sense of urgency to get work done. It is a recipe for failure because if items are all urgent and essential, they are just like they should have been prioritized. The easy or enjoyable tasks will go first, generating conflict between the employees and management who commissioned the work. 

Finally, we should prioritize work based on the needs of customers and stakeholders rather than the highest-paid people in the room. I have spoken at length about egoware and other types of waste in organizations. The top priority for any business is the customers who pay for the solutions and products the business manufactures. So, when confronting a situation where a customer conflicts with an Executive Vice President of Application development, you must side with the customer. Improved revenue and better profit margins have a way of silencing critics. 

So, for a backlog to be successful, follow these three postulates of prioritization. First, set priorities; otherwise, others will set them for you. Next, priorities need variation because if everything is a top priority, nothing is. Finally, prioritize based on customer needs instead of management desires. These postulates are the foundation of a successful backlog. A successful backlog is the beginning of a successful agile implementation. 

Until next time. 

Back to Basics the Building Blocks of a Backlog.

I want to return to basics for the next few weeks and discuss Agile fundamentals. Last week, I outlined my mission statement that the fundamental building block of an agile implementation is a product backlog. Today, I want to discuss the items you put in the backlog. 

I am currently reading Dave Todaro’s book, “The Epic Guide to Agile,” which I am enjoying. Todaro starts with the basics of Agile and Scrum. From this starting point, he covers the pragmatic impacts of applying agility to business. It is from here that he talks about product backlogs. In case you need a refresher, a product backlog is a list of work the team must do to deliver value to the organization. A backlog can cover numerous processes, from marketing to Human Resources, but my examples will focus on software development since I am a technology person. 

A product backlog should contain user stories, bugs, and tasks. A user story is a new functionality or a change in functionality that creates value for the firm. For instance, if you want to tie the corporate website to a Federated social media service, you create user stories for the development team to improve. Another example is when regulations change, you must change how to calculate sales tax in the shopping cart. User stories are uniquely suited to adding features and improving products. If you want to learn more about how to write user stories, you can follow this link, where I talk about how I teach others to write user stories. 

The next item you should add to a backlog is bugs. A bug comes from a funny story from the early days of computer science. The first computers were monstrous contraptions the size of entire buildings. These devices came before the invention of transistors and microchips, so they were composed of rooms of unreliable vacuum tubes that gave off unhealthy heat levels. According to National Geographic, a moth flew into one of these rooms and landed on a tube. The insect died instantly and shorted out the computer. Since then, anything physical or programatical that breaks a computer is called a bug. 

The product owner of a system needs to track bugs in a system. Thus, log a bug when something is not working as expected in the product backlog. For instance, if we return to our fictional shopping cart and sales tax. We must write up a bug if sales tax is incorrectly calculated. From there, the bug is prioritized like a user story and then worked on by the scrum team. 

We need to remind people not to get hung up on if they are working on bugs or user stories. As a developer and scrum master, I often argued about work. I always wanted to debate if something was a bug or a user story. A wise coach showed me that both product backlog items are working to drive value to the firm and that I should concentrate on the work instead of arguing about what kind of work I am doing. 

The final item in our backlog is called a task. It is an item that the team does which does not deliver direct value to the solution. Training, the configuration of environments, and product spikes all fall under the umbrella of tasks. At first, I disagreed with this approach because I consider spikes a separate entity. My attitude changed when I started working at organizations where twenty different product backlog types existed in instances of Jira with different workflows. Thus, spikes and work that do not add direct value to the product should be treated as tasks to avoid headaches in Jira and simplify managing backlogs. 

A product backlog lists User Stories, Bugs, and tasks. Together, they make up everything a team does to deliver value to the organization. Please avoid focusing on the specific details of each type and accept that all of them must be completed. Next time, I will discuss Roland Pitchler’s DEEP model of organizing a product backlog.

Until next time. 

From the Basics to Healthy Ownership

Agile professionals tell tales about our successes and failures regularly. It is how we learn about what works and what doesn’t in our profession. Agile people also enjoy a good tall tale about the foibles of working in the global economy. After some time, these tall tales become apocryphal stories that we share. I am guilty of this behavior, and I am sure other coaches do it. Today, I want to pull back from the mythology surrounding agile and focus on the basics. 

I am reading Dave Todaro’s book “The Epic Guide to Agile.” What I like about this book is that it concentrates on the basics of agile and scrum. Todaro builds out advanced concepts from the basic foundations grounded in years of experience working with software professionals and business people. It is refreshing to see this writing about agile. 

As a coach and scrum master, the most fundamental building block is the product backlog. It is the bedrock where most Agile efforts begin. It is also where we see the origin of many of the dysfunctions in a business. When reviewing the subject, a product backlog is a prioritized list of work, including user stories, bugs, tasks, and spikes. A product owner creates and prioritizes that list while a development team completes that list. In contrast, a development team completes that list, checking off individual stories.  

Backlogs work on the level of individual teams. When coordinating between multiple units, we create what the people in SAFe call a value stream. Value streams then roll up into portfolios of work. Thus, you can roll work up into larger blocks or break it into its most fundamental levels. We aim to have a clear view of what is being worked on and measure how much value is generated for the firm, not to create busy work at the organization.

To avoid getting lost, Agile professionals need to be able to measure progress and draw maps of where we have been to where we are going. It takes organization and a particular discipline, but if done correctly, you can communicate clearly with both business leaders paying the bills and development teams doing the work. The push-pull between the two groups is what I like to call “healthy ownership.” In a perfect world, leadership trusts the organization to get work done and can trust leadership to look after them. It should be a beneficial and mutually symbiotic relationship. 

Over the next few weeks, I will focus on how to help build healthy ownership in organizations, from setting up backlogs of work to ensuring that middle management does not strangle agility efforts for selfish reasons. I look forward to you joining the conversation. 

Until next time.

Small Changes Can Work Miracles

I am working on a monstrously large project.  Hundreds of developers, project professionals, quality assurance people, and executives are involved in the daily grind of releasing the product.  Being a small gear in a giant machine that builds software is humbling.  You spend much of your time waiting for others and making sure you are being helpful rather than a hindrance.  It is easy to become discouraged because you are an alone person lost in an army of developers.  Today, I want to point out where everyone on a project makes a difference, continuous improvement. 

Large enterprise projects are an endurance exercise.  You are toiling away, hauling huge stones to fit in place for the benefit of others.  The work carries on for years, and while you have deadlines to meet, you do not receive an opportunity to view how the collective group is doing.  I feel like the numerous extras in the Cecile B. DeMille film "The Ten Commandments." It looks like the antithesis of agile, with ponderous progress dictated by supervisors and pharaohs from afar.  

From a distance, gigantic projects look ponderous and top-down.  The agilist comes into the picture when they motivate groups of smaller teams to work together more closely and individual units to improve.  Pyramids take time to build, but the stones can fit together more efficiently, the joints can be tighter, and the worksite can be safer so that the workers eventually have a chance to return to their families.  It happens when you concentrate on making minor improvements often.  

For instance, the most significant delay in my team meeting the definition of done was waiting for test data creation by quality professionals.  After some discussion during a retrospective, the group agreed to create test data without relying on the quality professionals.  It took two sprints of effort, but the development team is moving faster and improving quality because they do not have to wait on other groups like quality to complete their actions. 

Small changes make a massive difference if they happen regularly and over time.  Eventually, these changes act like compound interest over time, increasing the product's value and the team.  For example, if you have a three-week sprint cycle and the team improves its throughput by one percent each sprint by the end of the year, the team will have cumulatively enhanced by 17%, which gets people promoted in the corporate atmosphere.  

The agile focus on empirical measurements of progress and attention to improvement is how big projects succeed.  If each area improves, it acts as a multiplier across numerous teams.  Managers will copy the success of others so that others adopt your improvements to become the improvements of the entire organization.  

Yes, giant projects feel like being one of the many enslaved people building the Egyptian pyramids.  However, if you focus on continuous improvement and helping others succeed, the toil is more pleasing.  

Until next time. 

Beginning a Journey Into Healthy Ownership.

We will remember the end of the COVID pandemic as a combination of science-fiction, fantasy, farce, and tragedy.  I was on a plane to have dinner with a client while tanks began rolling into Ukraine.  The contradictions between my life and the peril of others were oppressive.  

Still, the business world continued to turn, and clients were looking for ways to do business smarter and faster.  I am a minor player in the global business story, but my role is to make a difference.  Part of that difference is to help improve product ownership in the agile reformation.  I have authored numerous blog posts about product ownership, and I have advocated for something called "healthy ownership," which began at the 2018 Agile Coaching Retreat in London.  Today, I am starting a series of posts on being a better product owner and developing beneficial ownership on your team.   

Healthy ownership began when I had a jetlagged rant about the quality of the product owners at my organization.  I asked if I could instill good habits among product owners and respect the developers.  Then, I found a group of like-minded individuals, and we got to work.  An agile team requires trust and interdependence to be successful.  The team then takes collective responsibility for its outcomes to have healthy ownership.  It is a goal I think each team should strive to achieve. 

Product owners should begin by having an open dialog with team members.  It would help to ask the teams what works and what does not.  Take time and listen to what they are saying.  What are the team's frustrations, and what do they need to overcome those frustrations?  Assume good intentions unless proven otherwise.  Finally, collect data from the group and make it meaningful.  

As a coach, teach product owners the D.E.E.P  model of backlog management.  Let new product owners write user stories and then get them to critique their work.  Have developers push back on user stories that are unclear or incomplete.  The trial and error approach may be more clumsy, but it will help develop more skill and confidence in the long run.  

Product ownership requires more than writing user stories and gathering estimates.  It is not an easy job, but it can be a force multiplier if done well.  It takes clear communication with the team and understanding the social compact, which guides agile, and it takes interaction with business partners and saying "no" when necessary.  

We will talk about being a better product owner for the next few weeks.  We will have a blueprint to create healthy ownership in your organization by the end of our journey.  

Next week, the D.E.E.P model of managing a product backlog.  

INVEST in Agile

I have spent much of 2021 working as a product owner.  I receive new insight each day into the role.  I have developed empathy for the people who do the job and the unique pressures they face working on a large-scale project.  I have noticed in my tenure that writing user stories does not appear to be a consistent skill among my peers.  From time to time, when I point out ways to make stories better for the development team, I get testy pushback from my peers.  This time on the blog, I want to cover story writing and the INVEST model.  

Readers of this blog will appreciate that I am a fan of Roman Pichler and his D.E.E.P model, and I have written a few blog posts about the subject over the years.  Lately, I am noticing that some product owners are struggling with the basics of authoring user stories.  I spend plenty of time sharing my blog posts on how to write better stories with my colleagues.  

Lately, some of my peers have asked what makes a good user story, and I did not have a good answer until I learned about the INVEST model.  First proposed by Bill Wake in 2003, the INVEST model has become the gold standard for user stories.  Once I understood its purpose, I became an enthusiastic advocate of its application in story writing.  INVEST is an acronym that stands for; independent, negotiable, valuable, estimable, small, and testable.  Following this model will make your stories better, require less work for the development team, and make like easier for the product owner. 

Independent, when we say a story is independent, it can be worked on individually and not rely on someone outside of the team for completion.  The development team can work on separate user stories in any order.  Finally, if a story does rely on dependencies, it can be easily mitigated with mock data.  User stories should not create constraints or bottlenecks in the overall project.  

A negotiated user story is not a contract or recipe to follow slavishly; instead, it is a conversation.  The product owner and the development team should give and take to know what to build but not how to do it.  In my experience, the most significant area of conflict is when a front-end developer and a UX designer clash over the implementation of a design.  The UX designer often wants the developer to match the graphics file pixel per pixel.  The realities of CSS, HTML, and JavaScript can make that like jamming a square peg into a round hole, so it will require negotiation to get everyone to agree on how the page will look and behave.  

When a story is valuable, it means that its completion will add value to the customer or the project.  The development team or product owner should scrap any user story we cannot explain how it helps a customer or drives revenue for the project.  It is hard to do in hierarchical organizations because the highest-paid person in the room often makes project demands to have work done that delivers no value but satiates their ego.  When in doubt, provide value to the business and customers, the executives will have to pay for their ego gratification with their own money. 

Each story in the backlog should have an estimate.  The team should take time and ask how complexity, risk, effort, or uncertainty surround a story.  It then allows the team to make an educated guess about how long it will take to complete the work.  An estimate is not a quote for work because it may be off. Still, if the team cannot estimate a story, the product owner will need to refine the story further to allow the development team to provide an intelligent estimate.  

Small stories require less time to complete, and these types of stories are easier to understand and provide a swifter path to success.  I talk about the importance of smaller stories here.  

Finally, a user story must be testable.  Suppose you cannot quickly test a user story with either a unit test or easy-to-understand instructions. In that case, the story is overly complex, and it will generate further delays to the project because no one understands what the story is supposed to accomplish.  Keep things simple, and to keep them simple, they should be testable. 

That is the INVEST model.  A user story should be independent, negotiable, valuable, estimable, small, and testable.  Following this rubric will make writing user stories easier and will help get work done more efficiently.  

Until next time. 

Ignore Product Delivery at Your Own Risk.

When we talk about agile and scrum, we often talk about the process.  It is a curious paradox because the agile manifesto clearly states, “Individuals and interactions over process and tools.”  I want to take some time to discuss the reason we do this crazy agile thing.

When agile began in a ski lodge in Utah, it was the product of seventeen leaders in software development.  It is not a perfect document and others have made numerous suggestions for revision.  The agile movement has balkanized because people have different interpretations of the values and principles outlined in the manifest.  Finally, the challenge of scaling agile to accommodate large software projects has further split the community into competing camps.  I have attempted to stay above the bitter disputes but I have taken sides on a few issues like no-estimates. The conflicts among agile professionals hide something which all of us agree.  The purpose of agile is to get work done.

Agile does not promise to get work done faster; it promises to get customers involved with work so that businesses can deliver value to those customers.  Agile professionals ship software, develop marketing campaigns and provide services that offer value.  Anything else is differences in style.  These styles range from prescriptive approaches for organizations beginning the process of agile to experimental methods which allow teams to self-organize and come up with unique ways of doing things.

Many of the disputes in the agile community are about how well people are following the steps of agile or scrum.  It is an unhealthy disagreement about the process. Instead, everyone in the agile community should focus on delivery.  The shipping of products is what pays the bills and continues to build the agile movement.

To review, agile is about delivery.  Individuals are more important than development processes, and both are subservient to providing value to customers.  Anything else is waste.

Until next time.

Necessity and Urgency for the Scrum Master.

Necessity Matters.

Last week, I discussed prioritization and why it matters.  I received plenty of feedback and I want to devote extra time to the topic.

It has been my experience that the further one advances in the company the more people struggle with prioritization.  I blame this on individuals who have never had constraints on time, money, or energy placed in positions of authority.  I also suspect sales and marketing professionals advance into the executive ranks faster.  These individuals are trained early in their careers that “no,” is just one obstacle in the way of an eventual yes.  When they become responsible for operations or essential projects, “no,” has a very different meaning.  Unable to deal with shortages of people, money, or time they lash out or resort to deception to get things done.  It is an ugly state of affairs, and it will destroy the morale of a project team.

When I face this situation, I remember the 1999 movie, “Three Kings.”  The film features Ice Cube and George Clooney as gulf war soldiers who decide to steal a shipment of Saddam Hussein’s gold during confusion surrounding the end of the first gulf war.  The film has one moment which sticks out for me, and that is a monologue by Clooney’s character.  He asks his fellow soldiers what is essential.  After listening to several wrong answers, he says, “Necessity is the most important.  We need to know what is going to get us to the next moment and do that.”  When a ship is leaking, fix the leak.  When a house is on fire put out the fire.  Other issues can wait until the immediate crisis is over.  I have used this approach for five years, and I have seen its effect.  If you are in a staff meeting ask, “Is it necessary?” and if the answer is yes then inquire why it is necessary.  Eventually, people in the organization will start asking the same questions.

Some organizations have a culture of firefighting.  Jimmy Leppert observed these organizations are so focused on short term results they do not have time to focus on growth or excellence.  To get anything done, you have to become an arsonist to create a sense of urgency.  To reduce the “fire risk,” take away flammable material from the organization like technical debt and outdated software.  Next, take responsibility away from the “firebugs,” in the organization; people who create a crisis to get things done.  Finally, encourage fire safety with good engineering practices, automated testing, and code reviews among the team. 

People use urgency and necessity interchangeably.  Do not use these words for is a means to upset the process of prioritization in an organization.  It is arson burning down the business.

Until next time.

Have the Courage to Be Agile

The wealth of nations, the success of
agile requires courage and Adam Smith.

Technology is not a profession for wimps.  It requires hard work, intelligence, and creativity.  The profession also requires a level of courage you do not find in many white-collar jobs.  I want to discuss what type of courage it takes to be successful as a scrum master and coach.

One of my most popular blog posts talked about why some firms resist the agile mindset.  I place the blame upon a lack of psychological safety at most large organizations.  Additionally, I blamed the fear and uncertainty, which is inherent in a global company.  These factors combined create a toxic stew where everyone does the bare minimum and tires to remain invisible until they leave the company.  It is depressing and resembles the grim environment of a Franz Kafka story. 

To address the alienation and lack of initiative which festers in this environment, managers, put into place processes which if followed, have a better chance of yielding better results.  The processes become rituals and deviation from these rituals creates a reaction similar to blasphemy in the middle ages.  The process becomes the purpose of the organization.  In reality, the mission of any business is to create products and services which help customers.  Helping a customer creates revenue, and revenue should generate profit.  The description above has existed since Adam Smith and remains the best articulation of capitalism we have.  I think many people who work in business forget the simple principle of serving customers leads to profit.

The early days of software development reflected the spirit of Adam Smith.  Business people learned software development, and they used computers to address business concerns.  The first generation of programmers were the ones who helped automate payroll systems; they created the Saber travel system and provided the mathematics necessary to make the space program successful.  As computing became, more complex and specialized business, people began to abdicate their involvement in the systems which automated their business.  Project managers became go-betweens technology and business professionals.  Projects got more prominent, and the failures got bigger.  Millions of people had their potential squandered.

It was this waste of human capital, which leads to the creation of the agile manifesto.  I am part of the reformation which began on a ski trip to Utah. Many things unite us, but the main trait we all have is courage.  We all dare to go into the office each day and make a difference.  We are courageous enough to point out areas of improvement.  The agile reformation relies on the courage to be visible and vulnerable to our peers.  It takes courage to bet your career each day to make improvements.  It is easy to become invisible at a large organization; it takes courage to make changes.

I hope that I can maintain this courage for the remainder of my career.

Until next time.

Death to Agile-Lite!

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

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

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

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

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

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

Until next time.

Four Simple things

It can get lonely.

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

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

An Understanding Significant Other

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

A User group or Network of fellow Agilests

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

Support from Senior Leadership

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

Allies in the Organization

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

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

Until next time.

Goodhart's Law is Going to Get You.

Goodheart's law strikes!

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

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

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

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

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

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

Until next time.

Avoiding the Dumpster Fire

I have seen this ugliness before.

Technology is evolving and improving.  What is not improving is how we lead technology projects.  I have been in the business for twenty years, and it is clear how we lead technology projects needs significant improvement.  Last week news broke Hertz rental car was suing Accenture for 32 million dollars because it could not deliver improvements to its website.  I am surprised this kind of thing does not happen more often because plenty of large projects burn through obscene amounts of cash.  On the blog this week I want to talk about project failure and how it should provide businesses with a model on how not to do large projects.

Nathan Allen writes an excellent blog on all the things which went wrong during the Hertz affair.  It would be amusing if it did not involve the squandering of millions of dollars.  It contains all the usual culprits in a massive software delivery death march.  Salespeople made promises to executive and then forced technology professional to keep them.  Poor infrastructure at the client exacerbated poor development from the consulting company.  The deadlines were unrealistic, and the client abdicated all responsibility for the success of the project.  Add in a pinch of arrogance from a top tier consulting firm, and you have a perfect example of what scrum masters and project managers alike call a dumpster fire. 

Nothing is more dispiriting than working on a dumpster fire project.  It stinks, and it is fraught with getting your career burned.  Often, developers put their heads down and hope no one blames them for the catastrophe.  The main reason for this state of affairs is large projects are so big that any small setback will grind the project to a halt.  The state of affairs undermines the psychological safety of the people doing the work, and everyone is afraid to step forward and be honest with project leaders.  I suspect this was the primary factor why the project failed.

Deadlines were missed and missed multiple times.  When it was over, 32 million dollars disappeared.  What makes the entire episode more galling is Accenture refused to do more work unless Hertz paid more money to fix a broken project.  Failure crashed into failure setting more money on fire, and the only solution was to throw more money into the flames.

I have worked with several people from Accenture.  They are very good at selling products and getting paid, but they are not good at delivering results.  In the world where they work, it was more important to get paid than it was to provide value.  According to the agile manifesto, this is a refutation of the value of customer collaboration over contract negotiation.  It is clear Accenture is more interested in contracts than helping customers.

I entered the agile reformation because I wanted to build things rather than toil in obscurity.  I have worked on projects where we extracted money and value from the customer rather than deliver it.  Working on a project like this does pay the bills, but it does not move the practice of software development forward or improve the reputation of the development profession. It is up to experienced agile and project management professionals to pour cold water on these dumpster fires.  The business needs to set a standard which is more than watching piles of money burn.  Otherwise, we will have more trash fires like Hertz and Accenture.

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.

Agile Coaching must work with Corporate Leadership.

They made great art but the rivalry was toxic.
 Don't let this happen to your coaching relationship
with business leaders.

One of the best things about being an agilest is the network of smart and committed people who are willing to provide insight into how they are solving business problems.  I know if I ask for help I receive plenty of suggestions and feedback.  I wrote a blog about how agile is good at exposing toxic leadership inside an organization.  I received some criticism from people I respect who thought I was creating a false conflict with leaders.  Let me explain myself.

Organizations are coming around to the Agile Reformation for one apparent reason; it is good for business.  Faster time to market and more precise focus on meeting customer needs translates into profits.  Business leaders are also discovering disengaged workers, and toxic leaders are a drain to the bottom line.  It is just like what baseball manager Tommy Lasorda said, “Happy Cows make more milk.” The reality of the benefits of Agile provides an opportunity to make business better.  It also means business leaders and agile coaches have a vested interest in working together. 

The tension between leadership and agile coaches happens when agile exposes inefficiencies in the broader business.  Development teams release software, but the business users are not interested in testing.  Network professionals block the use of Continuous Integration/Continuous Deployment tools because they see it as a career threat.  Finally, pointing out a toxic leader can jeopardize the balance of power in office politics.  I struggle to navigate these situations. 

Often when teams become more agile, the surrounding business is stuck in the status quo.  It is inside this shadow zone where a company makes the transition from doing agile to being agile.  The metaphorical rubber hits the road in that place.  The only way it can succeed is if business leaders buy in, agile professionals lead by example and teams follow through.  A woman I respect very much said, “Do your job, tell the truth and if it does not work out it is their problem.” 

A large organization can behave like an addict they know they are involved in the self-destructive activity, but they cannot stop.  Only when the organization realizes they have to quit will they.  A scrum master or coach needs to be available when they are ready to make the change.  Leaders should be partners in any agile transformation.  Collaboration and cooperation should be the guiding principles of this relationship.  If it collapses into codependence and conflict, then it is time for the coach to admit failure and go elsewhere. 

Until next time.

Agile and the Toxic office

The Open office plan circa 1960.  

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

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

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

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

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

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

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

Until next time.

Talk to People Instead of E-Mailing Them!

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

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

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

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

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

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

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

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

Until next time.

Understanding Estimation for the Misinformed

When I speak with business professionals, they often struggle to understand the basics of the agile reformation.  For example, when I hold someone accountable for not doing work, they are shocked I am expecting results.  Many times, I feel like am discussing a round planet with people who still think the earth is flat.  These kinds of misunderstandings often lead to dramatic blow-ups as the agile coach expects one result and the business a different outcome.  This week and over the next few weeks I will try to explain some of the basic ideas agile practitioners use.  Today, an overview of why the agilest use story points.

One of the most controversial activities in business is project estimation.  The reason why is many estimates for creative projects is a lie.  The company is lying to itself about what it wants and how much it is willing to pay for it.  The creative team usually lies about how long it is going to take to complete the work.  To any objective person outside this process, it looks like madness.  Everyone is lying, money is getting spent, and nothing gets into production. 

Project Estimation is farce and tragedy.

The agile manifesto came into being with the twelve principles of agile because the failure of major projects in the business world was becoming unsustainable. The firm spends too much money for too little return on investment; something had to change.  The first thing the agile reformation addressed was estimation. 

A traditional project begins with executives looking at the corporate budget.  After the debt is serviced, shareholders compensated, and payroll met a portion of the money is left over.  Managers then submit requests to spend this leftover money on capital improvements and technology projects.  Based on profitability and political clout, this money is doled out.  For the attentive, you will notice the business executives do not experience the same reality of the front line consumers or employees.  Thus, a software project begins with a pile of money.

The managers and directors once they receive this money then have to figure out how to spend it.  The money comes with plenty of strings.  The project has to meet a deadline which may or may not be grounded in reality.  The plan must work with current technology at the firm.  Finally, the manager must have people who understand how to take that pile of money and turn it into working software. 

What happens next is something resembling a demented game of “Name that Tune.”  The manager goes to consulting companies and internal development teams asking how much time it will take them to satisfy the project requirements. The consulting company will bid a price to earn the business.  The internal developers will offer an amount to remain employed.  It goes on until the bidding ends and the project begins.  The costs are not grounded in reality, and neither are the estimates.

What happens next is both farce and tragedy.  The workers with the limited budget and impossible timeline fail to deliver.  Making matters worse developers are expected to incorporate changes mid-stream and the deadline does not change.  Eventually, the deadlines are missed.  The budget is used up, and cost overruns are rampant.  Finally, people quit because they are burnt out for working numerous hours of overtime to deliver a flawed product.  Quality suffers, money is wasted, and this approach ruins reputations. 

The primary cause for this kind of disaster is many managers equate time with money.  So, if you have $40,000 and it takes 1,000 hours to do something, this means it will cost $400 an hour.  Now suppose you have a consultant who will do the work for $200 an hour.  You can do twice as much work.  It depends on both of the people having the same skills and ability which is not the case. 

Story points for estimates came into being because time does not equal money for complicated projects.  Those projects also feature tremendous uncertainty and are often resistant to automation.  Instead of telling a manager that the team will be able to do the work in 1,000 hours at $400 an hour, a scrum master or product owner will say the team can do fifty story points a sprint and there are roughly 213 story points of work.  The ridiculous game of name that tune goes away and people can start having realistic discussions of time and money. 

Next week I will show you how that works.

Until next time.

A lack of skin in the game for employees

From the blog: ON ART AND AESTHETICS

Last week I talked about three types of cultural factors which can make an agile implementation challenging.  I also spent some time catching up with some of my contemporaries discussing the application of Agile at different firms.  It was a disappointing discussion.  This week I want to talk about agile and the lack of follow through in many organizations.

I started thinking about the inability for the organization to improve their agile maturity when fellow agilest David Koontz posted an article from the Harvard Business review about the failure of digital transformation at many firms. It opened my eyes.  I then noticed a new book published by the author Nassim Nicholas Taleb called “Skin in the Game,” about the uneven relationships we create in the labor market.  The most telling passage was the following.

“True, a contractor has a downside, a financial penalty that can be built into the contract, in addition to reputational costs. But consider that an employee will always have more risk. And conditional on someone being an employee, such a person will be risk-averse. By being employees they signal a certain type of domestication.”

In short, being an employee of a large company creates people afraid of risk and rocking the boat. The company through its leadership and culture incentivizes particular behavior.  The employee trades their skills and dependability in exchange for a paycheck.  It creates situations where conscientious people tolerate ignorance and inefficiency because they say, “…that is how we have always done it.” Thanks to this submissiveness large firms stagnate and die.

It also explains to me why agile coaches are contractors.  In the words of Ken Schwaber, agile holds a mirror up to an organization.  Many organizations are not equipped professionally or psychologically to look at that reflection because they would see the incentives they have created are perverse and the services they offer are not meeting customer needs.  It is like being in the Jean-Paul Sartre novel “Nausea.”  The world we know crumbles away, and we see the disorienting reality of how things are working. Confronted with this we have three choices:

1. Wallow in despair and impotence
2. Ignore the truth and pretend nothing has happened
3. Take action and try to make change

The modern corporation incentivizes employees to make the first two choices.  Those who choose the third option either quit or the company fires them.

So as a scrum master or agile coach we are stuck making a change at the margins and moving on when we cannot do anymore.  The global economy continues to spin, and nothing seems to change. It is easy to get discouraged, but the size and diversity of the agile reformation continue to grow.  According to Scrum.org, over 100,000 people are trained at Scrum.  Figures from the Agile Alliance and Scrum Alliance are harder to come by, but eighteen years ago the manifesto began with fifteen people in a ski lodge.   The growth of the movement has been increasing and today’s consultants and practitioners will become tomorrow’s managers, directors, and executives.  It is a matter of time, and the Agile reformation will be driving reform inside the business establishment.

So perverse incentives prevent businesses from being more innovative and agile. The good news is the agile reformation is growing and with this growth will come increasing acceptance.  It will not be easy, but it will be worth it.

Until next time.

It is worth it!

The work is worth it.

I have been doing plenty of reflection.  I blame the dispiriting winter season in my hometown of Chicago.  The cold winter nights force you to confront your past and ponder your purpose.  My friends and social media contacts are asking me plenty of questions about my weird profession.  These kinds of existential moments make me want to do a little explaining.

I joined the agile reformation in 2009.  I was working as a contractor for a family run medical supply company.  I was thoroughly miserable.  I had no job security and little hope. I spent each day grinding out code for capricious people who treated everyone not family as medieval peasants.   Family disputes would boil over on to the sales floor, and anyone caught in the crossfire could lose their job.  It was such a dispiriting place to work.  I witnessed the ten-year-old grandson of the founder tease a salesperson saying, “Daddy says you are fired.”

In the middle of this night of the soul, a project manager decided the team should try “agile.”  It began with daily stand-ups and doing releases in two-week chunks.  It ended with unemployment.  The project manager left for a better job.  The IT Director realized I had more credentials than he did so I was a threat, and it made me expendable.

Between job searches, I did research and the more I learned about Agile, the more I realized it was a better way to lead software projects.  I also realized that the concepts while simple to explain were hard to implement.  Thanks to the Agile Manifesto and the early proponents of the scrum, there was a way to perform technology work without abusing people and providing better value to the business.  I would spend the next four years as a developer spreading the word about this new approach.

Things finally came to a head when I left my last role as a senior developer and became a scrum master full time.  I was no longer some developer mentoring others.  I was leading other teams and setting an example.  I thought I was ready.  I was wrong.  Over the last five years, I have been tested and challenge in numerous ways.  I have succeeded in public ways and failed in equally public fashion.  I am not the scrum master I was five years ago.  Everything I have learned along the way has made me better.

I keep thinking about a quotation from Dave Burgess I tweeted out last week.

"It is not supposed to be easy- its supposed to be worth it!" Nice wisdom for scrum master from #tlap #agile #leadership

— (((Ed Wisniowski))) (@eeeThree_ed) February 13, 2018

The last nine years of my agile journey have been challenging, but it has been worth it.  I am a better leader.  I am a better developer.  The software is getting shipped on time, and the office is a little less capricious.  I do not have entitled ten-year old’s threatening to fire me, and the business community seems to be catching up to my way of thinking. 

This hard journey is probably worth it, and I am proud to be sharing it with you.

Until next time.