Rock Crusher Frequently Asked Questions

The Rock Crusher is a concept we have been working on in some form or other since 2011. The original graphics style used was based on artwork created by Newfoundland comic artist Dave Barrett. We used much of his artwork in our early Rock Crusher workshops, classes, and blog posts. Our pre-review manuscripts for the Rock Crusher also used Dave’s artwork. When our book became an IIBA publication, it was decided we needed a more “professional” look in our images.  For example, the image on the left is our original artwork, while the image on the right is the artwork created by the IIBA for the book. Our intention is that as we move forward, we will use more of the book artwork than the original artwork.

We chose the name Rock Crusher for integrating our patterns of successful backlog management because rock crushing in the mining industry offers a really good mental model for imagining active value management. In mining, value management is quickly processing vast amounts of mineral-bearing rocks to find perhaps a few kilograms, even just a few grams of valuable ore. Big ideas must be crushed and refined into smaller chunks that downstream processing can pull without overflowing or clogging. Excessive overburden must be discarded. During the rock crushing process, additional milling may be needed to find the ore, so heavy steel balls are added to the crushing process.

The name Rock Crusher emerged from a conversation in a New Jersey bar about 12 years ago. During that conversation, I was explaining backlog management to a client on the back of a beer mat. They had significant experience in mining and exclaimed, “Oh, now I get it! It’s just like rock crushing! You should draw it like this,” and he proceeded to sketch what we today are calling the Rock Crusher on that beer mat.

In a word, no. Regardless of what we may want to believe, software development is a reductive process, which means we first need to understand the problem, develop a solution to the problem, and then implement the solution. Making the process of understanding the problem visible is not an example of BUFD. Rather it is making the “….hardest part of developing a software system” visible and managed.

Crushers are Rocks, and as Rocks, they must be well formed.

The visibility into the analysis process created by Crushers also enables us to see if we falling into the BUFD trap.

Yes and no.

Yes, because both a spike and a crusher serve a similar purpose, which is to create the knowledge we need to make better decisions moving forward.

No, because a crusher is for learning about the problem space, while most of us associate a spike with learning how to implement a specific solution. This may sound like we are being a bit academic, but we have several justifications for simply not re-using the term spike:

• First, the term spike has a very strong meaning for software development teams, and expanding the definition may have come across as confusing. Our industry has a very bad habit of creating confusion by overloading well-known terms. Consider the challenges people have with terminology like Epics, and Capabilities.
• Second, the usual scope of a spike is maybe a day or two of investigative work, whereas a crusher may be close to the full duration of a sprint.
• Finally, the term Crusher fits nicely into the Rock Crusher model metaphor. The term was inspired by the additional ore processing steps in the mining industry, where heavy steel balls are added to the rock crushing process. Some mining processes also use what are call “rod mills” where instead of heavy balls, heavy rods are used to crush mineral bearing ore.

A Ball Mill for Crushing Mineral Bearing Ore

The “rock crusher village” deconstructs the role of the product owner into the seven roles required to own and manage a backlog

In this village, the role of the “analyst” is defined as:

An individual who is responsible for transforming the sometimes competing wants, hopes, interests, and aspirations of the Customer, Stake holder, the Initiative Owner, the Product Manager, and the contributions of the Subject Matter Expert into a shared clear understanding of precisely what to build.  Is responsible for progressively creating a better understanding of precisely what to build – the solution.

The Rock Crusher

In short, they have to hold this village together and ensure the village has a shared clear vision of what the solution is and what is truly valuable versus just a good idea.

The role of analyst is often very much what is referred as a “boundary spanner” where an individual listens and shares information across the enterprise to create a shared clear vision of what is valuable. Numerous studies correlate boundary spanning with successful technology deployment[1].

Often the individual(s) playing the Analyst role is also a Subject Matter Expert (SME) with deep product domain knowledge.

[1]Levina, N., & Vaast, E. (2005). The Emergence of Boundary Spanning Competence in Practice:

Implications for Implementation and Use of Information Systems. MIS Quarterly, 29(2),

335-363.

The IIBA’s Business Analyst Book of Knowledge (BABOK) lists a number of underlying competencies a Business Analyst should have:

Analytical Thinking and Problem Solving Skills : Business analysts must be effective in generating new ideas for approaches to problem solving and in generating alternative solutions.

Credibility: A business analyst must be able to behave ethically in order to earn the trust and respect of stakeholders and be able to recognize when a proposed solution or requirement may present ethical difficulties.

Communication Skills : Oral communication skills enable business analysts to effectively express ideas in ways that are appropriate to the target audience

Facilitation: Business analysts facilitate interactions between stakeholders in order to help them resolve disagreements regarding the priority and nature of requirements.

In the Rock Crusher we speak of the Analyst (e.g. a Business Analysts) as serving as a “boundary spanner” actively sharing information across the enterprise to drive alignment on what is truly valuable. Five common attributes of a boundary spanner are:

• They are relatively experienced individuals, usually with at least 5 years of industry experience and at least 2 years within the organization. They either understood the system (“technical knowledge”) or understood how things were done (“organizational knowledge”). They tended to have the respect of their peers and were considered thought leaders.
•  They were strong communicators, able to communicate issues to others in a manner they could understand.
•  They had a broad picture of their work – not necessarily the complete big picture, but they understood how they and others fitted into a broader scope as opposed to only understanding their job role.
•  They had the personal strength to reach out when they believed they discovered a perspective mismatch.
•  They strongly believed it was part of their job to play this role and the organization gave them the flexibility to play it by not overburdening them with production work.