Moving Past “I Don’t Know”

Recently I had the opportunity to attend the Mile High Agile 2015 conference in Denver where Mike Cohn delivered the morning keynote address: “Let Go of Knowing: How Holding onto Views May Be Holding You Back.” As you might expect from a seasoned professional, it was an excellent presentation and very well received. A collection of 250+ scrum masters, product owners, and agile coaches is no stranger to mistakes, failures, and terrifying moments of doubt.

As valuable as the ideas in Cohn’s presentation are, I want to take them further. Not further into the value of keeping our sense of sureness somewhat relaxed, rather onto some thoughts about what’s next. After we’ve reached a place of acknowledging we don’t know something and are less sure then we were just a moment before, where do we go from there? It’s an important question, because if you don’t have an answer, you’re open to trouble.

The “I Don’t Know” Vacuum

Humans are wired to find meaning in almost every pattern they experience. The cognitive vacuum created by doubt and uncertainty is so strong it will cause seemingly rational people to grasp at the most untenable of straws. It’s a difficult path, but developing the skill for being comfortable with moments of doubt and uncertainty can lead to new insights and deeper understanding if we give our brains a little time to search and explore. Hanging out in a space of doubt and uncertainty may be fine for a little while, but it isn’t a wise place to build a home.

After acknowledging we don’t know something or that we’ve  been wrong in our thinking, it’s important to make sure the question “What’s next?” doesn’t go begging. I’d wager we’ve all had the dubious pleasure of discovering what we don’t know in full view of others and in those situations the answer to this question becomes critical. It may not need an immediate answer, but it does need an answer. If you don’t work to fill the vacuum left by “I don’t know” or “I was wrong,” someone else surely will and it may not move the conversation in the direction you intended.

The phenomenon works like this. Bob, a capable scrum master, ends up in a situation that reveals a lack of experience or understanding with the scrum framework and doesn’t know what to do. Alice, maybe immediately or maybe later, moves into the ambiguity, assumes control, and tells the team what should be done. If Alice is wise in the ways of agile, this could end well. If command-and-control is her modus operandi in the defence of silos and waterfall, it probably won’t.

So how can an agile practitioner prepare themselves to respond effectively in situations of doubt and uncertainty? Here are a few things that have worked for me.

Feynman-ize the Conversation

In his book “Surely You’re Joking , Mr. Feynman!,” Nobel physicist Richard Feynman tells a story from his early career where several building engineers started reviewing blueprints with him, thinking he knew how to read them. He didn’t. Having been surprised by being placed in a position of assumed expertise, Feynman improvised by pointing at a mysterious but ubiquitous symbol on the blueprint and asking, “What if that sticks?” The engineers studied the blueprint in light of Feynman’s question and realized the plans had a critical flaw in a system of safety valves.

That’s how to Feynman-ize a conversation. Start asking questions about things you don’t understand in a manner that challenges those around you to seek the answer you need. In essence, it expands the sphere of doubt and uncertainty to include others in the situation. This tactic is particularly effective in situations where corporate politics are strong. Bringing the whole team into the uncertainty space helps neutralize unhelpful behaviors and increase the probability the best answer for the moment will be found. It is no longer just you who doesn’t know. It’s us that that don’t know. That’s a bigger vacuum in search of an answer. In short order, it’s likely one will be pulled in.

The Solution Menu

Thinking of the agile practitioners in my professional circle, they are all adept at generating possibilities and searching their experience reservoir for answers based on similar circumstances. When the creative juices or flow of answers from the past are somewhat parched by the current challenge, it is natural to project the appearance of not knowing. Unless you’ve drawn a complete blank, you can still use the less-than-ideal options that came to mind.

“I can think of several possible solutions,” you might say. “But I’m not yet sure how they can be adapted to this challenge.” Then offer your short list of items for consideration. One of those menu choices might be the spark that inspires a team members to think of a better idea. Someone else may find an innovative combination of menu choices that gets to the heart of the issue. I’ve even had someone mishear one of my menu choices such that what they thought they heard turned out to be the more viable solution. This is just another way to leverage the power of everyone’s innate drive for finding meaning.

Design an Experiment

