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. 

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.

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.  

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.  

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. 

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. 

SAFe is More Agile Than You Think

People who work in the agile world have two common characteristics.  The first is we are deeply committed to making work more sustainable, satisfying, and sane.  We also have strong opinions about how to make work better.  Like any other growing movement, you have a few splits between various camps about multiple practices.  I have spoken about the gulf between the no-estimates crowd and other agilists.  I also pointed out that the agile community often ignores the agile manifesto's admonition to put individuals and interactions over processes and tools.  Today, I will step into the debate between those who hate Scaled Agile Framework or SAFe and those who are more nuanced. 

Background –

I was exposed to SAFe when I attended training with Andrew Keener in 2017.  Agile worked on small to medium-sized projects, but a big challenge was getting it to work on a considerable scale.  Projects with thousands of developers and collaboration between numerous specialties, including hardware, mainframe, and legacy data systems, did not fit neatly into either scrum or kanban.  SAFe provided the answer with two key innovations.  

The first was the concept of a release train which made it possible to take numerous agile teams and coordinate them. Groups part of the same "train" would inspect and adapt merging code and sanding off the rough edges to create working solutions.  The other innovation was called product increment planning or P.I planning.  P.I planning is a series of meetings where the product owners and scrum masters would collaborate to eliminate dependencies and plan.  To coordinate these activities, SAFe created three new positions; a release train engineer, a program manager, and a software architect.  SAFe also provided a means for executives, and the rest of the organization to collaborate with release trains without interfering with the work.  

Backlash –

As SAFe grew in popularity, it spawned a backlash in the agile community.  Soon, SAFe had a reputation in agile circles similar to Nickelback in rock music circles.  The cool kids did not think it was good that this music and agile scaling technique became popular.  It spawned a backlash.  The web contains plenty of blogs and Twitter threads filled with earnest and lazy criticism of SAFe.

The best article about the criticism came from Gianpaolo Baglione, who pointed out that most of the criticism of SAFe fell into ten familiar categories.  I recommend you give it a read.  Many of the lazy arguments against SAFe are personal attacks on its authors or pointing out that it creates unnecessary layers of bureaucracy.  I have heard many of these arguments firsthand, and I want to acknowledge the more credible criticisms versus the lazy ones.  

Nuance –

I believe SAFe is an imperfect solution to the real problem of scaling software projects.  Being unable to deliver large software solutions hampered the Affordable Care Act's implementation and had deadly consequences for Boeing.  It provides a valuable starting point for managing massive projects.  I believe SAFe has three principal shortcomings; customer focus, poor leadership, and the P.I. sprint.

The agile manifesto says that customer collaboration is superior to contract negotiation.  If you look at the infographic on the SAFe website, it is tough to find the customer and relate them to the release trains.  I also notice that many conversations on agile teams are focused on meeting the goals of the release train rather than the customer.  I think more emphasis should be on the customer instead of less.  We should adopt the same attitude toward the customer which NASA did during the Apollo program.  Everyone, including the janitor who cleaned the bathrooms, said they were working on putting people on the moon.  When they crop up, conflicts should center around how the customer would be affected instead of personal agendas.  Once the focus is back on the customer, most agendas fall away.  

Next, we need to expose poor leaders within organizations and hold them accountable.  Instead of credible action, people who provide lip service are corrupt in many institutions, and SAFe is just as susceptible.  I remember being told by a Vice President that I could not discuss our challenges with DevOps with other departments because he did not want the "dirty laundry" of I.T. exposed to other groups.  I took a vow of silence instead of being transparent with others.  I left the company, but the V.P. still has his job, and the company filed for bankruptcy and laid off half of its people.  I consider this poor leadership and lack of transparency to be a factor in the companies failure.  Agile and SAFe have numerous feedback loops to fight poor leadership, but it requires people to set aside the status quo and commit themselves to something greater than themselves.  SAFe is nominally part of the Agile reformation, and so it is necessary to inspect and adapt everything in the organization to make things better, especially leadership.  

Finally, SAFe has what is called a P.I. iteration.  While leadership, scrum masters, and product owners prepare for the next increment during product increment planning, the development team coordinates to make sure code is ready for release.  It is supposed to be a training and development period.  In reality, the P.I. iteration is a frantic rush to release with plenty of "crunch time" and late nights making sure everything works.  SAFe must recognize that the development cohort must embrace software artisanship and DevOps if hundreds and thousands of people work on a project.  Otherwise, P.I. week is nothing more than a glorified hardening sprint, a severe anti-pattern in agile.

