The Benefits of a Good Backlog.

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

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

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

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

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

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

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

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

Until next time. 

A backlog must be DEEP

I am continuing my series of articles about the basics of healthy product ownership. The most fundamental thing in Agile is the product backlog. Borrowing from Dave Todaro and his book “The Epic Guide to Agile,” I said that the basic building blocks of a product backlog are user stories, bugs, and tasks. Today, I want to emphasize the structure of a backlog. 

Roman Pichler writes plenty of great books about Agile. My favorite is “Agile Project Management with Scrum.” Here, Pichler outlines his DEEP model of product backlog management. For a backlog to be robust, it must have the following necessary and sufficient conditions:

• It must be Detailed.
• It must be Estimated.
• It must be Emergent.
• It must be Prioritized.

I have blogged about each of these conditions in other blog posts. Today, I want to review them again and develop some structure you can use to ensure that your backlog is healthy and helping drive value. 

Many businesses actively view a product backlog as a grocery list to fill. It is a mindset geared toward failure. Even the most successful software projects began as small experiments that grew and adapted to market conditions. So, unfinished items are revised based on what the customers want. That is why we say a backlog is emergent and prioritized. A business must determine what is important and do those things first, and if the market determines those priorities need to shift, we must be flexible and intelligent enough to change them. Ego is the enemy of agility. 

One of the most universal features of project management is that once you start doing the work, there is no way to know how long it will take to complete the task. The reality is known as the cone of uncertainty. Estimates can be wildly off by a factor of eight from the low end to the high side of the budget and timeline. The only way to reduce the uncertainty is to do the work, which means that you are adding more detail and information to user stories. It also means that estimates may change as more information becomes available. The code of uncertainty will narrow, but it will take time and patience, which are in short supply in the global economy.

The properties of detail, estimation, emergence, and prioritization combine to make your backlog resemble a leaderboard at the golf event. A golfer rises and falls on the board based on the condition of the course. Halfway through a tournament, a cut takes half of the golfers out of contentions—the ones who make “the cut” then compete for the real money and recognition. Instead of golfers moving up and down a leaderboard, think of the user stories moving up and down the backlog based on the competitive information from your customer base. 

The road to healthy product ownership travels through a detailed, estimated, emergent, and prioritized backlog. A product backlog that meets those conditions will deliver value to the project and generate revenue for the firm, which keeps everyone working for another day. 

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.

A Place for the Manager in the Agile Organization

I am always impressed by my fellow Agile advocates. Some are grumpy cynics who see failure around them and feel responsible for helping clean up the substantial debris cluttering global business over the last fifty years. Others are cheerful warriors attempting to show a better way by living example for others to follow. My approach lands somewhere in the squishy middle as I see behavior that violates my values. I understand intellectually that these violations are occurring because people created those systems to normalize those violations. 

As an agile professional, I have spent the last ten years fighting the uphill battle of changing business culture and performance. A common observation we in the Agile community have when we attempt to bring Agile to organizations is that teams quickly adapt to this new reality. Managers, in particular, are a constraint on how successful agile is in an organization. Today, I want to discuss the manager's role in an organization. 

My coach at CAPCO Financial, Michael Guerrero, ruefully observes that middle management is where agility dies. Executives know the importance of being more agile, and teams embrace the ethics of agile frameworks like Scrum and Kanban. Managers are often caught in the middle and do not know how to navigate an organization transitioning to agility. The challenge of finding a place for a manager is becoming a central question in the agile reformation, along with how to scale it to the entire organization. Diana William and Liz Rettig from Project Brilliant gave an excellent presentation at AgileIndy 2023. 

The Scrum Guide and Agile are very good at defining the roles of a scrum master, product owner, and team member. The Agile community is silent about where managers fit into this system. It does not help that we do a poor job selecting and training managers and that those who advance into those roles behave in ways detrimental to the organization. Instead of making middle managers scapegoats for the failure of agile, coaches and scrum masters need to recruit them as partners for success. 

Williams and Rettig suggest four roles for the manager in an agile environment.

Provide Strategic direction –

Managers need to provide clarity and direction to the teams. They explain the 'why' of the decisions made and let the agile teams figure out the 'how' and 'what' of work. In traditional managerial roles, they thrive on ambiguity in an agile environment and must provide clear guardrails for performance and conduct. 

Grow People – 

A manager in an agile environment must grow the people they serve with training and development so that their skills become more 'T' shaped and they can advance within the organization. Even a person content to remain in the same position can learn to be better at their job. Managers of this type are judged by how they grow the people under their care. 

Create an Environment for Success – 

Managers in an agile environment need to learn how to address constraints and impediments. These managers must create solutions to these blockers and create an environment where people want to work. It is more than coffee, pizza, and foosball tables. It includes reducing technical debt outside the team and getting collaborations from other parts of the business. 

Being an Agile Champion – 

Finally, a manager in an agile environment champions the process. They encourage retrospectives, support efforts to build psychological safety, and allow teams to design their work areas. They must be willing to exhibit the same continuous improvement they expect from the development team. Finally, they need to get out of the office and talk with the scrum masters, product owners, and stakeholders to ensure they have what it takes to succeed. 

