Tag Archives: 3

An Introduction to Data Blending – Part 3 (Benefits of Blending Data)

Readers:

In Part 2 of this series on data blending, we delved deeper into understanding what data blending is. We also examined how data blending is used in Hans Rosling’s well-known Gapminder application.

Today, in Part 3 of this series, we will dig even deeper by examining the benefits of blending data.

Again, much of Parts 1, 2 and 3 are based on a research paper written by Kristi Morton from The University of Washington (and others) [1].

You can learn more about Ms. Morton’s research as well as other resources used to create this blog post by referring to the References at the end of the blog post.

Best Regards,

Michael

Benefits of Blending Data

In this section, we will examine the advantages of using the data blending feature for integrating datasets. Additionally, we will review another illustrative example of data blending using Tableau.

Integrating Data Using Tableau

In Ms. Morton’s research, Tableau was equipped with two ways of integrating data. First, in the case where the data sets are collocated (or can be collocated), Tableau formulates a query that joins them to produce a visualization. However, in the case where the data sets are not collocated (or cannot be collocated), Tableau federates queries to each data source, and creates a dynamic, blended view that consists of the joined result sets of the queries. For the purpose of exploratory visual analytics, Ms. Morton (et al) found that data blending is a complementary technology to the standard collocated approach with the following benefits:

  • Resolves many data granularity problems
  • Resolves collocation problems
  • Adapts to needs of exploratory visual analytics

Figure 1 - Company Tables

Image: Kristi Morton, Ross Bunker, Jock Mackinlay, Robert Morton, and Chris Stolte, Dynamic Workload Driven Data Integration in Tableau. [1]

Resolving Data Granularity Problems

Often times a user wants to combine data that may not be at the same granularity (i.e. they have different primary keys). For example, let’s say that an employee at company A wants to compare the yearly growth of sales to a competitor company B. The dataset for company B (see Figure 1 above) contains a detailed quarterly growth of sales for B (quarter, year is the primary key), while company A’s dataset only includes the yearly sales (year is the primary key). If the employee simply joins these two datasets on yearly earnings, then each row from A will be duplicated for each quarter in B for a given year resulting in an inaccurate overestimate of A’s yearly earnings.

This duplication problem can be avoided if for example, company B’s sales dataset were first aggregated to the level of year, then joined with company A’s dataset. In this case, data blending detects that the data sets are at different granularities by examining their primary keys and notes that in order to join them, the common field is year. In order to join them on year, an aggregation query is issued to company B’s dataset, which returns the sales aggregated up to the yearly level as shown in Figure 1. This result is blended with company A’s dataset to produce the desired visualization of yearly sales for companies A and B.

The blending feature does all of this on-the-fly without user-intervention.

Resolves Collocation Problems

As mentioned in Part 1, managed repository is expensive and untenable. In other cases, the data repository may have rigid structure, as with cubes, to ensure performance, support security or protect data quality. Furthermore, it is often unclear if it is worth the effort of integrating an external data set that has uncertain value. The user may not know until she has started exploring the data if it has enough value to justify spending the time to integrate and load it into her repository.

Thus, one of the paramount benefits of data blending is that it allows the user to quickly start exploring their data, and as they explore the integration happens automatically as a natural part of the analysis cycle.

An interesting final benefit of the blending approach is that it enables users to seamlessly integrate across different types of data (which usually exist in separate repositories) such as relational, cubes, text files, spreadsheets, etc.

Adapts to Needs of Exploratory Visual Analytics

A key benefit of data blending is its flexibility; it gives the user the freedom to view their blended data at different granularities and control how data is integrated on-the-fly. The blended views are dynamically created as the user is visually exploring the datasets. For example, the user can drill-down, roll-up, pivot, or filter any blended view as needed during her exploratory analysis. This feature is useful for data exploration and what-if analysis.

Another Illustrative Example of Data Blending

Figure 2 (below) illustrates the possible outcomes of an election for District 2 Supervisor of San Francisco. With this type of visualization, the user can select different election styles and see how their choice affects the outcome of the election.

