SW (SoftWare) engineers and experts do not have an interest in
documentation. SW engineers as well as experts have an interest in the final
solution, especially in a solution that fulfils the needs of the business or
users. Unluckily many organizations prevent successfully that SW engineers
communicate with the subject matter experts. That’s exactly what agile and lean
processes try to address – to tear down communication barriers to the minimum.
SW engineers
working in software development have an elaborated set of documentation means
built in into Scrum. Epics, user stories, source code, acceptance tests,
prototypes, a technical environment support the design, implementation, build,
test and deploy cycle with versioning and release management (at least hopefully
– if not, well you know now where you have aspects to improve. To be straight –
this is where we at digitec Galaxus as well do have room for improvement).
Subject
matter experts (example: actuaries in reinsurances), technical experts
(example: hearing experts in the development of hearing devices) all have very
special tools and environments. Actuaries often use Excel. I have seen
monstrous solutions built from man dependent Excel workbooks driving business
critical risk management solutions implemented by actuaries in reinsurances.
Nobody else except the creator understood these complicate solutions. I once
had the job to migrate such a solution into a scaling Java solution – what a
nightmare. The most important individuals in this project were Prolbares (see
above) that translated the requirements of the actuaries, hidden in the Excel
beast, into something executive managers (“why is it so expensive to rewrite an
Excel worksheet in Java??!!”) and SW engineers (“as a reinsurance key
accountant I want to …”) understood.
Point is:
Between SW engineers and experts (and managers) there is a distance that Prolbares
try to reduce or even to eliminate - with distance defined as well as physical
distance as mindset distance. In true agile environments elimination is the aspired
state. What is important in respect of documentation: SW engineers and experts
both have their specific way to deal with documentation.
With this
requirements of SW engineers and experts for documentation are:
- The very specific type of work requires the support by very specific processes and tools (Excel for actuaries; epics, user stories, acceptance tests, source code and a build/deploy environment for SW engineers).
- The least amount of documentation is the best – no matter of the documentation is required as information source to start my work or as information sink required by anybody else in the organization.
- SW engineers and experts are not interested in documentation. They are interested to get their job done and to create results and to deliver.
No comments:
Post a Comment