Conclusion –

The use of SAFe as a scaling method in business is imperfect.  It is up to people like me to help make SAFe behave more responsive and agile.  Let us start from the agile manifesto to make sure everyone is practicing the values and principles of agile.  SAFe needs more customer focus, and poor leadership needs exposure as part of the inspection and adaption process.  Finally, SAFe needs to do a better job embracing DevOps and software artisanship.  

Even though I'm not too fond of Nickleback, I am still open enough to listen to a song when the situation requires.  Scaled Agile Framework is not Nickleback, and with the work of skilled coaches, it can be a better tool if we are honest about the framework's shortcomings.  

Until next time.

  

The Business Analyst as Part of an Agile Team

It has to be said

From time to time, an agile coach needs to speak truth to power.  It often has career repercussions and creates more drama than an Anton Chekhov theater production.  A benefit is a truth-based approach to business, or anything else means you are confronting the reality of a situation rather than some other person's magical thinking.  I noticed something this week which bothered me, and I feel the need to call it out.  

Ananya Pani from the International Institute of Business Analysis posted a blog and info-graphic on LinkedIn, which explained that Business Analysts are a vital part of scrum and represent an active role in successful agile teams.  I am going to post the original blog here so you can read it yourself.  It is necessary to critique her arguments.  

If I were going to be prescriptive, I would point to the current scrum guide and highlight no mention of business analysts in it.  A scrum team is a Product Owner, a Scrum Master, and the development team – nothing more.  I realize for most agilists point to the scrum guide and saying that it is the only way to run an agile implementation is counter to the agile manifesto, which says, "Individuals and interactions over processes and tools." I need a better reason to object to Pani's role of business analysts in agile.  

The business analyst is a relic from many waterfall ways of managing projects.  A good business analyst knows about the needs of the business and can transform them into requirements.  It is the same skill set as a product owner, but it lacks the autonomy and authority of a product owner.  In my experience, I often see business analysts taking orders from project managers, and they generate documentation rather than working software.  The way most organizations use business analysts is degrading to the professional skill of the analysts and the power of the project to deliver value.  It is a position designed to create friction in an organization rather than help improve work.  

Additionally, Pani assigned the duties of a scrum master to the business analyst instead of the scrum master.  If I understand her correctly, a scrum master is not necessary on agile teams.  Observations like this point to her having excellent knowledge of Business Analysis but little understanding of agile and scrum; I look forward to her taking some PSM or CSM training and seeing if her perspective changes.  

I do not want to pick a fight, but I feel that the business analyst role is a square peg in the agile world, and we should not try to wedge it into the paradigm of a scrum team.  Instead, we should treat the business analyst as a member of the development team.  As part of the team, they can help with testing, documentation, technical writing, and pitching in with the developers.  Being a business analyst is an important skill and has value like testing, UX/UI, and coding.  We do not need to make a new role for it on the scrum team.  

The truth is the business analyst role is now just part of the development process and should not have any special privileges.  As coaches, we can fold business analysts into scrum teams and then prepare them to take on the role of scrum masters and product owners in the future because their skills translate into those roles.  We need to be honest with ourselves, business analysts are a legacy profession, and they have plenty of expertise to make agile teams successful.  We should take that expertise and fold it into our agile practices.  

Until next time. 

Call out Trolls Before They Destroy Your Business

Spot trolls before they hurt your business

The biggest challenge in Servant leadership is working with the disinterested, dishonest, and disrespectful.  Each organization harbors these individuals like weeds in a field of grass.  People like this seem to revel in their bad faith efforts to undermine others, avoid work, and act as parasites to everyone around them.  Throughout my career, I have confronted these individuals, and it never gets easier.  We should be brave enough to call out poor behavior.  

I spend plenty of time on LinkedIn. It is an excellent service because I can catch up on colleagues, get the latest news from the business community, and many of my fellow travelers share information about what is new. I was surfing along and read the following post from a coach and scrum trainer. The emphasis is mine.  

“I am a project manager having 15 years of experience and 5 years exclusively in project management. I do hold a PMP certificate too. My company is adopting Scrum-based delivery and it seems there is no role for the project managers. There are 3 roles in Scrum but none of them is for me. 

