In the first part of this blog series, we presented the analogy that the benefits of blockchain technology are the same benefits we seek to have in an ALM data strategy. This is potentially a multi-million-dollar analogy because there is a lot to gain throughout your product development flow once you tie in the key tenets and benefits of blockchain. Enter, the first benefit, which is identity.

Every time I talk to a customer, I almost always witness a spoof of the old Abbott & Costello Who’s On First skit. The simple act of trying to identify ‘the work’ that is being done in an organization, and by ‘whom’, turns into chaos. It is a very real thing in organizations today. This lack of identity around the work will evince ambiguity, uncertainty, and erode trust. We want the direct opposite result in product development.

Blockchain technology lowers uncertainty during the exchange of value because it provides identity about What is being transacted, by Whom, and When. We will focus on these three W’s for the moment, yet identity certainly empowers us to clarity around the five W’s. In blockchain, transactions are linked together to provide a chronological history or audit trail. The same is needed in product development; an overview of the all the transactions made from inception to delivery.

In the context of product development, the ability to quickly identify the pertinent information about the ‘work’ being planned and executed, in real-time, which means you can have quick conversations, make quick decisions; and the domino effect will be shortened delay times across the lifecycle, and tighter feedback loops.

With blockchain, technology is used to eliminate the need for a third-party intermediary to prove the identity of an asset, and who/what/when the work for that asset was completed. Let’s think about that in the context of agile planning. What acts like a third-party intermediary in product development?

Spreadsheets.

Spreadsheets are manually compiled, take a small army of people to do the mundane work, and lead to unproductive conversations about data accuracy, that all doesn’t help build trust or empower our knowledge workers. We go to great lengths to create and maintain spreadsheets all in vain of simply trying to identify what work is being done, by whom, and when. What if you just had a single registry of all the linked transactions in product development in real-time; to get an accurate big picture at a glance?

In my first blog post, we established the notion that product development is a series of transactions involving a multitude of stakeholders and artifacts. Use technology to identify all the transactions that occur during the product development lifecycle, and identify how these transactions are linked together. Now, have all that identifying data in a single registry to eliminate the need for spreadsheets; would that not be a game changer?

Let’s explore this a bit more; they say technology should help enable your business processes by freeing up capacity and providing data to guide decision making. To obtain that higher degree of trust and certainty in your ALM data, you must be able to identify the provenance, custodianship and attestations of the artifacts in your ALM data set.

Ideally, you should be able to answer the following questions:

  • Can I easily identify what the work item is? E.g. Is it a User Story? Task? Feature?
  • Identify the Acceptance Criteria, target objectives, child artifacts, whatstatus it is currently in?
  • Can I easily identify who is the owner of those work items?
  • What parent artifact is it linked to? Why is this work important? Whatproblem are we solving?
  • Can I easily pull a full audit trail of the artifact to show all transactions: test cases, investments, tasks, dependencies/risk, scheduled dates, etc.?

Having all this information in a single registry is the foundational stone to business agility. Yet, from my experience, ALM data infrastructure is often treated as an afterthought. If you want to attempt business or enterprise agility, then your technology must act as a robust backplane. The identification of the ALM data from top to bottom across the different planning horizons is something you should be solving with technology.

If you are not able to easily identify if your organization is building the right thing, and who/what/when the work is being done, then I would safely assume your product planning and status meetings involve a great deal of amnesia. There are hidden costs to operating in that way.

If you find these concepts interesting, and you have read this far, then may I suggest a couple of simple things to experiment with:

  • Data standardization: Put in place a standard around the work items in the work item hierarchy for you product development. Easily identify what the work item assets you manage are, is a good first step.
  • Single registry: To have the right conversations with the right people at the right time, you need to be able to easily identify, and retrieve the information. A single management system that supports one truth throughout the organization is the catalyst to decentralized decision making, and empowered teams.
Share this