This year, one of my students asked me the following question:
"I am doing the Script and Storyboard. I changed the presentation from what I stated in my Content Outline. Should I go back and change my content outline."
As I wrote the answer, I realized how much I have been influenced by Agile philosophy. My answer, as you see, is "NO" but the insight has changed to a product orientation. Here was my answer:
"EXCELLENT QUESTION!!! The answer is no, you should NOT go back and correct the outline. otherwise, the outline becomes the product. Let me explain. The ADDIE process is a system. A change in one phase affects the others. However, we want that system to be progressive instead of recessive. We don't want to go back. Sometimes clients with huge bureaucracies demand the documentation. However, that is a dumb thing for them to do because it slows down production of useful material.
Our goal is a product that the client (in this case ACME Driving School) can use. If we go back and do the outline, we have a very nice bit of documentation but who does it serve? The purpose of the
outline was to provide a guideline to get us started. We in the industry realize that things happen in scripting that may not have been anticipated in the Content outline. You may have gotten better
information from an SME, another professional may have introduced you to a better way of presenting content, you may have had a revelation about the content or the way it is presented. All those are great. WE DO NOT WANT TO BE SLAVES TO DOCUMENTATION. It helps us get started but it should not hold us back."
1 comment:
Should the student or should the student NOT go back and update the document?
Hmmmmm. A really good question...
1. Agile does favor Communication over Documentation (refer to Agile Manifesto).
2. Is the change substantial? Will a contract administrator or
upper-manager call the change to question at some future date? There are some aspects of documentation that cannot be avoided; however, one should ascertain WHAT and WHY something is being documented. Otherwise you'll spend hours documenting something that could have been accomplished in a couple of minutes. Try to ascertain what problem the additional documentation will address.
3. Who is empowered to make the decision to change the content?
That is where electronic support systems come in handy. A quick note
from the product owner, perhaps with a digital signature attached,
would probably be sufficient, to keep the historical record straight.
I think the concept of "empowered" is key here. Agile has to have
trust if it is to work. Somebody on the customer side (i.e., the bill paying side) has to have enough TRUST in the PRODUCT OWNER to empower him/her to make those decisions. The product owner is the "single wringable neck" so to speak.
The other piece to consider is configuration management; that is where the development team needs to pay attention and work together.
Somebody changes the script -- but did they ensure that the rest of
the team was aware of that change? What about the graphics guy charged
with making the on-screen text that has to sinc with the narration
(which will be driven by the script)?
This, again, is where communication is critical (more so than just documentation). In the morning stand-up meeting, the change should be brought to the team's attention. Additionally, an electronic environment should flag
everyone that a change has been made.
Finally, we must consider the medium. If we're talking powerpoint or configuration-managed CBT, change isn't that big of a deal (oops, we missed that one; we'll have it corrected in the next release, no big deal).
However, if we're talking Film or video that could be a really significant problem, down the road.
A system such as iKe should ensure that the record of change is
maintained, that only the appropriate person can make the change, that the entire development team is alerted to the change, and that the change isn't executed until the product manager says so.
I think that's the difference between Agile and sloppy production.
Post a Comment