What’s interesting from a blending standpoint is that this is an example of a many-to-one relationship between the primary and secondary datasets. This means that the fields being left-joined in by the secondary data sources match multiple rows from the primary dataset and results in these values being duplicated. Thus any subsequent aggregation operations would reflect this duplicate data, resulting in overestimates. The blending feature, however, prevents this scenario from occurring by performing all aggregation prior to duplicating data during the left-join.

Figure 2 - San Francisco Election

 Image: Kristi Morton, Ross Bunker, Jock Mackinlay, Robert Morton, and Chris Stolte, Dynamic Workload Driven Data Integration in Tableau. [1]

Next: Data Blending Design Principles

——————————————————————————————————–

References:

[1] Kristi Morton, Ross Bunker, Jock Mackinlay, Robert Morton, and Chris Stolte, Dynamic Workload Driven Data Integration in Tableau, University of Washington and Tableau Software, Seattle, Washington, March 2012, http://homes.cs.washington.edu/~kmorton/modi221-mortonA.pdf.

[2] Hans Rosling, Wealth & Health of Nations, Gapminder.org, http://www.gapminder.org/world/.

Interview Question #3: Converting a Consolidation to a Custom Group

Question

Can you always convert a consolidation to a custom group and vice versa?

Answer

You can always convert a consolidation to a custom group, but you can only convert a custom group to a consolidation when the custom group filters are from the same table or very similar tables.

Dr. Dobbs Journal: The Corruption of Agile (The Agile Holocracy) – Part 3 of 3

Readers:

In my last post, I included a recent interview Andrew Binstock, Editor in Chief of Dr. Dobbs Journal, had with Dave Thomas about the corruption of Agile and how many people are misunderstanding what the Agile Manifesto really said.

Allen HolubToday, I am continuing with the third and final part of my series titled The Corruption of Agile by highlighting thoughts from one of the key thinkers in the area of agile, Allen Holub. Allen is a consultant, trainer, and speaker, specializing in Lean/Agile process infusion, Agile/OO architecture, and cloud-based web-application development. He’s worn every hat from grunt programmer to CTO, and has written hundreds of magazine articles for various technical publications and a dozen books, including Holub on Patterns: Learning Design Patterns by Looking at Code. He is a regular speaker at various conferences, worldwide.

In a recent blog entry in Dr. Dobbs Journal titled The Agile Holocracy, Allen noted that agile is a culture, not a set of practices. It is upper management’s job to establish that culture, and then let it work. A holocratic organization is one of the better ways to do that.

Mr. Holub notes that the word holocracy popped up in a recent Dilbert cartoon, used incorrectly as a synonym for both a flat organizational structure and, as the pointy haired boss says, “wander[ing] around.” Nonetheless, full-on agile organizations have many of the characteristics of a holocracy, so Allen thought it was worth exploring the concept.

The term holocracy was coined by Artur Koestler in his 1967 book, The Ghost in the Machine, which is actually a discussion of the human brain. Koestler’s thinking applies to social organizations as well, however. A holocracy is made up of autonomous, self-reliant units called holons (from the Greek word for “whole”). The holons are simultaneously independent from and dependent on the organization that they comprise. That is, a holocracy is simultaneously a whole and its parts.

Kosetler uses our own brains as an example. The cerebellum (the “reasoning” brain) is largely independent on the amygdala (the so-called “lizard brain”). These two sub-brains operate independently under their own rules, but interact in a way that allows the whole system to behave both coherently and in a way that you couldn’t predict from looking at a single subsystem. This is a kind of emergence; the coherent behavior that arises from the complex interactions of the rules and strategies of the independent holons is more sophisticated than behavior of the parts. The ghost is the thing that you can’t predict just by looking at the parts.

Koestler also points out that when one subsystem dominates, the whole system can become pathological. When your lizard brain hears a loud noise and says “panic!,” your cerebellum counters with, “no, that’s just an electric guitar and a gazillion-watt amp” and overrides it. The synthesis is a feeling of excitement that the concert’s starting. If the lizard brain wins, everybody in the stadium gets trampled.

