... that would be the answer I would give you, if you ask me about my job today. So let me give you a little background, so you understand better what I mean.

Ok, I work currently for a german car maker as a Scrum Master. Not directly, but over an IT consulting contractor for the car maker. As you might imagine, a large corporation has a lot of departments and a lot of SW Development going on. So of course I can only speak for my small field I'm currently in, so of course you have definitely other examples, where the agile SWD setup is better or maybe ideal. But for my current project it is not.

Insights
Well, here are some of the points, why:

• Quarterly release cycle, with occasional bug fix releases
  Ok, that is not necessary a bad thing, but for a web application this is no longer state of the art. Modern web applications use CI/CD pipelines and an agile setup with much shorter and feature oriented release cycles.
• Four week sprints
  Also not so unusual, but with our setup a bad thing. Our PO's cannot produce good user stories fast enough to fill an entire sprint with work. Ok, to stand up for our PO's, that's not totally their fault. Our PO's work with the stakeholders of our customer. And they, although they work in sprints, too, they move and produce user stories very slow and they have no habit in delivery results at the end of a sprint. In addition their sprint ends exactly with the begin of our dev sprint. So our PO's and also our Devs have often no time to evaluate those US, groom them, estimate them and re-work them if they are not good. So we have to fill the dev capacity during the four week sprint with those US, often very late in the sprint. Hence we have never had a successful sprint since the start of the project
• We estimate not in complexity, we estimate in money.
  And that's definitely a very bad thing. So in the bidding phase some of our sales and I.T. managers - relatively unexperienced with bids on agile and somewhat DevOps oriented contracts - calculated the costs for the open commission from this car maker for that set of projects. Ah, one important information I should give you. Our project is part of a larger set of projects which was contracted to us. In the set are legacy software maintenance, new SW development, maintenance of relatively modern web applications, some operation and also customer support for those software. So a mix calculation was made and through a somewhat complicated formula a conversion to hourly cost was made. Nothing unusual so far, but then a fatal flaw happened. The customer was used to put T-shirts on the US. So our management connected this efforts with the values of the mix calculation and put a price and a hours value to the T-shirts. So from that point on, our Scrum process could no longer be made after good practices, our order was to estimate in T-shirt, so sooner or later had in their mind, they have to estimate the US's with money and no longer in complexity. And that is IMHO a very bad thing and not agile.
• Ordered team members in Scrum Teams
  So from the get go, when management decided to do agile SW development, they didn't followed the good practice and ask the personnel who wants to work in the projects, they went to the employee list, who had no or an outgoing project, and had a somewhat fitting skill level. And some who fit this profile where ordered to work in the project. Since our company is working in whole Europe, those devs where recruited from all over Europe and put more or less randomly put in Scrum teams. Then some teams where put on the different projects in the set of projects from the customer. Without team building, without preparing for the new corporate customer and some of the devs not even worked with Scrum, yet. And they not even get a basic training about Scrum. So you can guess what happened during the last year. Devs left, devs with almost no motivation, problems within the teams, problems with the software, problems with the customer, problems with the profitability and problems within our company. So not a good agile setup.

And more stuff
So above I already mentioned some bad things, but there is more and I don't want to go on, cause that's getting boring and you should have gotten the point by now. But here a list with more not so agile stuff:

• Unstable development environment
• Docker for Windows as test environments
• No Cloud oriented hosting, still based on Pet Servers
• Developers have no or very little docker experience
• Very little test automation, only a handful of selenium based tests
• Not even manual testing at our side, was not calculated, so it was not part of the initial setup
• Manual customer tests only before releases
• Bad written US, due to inexperience or lag of training of stakeholders in writing good US
• Only one integration environment, which is blocked for up to two weeks during bug fix releases
• No mandatory feature approval as soon as possible, hence delayed US review meetings
• No mandatory presence from customer side at Sprint Reviews, Sprint Plannings
• Wrong usage from Jira. Sprint feature is not used as intended. It is used as contracting tool.
• Due to T-shirt size orientation, no SP based burndown
• Stakeholders and their supervisors do not have a plan and IMHO no glue how to build a maintained and prioritised backlog.
• Our PO's not seen as partners who can help, they more or less only assistants who have to full fill the orders from the customer.
• Language barriers; German is default language, but common dev language in Europe is English
• aso.

Conclusion
So you see, even if a car maker designs and produces great looking, feature rich, powerful and agile cars, behind the scenes it might not be so.

Postlude
Ok, you might ask me now, why do you work in such a project, then? Well, as some of you know, life can have sometime events, that change the way you live and work. For me there was such an event, that forced me to take this job at this consulting company. And Corona and the wish to keep this job for at least two years had me involved in this project and all its problems.

But everything in life has almost every time not only a bad side, it also has a good side. For me the good side is, that I could realise my 4-day work week, a salary that pays the bills and let me put something back for retirement, and I can work a dull 9-5 job, where I do not have to invest much to get by and have a lot of time for my favorite sport "American Football".

As always apply this rule: "Questions, feel free to ask. If you have ideas or find errors, mistakes, problems or other things which bother or enjoy you, use your common sense and be a self-reliant human being."

Have a good one. Alex