If there is a glove that fits the “I don’t know” hand, it’s experimentation. I suppose you could work to stretch the guessing glove over “I don’t know.” But if your team is aware that you don’t know something, it’s worse if they know you’re pretending that you do. Challenges and problems are the situation’s way of asking you questions. If the answers aren’t apparent, form a solution hypothesis, set up a simple test, and evaluate the results. And as the shampoo bottle says: lather, rinse, repeat until the problem is washed away. It’s another way to expand the sphere of uncertainty to include the whole team and increase the creative power brought to bear on the problem. If your shampoo bottle is this agile, I’ve every confidence you can be, too.

Now I’m curious. What has helped you move past “I don’t know?”

This article was originally published by the Scrum Aliance under Member Articles.

Agile Haiku #2

The rules are in place.
We’ve always done it this way.
Sound of waterfall.

Agile Haiku #1

The plan crashed and burned.
We seek and find root causes.
A lesson is learned.

That Isn’t What I Expected

Adverse surprises during a team driven project are about as welcome as whooping cough at a glassblowers convention. Minimizing the opportunity for surprises comes down to how well expectations are defined at the very beginning and how well they are managed during the course of the project. Unidentified expectations are like landmines in the project path. When they explode, it’s bad and the course of the project WILL change. Product owners can’t elucidate all the expectations a stakeholder may have, but with experience they can define the major ones. With practice and attention, experienced product owners can tease out all but the minor expectations that are often dependant on discovery within the project’s sprints.

Key to this skill is knowing the questions to ask at the beginning. In my experience, stakeholders rarely deliberately hold back their expectations. They just don’t know what they don’t know and it is the product owner’s responsibility to establish clarity around expectations. Intuitively obvious expectations rarely play out as such.

A few questions for stakeholders that I’ve found helpful:

  • What business problems do you intend to solve with this project?
  • What do you need to see to know the project is progressing?
  • What will you see when the project is done?
  • What is your availability commitment for the duration of the project?
  • How often to you expect to meet to review progress?
  • How long do YOU think it will take to complete the project?
  • To what extent are your functional groups integrated?
  • Describe your process from design to development to implementation?
  • Are there other stakeholders we need to know about and include?
  • What factors have helped and hurt success with past projects?

This is by no means an exhaustive list of questions. And they may even seem obvious. The answers, however, are almost never obvious.

I also find it effective to challenge stakeholders with scenarios.

  • What happens if we discover this project will take two months longer than expected?
  • What happens if we discover a desired solution is technically unfeasible?
  • How will you support us if we encounter significant delays from client deliverables?

Product owners need to keep pursuing clarity around expectations until they are satisfied they have a good understanding of how the people side of the project will unfold. This will go a long way to helping the development team handle the technical side of the project.

While stakeholders answer these questions, product owners need to pay attention not just the words stakeholders use to answer, but how they answer as well. They need to be scanning for underlying assumptions that drive the answers. These often reflect relevant cultural drivers which can signal significant expectations seemingly unrelated to the project at hand. For example, perhaps the product owner has established the expectation of a three business day turnaround for feedback from the stakeholder when asked to review periodic project deliverables. “We can complete our reviews within three business days and work to get them to you as fast as possible,” says the stakeholder somewhat hesitantly as he looks off into the distance. Where the pain begins is when the inattentive product owner discovers that, while the feedback may be ready, the client organization has a thick layer of compliance and the feedback is hung up in legal for an additional one to two weeks…every time. If the stakeholder’s responses reflect something less than 100% commitment, keep asking questions designed to surface underlying assumptions.

As each sprint concludes, and eventually the project as well, the savvy product owner knows their work with expectations isn’t complete. Retrospectives for each sprint, each release, and the project conclusion should make note of the expectations that were missed and consider questions that could have been asked that would have helped surface the surprise expectations sooner.

This is also an excellent time to consider if any of the existing expectations have changed or if it appears there may be new expectations emerging. Internal forces, such as changes in team composition, and external forces, such as shifting market demands, can significantly impact the set of expectations a product owner is tasked with managing.

If  you expected to read these kinds of things about surfacing stakeholder expectations, then you’re probably an experienced product owner.

GnuCash Reports

More than 10 years ago I switched from using Quicken for managing personal finances to using an accounting application I developed for the task. I posted my rationale for doing so at the time and see not much has changed in the commercial landscape since then to change my thinking. Intuit is still diligently upsetting customers. Although my needs, demands, and interests have changed. I no longer have time to maintain the code I wrote and a year or two back my accounting needs changed. So I switched from the custom coded solution to GnuCash.