The notion of holocracy works well in agile organizations. In fact, I’d say that some level of holocratic structure is essential. Independent units — teams or individuals — are responsible for specific organizational roles, and interact with one another in a synergistic (to use an overused word) way. A person is holon, and so is a team. Each holon is both independent and part of the whole. Each holon is responsible for itself, but is also responsible for the success of the whole organization. The holons carry out well-defined roles, and are responsible for doing whatever they have to do to succeed in those roles. Nobody orders anybody around. The teams and the people are responsible for defining and executing their own tasks.

Getting back to Dilbert, holocratic organizations do have a flat hierarchy. They are peer-to-peer networks, not trees, and there’s no place for any sort of “middle management.” The executives are the organization’s lizard brain: They set the direction and support the broad culture. The teams are the cerebellum: Thinking out the details and getting the processes to work. The synthesis of those roles yields a functional agile organization. If either holon is dominant (that is, if agile practice exists without a supporting culture, or if the executives perpetuate command-and-control, or if the teams get to do everything they want without regard to budget or scope), everybody gets trampled.

There isn’t even a “CEO” in the captain-of-the-ship sense. Instead, the holons (both people and teams) communicate with each other in order to tune what they’re doing. In the same way that people talk to each other, teams interact horizontally. For example, teams can “inject” members into other teams. Spotify, for example, has a “guild” system. All the database folks from all of the teams get together occasionally for Database-Guild meetings, and so forth. Think of this arrangement as a database-guild holon that injects members into the development-team holons.

Holocratic organizations aren’t fantasies. Probably the most well-known is W.L. Gore, Inc., as described in Malcolm Gladwell’s Tipping Point. There are no formal titles and no hierarchical structure. People have “sponsors,” but nobody reports to anybody.

The main objections to the viability of a holocracy seem to come from people who confuse holocracy with anarchy — everybody doing whatever they want. That’s not what I’m describing. A holocracy is highly disciplined. You take your responsibilities seriously, and work hard both to be effective and to make everybody else successful. Communication and collaboration are central to both functions, so everybody does that.

Similarly, holocracy is not Communism. The people who contribute more are rewarded accordingly. However, compensation has to be transparent and rational. Secrets undermine the collaborative nature of the system.

Dysfunction happens when one holon becomes dominant. An out-of-control “executive” holon, for example, can destroy the agility of the organization. I’ve seen teams, departments, and whole companies brought to their knees by pathological “leaders” intent on dominating, who think that somebody has to “run” things. The mandates that come from these people do nothing but add dysfunction. I’m not talking about micromanagement, which is also a sort of disease. Dysfunction happens any time somebody can’t do something because they need permission, or won’t do something because they’re afraid of some repercussion. The holons (teams and individuals) must be empowered to fulfill their roles.

Of course, there’s no reason for some of the holons not to be tasked with the health of others. For example, one responsibility of the “executive” holon is to assure that company has an effective internal culture. If a team becomes dysfunctional, the “executive” holon’s job is to help the team heal, not by ordering people around, but by providing training, mentorship, etc. If that doesn’t work, though, the “executive” holon could act like an antibody. The immune system is part of a healthy brain. The core value in a holocracy is trust. Hierarchical command/control organizations are built on mistrust. They assume that nobody beneath you in the hierachy is truly self sufficient and competent, so they impose paternalistic governance practices that force these assumed-incompetent players to behave. A holocracy trusts everybody to do their work in the best way possible.

Since trust and assumed competence are also firmly ingrained in the Agile Principles, there’s a good match here. Everybody’s got to be a grownup, though. I once heard Aliestar Cockburn answer the criticism “your methods won’t work in the real world because they require nothing but A players” by saying that making good software always requires A players, regardless of your process. I agree.

As a final note, Holacracy.org adapted Kosteler’s notions into a social/organizational milieu, and serves as an interesting example of another functional variant of an holocracy. Everybody in the Holacracy.org is literally (in the legal sense) a partner. There are no bosses, and there is no CEO. I’m not a huge fan of Holocracy.org’s formalization, but they’re prominent enough to deserve mention. For one thing, I’m offended by the way that Holacracy.org has trademarked Kosetler’s term. The trademark isn’t enforceable, given prior use, but they have no right to set themselves up as the arbiter of somebody else’s idea. It’s like somebody trademarking “agile.” Moreover, I don’t particularly like their fixed rules (documented in a Constitution), which seems to me to fly in the face of the core principle of self organization.

