We all have most likely heard the term; Attention Deficit Disorder (or formally known as Attention Deficit / Hyperactivity Disorder). ADD or ADHD are the short phrases we use to identify those who lack the ability to pay attention for any length of time and are very active / motor driven.
Living with a person that has this condition; I have drawn parallels to the disorder as I work with Scrum Teams across the world. First, I would like to define ADD/ADHD for those who aren't too familiar with the terms. ADD/ADHD simply means that a person struggles in the following categories:
Inattention: described as having a short attention span and being easily distracted.
Hyperactivity: Excessive activity; uncontrollable urges to move around (motor driven)
Impulsivity: Acting before thinking; having difficulty waiting or delaying gratification (translated as impatient).
What I notice in organizations is that we often see the same type of behavior. I like to call it "Organizational ADD". Often I am asked to coach / assess / observe organizational behaviors as it relates to Scrum / Agile Software Development adoption. The agile side of the equation typically revolves around the fact that the organization is / is not embracing the agile values and principles. Scrum is a bit easier to observe as we look for the process framework in action.
My point to the title of this blog is that many organizations suffer from Organization ADD. Issues that I spot as areas of improvement for the Scrum Team or organization at large usually stem from the organizations lack of prioritization / planning at the product level. Teams are often pulled many directions as the organization lacks the patience of developing products. The teams usually have low visibility into the strategy and goals of what our product is suppose to accomplish; let alone the smaller pieces the team develops within their sprints.
If you see that your organization lacks attention / patience for good product development; they might have ADD. If your product / stakeholder team is constantly active on priority shifting and have uncontrollable urges to move to the next shiny object; they might have ADD. If your product / stakeholder teams act before thinking (impulsive); they might have ADD. Even worse, sometimes an organization hides behind the word "agile" to justify their condition. No doubt, agile is about being responsive and adaptive. Some markets have this as an inherent quality, but don't confuse being agile with "I have no idea what the best thing is for my team to build".
We want to put processes in place that help control the sudden urges that ADD represents. Prioritization is one of the medicinal qualities that help soothe organizational ADD.
Scrum doesn't prescribe these practices. This is a good thing and a bad thing. Bad in the sense that an organization really doesn't realize they need it (or know how to do it). Good in that we get to define what works best for the organization (and every organization is different).
Scrum says that a team starts with a "Product Backlog". It doesn't necessarily prescribe how to create one. The absent part of an ADD organization; in trying to prioritize the infinite list of things to do with the finite list of people to do them, is the lack of quantifiable business value.
Product Teams need to learn that they need to budget a team's capacity as well as the projects contending for that capacity. Think of it like a personal budget. Budgeting the backlog is part of the solution. The other part is prioritization exercises. Product Teams need to learn about techniques used to quantify value of one item over the other. One of my favorite techniques (learned from Mike Cohn) is called "Relative Weighting" and I like to have what I call monthly "Innovation Council" events that align the business on the goals for a quarter.
This is where the product team evaluates each backlog item against a set of themes / strategy for the organization. They subjectively determine the value of each item in those categories and come up with a value percentage for each item. They then consider the cost of each item (driven by estimates from the team), giving them a cost percentage. We can take the value percentage divided by the cost percentage to arrive at a quantifiable value relationship of the particular backlog item against the other ones.
It is so hard to say no to our customers or business stakholders. Let the data be the bad guy when trying to align all of the stakeholders and product teams to the priorities. It's a pretty simple technique and will improve the attention deficit, impulsivity, and hyperactivity of the business strategy.