For the most part, I’m quite pleased with the capabilities of GnuCash. Best of all, it’s open source. So I have full access to the code and, more importantly, the data. Where it is weak is in reporting capabilities. I find it rather frustrating to get to the view I want. True to the spirit of open source, users can create their own custom reports. Accomplishing this requires the user to be familiar with the Scheme programming language. When I was younger, this would have been a minor inconvenience. However, graybeard that I am amongst software developers, I’ve learned and forgotten more programming languages than I care to recall. Adding another bone to that yard is less than attractive.

So I turned to my go-to language since version 1.5.2: Python. Even after crafting all manner of solutions in Python over the past 15+ years, it still amazes me what I can do with it. My problems with GnuCash were no exception. Since my data isn’t locked up in some proprietary format, it was a simple enough task to craft a couple of SQL commands that would extract the data I need and wrap them inside an efficient Python script. Simply by setting a date range in a configuration file, I get the (so far) three reports I need in 2-3 seconds.

For those interested, I’m including the current incarnation of the code below. The data captured in the three csv files are:

  • A raw dump of the data, suitable for working within a spreadsheet
  • A subtotal report that includes line item details
  • A subtotal report without line item details

Configuration File

Python Script

Improvements and enhancements are left as an exercise for the reader.

The Value of “Good Enough”

Any company interested in being successful, whether offering a product or service, promises quality to its customers. Those that don’t deliver, die away. Those that do, survive. Those that deliver quality consistently, thrive. Seems like easy math. But then, 1 + 1 = 2 seems like easy math until you struggle through the 350+ pages Whitehead and Russell1 spent on setting up the proof for this very equation. Add the subjective filters for evaluating “quality” and one is left with a measure that is essentially indefinable in any practical way.

Math aside, when it comes to quality, everyone “knows it when they see it,” usually in counterpoint to a decidedly non-quality experience with a product or service.The nature of quality is indeed chameleonic – durability, materials, style, engineering, timeliness, customer service, utility, aesthetics – the list of measures is nearly endless. Reading customer reviews can reveal a surprising array of criteria used to evaluate the quality for a single product.

The view from within the company, however, isn’t so clear. Businesses often believe they know quality when they see it. Yet that belief is often predicate on how the organization defines quality, not how their customers define quality. It is a definition that is frequently biased in ways that accentuate what the organization values, not necessarily what the customer values.

Figure 1. Quality Mismatch I
Figure 2. Quality Mismatch II

Organization leaders may define quality too high, such that their product or service can’t be priced competitively. If the high quality niche is there, the business might succeed. If not, the business loses out to lower priced competitors with products that satisfy the customer’s criteria for quality at a price they can better afford (see Figure 1). On the other end of the spectrum, businesses that fall short of customer expectations for quality suffer incremental, or in some cases catastrophic, reputation erosion. Repairing or rebuilding a reputation for quality in a competitive market is difficult, maybe even impossible (see Figure 2).

The process for defining quality on the company side of the equation while difficult is more or less deliberate. Not so on the customer side. Customers often don’t know what they mean by “quality” until they have an experience that fails to meet their unstated, or even unknown, expectations. Quality savvy companies, therefore, invest in understanding what their customers mean by “quality” and plan accordingly. Less guess work, more effort toward actual understanding. Furthermore, looking to what the competition is doing may not be the best strategy. They may be guessing as well. It may very well be that the successful quality strategy isn’t down the path of adding more bells and whistles that market research and focus groups suggest customers want. Rather, it may be that improvements in existing features and services are more desirable.

Focus on being clear about whether or not potential customers value the offered solution and how they define value. With that benchmark in hand, companies are better served by then working to define quality in terms of “good enough” in the eyes of their customers and then setting the internal goal just a little higher so as to maximize internal resources (usually time and money) and deliver a product or service that satisfies the customer’s idea of “quality.” By understanding where the “good enough and valuable” line is, organization leaders are in a better position to evaluate the benefits of incremental improvements to core products and services that don’t break the bank or burn out the people tasked with delivering the goods.