I’ve said this before, but agile is a culture, not a set of practices. It is upper management’s job to establish that culture, and then let it work. A holocratic organization is one of the better ways to do that.

———————————————————————————–

Source: Allen Holub, The Agile Holocracy, Dr. Dobbs Journal, March 14, 2014, http://www.drdobbs.com/architecture-and-design/the-agile-holocracy/240166629.

 

Dr. Dobbs Journal: The Corruption of Agile (or What the Agile Manifesto Really Said) – Part 2 of 3

Readers:

In my last post, I included a recent article from Andrew Binstock, who is the Editor in Chief of Dr. Dobbs Journal. Mr. Binstock expressed his concerns about how we are corrupting Agile.

Dave ThomasToday, I am continuing with Part 2 of my The Corruption of Agile series by highlighting thoughts from one of the founding authors of the Agile Manifesto, Dave Thomas. Dave (photo, right) is a coauthor of the legendary Pragmatic Programmer book, one of the authors of the Agile Manifesto, a publisher, speaker, and the man who brought Ruby to the masses.

In a recent interview with Mr. Binstock, Dave discussed what he feels is wrong with Agile. But, before we get started, let’s review what the Agile Manifesto really said. This is verbatim from the Agile Manifesto website.

 

Manifesto for Agile Software Development

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more. [2]

The Corruption of Agile – Andrew Binstock’s Interview with Dave Thomas [1]

AB: Let me move to the Agile Manifesto. You were one of the original signatories…
DT: Yes, yes. There were 17 of us that met in Snowbird in Utah in February 2001; and we came up with the four values and the common ground and practices. The way we came up with it was not something I’d ever experienced before. There were 17 people and everyone had their own ax to grind and their own particular viewpoint on what was best. And within a couple of hours, we’d come up with a way of working that let us discuss the principles behind what we were doing without going into the details.So the framework itself, the actual four values, came out in half a day. It just kind of came. I think everyone kind of knew what they wanted to say. I think it was actually Martin Fowler and I — everyone else was having lunch — we were kind of sitting at a whiteboard just chatting through things and we came up with the “we value A over B” formulation, which as it turns out, has worked out really well.
AB: I think that perhaps a limitation is that a lot of people have interpreted it as “no B whatsoever.”DT: Indeed! And, in fact, we recognized that might happen at the time, and we put in the little phrase at the bottom: “whereas we value B, we value A more.” So, we thought that would happen and we tried to stop it, but, of course, we…AB: …can never control…

DT: Yes, that was the depressing thing for me. I came away from Snowbird feeling really happy. And within a month, I realize it wasn’t going to work. And I have not been involved in anything even called “Agile” until last month.
AB: Last month?
DT: That’s right, last month. I have not gone to any Agile conferences. I have not joined the Agile Alliance.
AB: Why is that?
DT: Because it got immediately productized in many different ways. The whole point, to my mind, of the Agile Manifesto is that it’s a set of personal practices that may scale to team level. You do not need a consultant to show you how to do that. It may help to have someone facilitate, but you do not need a consultant. And yet immediately what happened was that everyone and their dog hung out an Agile shingle and the whole thing turned into a branding exercise.
AB: Yes.
DT: And so now in the software world, if you’re selling something and it doesn’t have the word “Agile” somewhere in the title, it’s not good. And I hate that because we had something that was…it was my best attempt at the time to present a set of free-standing, self-contained values that could be applied by all. And now it’s just become mush. It’s become devalued to the point where it doesn’t mean anything.
DT: I also have a pure English-language abhorrence to the people who use Agile as a noun. As in “I do Agile.” No you don’t. It’s like saying “I do orange.”
AB: When you were meeting at Snowbird, was there a feeling there that you were doing something important that was going to change software?DT: Good question.AB: The fact that you chose the term “manifesto” suggests that you were planting a flag.DT: There was a lot of discussion at the time about what it should be called. And, to be honest, I can’t remember to what extent we were thinking of posterity when we came up with the word “manifesto.” Even the word Agile was debated a lot.

