This week's book giveaway is in the Programmer Certification forum. We're giving away four copies of OCP Oracle Certified Professional Java SE 11 Programmer I Study Guide: Exam 1Z0-815 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
Daryl / Hong (or is it Li? Traditionally, Hong would be the family name):
I mentioned systems thinking while coaching at a client this week. It was in the context of giving them a picture of where they wanted to be eventually in their practice, sort of like showing them a picture of the beach they're about to make a long and arduous trek through a jungle to get to.
One thing that confuses the heck out of the people actually doing the work is when management tells them things like "You have to do two-week sprints and you have to put all your requirements in JIRA in the form of user stories." and "User stories should follow the 'As a - I want - So that' format." Without further guidance, what's most likely to happen if these people are used to doing more traditional/waterfall development is that they will just take whatever they were putting into massive Word documents and jam them into JIRA as massive "user stories." That is not good and it doesn't provide any more value than it did when they were using Word docs. If anything, it becomes a net loss because now their requirements are going to be all over the place in JIRA and it becomes a confusing jumble that's difficult to impossible to track.
I told the team I was coaching that they had to recognize huge JIRA items as "smells" that needed to be refactored. Teams are often told to keep User Stories brief and high level ("It's just a reminder to have a future conversation") but then there's no further guidance about what they need to do with the things they don't write down in the user story. When they already have many requirement details documented in Word, they are going to want to keep that knowledge somewhere. Just telling them to delete all that is not useful and it won't make sense to them because those details are the result of what they will feel was valuable work, which for the most part is probably true.
That's what brought me to the idea of "Conservation of Knowledge" and systems thinking. If you're going to change the way you're managing requirements and the knowledge of what needs to be done, then you have to think at the system level. If you take some levels of detail out of the user story, then those details don't just go away. The knowledge must be conserved and transformed into something else. That "something else" can be conversations that result in executable feature specifications (Gherkin/Cucumber) and unit tests. That means that practices like BDD and TDD need to be taught to the teams. The idea is to refactor "Big Word Docs and Handoffs" into "Stories, conversations, executable specs, and automated unit tests." Doing that requires teams to look at their development process as a system of delivery that needs to follow that principle of conservation of knowledge. Where once they had all the knowledge concentrated in a big Word Doc, they now needed to spread it out, without losing useful knowledge, across stories, conversations, tests, and shared understanding among team members.
In other words, when transitioning your development practice from Big Requirement Specs to User Stories, the knowledge you're trying to capture is essentially the same but it goes from one form that has many levels of detail to different forms that have different levels of detail.
I wonder if there is something related to this idea discussed in your book. If not, what are your thoughts about this?
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck
Yes, you make a great point and even have an excellent name for it - "Conservation of Knowledge."
We talk a bit about this in our book in the software craftsmanship chapter (Chapter 9 - Flipping the Run/Build Ratio). I've sometimes described TDD and BDD to clients as "executable requirements." It is great if you have a big Word doc that describes the requirements for this app. But it goes out of date, as we all know. However, if you put those requirements into automated tests instead, and the tests are continuously run as part of code check-in, then those can never go out of date.
The biggest value to having requirements is that you can know the "why" behind the design decisions months or years later. With the Word doc, it is an outdated why. But the tests have the up-to-date why.
Sounds like you need to write a book too, Junilu! I like how you explain things.