Case in point: Several months back, I needed a set of cutting tools used to put the thread on the end of a metal pipe – a somewhat exotic tool for a woodworker’s shop. Shopping around, I could easily drop $300 for a five star “professional” set or $35 for a set that was rated to be somewhat mediocre. I’ve gone high end on many of the tools in my shop, but in this case the $35 set was the best solution for my needs. Most of the negative reviews revolved around issues with durability after repeated use. My need was extremely limited and the “valuable and good enough” threshold was crossed at $35. The tool set performed perfectly and more than paid for itself when compared with the alternatives, whether that be a more expensive tool or my time to find a local shop to thread the pipes for me.

Determining what is “good enough” depends on what the goal is. Sending a rover to Mars, “good enough” had better be as near to perfection as possible. Threading a dozen pipes for bar clamps can probably be completed quite successful with a low quality tool that’s “good enough” to get the job done.

References

1Volume 1 of Principia Mathematica by Alfred North Whitehead and Bertrand Russell (Cambridge University Press, page 379). The proof was actually not completed until Volume 2.

Agile Team Composition: Generalists versus Specialists

In a previous post, I described several of the shortcomings with planning poker, particularly when the tool is used in a context that includes more than just the developer’s shop. Estimating levels of effort for a set of tasks by a close knit group of individuals well qualified to complete those tasks can efficiently and reliable be cast with a tool like planning poker. Once the set of tasks starts to include items that fall outside the expertise of the group, or the group begins to include cross functional team mates, or both, the method becomes increasingly less reliable.

The issue is a mismatch between relative scales when the team includes an increasingly diverse set of project specialties. A content editor is likely to have very little insight into the effort required to modify a production database schema and therefore offer an effort estimation that is little more than a guess based on what they think it “should” be. Similarly for a coder faced with estimating the effort needed to translate 5,000 words of text from English to Latvian. The answer is to add a second dimension to the estimation: a weight factor to the estimator’s level of expertise relative to the nature of the card being considered.

A similar effect is in play when organizing teams according to Agile principles. When implementing Agile methodologies at the organizational level it is important to consider the impact of forming teams of generalists versus specialists. According to Scrum, for example, it is preferable to have a good measure of skill overlap – that is, generalized skills that allow for any one team mate to work on a variety of tasks during a sprint. This is very efficient for highly technical and coherent domains. Differences in preferred coding language among team mates is less an issue when all team mates understand advanced coding practices and the underlying architecture for the solution. In this case, it is easier to measure sprint velocity when a set of complimentary technical skills allow for cross functional participation and re-balancing when needed (vacations, illness, uncommon feature requests, etc.) As with planning poker,however, efficiency degrades as domain expertise on the team becomes more incoherent.

In cases where the knowledge and solution domains have a great deal of overlap, generalization allows for a lot of high quality collaboration. However, when an Agile team is formed to address larger organizational problems, specialization rather than generalization has a greater influence on team velocity. The risk is that with very little overlap specialized team expertise can result in either shallow solutions or wasteful speculation – waste that isn’t discovered until much later. Moreover, re-balancing the team becomes problematic and most often results in delays and missed commitments due to the limited ability for cross functional participation among team mates.

The challenge, then, for cases where knowledge and solution domains have minimal overlap is to find a way to manage the specialized expertise domains in a way that is useful (reliable, predictable, actionable). Success becomes increasingly dependent on how good an organization is at estimating levels of effort when the team is composed of specialists. The answer is to add a second dimension to the estimation: a weight factor to the estimator’s level of expertise relative to the nature of the card being considered.

With a weighted expertise factor calibrated to the problem and solution contexts a more reliable velocity emerges over time. With this enhanced velocity reliability comes an increased reliability in level of effort estimates, greater accuracy in resource planning, and less waste.

 

Creativity Under Pressure

[In the fall of 2013, I completed a course on Coursera titled “Creativity, Innovation, and Change” presented by Drs. Jack V. Matson, Kathryn W. Jablokow, and Darrell Velegol at Pennsylvania State University. It was an excellent class. At the end, they invited the class (How many tens of thousands of us?) to submit short essays about our experence. The plan was to select the best of these essays and roll them into a free Kindle book. Today, they sent out this update:

We are sorry to inform you that we have decided not to proceed with the publication of a CIC eBook. The submissions were read and commented on by four reviewers.  The consensus was that the manuscripts for the most part would take efforts far beyond our capabilities and means to edit and upgrade to meet the standards for publishing.  We are very sorry that the plan did not work out.

What follows is slightly edited version of the essay I submitted for consideration.]