AB: That’s what I’ve heard.

DT: I think we discussed “lightweight.” There was some sense that this was going to be bigger than the 17 of us because we agreed on the last day that Ward [Cunningham] was to go create a site that would allow people to sign up. Ward is someone who is always building community. And I think we all went along thinking that would be a really good way to spread the word. But the reality was that I don’t think any of us were particularly marketing people. The fact that it took off as quickly as it did was that we just happened to say the right thing at the right time. We didn’t actively push it particularly, it just kind of pushed itself or actually pulled itself.

Next: Allen Holub and The Agile Holocracy

Bonus Section: The 12 Principles behind the Agile Manifesto

For you folks that have never read the actual Agile Manifesto, I have provided a copy of its guiding principles here for your review.

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly. [2]

———————————————————————————–

Sources:

[1] Andrew Binstock, Dave Thomas Interview: The Corruption of Agile; Ruby and Elixir; Katas and More, Dr. Dobbs Journal, March 18, 2014, http://www.drdobbs.com/architecture-and-design/dave-thomas-interview-the-corruption-of/240166688?pgno=3.

[2] Kent Beck et al, Manifesto for Agile Software Development, The Lodge at Snowbird Ski Resort, Utah, February 11-13, 2001, http://agilemanifesto.org/.

 

 

Dr. Dobbs Journal: The Corruption of Agile – Part 1 of 3

Readers:

I have been in the Computer Science / Information Technology / Management Information Systems profession a long time. There are times when I need to take a break from all of the noise going on in our profession and revisit words and thoughts from the people I consider my mentors. These are the people who helped me become a better programmer, a better thinker, and learn to question everything.

One of my favorite magazines that I have read since my early days in this profession is Dr. Dobbs Journal. Reading articles in this wonderful magazine from many of the thought leaders (e.g., Scott W. Ambler, Allen Holub, Bruce Eckel, Larry O’Brien, Dave Thomas, Andrew Koenig, etc.), who taught courses early on at various conventions I have attended during my actual computer language programming days (e.g., C, C++, Java), remind me of the principles and personal practices I have let slip or ignore with all of our new drag-n-drop GUI-related tools.

Andrew BinstockI came across this article from Andrew Binstock (photo right), who is the Editor in Chief of Dr. Dobbs Journal. Prior to joining Dr. Dobb’s Journal, Andrew Binstock worked as a technology analyst, as well as a columnist for SD Times, a reviewer for InfoWorld, and the editor of UNIX Review. Earlier, he was a senior manager at Price Waterhouse. He began his career in software development in the early 1980’s.

I have included Mr. Binstock’s recent editorial about his concerns about how we are corrupting Agile in it’s entirety below. In Parts 2 and 3 of this series, I will explore some interesting thoughts about the Agile Manifesto and an interesting technique developed by Dave Thomas to continuously improve our programming skills.

Best Regards,

Michael

The Corruption of Agile

by Andrew Binstock, Editor in Chief, Dr. Dobbs Journal

What was intended as a set of personal practices has become a doctrine. And despite the mainstream adoption of Agile, the loss of its original intent has undermined its effectiveness.

Many people over the years have discussed their distress with the religious tone that cloaks the implementation of Agile practices. Particularly from the testing side of the world, there is a lot of “should,” “should not,” and “can do better next time” dialogue that sounds more like a man trying to fix ethical lapses than a developer writing code. When I speak with adherents of test-driven development (TDD) in particular, there is a seeming non-comprehension that truly excellent, reliable code was ever developed prior to the advent of this one practice. I sense their view that the long history of code that put man on the moon, ran phone switches, airline reservation systems, and electric grids was all the result of luck or unique talents, rather than the a function of careful discipline and development rigor.The disconnect between today’s Agile view and earlier reality is equally evident in the wanton bashing of the waterfall model. To get any programmer today to adopt your recommendation, simply state that not doing so is just a new way of doing waterfall. Watch his toes curl despite never having used waterfall, nor seemingly having any awareness that it served the industry really well for decades. What, was everyone in that bygone era a fool?Alan Kay was entirely right when he said that programming today has become a pop culture: “Pop culture is all about identity and feeling like you’re participating. It has nothing to do with cooperation, the past or the future — it’s living in the present. I think the same is true of most people who write code for money. They have no idea where [their culture came from] — and the Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free?”

