Part of my work for cPrime will be to write for the cPrime blog, which means that Deep Scrum will go dormant. Some of my old from Deep Scrum material will appear on the cPrime blog, and so will all of my new material. I expect to produce a similar mix of instructional articles, musings about how and why Scrum works (and occasionally, doesn’t work), and opinion pieces.

So come over to https://www.cprime.com/blog/ and say hi! And if you have been following my writing on LinkedIn (where my profile is www.linkedin.com/in/kevinthompsonphd), be sure follow my cPrime profile in the future (www.linkedin.com/company/cprime-inc.).

The discussion revealed a major split between two approaches for estimating effort and velocity. While both defined a sizing unit named “point,” the definitions were quite different.

Points as a Measure of Effort

“Effort” refers to an amount of work. The units of effort are time-based, such as “person-hours” or “person-days,” and describe the time spent on a specific task by a person.

Effort differs from duration in that a single person-day of effort may be spread across two or more calendar days, if the person only devotes part of each work day to the task. The ratio between the effort someone spends on a task, and the duration of the task, is his availability. Even someone who is officially dedicated to a particular task full time will have some of his day taken up by overhead, such as meetings, phone calls, and email. (A reasonable rule of thumb for the availability of someone dedicated full-time to a task is 75%, meaning he is likely to spend about six of his eight work-day hours on the task.)

When points are taken as a measure of effort, the usual definition is that one point equals eight person-hours, or one perfect person-day. Team members then estimate a Story’s size based on how much effort they believe the Team will expend to implement the Story.

The Team’s velocity is the number of points of effort available for the Sprint, based on the members’ availability and the number of workdays in the Sprint. Given the velocity and point estimates for Stories, it is easy to determine how many of the top candidate Stories will fit into the Sprint.

Points as a Measure of Complexity

It seems obvious that the complexity of a Story affects the effort required to implement the Story, so complexity makes sense as a sizing metric. Unfortunately, there is no standard means to define complexity for a Story. (Function-Point and related techniques might provide such a standard, but are not commonly used in Scrum projects.) Instead, various estimation techniques are used to create a relative numerical scale, such that a Story with a larger point estimate is more complex than one with a lower point estimate.

Estimation techniques often analogize Story complexity to common physical tasks, such as “moving piles of dirt” or “painting the house,” or to commonplace scales such as “T-shirt sizes.” Historical information is very important, so that a Team can say, “This Story is about as big as that three-point Story X from last Sprint, so we should estimate it at three points.”

Team velocity is then not computed a priori from team size, but based on historical data regarding how many points the Team implemented in the last Sprint. Again, once Story sizing and Team velocity are known, it is easy to determine how many of the top candidate Stories will fit into the Sprint.

Which is Better?

We can’t answer the question unless we know what “better” means. Possible measures of “better” include

1. Reliability of predictions about the Team’s ability to complete a planned set of Stories per Sprint
2. Ease with which Team members understand and internalize the scale
3. Ability to measure increases in productivity over time
4. Support for Scalability, by ensuring uniformity of definitions across Teams
5. Transparency and comprehensibility to external stakeholders
6. Opacity and insulation from interference by external stakeholders

The first measure should be the most important, since it is the reason for having an estimation process. The other measures are secondary (and 5 and 6 are diametrically opposed).

So which approach is better, given these measures?

I believe that Effort estimates do better for measures 2, 4, and 5, while Complexity estimates do better for measures 3 and 6. I have seen no compelling evidence that either approach is superior for the key measure, #1. In other words,

It doesn’t matter whether you choose Effort or Complexity estimates for Story sizing and Sprint planning. They both work.

Heated debate between comparable alternatives usually reflects strongly-held values. If one were clearly superior, there would be no need for debate. If neither were superior, and strongly-held values were not an issue, no one would care enough to engage in debate. The fact that such a debate exists tells me that such values have come to the fore, and I find this interesting.

What are these values? I can’t speak for everyone, but here are my guesses:

Effort estimation appeals to those who prefer metrics that can be measured against an objective standard, such as time. These people

• Value scalability, and so prefer metrics that are uniform across teams
• Have a good relationship with external stakeholders, and want to provide the latter with useful status information that is easy to understand
• Like to create mathematical models, and find them useful

Complexity estimation appeals to those who prefer metrics that cannot be measured against an objective standard. These people