Creativity Under Pressure – When necessity drives innovation.

Background

When you hear someone speak of an individual they know as being creative, what images come to mind? Often, they spring from stereotypes and assumptions about such an individual being an artist of some sort. Someone unconstrained by time or attachment to career, family, or a mortgage. My personal favorite is the image of a haggard individual wearing a beret, a thin cigarette balanced on their lower lip, and busy being inspired by things us mortals cannot see. A foreign accent adds the final touch to firmly set the speaker’s creative individual in the “That’s not me.” category. Our preconceived notions and assumptions assure us we are not creative.

The truth is all of us are creative. The artist’s Muses are not the only source of inspiration. Chance can inspire creative ideas by the convergence of seemingly unrelated circumstances and events. An activity as passive as sleep can lead to creative ideas. Moving away from beauty toward the other end of the inspiration spectrum, the source may not necessarily be pleasant. Frustration and irritation may inspire us to find a creative solution as we spend an inordinate amount of time searching for a way to scratch a just-out-of-reach itch. Crisis, too, can be a source of inspiration, often of the very intense variety. Chance surrounds all of us. We all sleep. And alas, we are all subject to frustrating or crisis situations from time to time in our lives. We are immersed in opportunities for creative inspiration.

Perhaps the least obvious or explored opportunities for applying creativity and experimenting with innovative ideas happen when we are under pressure to perform. At first glance, the tendency is to think that such situations require extensive knowledge, abundant prior practice, and scenario rehearsals in order to navigate them successfully. It’s fair to say that the chances for successfully responding to a crisis situation are greatly enhanced by deep knowledge and experience related to the situation.

The Apollo 13 mission to the Moon is a familiar example of crisis driven creativity by a team of experts. Survival of the astronauts following the explosion of an oxygen canister depended on NASA engineers finding a way to literally fit a square object into a round hole. The toxic build-up of CO2 could only be prevented by finding a way to fit a cube shaped CO2 filter into a cylinder shaped socket using nothing but the materials the astronauts had with them. Of course we know from history the team of engineers succeeded in this exercise of creative improvisation.

Individual experts have also succeeded in devising creative solutions in crisis situations, and in doing so introduced critical changes in protocols and procedures that have saved lives. For example, smokejumber Wagner Dodge’s actions in the Mann Gulch forest fire on August 5, 1949, introduced the practice of setting escape fires as a way to protect firefighters caught in “blow-ups.”

What I’ve always found interesting about these and similar examples is that, although the creative and innovative solutions were found while “on the job” and using established expertise, the solutions were counter to what the individuals and teams were expected to do. The NASA engineers were paid to design and build an extremely high tech solution for sending three men to the moon and bringing them safely back to Earth. Their job descriptions likely didn’t call for the ability to “build a fully functional CO2 scrubber from a pile of junk.” Wagner Dodge was expected put out fires, not start them.

The Course

What else is important in preparing us to respond creatively in high pressure situations? It’s a question that’s dogged me for years. The “Creativity, Innovation, and Change” (CIC) course offered by Pennsylvania State University and taught by Professors Jack Matson, Kathryn Jablokow, and Darrell Velegol offered an opportunity to explore this question.

The first insight from the course was the importance of the “adjacent possible” to creative and innovative problem solving, even in crisis situations. The phrase was originally suggested by the theoretical biologist Stuart Kauffman to describe evolutionary complexity. The idea is that innovative or creative ideas occur incrementally. While they may appear as substantial leaps forward, they are in fact derived from a collection of adjacent ideas that coalesced to make a single idea possible. As an individual explores deeper and farther into an idea space, they extend the boundaries around which adjacent ideas collect, increasing the potential for new idea combinations. In other words, increasing the likelihood of creative or innovative ideas.

In the case of Apollo 13, the deep experience and knowledge of the engineers allowed them to consider a wide spectrum of possibilities for combining an extremely limited number of objects in a way that could remove CO2 from a spacecraft. In the case of Wagner Dodge, his extensive experience with fighting forest fires allowed him to spontaneously combine a variety of “adjacent possibilities” in a way that lead to the idea of lighting an escape fire.