It will pain some readers to know that the vast, error-free Internet predates Agile and even predates TDD. Crazy, right?

What I’m saying here is certainly not new. The fascination with today’s way of doing things and the view that it is the one true path to good code is a seemingly permanent part of the programming culture. But it has been greatly abetted by the legions of Agile consultants. By stressing the practices, they have corrupted what Agile was about. It’s important to remember that the Agile manifesto stated values, not practices. Immediately, though, values were translated into programming practices by consultants and, quickly, the former was lost. One of the original formulators of the manifesto, Dave Thomas, whom I interviewed this week, states his realization that a month after the manifesto was written it was already being corrupted: “…it got immediately productized in many different ways. The whole point, to my mind, of the Agile Manifesto is that it’s a set of personal practices that may scale to team level. You do not need a consultant to show you how to do that. It may help to have someone facilitate, but you do not need a consultant. And yet immediately what happened was that everyone and their dog hung out an Agile shingle and the whole thing turned into a branding exercise.”

What’s interesting in Thomas’s account is the view that Agile was a personal practice. Implicit is a personal way of orienting oneself towards a development process that accepts, even welcomes, change.

By pure coincidence, Allen Holub has been driving this point home in several blog posts, the most recent of which is a brilliant little piece that reminds us that Agile is a culture, not a set of practices. As he has previously explained, just because an organization is using scrum, doesn’t mean it’s Agile. He could have said the same thing about TDD, continuous integration, pair programming, or the like.

Whether a site is Agile or not depends on its culture. Does the culture support the personal values of the manifesto? If so, it’s Agile, if not, then it’s doing something else. So, indeed you could have a fully Agile site without TDD, continuous integration, or scrum. Likewise, you can have a site that uses all three practices, but cannot adapt to changes and is wholly inflexible in its work — so, not at all Agile. Yeah, I know, crazy, right?

Next: What the Agile Manifesto Really Said

———————————————————————————–

Source: Andrew Binstock, The Corruption of Agile, Dr. Dobbs Journal, March 18, 2014, http://www.drdobbs.com/architecture-and-design/the-corruption-of-agile/240166698.

Andrew Binstock can be reached at alb@drdobbs.com or via Twitter at platypusguy

Tips & Tricks #3: How to Define Custom Subtotal Displays in MicroStrategy Desktop

By default, when users apply subtotals in a report, the name of the subtotal is displayed in the subtotal line items that appear in the report. Users can use custom subtotals to give more control over the characteristics of a subtotal. Custom subtotals allow users to define custom subtotal line items that appear on the reports.

Users can make the subtotal name dynamic by typing special characters in the subtotal name field as listed in the following table.

Trick2-1

Trick2-2

To define a specific subtotal displays for a report like the one shown above, follow the steps below:

  1. Select Subtotals from the Data menu. The Subtotals dialog box opens. Clear the Totals check box to remove the standard subtotals.
  2. Click Advanced.
  3. Click New to create a custom subtotal.
  4. Type the following for the name: “Total for the #P #0”. Remember that P displays the parent attribute and 0 (the number zero, not the letter o) displays all the forms of the parent attribute. In this case, only one form exists for each, as shown below.

Trick2-3

 

All the metrics on the report are listed. Users can select the subtotal function to use for each. Total is correct for all of the metrics.

  1. Check the Total for the #P #0 subtotal (shown below).
  2. Click Advanced.
  3. Select Across level and then select the Region and the Employee as the levels.
  4. Click OK to save the new subtotal.
  5. Click OK to return to the Subtotals dialog box.
  6. Click OK.

Trick2-4

The report should now look like this.

Trick2-5