• Do not want anything that smells of the ‘bad old days’ of waterfall projects, such as time-based metrics, because the latter open the door to criticism when performance differs from estimates
• Do not trust external stakeholders, and wish to keep status information private within the Team, and unintelligible to outsiders, because outsiders may try to meddle if they know what is happening within the Team
• Dislike mathematical models, and do not trust them

Conclusions

I don’t believe that the above reasons provide the whole story for why some people prefer one sizing metric over the other. I’m sure that personal feelings about what feels most natural play a role, and I’m also sure that those who started with a particular approach and found it successful see no reason to change.

However, I’ve seen enough insularity (‘Scrum islands’) and distrust between development teams and business stakeholders to find these plausible influences for shaping metrics. I’ve also seen strong knee-jerk reactions among Scrum experts against anything that they associate with failed waterfall-style projects. I think the latter is a mistake, and leads to throwing out the baby with the bath-water, but it is definitely an influence.

So at least in some cases, I suspect that a preference for subjective measures of Story sizing and velocity is driven partly by distrust and an ‘us versus them’ attitude. If so, I think it would be wise to build bridges and improve trust, rather than accept the status quo.

The “Sweet Spot” for Scrum

Scrum is optimized for projects that have high uncertainty (due to the inability to estimate effort accurately), a high likelihood of frequent changes of direction (due to rapidly-changing requirements), and the need to respond quickly to customer requests. For these reasons, it mandates short development cycles of uniform length, to minimize risk and maximize responsiveness to rapidly-changing customer needs. The emphasis on short cycles enables a predictable schedule of releases, each of which is the result of one or more development cycles.

The “Sour Spot” for Scrum

Let’s think about some examples of projects for which Scrum is not particularly useful.

I don’t use Scrum to make a cheese sandwich. I use a waterfall process, following a template devised long ago: I get out two pieces of bread, slice enough cheese for the filling, and assemble the sandwich.

I also don’t use Scrum to build a set piece for a play. Instead, I collaborate with as many other volunteers as we can reasonably use, and work on the piece until we have to quit for the day, or until it is done. After one or more work sessions, we finish the piece and move on to the next. This process is neither Scrum nor waterfall in nature, but bears more of a (rather vague) resemblance to Kanban.

So what do these examples tell us? Basically, they say that Scrum is much less useful when the work is thoroughly understood in advance, or when the delivery date is not specified, and not cyclic.

A Real-World Example: LifeHints

I’ve been helping out some friends at LifeHints over the last year, working with them to set up development guidelines. My first thought, of course, was that the LifeHints folks should use a Scrum process, but I soon changed my mind.

Why not use Scrum? Well, before their first release, they had no established customers, and so no customer requests, for features or release schedules. Thus the cyclic nature of Scrum provided no particular benefits, and responsiveness to customers was not an issue.

What was in issue was the need to build a system incrementally, starting with the simplest scenario (logging in and showing a home page), and adding functionality bit by bit over time until the application had enough to be useful. This process definitely required agility, as the requirements evolved in unpredictable ways over time. It also required daily, or near-daily, builds that worked, so that everyone could see how the new features were shaking out.

In a nutshell, the LifeHints team, which contained both Product Owner and Team member roles, worked in short but variable-length iterations, refining requirements and refactoring code as needed, until the evolving vision and the evolving product converged to a useful reality.

This process was very effective, and I suspect it occurs frequently in pre-release startup companies. I also suspect that, as the company and its customer-base grow, something more formal will eventually be required, and Scrum will become an attractive option.

Conclusions

Everyone knows the saying, “When your only tool is a hammer, every problem looks like a nail.” Scrum is a tool in the toolbox of project management, and, like any tool, is better-suited for some situations than others. For the people at LifeHints, Scrum was too structured and prescriptive for the company’s stage of development. Given the focus on Scrum as a lightweight framework, I find the irony gently amusing.

(For the curious: LifeHints provides guidance on what things you need to do to live a life that reflects your personal preferences. You can check it out at www.lifehints.com.)

In short, the talk is about the view from “Scrum Island,” where the Scrum team lives. Either the islanders are discussing how to make the island work better, or they are talking about how to get foreigners to fund the island. One could be excused for thinking that the islanders have no concern for those who live elsewhere. In fact, I’ve heard of (but not personally experienced) cases where Scrum teams are actively hostile to the notion that outsiders have any right to know what is happening on the island.