That’s the theory, anyway. There’s a difference, though, between theory and practice. Albert Einstein explains, “In theory they are the same. In practice, they are not.” The CIC course offered an abundance of techniques and methods that facilitated the transfer of learning and strengthened the connection between theory and practice. In particular, there were two important reframes that opened the door to deliberately improving how I approach creativity and innovation in stressful situations:
“Successful” failures are those that are strategic. That is, not random guesses about what will work, but deliberate experiments designed to succeed. Yet if they fail, the design of the experiments also reveal weaknesses that are preventing the eventual success. Unconsciously, I had already become reasonably good a doing this. But there was significant room for improvement. Using many of the methods and techniques offered during the CIC course, I deliberately unpacked my unconscious competence in this area, consciously explored how I could practice becoming even more competent with this skill, and am now exploring ways to integrate the new capabilities back into unconscious competence.

“Failure” is a necessary, even desired process for finding success. This ran counter to my get-it-right perfectionist approach to success. Likely the result of having to work in too many crisis situations where failure was not an option, it was nonetheless a poor strategy for finding success in day-to-day business. In concert with point number one, these failures should be strategic.
Each of these insights are encapsulated in the “Intelligent Fast Failure” (IFF) principle presented in the CIC course and further described in Prof. Matson’s book, “Innovate or Die!”:

The “Intelligent” part refers to gaining as much knowledge as possible from each failure. The “Fast” part means speeding up the trials to quickly map the unknown thereby minimizing frustration and resources spent.

The “fast” part also increases the pool of “adjacent possibilities” and raises the potential for successful innovations to emerge from the process.

The Test

Has all this experimentation and thought practice made a difference in my ability to respond more creatively in stressful situations? A full-on test in crisis mode hasn’t happened as yet. And frankly, I’d count my self fortunate if I never had to face such a test again. But there are indications the changes are having a positive effect.

These days, work typically offers the most abundant opportunities for stressful situations. Most recently, I was tasked with coordinating a significant change in how an organization went about the process of completing projects. The prevailing process had deep roots in the company’s culture and was incapable of scaling to meet growth goals for the organization. With so much personal investment into the old way of doing things, implementing a more agile and scalable process was going to require as much mediation and negotiation as it was process definition and skill development.
Using the techniques and methods that support the IFF principle, I have been successfully implementing a wide range of new ideas and process improvements into the organization in a way that makes them appear less as a threat and more as a value to each of the stakeholders.

Most Workers Come to Work When Feeling Sick

The staffing firm OfficeTeam has an interesting infographic showing how often people go into work when they’re ill. It’s not stated, but implied that “go into work” means “go into the office to work.” My subjective experience matches what the small OfficeTeam study revealed. Far too many people come into the office to work when, in the interests of the health of their co-workers, it would be better they stayed home.

I’ve heard many excuses for why people do this. “It’s just a head cold.”, “I’m past the contagious phase.”, “There’s too much important work to get done this week.”, “I don’t want to get behind any further than I already am.” The list is endless. When my career advanced to the point I needed to manage people, I learned more of what was motivating some of these excuses. They included things like home life was so miserable that the employee would rather come into the office sick than stay at home. There was also a perverse incentive in play at work environments that allotted employees a bulk quantity of paid time off for use as vacation and sick time. Want a longer vacation? Work sick rather than take a “vacation” day to recoup and prevent the spread illnesses to co-workers. As a manager, I frequently used my authority to send people home when they came in sick.

Viewed from another perspective, the OfficeTeam study reveals an often unstated value to telecommuting. When one at least has the option to work remotely and their productivity is not compromised by that option, they can organize their work around such things as seasonal illness much more effectively and prevent the spread of illness to co-workers. Personally, I took paid time off for sick days. I found it much easier to “catch up” when I felt better than try to remain productive when sick. In fact, the work that was done while ill was usually of poor quality and needed to be reworked later. However, when feeling ill while working remote, I would put in a day or two of light work and make up the slack later when I felt better, even if that make-up time was on the weekend.

In this type of scenario and given the long view, productivity is likely to be consistent and of high quality. Furthermore, containing the illness and preventing the spread to other members of the work team helps maintain organizational productivity. A topic for another day is: How do you measure productivity in a remote work force so that it can be evaluated for consistency, quality, and other such metrics?

Essential Graphics #2

Big Data Edition

Those on the Big Data Bandwagon say you can never have too much data. But if you do have too much to manage and are overloaded, you can always jump off the wagon and push.

overload