I can’t be a Product Owner because it will get filled from the business/customer side. I am not hands-on so I can’t be a part of the Development Team.

Scrum Master seems to be a very junior role for me. Many Scrum Masters are just a part-timer or working previously as Team Lead/ Tech Lead etc. There was a point when these people were reporting to me on my projects.

I also have an issue with the Servant Leadership style. It is not that I am a command & control person and you can ask my colleagues. Everyone will say how good I am with empathy, situation leadership, and self-reflection. But servant leadership sounds to me either head of the Servant or becoming Gandhi and Mandela. 

What will you suggest? Should I look at some different roles if yes then which one? I have also heard a lot about Agile Coach though I don’t know much how is this different than Scrum Master.”

I had a lot to unpack in this message.  It is an excellent example of how NOT to do Servant leadership.  I have said in the past, that ego is the enemy of good leadership.  Additionally, Servant leadership is more about leading by example than attempting to behave like a saint.  Scrum mastery requires kindness, and it often requires going beyond the call of duty. 

Being a scrum master is not a junior role.  It is a managerial role with tremendous responsibility and little authority. You are the person in the Taupe blazer who must inspire others to get work done.  At times you are a therapist, and at others, you are doing code reviews.  Often you are a square peg in a round hole.  Scrum masters are not junior; instead, they are essential to the success of your organization. 

The arrogance associated with the post was very telling.  What made it shocking was that it came from an instructor from Scrum.org.  I could expose this individual, but that would make me no better a coach or scrum master.  I am sensitive to harassment and doxing concerns on the internet.  I want the satisfaction of calling out a troll and exposing them to shame and ridicule.  The reality is they do not care.  A troll does what they do for the attention and outrage.  Instead, I would rather point out the attitude of these people so that we can be on the lookout for this behavior.  People like this are going to hurt your organization, so it is best to make you aware of them and not give them a chance.  

I take a great deal of pride in what I do.  As I continue to advance my career, I do not want to forget where I came from and the lessons I gained along the way.  Being a scrum master and product owner is hard work.  Developers and people in the organization are under tremendous pressure to deliver value to their customers and organization.  In the global economy, we are all servants, whether we like it or not.  Insulting other professionals as junior or beneath you is not how you participate in the agile reformation.  It is a form of elitism that has sparked backlash around the developed world.  

Today, I wanted to call attention to an attitude that will hurt your organization.  It is elitist, and it comes from a position of arrogance.  Do yourself a favor, find these people, and make sure you never hire them.  

Until next time. 

Helpful Tips Setting Priorities

Being a white-collar professional is a mixed bag.  With a few clicks of a mouse or the stroke of a pen, construction projects begin, or new markets born.  It is also suffering through bad coffee, office politics, and people who enjoy humiliating others.  It is a load of responsibility without much authority and being separated from your family to provide them with opportunities you never had.  As a professional, it amazes me to see who rises through the corporate food chain and who flounders.  It feels like the worst moments of high school when you thought you were not smart enough, cool enough, or pretty enough to matter to anyone else.  Those who do rise to the top often depend on the invisible people to manage the business and keep the global economy spinning.  One of the most critical skills of keeping the company moving forward is prioritization, and I would like to discuss it.

Roland Pilcher, in his excellent book about product ownership, talks about how every backlog needs prioritization.  Over my career, I am amazed by how many people in positions of leadership have never been forced to set priorities.  I blame this state of affairs on business cultures who are afraid to say “no” to executives.  It is the creation of a fantasy world where anything is possible, and the only limits are money and ego.

People who do not hear “no” often enough cannot set priorities, so it is up to others to teach them how. I have created a grid to help evaluate how to address priorities.  The Y-axis is importance with the high being very important and the low being trivial.  The X-axis is the urgency of a task from mission-critical to inconsequential.  Any work can fall onto the plane and based on where it lands determines how you are going to take action.

Mission Critical and Important - 

Anything which threatens the survival of the business or costs money falls in this category.  Consider it like the e-commerce site is down or your boat in the middle of the ocean is sinking.  You need to stop what you are doing and address it now.

Less Critical but Important - 

These are things which will improve the business and increase profits.  It could be an update to the company website which has full social media integration.  It might be the addition of a more powerful engine on your fishing boat.  Whatever the issue, speed to market means you should do it before your competitors do.