These are the four roles of a manager in an agile environment, and they will look alien to people accustomed to sitting behind a desk and doing administrative work. It is a much more hands-on role. 

When we portray agile in organizations, we show it like a three-legged stool with the development team, scrum master, and product owner, each playing a supporting role. We intentionally exclude the manager. If we want Agile to succeed, we must change this mindset to include managers. Thus, a manager should envelop the team providing these four services to make each of its legs successful.  

The next five years will be critical for Agile's success, and it is up to us in the profession to ensure managers are not left behind.

Until next time. 

Decisions are Better Than Dithering.

One of the most amazing things in my experience in the business world is the people responsible for millions of dollars of business and hundreds of people but incapable of making a decision or setting a priority. It is so common that it has become a cliché in business writing and the popular imagination. Decision-making and prioritization are central to success, so why are many business leaders so bad at it? 

In college, I was eager to graduate because I wanted to work with the mature grown-ups of the business world. I was deeply disappointed by some businesspeople's emotional maturity and self-reflection. In fact, I soon discovered that a contemporary corporation has many of the same characteristics as a high school. You have jocks as part of the sales force and leading important teams because they look the part. I have experienced plenty of mean girls who become awful women in marketing and human resources. Band and theater kids gravitate to customer-facing roles, while the more nerdy contingent makes a living among the technology staff. If he were still alive, John Hughes could make a great movie about the contemporary office. 

Unlike high school, a corporation does not have teachers or administrators to reign in bad behavior and raging hormones. The students are running things, so tribal and personal bias plays a big part in who succeeds and who fails. Leaders prioritize being likable to their peers over getting things done. A popular person is likelier to be promoted than someone despised. It forces ambitious people to be uncontroversial. It means saying yes to everyone they can above them and being pleasant to a fault. It is the behavior known as "kiss up and kick down," which business professor Robert J. Sutton defines as an asshole. 

These individuals do not need to make decisions; they must be cute or charming to their superiors, keep their peers from hating them, and keep the people they serve busy. As time passes, they rise in organizations and act like cholesterol, slowly choking the life out of the organization. When asked to accomplish something, they often take credit for someone else's work or find a helpful scapegoat for failure. Being in an environment like this is why productivity is low and worker engagement is poor. 

The harsh reality is that Collin Powel is correct when he says leadership means you will piss people off. Deciding to do something or setting a priority for work will make enemies. Unfortunately, skillfully getting the job done is not enough; you must be likable. Thus, these ineffectual people wind up in leadership. 

The good news is that agile forces an organization to see itself as it is and confront ugly truths. It is then up to the organization to decide if these ineffectual people should remain in leadership. Nothing is worse than two equal priorities colliding and creating an organizational train wreck. So setting priories is the first skill that all leaders need to perfect. It is simple to do in practice; develop a list of things that need to get done and then number them with no two items having the same number. As items get completed, then review the list and re-prioritize it. It provides you with flexibility and communicates what is getting done. It will still create enemies and cause conflict, but the information's transparency ensures that all controversy will be out in the open instead of getting whispered behind your back. 

You cannot change business people's feckless and immature nature, but you can create incentives where people set priorities. A workplace where work gets completed is better than one mired in dysfunction. Each of us in the agile profession needs to be transparent and clear about priorities and decision-making. Otherwise, we are reliving the worst aspect of high school. 

Until next time. 

It Is Never a Ten Minute Fix

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

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

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

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

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

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

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

Until next time. 

Reflecting on Time Off

The last week has been a departure for me. Instead of working and concentrating on my numerous pursuits, I spent most of my time sleeping and relearning how to eat again. The rough moments felt mighty low. Fortunately, they did not last long. Many people have difficulty being alone, and I am no exception. I prefer focusing on things I can control. When your body is recovering from major surgery, you must depend on a team of doctors, nurses, hospital staff, and family members to help you get through the days. This vulnerability and dependency are new to me, and I consider it as I return to work. 

As a society, we train professionals and business people to be suspicious and skeptical of others. People are always looking for a better deal and an advantage over others. It hurts trust, which is the central lubricant of the business world. Without trust, the gears of the global economy would grind to a halt. Work is also so extensive and complex that hundreds of skilled professionals must work on systems to make a change or come up with innovations. Combining this reality with office politics, egos, and incompetence and creating things in the global economy feels like a torturous death march. The author Lewis Carol said, “That between light and darkness lies the shadow.” It is clear to me that I have made my living within this shadow realm. 

As an agile coach and leader, it has made me reaccess how I look at this shadowy realm of dysfunction and frustration. First, I cannot change things that are outside my control. I can control my emotions and guide my teams to do the right things, but if the organization does not want to change, I cannot force it. Next, if the recent layoffs in the tech industry prove anything, work is a place to make a living instead of being a surrogate for a family. If I die, it is clear that my family will mourn my death and lower me into the ground. A company will post a job opening the next day. I will bring a sense of craft and professionalism to my job but will never become emotionally reinvested again. Experience has also shown me the people you can trust and depend on are rare. When you find those people, it is your responsibility to cultivate and empower them so you can do your job better.

