I've been thinking - there's only two types of production issues

1). A temporary infrastructure problem pops up at all hours of the day or week and takes the entire application out. At best kicking the users to the logon screen, worse case, ugly dirty error screen with a full load of stack information. Question is what damage has been done to the data? Who knows? Who cares? What if it happens again? Can infrastructure provide a guaranteed fix?

2). More serious a defect(s) in the application which means a code fix. These are the ones that can be reproduced and they don't go away no matter how hard you try until the code has been fixed. Fixed, now it's time to jump through the loops of unit/integration testing(if your lucky), system testing, UAT testing and Preproduction smoke testing.

Do we have to do a data conversion or fix? Whats the impact? How long will it take?

Finally the out of hours deployment and smoke testing before allowing the users back on to the application.

Does Application Support have documentation to support the change(s)?

To be fair no matter how well an application has been developed, edge cases will present themselves and sometimes at the most inappropriate times. Good luck with that!

COV-ID19 and working from home, before the end of my current contract!

Well two years and the application finally went live in December 2019. I'm at home doing application support - documentation of the failed ServicePulse messages which really means why is the application falling over, plus poor performance, being just a handful of issues for a handful of users too- NO UNIT TESTS, NO AGILE, NO TEAM WORKING AS ONE = POOR APPLICATION.

IR35 has been postponed, with the contract market shrinking faster than a whore dropping her draws who knows what will come next.

What next, not sure, just blog for the next three months. Think I will never find a true agile contract, there must be some out there. Real people wanting to have a work life balance delivering a quality application.

Whatever happens next stay safe, stay well, keep doing Agile.

PS. Next time I will not hang about bashing my head against a wall.

PPS June 2020, Found the perfect contract, or I hope so. :-)

I have just spent nearly two years trying to get a project to become Agile and failed, as the Team Lead was too busy playing politics.

The bulk of the code (99% of the code ) has no unit tests and now they have been told to retro fit them. Depressed, yes, happy I'm moving on, you bet. There's only so much headbanging against the wall you can do before it hurts. Then you stop. I should have stopped a long time ago, why didn't I, cause I wanted to push this monster across the line. Shame on me. But in my heart I'd hoped that they would listen and become Agile.

1). Did the team understand the meaning of Agile?
No. They likes the word and liked using it, but at the end of the day they didn't understand despite repeated attempts to make them understand. The key values of Agile e.g. NOT, working as a team and helping others. Even the Team Lead took the words in one ear and let them fall onto the floor out the other ear.

2). Apathy, resisting change.
There maybe more than one reason why people don't want to change deep down. Loss of status with the change of the old guard going to the new stateless flat team structure. Or they just want to be seen doing Agile and shout the key words about but still sit down and do it their way. Reminds me of a song.

3).Make over, not!
So everyone still loves the old school ways and the team want to appear modern and up to date, so just used the words whilst walking around the office e.g. I'm Agile darling don't you know, it's hot right now. When really it's time for change out with the old and in with the new. Why have so many waterfall projects failed, elephant burgers. Why not try eating a quarter pound burger of cut the elephant burger up in small chunks.

4). The minute someone says it costs more!
So Agile is more expensive as you deliver quality testable code.In bite size chunks that the user can commit to and sign off on at regular intervals, sprints. They also get to make changes for the better as they may have misunderstood or missed out functionality. It also means that when you hand over to support there's less panic as the application is more stable and documented with unit tests that CI/CD run.

5). Sprints, two weeks, three weeks or four weeks,Sir!
So frequent deliveries are over kill, really! Small is beautiful, small changes are easy to test, small changes are made at a quality pace. It give the development, system test and UAT teams discipline as to the application being in manageable parts and no one has that elephant burger to test.

6). We are Agile, just to attract new people.
Really, how long do you think they will be impressed with you and the environment. Most will stay a matter of months then go. The excuse we are going agile then some month pass and still no progress has been made. the key to successful management of developers is to keep ahead of the curve or at least on it. Waterfall is dead it never worked, get over it.

7) No, don't do it - waterfall with agile.
Why, just why would do this I have no ideas. Agile allows the entire team from Application support, UAT, System testers to get involved and see the application from birth to delivery. No surprises along the way, better understanding for all, transfer of knowledge in key functionality and process. Come everyone just do it - go Agile and stick to the core values unlike the Team Lead who likes to hear the sounds of his own voice at the stand ups, or daily argument meetings as the development team called them - amongst other things too rude to mention.