Need to have Items - 

Items which are less critical than the things above which are not time-sensitive are called need to have issues.  These items will generate profit, but they can be scheduled based on budget or staffing priorities.

Nice to have Items - 

When something is neither trivial or essential and it is neither mission-critical or inconsequential, it is known as a nice to have priority.  Things like changing the color scheme of a website or streamlining an ordering process fall into this category.  Fit these tasks in when time allows.

Egoware - 

In large organizations, some people have a tremendous amount of authority and the self-esteem to match.  These individuals look at priorities which may not be essential and give them urgency.  Often it is to satisfy personal preferences rather than business needs.  In the software business we call this kind of development Egoware.  Any organization which fulfills the construction of egoware is toxic, and executives, scrum masters, and coaches should work to eliminate it from the organization; otherwise egoware will choke out the more important work at the firm.

Willful Ignorance - 

The organization is often blind to these issues, which are essential but treated as inconsequential.  For example, a top salesperson is using his expense account to cover gambling losses.  Another example is a toxic person with a history of sexual harassment stalking the office.  In both cases, the organization is looking the other way and treating these risks as inconsequential.  Eventually, they will pay for this inattention, and the problems become more prominent and the financial dangers more considerable.

Things which can wait - 

If something is trivial and inconsequential; it can wait.  Often, we get ideas, or the business comes up with suggestions.  If they are not urgent or essential, they can linger for another day.  These items sit at the bottom of the backlog or project plan. If something can wait it should have “shelf life.”  After sitting in the “to do,” pile for a certain amount of time, it should be reviewed.  If the idea can deliver value it should be moved to the nice to have priority.  If it does not, then it should be scrapped to make room for other ideas.

Peter Drucker, the famous business consultant, said, “First things first, last things never.”  If you take a look at this chart it should be easy to determine what matters what can wait.  You can spot things which are dangerous or dysfunctional to the firm.  Following this approach will make you more competent than many executives at big companies.

Until next time.

Helpful Tips for Splitting User Stories

Splitting user stories require creativity and the right tools.

Being a product owner is hard work.  It is days filled with meetings and writing user stories.  You are under pressure to deliver working software, and if it all goes wrong, your career is often at risk.  One of the hardest parts about product ownership is a collaboration with the development team and estimation.  Software developers are notoriously hard to work with, and estimating software development is exponentially more difficult.   The estimation process is fraught with conflict and compromise.  Often, work is too large to be completed in the time box of a sprint.  The product owner in this situation should split user stories.  Today, I want to share a common technique to divide user stories.

I have a relatively straight forward process for writing user stories.  Once you write a story, the development team should try to estimate the story.  A story point estimate is a function of complexity, risk, uncertainty, and effort.  According to Kedar’s constant, the larger a story is in points, the riskier it is to complete in a sprint.  It means a set of four three-point stories are less risky to complete than a single 13-point story.  When you have essential stories with high point values, it is up to the development team and scrum master to request the story get split before sprint planning.   The product owner is often frustrated by this request. Breaking stories is additional work, and it implies the original story was too big.  I empathize with this kind of frustration.  Being asked to split a story is the team being conscientious.  It is also an opportunity to make the sprint more successful.

Richard Lawerence has written a fantastic post on how to split user stories.  I recommend you read it here.  For me, the most critical pattern is to break down work based on complexity.  Something complex is often the assemblage of smaller, more straightforward elements.  Suppose you are a sales manager for a cable T.V. station, the base rate for a 30-second commercial is $150 per broadcast so when a client purchases ten impressions they are invoiced $1,500 when the last commercial airs.  If you are going to write a user story with acceptance criteria, it will look something like this:

As a sales manager, I want to charge $150 per impression for a 30-second commercial because I want to generate revenue.

GIVEN I am a customer.

WHEN I purchase a 30-second commercial.

THEN I invoice $150 times the number of commercials purchased.

The rule is simple, and the team says following SOLID principles and authoring unit tests it would be two points worth of work.

The world of broadcast is time-sensitive, so commercials air during prime time between 6:30 PM and 10:00 PM are more valuable while ads aired after midnight are less costly.  The product owner realized this and added two more acceptance criteria to the story.

GIVEN I am a customer.

