Problems with management

John_Mc wrote: »

So you don't think a company can do Agile properly, but you do think that they can do Waterfall properly to such a degree that the delivered software will do exactly what they wanted?

That makes no sense whatsoever.

Can you describe what you mean by "can do agile properly"?

Franz Von Peppercorn wrote: »

He also needs to leave that company.

I'm a glass half full sort of person, so I see his problem as OPPORTUNITY.

I would use this to try to get a promotion. I would write an e-mail explaining the problem, explaining the short, medium, and long term solution, and how I can be the person to implement the solution. I would ask for a title change...

OMM 0000 wrote: »

Nowhere did I say this. You're consistently projecting your own meaning onto my posts.

In practice, Waterfall is a strict process, and Agile is a looser process and very frequently misunderstood.

The OP is dealing with unreasonable people who have no understanding of software development.

So it is safer, easier to implement a strict process, hence why I recommended Waterfall.

Waterfall is a step-by-step process which is quite difficult to screw up. But it can be inflexible and have a long project time.

Regarding your posts:

Your language is consistently very baiting, and you're making me defend points I didn't make. Why are you doing this?

We're going around in circles here. You've made out in a few posts here how companies aren't doing Agile properly and the OP should be using Waterfall as it's stricter - as if that is a good thing or something.

Agile works on the basis of man days/hours, capacity, estimates etc. Once you draw the line of capacity and outline it to the business they are well capable of understanding that a change results in longer development time and cost. It's no different to building a house or extension and making alterations to the plan as you proceed. You don't need to be technical or business savvy to understand it.

I'm not trying to "bait" you, I just disagree completely with you and I'm entitled to counter the points you're making.

rizdub wrote: »

you have clearly explained in your first post itself... from my own long experience i can say its very true what you have described about the so called Agile process..

Ah yes, Waterfall is just magic stuff. The users always get what they actually want

John_Mc wrote: »

We're going around in circles here. You've made out in a few posts here how companies aren't doing Agile properly and the OP should be using Waterfall as it's stricter - as if that is a good thing or something.

Yes, Waterfall is good when working with people who want to keep making changes.

Why?

It forces them to properly think through what they want at the beginning of the project, not the end. And spec changes are generally frowned upon (or at least, spec changes are very visible to everyone).

The point I'm making over and over is that when you are dealing with people like the OP is dealing with - people who have no understanding of how their changes and incompetence screws up the project - it is far safer to revert to a strict process like Waterfall.

Also, Waterfall is easy to understand. I can explain it in 2 minutes.

But Agile is very often misunderstood, and is really easy to abuse.

I've also stated I have no issue with Agile when it is done properly. In my experience this always requires the team members to be experienced and mature. The OPs situation doesn't sound like a good fit.

You seem to be taking this really personally, so let me be clear that I am not saying you, as someone with Scrum training, is useless or should be unemployable.

Agile is not always the right fit. Nor is Waterfall. But there are times when Waterfall makes more sense (overall), and this sounds like one of them.

John_Mc wrote: »

By Agile I mean Scrum or Kanban. They are simple methodologies but you need to follow them properly. By that I mean to plan accordingly,get the backlog together, have the appropriate meetings (backlog grooming, sprint planning, retrospective etc), measure and record the metrics and feed them into planning etc.

I do agree that some companies use it as an excuse to not do proper requirements, which is why I qualified it with "properly".

Scrum is a framework and Kanban is a process control focused on delivery and the elimination of waste.

Agile is an umbrella term the takes into account different methods and frameworks... DSDM. RAD, lean, XP, Scrum, Kanban, Crystal etc, etc..which have been used way back to the 70's and Toyota have use Lean and JIT for many decades before that.

Usually companies implement Scrum badly, have stand-ups and use Jira therefore say they are 'agile' yet they have command and control project management to micromanage dev's. in 2 week 'sprints'. This is not agile yet it is what so many engineers experience as agile. Scrum alone is not 'agile'.... I could go on but won't..

At the end of the process what's important is what gets in the customer's hands, when and with high quality... Mostly this does not happen with WaterScrumFall, Wagile or Fragile

John_Mc wrote: »

I don't disagree with any of that

So you agree Agile is frequently implemented incorrectly, so when a company says "we use Agile" it could mean almost anything?

But you spent three pages disagreeing with that concept...

Franz Von Peppercorn wrote: »

Thanks!



Like communism it’s never been tried properly.



I’ve got all the certs.

It has some use but the idea that it fixes bad programming practice, or can magically make dysfunctional teams or companies be stellar performers is just nonsense.

Its popularity is because it’s a useful management tool. Daily status meetings, burndowns, what’s not to like.

Yes, very articulate straw man arguments... Whatever makes you happy

cinnamony wrote: »

Unfortunately I am still on probation
This is a worry of mine regarding leaving as I'm afraid it wouldn't look good to other companies when applying for jobs.

it's all about the interview approach and having a coherent explanation as why you want to move.
If you have limited experience and look to move to a supported team environment to expand your learning and have a proper career development path, while being on probation, should not be an issue to the right employer. Just explain that you have realised that you need the support of a team to grow and develop that you need experience in the people management side of project management. This is a learned skill and is usually the key to sucess or failure of user acceptance and manager satisfaction. These points are not critical of your current employer (a no-no in interviews) but you realising that while you can do the job at the moment, but to grow you need to be mentored which can't happen in your current job.
Think of it this way, can you post on here and get John_Mc and Jim Salter to concede their positions and agree to a mis-mash of both approaches as the only way forward and that each will loose but will ultimately gain? That's what you are up against and your current manager is not managing you as she should be aware of the specifics of the project and timelines and communicating this out to the other departments. She should not be emailing you claiming that the work you produced was not what was agreed. If you are producing the reports requested but not required this is a people problem, and your manager is the first problem you need to solve.

listermint wrote: »

....

The OP needs to use a ticketing system with set criteria, agreed timelines and weekly meetings, if a change is required new timelines are agreed and ALL parties are involved in the weekly meetings for progress updates.


Small steps.

My point in my 1st or 2nd post on the first page.

John_Mc wrote: »

Yes I agree it is not done properly in many companies. I have been saying that when done properly it is far better than Waterfall. Everyone is happier with the end product.

I also think it's no harder than Waterfall to follow and that's why I was disputing your suggestion that the op should go with Waterfall because it's stricter.

Go back and read the start of this thread - you were equating a requirements spec with waterfall when the very same thing exists with Scrum.

If Agile is often not done properly, what do you think are the chances of the OP doing it properly? Remember he is inexperienced and working in a mess of a company.

At least Waterfall is hard to screw up, and when there is a screw up it's quite visible. For example, "we need to change the feature". Everyone is aware the spec is now changing and the timeline will change. This is very visible in Waterfall because everyone clearly understands the process (it's a step by step process).

You admit Agile is often done incorrectly, so it's likely the OPs colleagues won't understand Agile as clearly as they will understand Waterfall.

I wasn't equating requirements with Waterfall. That was something you made up and I was forced to defend.

Are you a manager? I feel like you have an engineers perspective on this. I am looking at the big picture whereas you're focussing on a technicality.