This kind of understanding comes with experience and plenty of failures, but it guides me forward. Being an agile professional means dealing with the world as it is and aspiring to make it better. Sometimes, I question my dedication and commitment to those goals. In my small way, I have made the world better, so I carry on. It is ambitious to change the world a bit at a time. Hopefully, my legacy will alter the future for the better. 

Until next time. 

Cross Training for the Curious Agile Coach

Software development is a long slog of false starts and frustration. It is different from other forms of construction. Stakeholders generate vague guidelines, and it is up to software engineers to transform them into working software on various platforms. As an agile coach, the complex process of building software must have an environment of psychological safety, mutual respect between team members, and a ruthless commitment to quality. I keep thinking about Alex Stoley's discussion about how we need to have a 'brain transplant' between members of an agile team. 

I first met Alex in 2018 at the Agile 2018 conference. We were both giving presentations, and I looked forward to his unique perspective. During his presentation, he used the metaphor of a mad scientist to describe the process of cross-pollination, which should happen between a scrum master and a product owner. He likened it to something like the Frankestines monster, with brains transferred between the two roles. To Stoley, only by living and working in the other person's role was it possible to improve the entire team's performance. I instantly converted to this message, and when I had a  chance, I decided to work as a product owner to improve my skills. 

Today, I continue to think about Stoley and his message. My experience in the software business has convinced me that teams perform better when members cross-train. Training like this allows team members to help each other during difficult periods and prevents bottlenecks from happening when one team member can only do work. Each team member can have a specialty, but each member is responsible for instructing the others on the team on how to do the basics of that specialty. Someone with object-oriented skills can help a javascript developer better understand types. That javascript developer can teach the object-oriented developer how a domain object model works on the web page. 

The cross-training process on your team will be hard work, and the go-go business world might need help understanding it. Still, the hard work done upfront will make the team more resilient and better able to code with the numerous challenges which crop up during a software release. 

If you attempt to explain this to an executive, use a metaphor from athletics. The next player steps in to fill a role when a football player is injured. The replacement player is good enough to help the team and will act as a sparkplug for the people already on the field. Crosstraining is also valuable because it defines the standards of excellence everyone on the team should follow. For example, everyone on the team should know how to write unit tests because a story is incomplete until someone writes a unit test. Thus, when new people join the team, part of the integration process is showing them how to write unit tests. It creates a common bond that all the team members share.

Brain transplants are the stuff of science fiction, but the benefits of cross-training are genuine. Team members who share a standard skill set are less likely to get stuck and perform better for the organization. That knowledge makes me want to cackle like a mad scientist. 

Until next time. 

Product Ownership Onward and Upward

Product ownership is the most demanding job in agile and gets the least attention.  I have created a series of blog posts to explain the skills necessary to become a great product owner.  Today, I want to summarize and provide some inspiration.

The first thing that a product owner should understand is the team succeeds or fails together.  The scrum master, product owner, and development team all hang together.  Rock stars, divas, or people seeking to punch their ticket to a higher position need not inquire into the role.  The agile principles plainly state that working software is the measure of progress.  The team creates working software and should receive credit because it is never about one individual.  If you are looking for glory, my recommendation is reality television. 

The next thing to remember is the social compact of agile.  The product owner must respect the estimate of the development team, and the development team must respect the priorities of the product owner.  The product owner sets the importance, and the group says how long it will take to do the work.  It is a difficult balance to master, but it will build trust in the team.  

Next, a product owner should adopt the DEEP model of backlog management from Roman Pichler.  The DEEP model is the blueprint of your backlog.  Having a backlog that is detailed, estimated, emergent, and prioritized will make everyone's life easier.  Sprint planning is easier when you have correctly detailed stories and the team estimates them.  Priorities help organize the social compact of agile, which builds trust.  

IF the DEEP model is the blueprint for the product you want to build, then to author good user stories are the individual bricks that make it possible to construct those products.  Stories that have clear descriptions of work plus acceptance criteria for getting the job done to speed up the development of the product and make it easier to test are what separate good product owners from great ones.  Thus, product owners need to practice writing better user stories.  

Finally, a product owner needs soft skills to deal with the "art" and the science of creating a product.  It requires saying not to others because priorities do not align.  Listening allows you to understand what needs doing and why.  Good listening skills also allow you to build trust with other teams.  Finally, diplomacy is necessary to deal with situations where there is a power imbalance of a stressful situation that requires navigation.  These soft skills help build professional credibility in the job.  

Most organizations do not understand the importance of quality product ownership.  The DEEP model, writing good user stories, and soft skills will set you apart from a run-of-the-mill product owner.  By embracing these areas of professional development, you will improve your career and your team's performance.  Product ownership is the most challenging role in agile but, if done right, the most rewarding.

Until next time.  

