What can I say here that isn't on my LinkedIn? In my storied career, I've seen some things. You can see it in
the eyes. While we tend to be super positive on LinkedIn, I'm going to try something different here and talk about the horror that I've experienced in the long stretch of time I've been involved in training systems in the DoD space.
While I started with a small production crew making a commercial game, I quickly moved to DoD contracting since where I lived at the time, that was where most of the offered positions were. I was creating content for video and interactive training software, and I got my first taste of the craziness that accompanies doing creative work for a highly process driven bureaucratic organization where the goals seem to be to fit production into existing systems designed for engineering (round peg into square hole).
After a bit of a culture shock, but I was able to adapt with some time and even learned to appreciate the idea of using process to speed things up where it makes sense to do so. Still... sometimes I found a clash between the heavy processes we were navigating and my need for agile.
Years of this and many tailoring documents written later I see things have improved and with the introduction of DevOps I'm starting to lose that eye twitch. Now we are using interactive training using game engines which was a significant shift but certainly a good one. These processes I've learned are starting to come in handy with application development vs. video production. but still there remains that clash with creative folks that are involved in decision making and the need to balance that with documentation processes required for government work. One of the more puckering moments is a heavily under rom'd effort that comes from trying to guess at how long doing something creative will take ahead of time. Definitely takes a crew that has a lot of time in to understand what goes on with the production team when you load up on requirements.
Working over becomes part of the culture. It's really difficult to simply turn something in that is adequate for an MVP when you see 'what it could have been like'. This is true for art as much as it is for code writing.
-sigh-
Then there is the issue with teams that live in a silo. One team doesn't understand what affect changes will have on the other team's production. Happens a lot when one team doesn't understand how the other team works or the project as a whole. Lots of wasted time backtracking becomes common. I've always tried to help iron out this particular issue a lot since I walk this line between the two a lot but it's not easy without real support from leadership. I usually suggest getting the teams familiar with each other's methods and find some common ground there. Then setup the tool building and DevOps systems. Maybe one day I'll find that team that supports this sort of mentality.
After a bit of a culture shock, but I was able to adapt with some time and even learned to appreciate the idea of using process to speed things up where it makes sense to do so. Still... sometimes I found a clash between the heavy processes we were navigating and my need for agile.
Years of this and many tailoring documents written later I see things have improved and with the introduction of DevOps I'm starting to lose that eye twitch. Now we are using interactive training using game engines which was a significant shift but certainly a good one. These processes I've learned are starting to come in handy with application development vs. video production. but still there remains that clash with creative folks that are involved in decision making and the need to balance that with documentation processes required for government work. One of the more puckering moments is a heavily under rom'd effort that comes from trying to guess at how long doing something creative will take ahead of time. Definitely takes a crew that has a lot of time in to understand what goes on with the production team when you load up on requirements.
Working over becomes part of the culture. It's really difficult to simply turn something in that is adequate for an MVP when you see 'what it could have been like'. This is true for art as much as it is for code writing.
-sigh-
Then there is the issue with teams that live in a silo. One team doesn't understand what affect changes will have on the other team's production. Happens a lot when one team doesn't understand how the other team works or the project as a whole. Lots of wasted time backtracking becomes common. I've always tried to help iron out this particular issue a lot since I walk this line between the two a lot but it's not easy without real support from leadership. I usually suggest getting the teams familiar with each other's methods and find some common ground there. Then setup the tool building and DevOps systems. Maybe one day I'll find that team that supports this sort of mentality.