From Agile to Design Thinking. Scrum assumes tame problems that can be time-boxed, estimated with planning poker, decomposed into user stories, tracked on a velocity chart and declared done against a checklist. If only knowledge were this tame. Knowledge organization is anything but tame.
I can't believe there aren't a million comments from every knowledge worker in the world praising this post. The struggle is so real. Can't tell you how many times I've argued with folks that this work can't be done - or can't be done well, anyway - in 2 weeks!
Thank you, Nicole! Once you’ve lived the reality a few times over across orgs, the pattern is unmistakable. It slows down progress and hampers the work to be done ;)
Thank for you for this article. Reading your prior articles on the Ontology Pipeline it had occurred to me that work of this nature would fit well into an Agile approach. Few thoughts in this regard:
- Design Thinking and Agile should not be mutually exclusive and any software development without upfront design work is likely to produce what the business wants but not what it needs.
- The application of Agile to knowledge work should look very different than Agile for software development. But my experience is similar to yours in that if you try do them together, the project becomes all about software and not about the knowledge.
- Applying Agile to knowledge work requires a re-writing of the principles, but small, highly-skilled, cross-functional project teams working together within a time-boxed plan is a highly effectively approach.
Fair. However I do overall think Agile is somewhat dated and should be revised to support innovation.
When you say “rewriting of principles”, I’m interested in what you are thinking? Rewriting of Agile principles or…?
my experience throughout the years is we write user stories to communicate the benefits of a system — detailing how the user will benefit from a taxonomy thesaurus or knowledge graph. How Sally can find what she’s looking for or Bob can reliably integrate his chatbot.
we can timebox the building of say level one categories in a taxonomy or the TBox in an ontology. But after modeling level one or top level concepts or modeling the class hierarchy in an ontology—then what? The work that comes next may upend or change the timeboxed sprint where we only modeling and built a fragment.
The next sprint, we build level two and three of one part of a taxonomy or we model and build a part of the Abox or instances. And in so doing, we have to revisit and restructure part of the taxonomy because the taxonomy did not validate. With the ontology, the ABox modeled and partially built demands more TBox individuals or members we overlooked.
competency questions drive the build ultimately, the work is driven by what questions we want a system to answer. Meaning before it’s integrated with products, features or http://platforms.so
And then, throughout multiple sprints, say 10 sprints, we still cannot satisfy the user stories as we continue to refine, iterate, test, validate the model for logical reasoning. And leadership pushes as to why nothing has materialized, that’s tangible.
Perhaps the engineering work—the operationalizing of the taxonomy, ontology or graph, follows agile but the design portion does not? Curious about your thoughts here…
Definitely agree the term is dated and "Agile for Knowledge Engineering" is probably not a helpful term.
Agile principles are written for software development. So if you were going to apply them to a project that was not software development, you would want to re-write them for the subject matter of the project. When reading your Ontology Pipeline series I thought of Competency Questions as analogous to User Stories.
The challenge of any large project is to maintain leadership confidence in the project across an extended period of time and $spend. Agile addresses this through continuous delivery. For a project of this nature, I would assume it is the demonstrated ability to answer complex competency questions.
I would likely start the project with an intense design phase that involves both leadership and the project team. (art of possible and build enthusiasm). Then a series of foundational sprints, where there is no expectation of business value. Then a series of sprints built around answers to competency questions and business value. While the foundational taxonomy elements are never "locked" and can be revisited, if the taxonomy is continually re-worked such that the competency questions are never resolved, you run the risk that management will lose enthusiasm.
Not sure if that makes sense. You certainly have all the expertise from the trenches.
I can see this working for leadership buy in and confidence. But the competency questions cannot be answered until the ontology and graph are complete.
Perhaps a hybrid or adaptive model works.
I have experienced all too often, where the knowledge engineering work is stuck in an epic for a quarter through a design and build phase. For example, if the project is to build a graph to support autotagging and a document knowledge graph.
Your comments are super helpful here. Do you see risk in lengthy epics (lasting a quarter) for the design and build phase?
A quarter strikes me as the right size of an epic, where you could fit in 3 to 6 sprints and deliver against a set of competency questions. Less than that feels like a pilot or test project.
Can the the knowledge work be separated from the broader system work? My guess is that in some cases it can, and in others is can not. When it can be separated then is not dependent on the broader project.
Brilliant. It applies to writing as well: write slow, think deep, see new connections. Thank you!
ZH
I can't believe there aren't a million comments from every knowledge worker in the world praising this post. The struggle is so real. Can't tell you how many times I've argued with folks that this work can't be done - or can't be done well, anyway - in 2 weeks!
Thank you, Nicole! Once you’ve lived the reality a few times over across orgs, the pattern is unmistakable. It slows down progress and hampers the work to be done ;)
I like the pushback against forcing Scrum onto messy knowledge work
Thank for you for this article. Reading your prior articles on the Ontology Pipeline it had occurred to me that work of this nature would fit well into an Agile approach. Few thoughts in this regard:
- Design Thinking and Agile should not be mutually exclusive and any software development without upfront design work is likely to produce what the business wants but not what it needs.
- The application of Agile to knowledge work should look very different than Agile for software development. But my experience is similar to yours in that if you try do them together, the project becomes all about software and not about the knowledge.
- Applying Agile to knowledge work requires a re-writing of the principles, but small, highly-skilled, cross-functional project teams working together within a time-boxed plan is a highly effectively approach.
Fair. However I do overall think Agile is somewhat dated and should be revised to support innovation.
When you say “rewriting of principles”, I’m interested in what you are thinking? Rewriting of Agile principles or…?
my experience throughout the years is we write user stories to communicate the benefits of a system — detailing how the user will benefit from a taxonomy thesaurus or knowledge graph. How Sally can find what she’s looking for or Bob can reliably integrate his chatbot.
we can timebox the building of say level one categories in a taxonomy or the TBox in an ontology. But after modeling level one or top level concepts or modeling the class hierarchy in an ontology—then what? The work that comes next may upend or change the timeboxed sprint where we only modeling and built a fragment.
The next sprint, we build level two and three of one part of a taxonomy or we model and build a part of the Abox or instances. And in so doing, we have to revisit and restructure part of the taxonomy because the taxonomy did not validate. With the ontology, the ABox modeled and partially built demands more TBox individuals or members we overlooked.
competency questions drive the build ultimately, the work is driven by what questions we want a system to answer. Meaning before it’s integrated with products, features or http://platforms.so
And then, throughout multiple sprints, say 10 sprints, we still cannot satisfy the user stories as we continue to refine, iterate, test, validate the model for logical reasoning. And leadership pushes as to why nothing has materialized, that’s tangible.
Perhaps the engineering work—the operationalizing of the taxonomy, ontology or graph, follows agile but the design portion does not? Curious about your thoughts here…
Definitely agree the term is dated and "Agile for Knowledge Engineering" is probably not a helpful term.
Agile principles are written for software development. So if you were going to apply them to a project that was not software development, you would want to re-write them for the subject matter of the project. When reading your Ontology Pipeline series I thought of Competency Questions as analogous to User Stories.
The challenge of any large project is to maintain leadership confidence in the project across an extended period of time and $spend. Agile addresses this through continuous delivery. For a project of this nature, I would assume it is the demonstrated ability to answer complex competency questions.
I would likely start the project with an intense design phase that involves both leadership and the project team. (art of possible and build enthusiasm). Then a series of foundational sprints, where there is no expectation of business value. Then a series of sprints built around answers to competency questions and business value. While the foundational taxonomy elements are never "locked" and can be revisited, if the taxonomy is continually re-worked such that the competency questions are never resolved, you run the risk that management will lose enthusiasm.
Not sure if that makes sense. You certainly have all the expertise from the trenches.
I can see this working for leadership buy in and confidence. But the competency questions cannot be answered until the ontology and graph are complete.
Perhaps a hybrid or adaptive model works.
I have experienced all too often, where the knowledge engineering work is stuck in an epic for a quarter through a design and build phase. For example, if the project is to build a graph to support autotagging and a document knowledge graph.
Your comments are super helpful here. Do you see risk in lengthy epics (lasting a quarter) for the design and build phase?
A quarter strikes me as the right size of an epic, where you could fit in 3 to 6 sprints and deliver against a set of competency questions. Less than that feels like a pilot or test project.
Can the the knowledge work be separated from the broader system work? My guess is that in some cases it can, and in others is can not. When it can be separated then is not dependent on the broader project.
Glad to provide a perspective,
Thank you!