Soft Skills for an Excellent Product Owner

I want to improve the skills of Product Owners.  I introduced the topic and provided tips about backlog management and authoring user stories.  Today, I will discuss the soft skills a good Product Owner needs to cultivate.  

The Authority and Ability to Say No –

One of the tragedies of the contemporary business world is the number of people who are crushed with responsibility but have no authority over what they do.  Open offices and cubical farms contain many lonely souls who are accountable and responsible for the business's success but have no say in its operation.  Daily they are asked to sacrifice and be team players.  Bathed in toxic positivity, they stifle emotions and abilities for the business and their careers.  The unspoken rule is saying no to a request from leadership is career poison.  Business leaders need to break this cycle of abuse and mediocrity.  The first step is to give Product Owners the ability to set priorities and say no.  It means that they should be director or Vice President level in the organization and responsible for an individual portfolio of work.  

Listening Skills –

A Product Owner needs to learn how to listen.  A product owner will interact with customers, developers, and executives on any day.   Each interaction requires listening skills that account for what is said and intuiting what is left unsaid.  I continue to struggle with this skill because I feel I can continue to understand better the needs of the people I work with daily.  Not only do you have to understand stated and implied meaning in conversation but communicate it to others.  Having listening skills will separate the great product owner from the good.  It requires taking notes, being transparent, and spending plenty of time following up.  

Diplomacy –

Product Owners will find themselves in situations with a significant power imbalance.  These situations will include unhealthy levels of stress.  A key to survival is being diplomatic when everything goes sideways.  Diplomacy requires you to use "please" and "thank-you" when you want to say something else.  It is factually answering questions when being yelled at over a conference call and keeping your mouth shut.  At the same time, your manager attempts to steer a conversation into a more constructive place.  Finally, diplomacy requires you to let someone reveal they are a jerk instead of personally bestowing that title on them.  Being diplomatic does not mean you are a pushover; instead, you are advocating for your team and yourself in a manner that cultivates the respect of others. 

Product Ownership is a difficult job, but it also is an opportunity to deliver value to the organization in a conspicuous role.  The ability to say no, listen and diplomacy make it possible to be an excellent Product Owner.  

Next time we wrap up. 

Writing Good User Stories

The most important responsibility of a product owner is to write user stories.  It requires focus and skill.  The team members are responsible for completing work, but the product owner makes sure the team has work that delivers value to the business.  Today, we continue our series on healthy ownership by looking at some helpful guidelines on how to write better user stories.  

User stores are the bricks that construct your product and deliver value to your organization.  Together as an assemblage, they are the structure for all the agile team's conversations about the work they accomplish.  Good user stories have two principal characteristics: why the story needs execution and, finally, acceptance criteria that explain success.   

I wrote a blog three years ago which explains my technique of writing stories that I teach to others.  Please take a look at it here.  It features a sentence narrative that I then explain what needs to be done and why.  I do not tell the agile team how I want the work done.  It is because the team members are smart enough to develop solutions.  The team will appreciate the trust. 

Next, I encourage you to author acceptance criteria using the Gherkin syntax.  The simple use of the given, when, then narrative makes it easy for quality assurance people to confirm quality and for the developer to do the work.  Clear acceptance criteria in a given, when, then format avoid mistakes when people attempt to parse ambiguous requests.  Acceptance criteria allow the team to estimate more effectively and split stories.  

Finally, embrace the INVEST model of writing user stories.  INVEST stands for independent, negotiated, valuable, estimated, small, and testable.  These qualities make a user story a helpful nugget of information to help complete work.  

User stories are the bricks that make up the cathedral of your product.  If you create quality stories those bricks will be strong enough to make your product a success.  The architect Louis Kahn famously said, "Even a brick wants to be something."  

Next time the soft skills of a good product owner.  

Using the DEEP Model for Success

Agile has three primary roles, the development team, the scrum master, and the product owner.  Since the authoring of the agile manifesto, the reformation has done an excellent job encouraging the development of craft among software developers.  The reformation has also spent considerable time working on the professional development of scrum masters.  The weak link has been the development of product owners.  Understanding this, I have dedicated most of my career to helping product owners improve.  I call this “healthy ownership,” and today, I want to discuss a portion of what it takes to be a successful product owner; backlog management.   

When I discuss the principal role of a product owner, I say they are responsible for telling the development team what they need to work on next.  A product owner is also responsible for the business, ensuring the customer receives the value.  It is a demanding role that requires diplomacy, expert business knowledge, and a full-time commitment.  

Unfortunately, most organizations do not feel this way and often provide product owners who work part-time while doing other accounts receivable or shipping tasks.  A product owner should also have the authority to say “no” to others but often are subservient to executives.  The minimum requirements for a product owner are full-time commitment to the role, executive-level authority to set priorities and say no, and finally, the ability to work diplomatically with people inside and outside the development team.  It is not an easy job.  

