I completely agree! I can't tell you how many devs I've worked with try to use the "working software over comprehensive documentation" agile principle as an excuse to be lazy and not put in the extra effort for the customer. There is still value in documentation. I've built some cool stuff in ServiceNow but I get by far more recognition for my videos, training sessions, and documentation than my slick script includes.
@@robertthedukefedoruk5607 All internal or shared with the higher education community. I'm considering releasing some public content but don't have anything in the works. Most of my videos are focused on guided UAT, walk-through guides, or dev demos of integrations or how to use a custom util SIs. So I often create them specifically for customization as a way to document.
getting As-Build document is really important. I have seen people writing single BR with multiple functionalities and without proper description. Thanks Robert for sharing!
True! And the requirement for documentation should be exactly the same, regardless of who develops, partner or my own team. No team is forever, and hero ball just doesn't work in the playoffs. Also, handover is not the end, it's the beginning. Keeping the documentation updated and relevant is just as important as creating it.
Great vid, Rob. While there are no excuses for not documenting pre-built solutions of any sort, it would be good to highlight the flip side of this which is sticking to original requirements! Scope creep and changes during the project are the bane of any documentation writer and this can easily increase documentation costs by 100-200% with all the capturing and editing that ends up taking place. You also have to rely on developers a lot to do this documentation and generally they are keen or under pressure to move on to the next thing (the customer just wants something built and the developer is all to happy to just build it and move on). In the moment, documentation can seem pointless - its in the stories/emails/logs! - it’s only when Joe future (which could even be you) comes along that it’s true value is realised. But then, even if the documentation is fantastic, you also need governance to actually make sure it is stored somewhere central and easily accessible where it can be found in future!
Being THE James Neale, you bring up excellent points. To my shame, the last time I failed at documentation was for reasons you describe: the scope changing every second day. However, I still don't think that would have been any more than 5-10% total effort to have kept up with (thus the shame). Agree that "in the moment" documentation seems less important... but I'd stress that Joe Future *always* comes along. I'm not trying to say its easy, but rather easier than a lot of partners make it out to be, and a lot more valuable too.
So true, but this medal has two sides, the partner that is openly not able to fulfil a quality job and the customer who is not insisting on it. I saw this so often in the last three years, ridiculous.
Any chances of getting a video on the risks of the new feature in New York called "Instance Key Management"? My first mental image is the nuclear bomb two-key sequence to arming, where the two specialists each have a key on a necklace, they have to insert them both at the same time, and then turn to arm at the same time. The best movies from the fifties drag this scene out over two minutes with lots of sweaty palms and drama. The best scene and scariest scene was from a PBS series called Secrets of the Dead: The Man Who Saved the World, here is a link to the trailer: ua-cam.com/video/453PEldRoIE/v-deo.html this is from the PBS channel.
The template document at 4:24 is a small life saver; thanks Rob !!!!!!!!
My pleasure, James. Every time I hear this I get to thumb my nose at the ITBM vendor who refused to give us any form of documentation.
I completely agree! I can't tell you how many devs I've worked with try to use the "working software over comprehensive documentation" agile principle as an excuse to be lazy and not put in the extra effort for the customer. There is still value in documentation. I've built some cool stuff in ServiceNow but I get by far more recognition for my videos, training sessions, and documentation than my slick script includes.
Any one who tries to downplay the importance of documentation I immediately suspect of having spent NO time outside of the consulting world.
Are you talking about internally consumed videos? Or do you have stuff out in public?
@@robertthedukefedoruk5607 All internal or shared with the higher education community. I'm considering releasing some public content but don't have anything in the works. Most of my videos are focused on guided UAT, walk-through guides, or dev demos of integrations or how to use a custom util SIs. So I often create them specifically for customization as a way to document.
@@sonoranskyoutdoors I'm a big fan of video. :D
getting As-Build document is really important.
I have seen people writing single BR with multiple functionalities and without proper description.
Thanks Robert for sharing!
You said it, brother.
True! And the requirement for documentation should be exactly the same, regardless of who develops, partner or my own team. No team is forever, and hero ball just doesn't work in the playoffs. Also, handover is not the end, it's the beginning. Keeping the documentation updated and relevant is just as important as creating it.
"hero ball doesn't work in the playoffs"
GOLD!
Great vid, Rob. While there are no excuses for not documenting pre-built solutions of any sort, it would be good to highlight the flip side of this which is sticking to original requirements! Scope creep and changes during the project are the bane of any documentation writer and this can easily increase documentation costs by 100-200% with all the capturing and editing that ends up taking place. You also have to rely on developers a lot to do this documentation and generally they are keen or under pressure to move on to the next thing (the customer just wants something built and the developer is all to happy to just build it and move on). In the moment, documentation can seem pointless - its in the stories/emails/logs! - it’s only when Joe future (which could even be you) comes along that it’s true value is realised. But then, even if the documentation is fantastic, you also need governance to actually make sure it is stored somewhere central and easily accessible where it can be found in future!
Being THE James Neale, you bring up excellent points. To my shame, the last time I failed at documentation was for reasons you describe: the scope changing every second day. However, I still don't think that would have been any more than 5-10% total effort to have kept up with (thus the shame). Agree that "in the moment" documentation seems less important... but I'd stress that Joe Future *always* comes along. I'm not trying to say its easy, but rather easier than a lot of partners make it out to be, and a lot more valuable too.
This is great and so true. Time to change our processes!
So true, but this medal has two sides, the partner that is openly not able to fulfil a quality job and the customer who is not insisting on it. I saw this so often in the last three years, ridiculous.
You can do high level documentation that outlines most of the build with less than 5% of the total scope.
This is helpful. Thanks for sharing this!
You bet!
Is there a way to get a sample of the document you showed here
Couldn't agree more!
Any chances of getting a video on the risks of the new feature in New York called "Instance Key Management"? My first mental image is the nuclear bomb two-key sequence to arming, where the two specialists each have a key on a necklace, they have to insert them both at the same time, and then turn to arm at the same time. The best movies from the fifties drag this scene out over two minutes with lots of sweaty palms and drama. The best scene and scariest scene was from a PBS series called Secrets of the Dead: The Man Who Saved the World, here is a link to the trailer: ua-cam.com/video/453PEldRoIE/v-deo.html this is from the PBS channel.
If I knew much more about encryption, I'd probably take a stab at it.