You need to know what's on the cutting-edge of technology. Find out what's coming and the unique Warptest POV with just one click on the "Blog" tile.

Tools, techniques and resolving conflicts in Development

Tools, techniques and resolving conflicts in Development
There are many different organizations, start-ups amongst them where the transfer of knowledge between teams or individual can be akin to pulling teeth; difficult, messy and painful.
The classic example in development is when the QA or Test team has to begin defining tests for the next release but has no clear idea beyond terminology on a Gantt or various emails what they have to test.
Getting documentation at this stage can be frustrating and even ultimately counterproductive in terms of the conflict or friction it raises between the person who has to produce the documentation (in our case specifications) and the person who needs the documentation to continue working and not become a bottleneck.
In SCRUM during the daily meeting this issue would be raised as an impediment to the testing progress and the Scrum Master would help the team in resolving this.
However as an experienced QA Manager I can state that this issue is a function of corporate culture. Normally this occurs where VP of R&D and or the CTO continues to make statements committing to full knowledge transfer but actually the real concept being maintained is that writing code comes first and if you are lucky we might get to writing spec down the line.
This truly demonstrates a Waterfall methodology regardless of the methodology that the organization claims to be using.
How do we resolve this? Perhaps this is something you just have to live with and realize that this is an organization that will never embrace Kanban, Lean, Kaizen, and Agile – SCRUM or any variant thereof without a true management commitment.
There are different personality types depending on which theory of psychology you adhere to; I’m a tools and techniques guy, I try to identify the problem and knowing it will recur find the correct tool or technique that allows everyone involved to keep a smile on their face and get the job done.
I encountered this kind of problem myself several times and it occurred to me that if the core of the problem is finding the time to write stuff down, then why make people write at all? The written medium is tiresome to create an often just as difficult to read and learn from. So why not use a different medium?
Ideally, you would introduce the use of Digital Audio or preferably Video recording and get the relevant knowledge owner to speak freely explaining the (in our example) spec. Diagrams, charts and slides could be added later making this “living document” or work in progress. (I re-heard this idea at the Israel Scrum Users Conference, earlier this month; many of us confirming that a good idea is something others thought of at the same time as you).
This is the easy part; there will still be a need for post-processing, review/ approval, document control and much larger storage/ backup than if these were simple textual documents.
Users would have to learn to be comfortable with being filmed, cameras would have to be readily available and seated on a stable platform. The video files would need some form of tagging which could be used for creating a searchable index in the Document control database but ultimately the ROI would be enormous in terms of reducing the friction and frustration in dealing with this impediment.
 
Comments

No comments yet.

Leave a Reply