The first order of business is to create a list of work that needs to be done by the development team.  It is called a product backlog.  Roman Pichler wrote a fantastic book on product ownership and scrum entitled “Agile Project Management with Scrum.”  In it, he outlines a helpful framework for organizing a product backlog.  It is called the DEEP model.  It is an acronym which stands for –

• Detailed
• Estimated
• Emergent
• Prioritized

I have discussed these backlog qualities in more detail in previous blogs.  I have included links to the original articles to review at your leisure.  

A detailed, estimated, emergent, and prioritized backlog is a recipe for success.  Estimated stories allow product owners to answer better the question of when work will get finished.  The correct level of detail in stories makes it possible to understand what needs to be done instead of doing it.  Just make sure you treat estimates like an educated guess instead of a quotation; otherwise, you are setting yourself up for unnecessary stress.  Backlogs are emergent because uncertainty around a project decreases when you get close to completion.  Prioritized because if nothing has a priority, then everything has a priority.  Lack of prioritization will transform any project into a carnival of chaos, so you must be sure you are doing things in a set order.  

Using Roman Pichler’s DEEP model is an excellent working guideline on managing work for your Agile team and giving you a leg up on other product owners.  

Next time a discussion on how to write user stories.  

When the Going Gets Tough Emotional Intelligence is a Force Multiplier

One of the most frustrating things I experience is business people making promises to customers and expecting technical professionals to keep those promises.  It is a clear violation of the social compact of agile.  Sadly, it is also a common occurrence.  In these high-pressure moments, it is clear that the people making the promises do not have the technical knowledge necessary to keep those promises.  If the situation becomes, egregious people can wind up in jail.  I have spent plenty of time working on these intense projects, and I want to try and provide a few tools to keep you from going insane.  

William H. Janeway is a founding silicon valley venture capitalist; his book “Doing Capitalism in the Innovation Economy” includes a great piece of wisdom about times of crisis in the investment world.  When situations deteriorate in a business, investors want cash and control.  The money is necessary in case of more economic hardship, and the control ensures work gets accomplished.  It is a harsh truism.  

With deadlines looming, executives are under intense pressure.  An executive often micromanages a team because it is the only way to look like they are in control.  It feels like playing a game of twenty questions with someone on amphetamines, pointing a gun at your head.  

Conversations resemble the following.

Executive #1 – “Those two bugs, when are they going to get fixed?”

Product Owner – “We wrote up the bugs five minutes ago when we were testing, so we are going to diagnose the problems and provide logs for the development team.“

Executive #2 – “We promised the client a release date on X.”

Product Owner – “I am aware, but releasing buggy code is going to undermine our relationship with the customer.”

Executive #2 – “We need that by X.”

Executive #1 –  “Can you give me an ETA on those defects so I can report them to my boss.”

Product Owner – “Yes, as soon as we trouble-shoot the problem and gather response object from the failed service.”

Executive #1 – “So when?”

Product Owner – “I am not sure.  Let us work the problem.”

Executive #2 – “We could lose millions of dollars if we don’t release by X.”

As you can see, conversations like this resemble something out of a Kurt Vonnegut novel.  The stress levels increase, and no one benefits from the increased attention other than the executive. 

Often you are working with people inside your team and outside to address crises.  It requires plenty of emotional intelligence to do this correctly because many of the people around you begin to panic and are frazzled.  When confronted with situations like this, it is best to be the calmest person in the room.  State the facts and tell people what you are doing to work the problem.  Also, share with leadership the others working with you to fix the problem.

Next, let people know they are creating unnecessary stress.  If a manager is asking for updates each hour for a bug in testing, point out that their concern, while necessary, is not improving the situation.  

Finally, be kind to others and yourself.  Deadline pressure is never fun, but everyone is in the same difficult situation.  Being mean or showing a lack of kindness will create a feedback loop of reprisals on the team.  If the unit is fighting, they are not focusing on the deadline.  Kindness and grace are not easy during a deadline, but they are necessary to get the job done. 

High pressure and uncomfortable situations happen in software development.  As a coach or scrum master, you must show emotional intelligence when others are not.  

Until next time. 

Uncomfortable Truth Defeats Convenient Fiction in Agile

Working on a colossal software project is an endurance exercise.  Based on my experience in software development, no one agrees all the time during a project.  Coordination with thousands of people across continents to get something done is challenging when everyone agrees; it is next to impossible when there is a dispute.  The amount of money, time, and reputation wagered during each software project is tremendous, and this high-pressure environment arouses strong passions.  As a coach or scrum master, a person needs to adjust to those strong waves of emotional energy and find ways to move the work forward.  I want to discuss how to make this happen.  

Large projects are a Rube Goldberg contraption of competing interests, visions, and skills.  Systems which need to work together are often incompatible.  The people doing the work rarely understand the systems they are working with and how they are supposed to work.  Finally, no one person understands how the entire system operates.  What is not apparent is what the team must do and why it needs doing.  The only clear thing is that the project has funding and something needs to be delivered.  

Soon, skilled professionals will attempt to collapse the cone of uncertainty and figure out those two crucial questions.  By the time work begins, some understanding should be part of the project.  In reality, work is done blind, and the organization attempts to dig through the complexities of the task at hand.  