The insular view that the team should be protected by an “ocean” (a procedural firewall) that makes it a black box from the outside is understandable, but unfortunate. It is true that the team’s internal workings should be protected from meddling by outsiders, but outsiders have a real need to know what the team has done, is doing, and plans to do.

The Foreigners

The software development process, and the teams that make it happen, do not exist in a vacuum. They exist in the context of a business that has customers, and which contains important roles outside the engineering department. Many of these outsiders are stakeholders for the process. Either they provide inputs to the process, or they are impacted by the process. These stakeholders (“foreigners”) have legitimate reasons to know what is happening on Scrum Island.

Who are these Stakeholders, and what do they want?

1. Customer Support personnel need to enter problem reports into the bug-tracking system, complete with some assessment of impact or priority. They also need to know when bugs are scheduled to be fixed, or have been fixed, in order to respond to questions from customers.
2. Professional Services personnel are in a similar position to Customer Support. They interact with customer who have purchased a service offering, and who expect that their bug reports and feature requests will receive attention.
3. Not only do Salespeople get requests for features from current or potential customers, but they also must communicate expectations about the schedule for feature development. As a result, they place a high priority on getting this information, because it has a direct impact on quarterly sales.
4. Directors, Vice Presidents, and C-Level executives need to plan out business strategy that is aligned with development schedules, which means they need to know (and influence) development plans.

Bridging the Ocean

Bridging the space between the “Islanders” and the “Foreigners” requires three things: tools, procedures, and attitude. Of these, the last is the most important, because it enables the first two to work smoothly.

“We’re all in this together” goes a lot further towards success than “us versus them.” If the Scrum team and external stakeholders can work together easily, the result can be very good. However, if the Scrum team refuses to share information, or external stakeholders try to interfere with the current Sprint’s work, the results will be dismal.

As for tools, the classic “sticky notes on whiteboard” solution for displaying Sprint content and progress does not meet the needs of stakeholders well except in very small companies. When teams and stakeholders are no longer on the same floor, the visibility suffers; when they are in different buildings, it vanishes. A more effective approach is to use an agile project-management tool, which provides a “single source of truth” for requirements, schedule, and progress for everyone, including the teams and external stakeholders. Many such tools exist (e.g., Rally, VersionOne, ScrumWorks), and they can be very effective at providing the information stakeholders need. (As an added benefit to both side, the Scrum Master is freed from the need to write reports for stakeholders.)

“Procedures” refers to the practice of entering requirements and plans into the project-management tool, and keeping the status information current. As Scrum teams have to do these things anyway, in order to function, there is no additional cost to supplying the information to external stakeholders.

Moving to the Continent

We don’t really want Scrum Islands. They arise as accidents, or in response to perverse incentives. What we really want is to have everyone, on Scrum teams and not, working together smoothly. A Scrum process provides the opportunity for tremendous visibility into work done and planned, and this information is valuable throughout the company. Making the information available is not difficult, and brings real rewards to everyone involved with supporting, selling, planning, and building products.

So let’s say good-bye to Scrum Island, and move to the Land of Agile Business. We’ll all be happier.

How can we resolve this paradox?

Scrum Revealed

The apparent discrepancy between Scrum concepts and standard project management concepts is due partly to unfamiliar terminology, and partly to unfamiliar tradeoffs. Let’s look first at the terminology.

Terminology

The terminology of Scrum reflects the practice of working in short, fixed-length cycles called Sprints, a set of which produces a Release of the product. With this understanding, we can translate Scrum terms into language more familiar to project managers:

The correspondence is straightforward. The burndown chart, for example, is just the graph of remaining planned work versus time, which should trend down to zero on the last day of the Sprint. The Sprint Backlog is the set of requirements (“Stories,” in Scrum) planned for implementation in a Sprint.

Tradeoffs

The key to understanding Scrum is to understand what success means for a software project, since the definition of success drives the process.

Project managers are familiar with the “iron triangle” of scope, schedule, and cost. For any project, changes to any of these affect the others. For example, if the scope (or effort needed to achieve it) was underestimated, cost and schedule may have to increase to achieve the scope.