WHEN I purchase a 30-second commercial.

AND the commercial airs during prime time between 6:30 PM and 10:00 PM

THEN I invoice the customer $150 times the number of commercials
purchased plus a 40% premium fee



GIVEN I am a customer

WHEN I buy a 30 second commercial

AND the commercial airs during late night (between midnight and 5:30 AM)

THEN I invoice the customer $150 times the number of commercials 
purchased with a discount of 20%

During sprint planning, the team looks at the revised user story with the additional acceptance criteria, and they adjust the story points to eight because the story has become more complex.  A good rule of thumb I like to use for splitting user stores is anytime you see the contractions “and” or “or” it is an excellent place to divide a user story into smaller stories.  In the above example, one eight-point story, when divided into three stores with an estimate of two, each generates less risk for the sprint.  The story split also makes budgeting work easier.

Splitting user stories is a useful skill, and it helps make the development team more successful.  Start breaking user stories today.

Until next time.

More difficult than crayons

Crayons are easier to create than software.

When you spend your career helping people deliver software, it quickly becomes apparent that the biggest challenges you face are not technology problems.  The biggest challenge is working with messy people.  Machines can make pencils and crayons by the thousands each hour, but before that happens, someone has to design the product for manufacturing.  The people who do this are engineers and product designers.  Software relies on Scrum Masters, Product Owners, and software developers.  The creative process is the same, but it is much easier to manufacture crayons than software.  Today, I will try to answer why it is so hard to write software.

Software has only existed since the aftermath of World War Two.  The first documented “bug” was a moth which died among the vacuum tubes of the first computer.  In spite of technological advances, the way we write software is still primitive.  Developers continue test code on local machines and then push that code to remote servers to see if they work.  Testing is manual, and the ability to automatically push code through the web or large enterprises is limited.  The software craft movement is making progress in this area along with the DevOps movement are helping with this antiquated process, but it is still a long, tedious trudge to get software written.

The key adverb here is “written.” The writing of software is a creative process.  People take the vague directions of others and translate it into web pages or client-server applications.  Unlike traditional prose, software contains code, markup, and data.  The disciplines working with each is different and filled with plenty of nuances.  Business people compensate software professionals generously because it is such a rare skill to cultivate.  Developers are also under tremendous pressure to ship code and work long hours to do it.  Imagine, Earnest Hemingway, attempting to write “A Farewell to Arms,” with management standing over him demanding updates each day. Furthermore, imagine the Nobel laureate is required to write one character’s dialog in English, another in Spanish and finally hexadecimal code for each letter on the page for a different character.

If the above was not challenging enough, the people paying for the creation of software are not actively involved in its production.  Software projects often begin with a problem which does not have an answer.  A marketing executive blurts out, “I need a client website!” or a Human Resources professional asks if it is possible to manage timecards online.  The business set aside money hired consultants to do the work, and begin writing software with no idea how it should work.  Agile fixes this problem by requiring rapid time boxes.  Often, lack of participation and vision from business partners thwarts the benefits of agile.

Combined with the difficulty of writing software and the apathy of the people how to pay for the software, the final challenge is the hypercritical nature of everyone who cannot write software have for the people who can write software.  It is similar to the Austrian Emperor mocked in the movie Amadeus whose only criticism of Mozart’s opera is, “There are too many notes in it.”  Many people have opinions about software and provide critiques, which is either nitpicking or unhelpful.  As a developer, a color pallet I used for an application caused controversy, and we spent countless meetings reviewing color chips.  It extended the life of the project by three months and made it over budget.  In a different episode, punctuation on a page sparked hundreds of revisions and emails.

The reality is like a committee of proofreaders, executives, and people not involved in the creative process demanding edits to Hemingway’s work.  The final straw might be the demand that “A Farewell to Arms,” not have one of the main characters die at the end of the book.  The entire narrative arc of the book changes because of the “suggestion,” but if Hemingway does not make the changes, he does not get paid or published.  Considering this type of feedback, Hemingway would have consumed more alcohol than he did.

So this is why writing software is so complicated.  It is a creative process.  Next, the people who want and pay for the software are not actively involved.  Finally, if customer partners are in the project, they provide feedback and guidance, which is often removing value from the software rather than adding it.  I have been in this career for a long time, and I know how to write and deliver software.  It is much more complicated than creating crayons.

Until next time.