It also does not help that there are considerable gaps in power between the people commissioning the work, those leading the job, and the developers doing the work.  An executive vice president wants to know a completion date, and when they ask a developer who they can fire, the developer will create a comfortable fiction.  It ratchets the stress on the development team because the executive now treats the comfortable fiction as an actual deadline.  If the deadline is missed, the CIO becomes involved in the project, escalating the tension further.  

What happens is an awful cycle of failure which undermines trust up and down the chain of command.  It leads to micromanagement and arguments about service level agreements and contracts.  Sadly, I have experienced these situations more than I would mention.  

Clearly, as a coach and scrum master, we need to address this awfulness.  First, recognize a power imbalance and make it clear to everyone involved.  Let people know that someone will not return your calls or email without getting a director or vice president engaged in the conversation.  Next, state that you do not know what to say in a situation because you are not in a position of power.  For example, “ I want to provide an estimate for that feature, but I am understaffed and do not have the authority to hire.”  Finally, state the uncomfortable truth instead of a convenient fiction.  It is the hardest part of an agile professional’s job because it puts you at risk, especially contingent workers or consultants.  

Business is overflowing with convenient fiction, but if you want to get work done, you will have to point out uncomfortable truths and ambiguity in what is happening.  If you don’t, it will create the cycle of mistrust and escalation, which I outlined earlier.  Robert Sutton points out that corporate leaders often live in a “Fools Paradise,” where they only receive good news because subordinates are afraid they will be ostracised or fired for bringing bad news.  It is true in an organization with little psychological safety, but leadership will be grateful for the clear insight in an agile organization.  Thus, it is courageous to tell uncomfortable truths instead of a convenient fiction to leadership because if they are good leaders, they will act on these truths instead of burying them. 

Massive projects are challenging.  Working on one makes you feel small and futile.  What will help you and others get things done is admitting uncomfortable truths and working through them.  It requires courage and strength, but it will be better for everyone involved, and the project might get done sooner.  

Until next time. 

Communication is Necessary for Agile

Leadership is a complex subject to discuss in a business setting.  Many people wrongly believe that leading others is an inborn trait.  Others have backward views about who should be in positions of leadership.  Over the years, I have discovered that leadership is like any other skill; it must be practiced.  Today, I want to cover a simple craft that gets lost in gigantic organizations and improve your leadership skills – communication.  

I pointed out an article in Forbes magazine saying managers need a better job description.  The main argument of the blog is contemporary organizations discourage the creation of leaders because of the ambiguous nature of the information within their corporate cultures.  The decisions have to be correct instead of fast.  Paralysis forms because no one wants to stick out and call attention to themselves in this environment.  In the current global economy, it is a prescription for failure because market conditions are changing faster than the decisions process in many organizations.  

Personal initiative, taking responsibility for decisions, and taking action when required are discouraged in organizations with this retrograde culture: another characteristic that suffers is communication.  In an unhealthy organization, managers do not want to hear bad news from subordinates.  Unhealthy organizations also discourage the free flow of information.  Information comes from the top of the organization and filters down to employees.

Organizations with a more healthy culture embrace the value in the agile manifesto, which prefers “Individuals and Interactions, over processes and tools.”  Thus, information moves both up the hierarchy of the organization and down.  The terrible news is communicated accurately, and leadership acts on it.  Finally, we see fewer meetings and more action taken by people doing good communication.  

It means having a rapport with your development team as a product owner.  A good product owner acts as a bridge between the business and the development team.  As part of the job, you need to regularly communicate with the organization and the software customers.  It is vitally important to communicate with the development team. 

Writing user stories and giving them to the development team is only part of the job.  The developers have questions, so you need to be available to answer those.  Finally, the development team is a source of valuable information for other development teams.  Often front-end developers need direction from other teams who write APIs or middleware.  On large enterprise projects, you can ask your developers to answer questions for different groups.  A product development team can answer a simple question then share that information with other groups.  Even better, they can facilitate a face-to-face meeting to share information. 

Traditional project management approaches treat information communication as a one-direction process.  The people doing the work communicate the progress, and then the project manager acts as a scorekeeper.  Agile requires communication to be a two-way street where information moves both up and down the chain of command so that people can make educated decisions.  In an agile organization, secrets and unshared information are risks that undermine a project. 

Communication is not easy.  It takes effort and humility to listen to others, particularly those with less power.  Listening and conveying information helps avoid surprises.  Learn about your team, and get to know them as people.  Take time to listen and accept bad news when it is delivered.  It takes practice, but anything worth doing requires effort.  

Until next time. 

Communication is the Key to Agile

Gigantic enterprise projects require thousands of developers and countless hours of work.  I am working on one of these projects, and I have learned a few things along the way.  Today, I want to discuss the importance of communication if you are going to be a successful agilist. 