The traditional definition of success requires implementing the planned scope, on schedule, and on budget. When this isn’t possible, the next best thing is to trade off, perhaps extending schedule, adding resources (cost), or reducing scope. In most cases, however, achieving the specified scope, or something close to it, is the most significant part of the definition of success for the project.

Software is different. Unlike houses, software products evolve incrementally, and modest increments of functionality can provide significant new value to customers. Moreover, customer needs can change rapidly, as some of today’s expectations turn out to be less important in six months than other needs that materialize three months out.

The definition of success for most software projects is not to deliver a fixed scope in six months, but to provide desired features quickly in response to urgent (and changing) customer needs. Responsiveness trumps scope as the most significant element of success.

The need to optimize responsiveness drives us to an agile concept of project management, characterized in Scrum by

• Short cycles (Sprints)
  • Allows frequent course corrections in response to changing customer needs
  • Enables quick delivery of urgent customer needs
• Fixed schedules (uniform length for Sprints)
  • Guarantees reliable scheduling of release-quality code
• Completion of features in priority order within each Sprint
  • Guarantees top-priority features will be completed even if actual effort for planned features exceeds estimates significantly

Scrum trades off between scope and schedule by freezing schedule and adjusting scope as necessary. The reason we do not fix scope is because effort estimates for new-feature development have consistently proven unreliable in the software industry, and rather than fight the losing battle for more accuracy, we optimize for what we can predict (schedule, which helps in planning delivery dates), rather than what we cannot (the delivered scope).

Conclusion

The apparent departure of Scrum projects from standard project-management concepts turns out to be an illusion. In fact, Scrum processes are tightly-choreographed and involve careful planning, as any successful project does. The illusion of otherness arises from the unfamiliar terminology, and an unfamiliar tradeoff of scope versus schedule. In the end, an effective Scrum project is indeed following sound project-management practices.

I’ve used multiple flavors of instant messaging and Web-based presentation tools (like Skype and WebEx), but these solutions have significant limitations. They are very effective at addressing the needs for which they were created, but they were not created as general-purpose collaboration tools. Conducting distributed stand-up or sprint-planning meetings with these tools is possible, but laborious. The effort required to set up connections can make using these tools for ad-hoc collaboration impractical.

Sococo’s Team Space takes a very different approach. It provides a virtual office (complete with cubicles and conference rooms), which shows the availability and activities of everyone who is logged in to the application. Users can start online voice or chat discussions, share application views, and pull in more people as needed. The always-on nature of the product provides an on-demand experience, which differs from the scheduled nature of standard teleconference solutions in a manner reminiscent of how DSL connections differ from dial-up modems.

Team Space is in beta-test phase right now. The company is seeking beta testers, and is offering free accounts to people who want to try Team Space for their projects.

If the difficulty of collaborating with distributed team members has been a thorn in your side, I suggest heading over to Sococo and giving Team Space a try.

• lightweight because it has few prescribed elements
  • Three roles: Team, Scrum Master (often a Project Manager), Product Owner (often a Product Manager)
  • Three meetings: Sprint Planning, Daily Scrum, Retrospective
  • Three artifacts: Product Backlog, Sprint Backlog, Burndown chart
• agile because it maximizes responsiveness to changing customer needs
• a process framework because it is not a process, but a collection of practices and concepts around which a process can be built

For those who are not already “doing Scrum,” the key question is not, “How does it work?” but, “What are the benefits?” This question does not have a unique answer, because it depends on who is asking. Benefits to developers, project managers, and salespeople are different.

This article identifies key benefits of Scrum, and the Scrum practices that produce them.

The Benefits of Scrum

Different stakeholders want different things from a software development process.

• Developers want to write code, not documents.
• Quality Assurance engineers want to create test plans that ensure product quality, and have high-quality code to test.
• Project Managers want a process that is easy to plan, execute, and track.
• Product Managers want features implemented quickly, with no bugs.
• Services and Support personnel want to know exactly what is in all product releases, and have a reliable means to satisfy customer requests for bug fixes and enhancements.
• Sales personnel want to know what is “in the pipeline” for future releases.
• Customers want all of their feature requests and bug-fixes done quickly.
• Executives, Program Managers, and PMO personnel want to know exactly what is happening, and what is planned to happen.
• Everyone wants happy customers.

The list seems long, but the key points are few:

• Team satisfaction and productivity are maximized when effort spent on non-deliverable items (e.g., internal documentation) is kept to a minimum.
• Maximizing quality at each stage minimizes re-work at following stages, and maximizes product quality seen by customers.
• Responsiveness is best achieved by fulfilling customer requests quickly.
• Everyone who cares should be able to see all relevant information about project plans, status, and history.

Thus the best real-world development process devotes as little effort as possible to deliverables the customer doesn’t value, provides relatively bug-free code at the start of testing, delivers all relevant information to everyone who needs it, and fulfills customer requests quickly.

It is no coincidence that Scrum was designed to satisfy these points.

How Scrum Provides its Benefits

The following sections describe how Scrum practices produce the desired benefits.

Team Satisfaction and Productivity

The “team” consists of the development and Quality Assurance engineers who do the hands-on work of creating a high-quality product. Team members generally find their greatest satisfaction when they can do work that is rewarding.

• For developers, this means designing and writing computer software.
• For QA engineers, this means defining the exact criteria for success through the test cases they develop.
• For all team members, this means producing something they are proud of.

Productivity goes hand-in-hand with eliminating unnecessary work. Scrum addresses team satisfaction and productivity by emphasizing work that is valuable (as a deliverable) and rewarding (to the team), and de-emphasizing what is not (non-deliverable artifacts).

In practice, “non-deliverable artifacts” usually consist of internal documentation about product requirements and design, which customers do not see or value. Scrum projects do require some written documentation, but minimize it by relying as much as possible on real-time communication between people. Thus a Product Manager will write brief requirement descriptions (called “Stories”), and elaborate on the details as needed in discussions with team members.

The requirement for effective real-time communication means that one of the following must be true for all team members, Product Managers, and Project Managers (in order of decreasing desirability):

1. All are in the same building
2. All are in the same city
3. All are in time zones that overlap at least four hours per day
4. All are willing to spend hours per day outside normal working times (e.g., transoceanic teams).

The last three cases can only be made to work if real-time teleconference and Web-conference capabilities are available on demand.

Maximizing Quality

Teams implement Stories to the requirements, in a very literal sense: An implementation is not complete (a story is not “done”) unless it satisfies the requirements, as defined in the test cases. While test-driven development is not required for Scrum, test cases do define whether the requirements have been met, and no story is complete unless it passes all of its test cases. If bugs arise, developers fix them until the tests succeed.

This practice ensures that each Story implementation is bug-free, with respect to the requirements, at the time of its completion. It does not prevent regression bugs, so additional testing is necessary after all development is frozen. However, the quality of the product going into regression testing is higher than is the case for products going into the final test period for waterfall projects, and high quality ripples through all stages of the process.

Maximizing Responsiveness to Customers

Responsiveness means providing turnaround to customer requests in a manner that is consistent with customer priorities. Since instant turnaround is not possible, the next best thing is to respond quickly to high priorities, and less quickly to low priorities.

The only way to deliver any new feature or bug-fix quickly is to work in short development cycles, which is why the basic unit of Scrum development, the “Sprint,” is typically 2-4 weeks in length. Longer cycles, composed of two or more Sprints, are also common and often referred to as “Releases” (which is not a Scrum term).

Productivity and job satisfaction both require that people are productively employed, not sitting idle, which means that parallel work for team members is the norm. The two strategies for parallelizing work on a set of Stories are

• Parallel work on serial Stories. The whole team collaborates on one Story, until completion, then begins work on the next.
• Parallel work on parallel Stories. Each team member works on a different Story, until completion, then starts on another one.

Since Sprint lengths are “time boxed” (have rigidly-enforced durations), and unexpected problems can occur, it is often not possible to complete all work planned for a Sprint. For this reason, it is critically important that Story development be serialized as much as possible. This allows us to deliver, say, eight of ten planned Stories when only 80% of the expected work can be completed. In contrast, the parallel-Story strategy might produce no completed Stories at all in this case, and deliver zero value to customers.

The need to serialize Story development implies another important Scrum concept: Ranking. The set of Stories planned for a Sprint is called the Sprint Backlog, within which Stories are ranked (sequenced) for implementation. The Product Manager (say) is responsible for ranking the Stories, so that the most important ones are done first. (The Sprint Backlog is a subset of the larger Product Backlog, which contains all un-implemented requirements.)

The combination of short development cycles and ranking of requirements maximizes responsiveness to customer needs.