When working with extensive enterprise applications, you should understand that no one will know how the system works.  A person will understand how a particular portion works but not how the entire system operates. Today's giant software applications for business are so big and complex that it is impossible to comprehensively understand how information flows through the system.  Confronted with this reality requires numerous people's collaboration to outline how a system operates.  

The collection of experts in a room will hash out how the system operates.  Once they have a general idea, they start creating user stories to flesh out that operation and assign work to different teams.   With software teams scattered around the world in different time zones, questions are bound to come up.  Product owners and scrum masters then attempt to bridge the gap between the various teams to get the work done.  It is a tedious and painstaking process. 

I use a technique I learned in my undergraduate days as a speech and debate person.  I tell people what I am going to say to them.  I tell them and finally tell them what I just told them.  These techniques sound redundant, which is the point of the entire exercise because repetition aids in the retention of information.  

For instance, we are adding extra fields to an API, so I call a meeting to discuss it with the vendor and the team consuming the vendor's API.  I send out a meeting notice with a brief plan.  During the conference, I said, "We will cover the new fields in the API and how they are going to be consumed."  The next portion of this meeting talks about the fields and how the team will consume them.  At the end of the session, I review what we talked about and, if necessary, follow up with an e-mail and some user stories the teams need to finish.  

Notice the goal of the meeting is clear and stated up-front with a clear purpose.  We work toward that goal.  Finally, we restate how we are going to achieve that goal.  It helps to leverage the communications systems used in the office, including e-mail, instant messaging, and project management tools.  It is a way to hold people accountable and make sure they understand. 

Checking for understanding is essential.  It is one thing to say something, but understanding is a different skill.  It is why you should ask others to repeat back what they know.  When there is a disconnect, you can clarify the misunderstanding.  For a busy person, communication like this can be exhausting, but checking for understanding will improve the quality of work on the team.  The time spent talking now is going to save time doing rework later. 

On gigantic projects, it pays to over-communicate.  Tell people what you are going to tell them.  Tell them, and then tell them what you just told them.  You can thank me later when the level of misunderstanding decreases and quality improves.  

Until next time. 

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. 

Taking Agile One Day at a Time.

The most significant moment in any project is the ribbon cutting or product launch.  It features executives, politicians, and other VIPs cutting a ribbon or giving a splashy PowerPoint presentation before a crowd of adoring fans.  Many people do not understand that those moments of public triumph required many days of sacrifice, frustration, and suffering.  Technology is hard work, and it requires focus, intelligence, and unhealthy levels of concentration.  As an agile coach or scrum master, it is challenging to navigate these long periods of grinding work.  Today, I want to take some time to discuss how an agilist can navigate this period author Lewis Carroll labeled between the idea and reality.  

One of the most important books a technology professional can own is Fred Brooks' "The Mythical Man-Month" it outlines some principles of project management that remain applicable today.  It includes Brooks' Law, which says that late projects become later if you add more people.  Brooks talks about the importance of architecture in software development and how the division of labor between different specialists makes it harder to lead a project.  The most significant insight was the idea that a project falls behind schedule one day at a time for me. 

Each day the team attempts to get its work done.  If you are digging a hole in the ground, the task is straightforward.  Software professionals look at problems that resemble getting square pegs to fit into round holes.  Data from one system must be displayed differently on a mobile device than a web browser while traversing trillions of data points to obtain meaning.  Each day, engineers, developers, and project professionals slog through those problems and more.  It creates pressure that builds over time because many of these problems that need to be solved do not have easy answers. 

Chicago Sports columnist Bob Verdi would joke weekly when football injury reports were published.  A famous player often is listed as day-to-day.  With a comical tone, Verdi would tell his radio audience, "… aren't we all." As technology professionals, we are all living day to day, solving problems and building solutions.  It means that we should not concentrate on where we are in the project's overall life; instead, we should focus on what we need to finish that day.  It makes the emotional ups and downs less severe.  

Taking the work day-by-day allows you to filter out the politics around projects and the petty displays of status you see in corporate environments.  When problems linger, you gather together with others to find solutions.  It is hard to do because the people who begin enterprise-level projects are not around when they finish.  It is why you look at each day as a single unit and judge your success or failure on how you meet the goals of that particular day.  You build up good days and attempt to shrug off the bad ones to create a body of work that meets the project's long-term goals.  Brooks is correct projects do fall behind day-by-day, but they also succeed daily.  

If you are a coach or scrum master, instill this notion in your team.  The team is building big things, but they create many small items, adding up to something spectacular.  Improving one percent a sprint means an improvement of over twenty-six percent over a year.  Improving team performance like this often gets people promoted in corporate environments.  It makes working on the team more satisfying and lowers the stress levels of everyone on the project.  

Lewis Carroll said, "…between the idea and the reality lies the shadow." Taking work day-by-day allows you to handle better the darkness which occupies the shadows of your project.  It is not easy, but nothing worth doing is. 

Until next time. 

Smash Dependencies on Large Agile Projects

Working as a technology professional does not have the working-class credibility of being a plumber or ironworker.  We do not get dirty, and we do not pay a physical price for our work.  The worst injury we can suffer on the job is a repetitive stress injury or the occasional heart attack caused by chronic stress.  The biggest challenge in the profession is coordinating numerous savvy professionals to work together to accomplish a goal.  Today on the blog, I want to take time out to review dependencies for agile teams and mitigate them.  

When a project is small enough to require one agile team, dependencies are not a significant problem.  Often, the scrum master or a team member will take the initiative and address the situation.  At most organizations, a different team manages the production servers,  so when it is time to promote code into production, someone from the agile team makes arrangements with the server team.  Dependencies are simple on these projects. 

A larger project quickly becomes a tangle of dependencies.  For instance, an extensive enterprise application might have an AS/400 team working with enterprise data, a group writing a web interface, and finally, a group writing middleware to connect the two.  At this point, dependencies grow on a logarithmic basis.  Add an extra team, and the number of dependencies jumps from three to six.  Add a fifth team, and you get ten and so on until you get a tangle of communication channels.  The PMBOK guide has a fancy mathematical formula to calculate how these systems get out of control.  

Doing the math, a team of ten people or groups has forty-five different connections.  It is clear to see that the number of links and dependencies will be a problem for people to follow.  

The solution to this problem is to isolate those lines of dependency to make a clear connection between groups.  In my previous example, the middleware team is connected to the AS/400 team and the web interface team.  Upper management wants to add a team to write a mobile application.  Instead of linking the mobile development team to the middleware team and giving them more dependencies, the new team should collaborate with the web team because they already understand how to connect to the middleware already generated, saving cycle time and distractions. It seems counter-intuitive, but the knowledge from the web team will be more valuable than the middleware team attempting to educate the mobile application team on how to consume the web services.  Organizing your groups in this fashion prevent your dependencies from looking like the bedroom wall of a conspiracy theorist.  

To address dependencies, isolate them into narrow paths to reduce the number of connections between groups.  Not only does this conform with the PMBOK Guide, but it conforms to the theory of constraints because it allows a scrum master or coach to isolate and exploit limitations in a system.  Doing this will help remove complexity and lower your stress levels below heart attack severity.  

Until next time. 

Don't Estimate Spikes

One of the principal values of agile is individuals and interactions over processes and tools.  Each organization is different, so how they do agile is going to vary.  Coaches should be sensitive to this reality.  Unfortunately, as people learn how to practice agile at an organization, they often let old biases and ways of doing things obscure how they continuously improve.  It is at this point a coach steps in points out they are doing something wrong. So today, I am taking some time to correct a gross misunderstanding.  

Earlier this year, I wrote about a particular type of product backlog item known as a spike.  It is a helpful way to plan work where the team is uncertain of how to proceed.  A manager instructed a colleague and his team to provide estimates for spikes during sprint planning.  When I learned about this, my danger sense started throbbing like an infected paper cut.  A spike is not estimated.  People who ask for estimation on spikes are misunderstanding their purpose.  

A spike allows the development team to perform research and analysis.  If they do the job appropriately, at the end of the sprint, they will have a prototype, code which is proof of concept, or more user stories that they can correctly estimate.  The team is learning how to do something; to ask them when they are going to know it is foolish.  Imagine a high school teacher demanding a student estimate how long it will take to learn how to perform equations with two variables when they do not understand what they need. As a result, the student feels pressured and resistant to learning.  Software developers will do the same, or they will give the manage lip service to make them go away.  

I understand why some managers want estimates for everything.  These managers do not know any better and hate dealing with uncertainty.  It is a direct by-product of traditional project management training.  Waterfall project management depended on people knowing how long it would take to perform a task. For example, a concrete slab can be poured and cure in 72 hours.  If a project required four concrete slabs, then the math is four times 72 or 288 hours.  Thus, a project manager could estimate it would take twelve business days to get the concrete finished for the project.  

The approach does not work for creative activities like software development, marketing, or business processes.  All of these activities have too much ambiguity and lack easy answers.  Asking someone to guess how much it will take to do something they have never done before is insensitive. These managers desire to have control over a situation they have little understanding or influence over the outcome.  A manager is asking for believable fiction rather than the messy reality we exist.  

Let me repeat, do not estimate a spike.  It does not add value to the customer.  The development team does not know if they can solve the problem, and management will treat the estimate like a quotation instead of fiction.  

People wanting to find some predictability for the team can choose a different approach.  Instead of asking the team to estimate a spike, count the number of spikes in a sprint. For example, suppose a team completes forty story points in a sprint; when they spike the sprint, they only complete thirty points.  Thus, a manager can deduce the spike took up ten points of intellectual capacity from the team.  People who use a “no estimates” approach can subtract the number of spikes in a sprint from the number of stories attempted.  Both methods to spikes concentrate on problem-solving instead of providing estimates with dubious value.  

Leading a large project is challenging on the best days, so I understand why managers want to estimate spikes. Still, it is not going to provide value to the customer, and it is going to generated meaningless data, which is going to hurt decision making. Moreover, it is more painful than an infected paper cut. 

Until next time.