Providing Transparency

“Transparency” means that all steps, inputs, and outputs of the development process are visible-but to whom?

In the narrow sense, as typically described in books on Scrum, transparency applies to the internal membership of the team, the Scrum Master, and the Product Owner, as they need to know the status of the project every day. In this case, and for co-located teams, transparency may be provided by posting index cards or sticky notes with the current Story and task status, along with the current burndown chart, in a public location. The Scrum framework essentially guarantees this level of transparency.

(A “burndown chart” is a bar or line chart showing, each day, the amount of this Sprint’s planned work that remains to be done. The ideal progress is indicated by a diagonal line, trending down to zero on the last day, against which the actual state is compared.)

Transparency in the wider sense means that every stakeholder who has a need for project status information has immediate access it. “Status information” includes not only the status of the current Sprint, but the content of past Sprints or Releases, and the Product Backlog. The Scrum framework does not provide a standard practice to meet this need, but it provides excellent an excellent foundation for meeting it.

Transparency for stakeholders and distributed teams can be achieved via agile project-management applications (e.g., Rally or ScrumWorks), to which all team members and stakeholders are given access. These applications store all requirements and task definitions, track work status, and provide sophisticated reports. They enable distributed teams to collaborate, and allow stakeholders to query for the information they need, without adding a burden on the team or Scrum Master.

Conclusion

Scrum is designed to optimize team satisfaction and productivity, product quality, responsiveness to customers, and transparency for stakeholders. The key practices that enable these benefits include de-emphasizing work on non-deliverable items, implementing and finishing each Story in a Sprint Backlog in rank order, working in short Sprints of 2-4 weeks, and making past, present, and future project information available to all stakeholders.

Enjoy!

http://lizkeogh.com/2009/09/16/scrum-vs-kanban-fight/

Also, Roderick Lim Banda has produced a good article comparing several approaches to project management, and mapping them to different project attributes which they best address. See his thinking at

http://www.cioforum.co.za/publiccioforum/topic_026.htm

Not having heard the term in daily use, I can only speculate, but I infer that a Scrum Nazi is a fanatic who demands rigid adherence not only to a particular Scrum process, but to an ideology of Scrum that permits no disagreement regarding its superiority over all other project-management philosophies.

Every ideology has its fanatics, so it shouldn’t be surprising that this is true of Scrum, but I find something ironic about a rigid orthodoxy based around a lightweight framework that deliberately under-specifies how software development is to be managed.

I’ve never met a true Scrum Nazi in person, but a discussion with some people at one company some time ago made clear to me that a “Scrum uber alles” mindset does exist.

These folks, many of whom had a strong background in Scrum, were in the process of setting up a new office. They had put together a set of requirements for the office, and a to-do list for various tasks that needed to be accomplished to complete the move.

The odd thing, to me, is that they discussed planning the office move as a Scrum exercise, complete with user stories, epics, and release plans.

Why is this odd? It’s odd because Scrum is designed for cyclic development, wherein teams provide useful increments of new functionality (which have immediate value) for a product at short, frequent intervals. The schedule for Scrum projects is fixed, but the scope is allowed to change in order to meet the schedule.

In contrast, there is no product as such for an office move. Also, the work has a fixed scope that must be achieved, and is neither cyclic nor incremental in any useful sense. Finally, the schedule, while important, has more “give” in it than does the scope.

In short, an office move is an inherently waterfall-style project, not a Scrum-style project.

I mentioned these points to the folks at this company, in as mild a fashion as I could. While everyone was polite and civilized, it became clear that there were no points of agreement to be reached.

My attitude towards project management is that one should use the approach that makes the most sense, rather than apply the same approach to all projects. I suspect that the Scrum ideologues (surely a nicer term than Nazis) feel as they do because Scrum is the only technique they’ve seen used, successfully, on software projects, and have often seen waterfall approaches fail. To me, this is an example of learning the wrong lessons, in a way that leads to a case of, “If you only have a hammer, all problems look like nails.”

I love Scrum, and believe in it deeply for managing most software projects. However, I wouldn’t plan an office move, or a fancy dinner party, with Scrum.

I’d like to hear about your experiences with Scrum ideologues, and mis-matches between project characteristics and project-management philosophies that you’ve seen. Are these things common? I suspect the answer is “Yes,” but would like to know.