Problems with management

cinnamony

I work in IT but the department that I work for is all non IT professionals including my manager.

Last week she asked me to automate some report and asked for a specific output. So I began working on it and after developing non stop I finally finished it and sent her the output. However she now wanted a different output so once again I changed that.

At the same time she emailed the different departments telling them I was almost done with the code and I kept getting emails asking if the code was ready to be deployed, when i looked at the output they were looking for the output they require is completely different and would take a really long time to build.

When I came in today I had an angry email from her and more emails from the other departments saying i was given enough time etc and that they clearly explained to me what they wanted but this simply isnt true.

I explained to them that I am building a program not an excel report and the amount of data is huge so it takes time and everytime they ask for a different output this just delays my job.

Theyre also constantly asking me to automate other reports and act as if it should be instant when it is not. Development takes time and Im also the only developer in the team, for example the other day they asked me to automate an entire report 30 mins before I left the office.

They also expect me to do overtime which is unpaid and i have a really long commute back home (2 hours)

As a result of this i keep getting into trouble but I'm doing the best I can with what I have.. I'm not a magician!

How csn I work this out with them?

OMM 0000

Force them to follow a waterfall software development process.

That means they write a spec (can be short) explaining what you need to implement.

When the spec is complete, you then start development.

You develop what is in the spec.

Therefore, when the project is complete, and they complain, you can point at the spec.

I have 20 years experience doing this. Believe me, the spec is your best friend.

No spec, no development.

You can explain it is their interest to write a spec because:

1. It helps them think through what they want, and get buy in from the other managers after they've reviewed it.
2. It clearly states what needs to be developed, so everyone is on the same page.
3. It will save time and money, as it is less likely you will need to spend time re-developing the product after it has been built (due to the original functionality not being thought through).

John_Mc

cinnamony wrote: »

I work in IT but the department that I work for is all non IT professionals including my manager.

Last week she asked me to automate some report and asked for a specific output. So I began working on it and after developing non stop I finally finished it and sent her the output. However she now wanted a different output so once again I changed that.

At the same time she emailed the different departments telling them I was almost done with the code and I kept getting emails asking if the code was ready to be deployed, when i looked at the output they were looking for the output they require is completely different and would take a really long time to build.

When I came in today I had an angry email from her and more emails from the other departments saying i was given enough time etc and that they clearly explained to me what they wanted but this simply isnt true.

I explained to them that I am building a program not an excel report and the amount of data is huge so it takes time and everytime they ask for a different output this just delays my job.

Theyre also constantly asking me to automate other reports and act as if it should be instant when it is not. Development takes time and Im also the only developer in the team, for example the other day they asked me to automate an entire report 30 mins before I left the office.

They also expect me to do overtime which is unpaid and i have a really long commute back home (2 hours)

As a result of this i keep getting into trouble but I'm doing the best I can with what I have.. I'm not a magician!

How csn I work this out with them?

If you're a developer, you should be working off a ticket which clearly outlines the requirements and acceptance criteria. This allows no room for ambiguity and allows it to be tested and verified once complete.

Was there such a ticket in place? If not, I'd be moving on as you're not working in a professional environment and will likely do more harm to your career by staying there.

There are no shortage of developer positions out there so you've no excuse in that respect. I'd definitely be finding somewhere closer to home too as that commute is not sustainable.

John_Mc

OMM 0000 wrote: »

Force them to follow a waterfall software development process.

That means they write a spec (can be short) explaining what you need to implement.

When the spec is complete, you then start development.

You develop what is in the spec.

Therefore, when the project is complete, and they complain, you can point at the spec.

I have 20 years experience doing this. Believe me, the spec is your best friend.

No spec, no development.

You don't need to be doing Waterfall to have a spec though. SDLC is archaic at this stage and not really realistic to business users, especially when there's no experienced BA driving the requirements gathering.

OMM 0000

John_Mc wrote: »

You don't need to be doing Waterfall to have a spec though. SDLC is archaic at this stage and not really realistic to business users, especially when there's no experienced BA driving the requirements gathering.

You need to use Waterfall when dealing with idiots. It's the only way to force them to think through what they want, and force them to follow a defined process, where they have a clear responsibility.

Agile means too many things these days. From no spec to make it up as we go along, and everything in between.

beauf

#1 Put in place a change request, requirements process that they'll never adhere to.

and/or

#2 Write a generic reporting system that allows them to select what they want in a report.

John_Mc

OMM 0000 wrote: »

You need to use Waterfall when dealing with idiots. It's the only way to force them to think through what they want.

No, you need to write a requirements spec. That does not automatically mean you need to use waterfall.

OMM 0000

John_Mc wrote: »

No, you need to write a requirements spec. That does not automatically mean you need to use waterfall.

Yes but we want them to have defined everything before development begins.

We don't want them changing their mind mid way through, or after development.

Waterfall forces this to happen.

I'm old and have been through this a million times. It is the safest solution when dealing with people who have no understanding of software development.

But I agree with your general point, obviously you don't need to follow Waterfall to write a spec.

cinnamony

Thanks all for the input.

The discussion to build this code actually took place 3 weeks before development began.
At the time I made it clear to management that I needed a clear and detailed written explanation of the output they required and what they expected it to do. As usual however, they left it to the last minute and by the time they bothered to come back to me with this the higher ups were asking for this report.

This morning I sent her an email detailing everything the code does and why it does what it does (ie because she asked), she also keeps referring to my task as creating a report when what Im actually doing is creating a PROGRAM that automates the report. Obviously very different.

OMM 0000

Do you use e-mail to protect yourself?

You need to make sure you are sending e-mails so there is a clear written chain of you pointing out there is no spec and the project is at risk.

Basically you are currently letting people blame you for their mistakes.

E-mail chains where you point out project risks are always your friend.

And always get stuff written down! No oral specs...

John_Mc

OMM 0000 wrote: »

Yes but we want them to have defined everything before development begins.

We don't want them changing their mind mid way through, or after development.

Waterfall forces this to happen.

I'm old and have been through this a million times. It is the safest solution when dealing with people who have no understanding of software development.

But I agree with your general point, obviously you don't need to follow Waterfall to write a spec.

The business is entitled to change their mind midway through development but there's a consequence to it. i.e longer development time and increased cost. Agile is about putting this firmly on the product owner representing the business. It's on them if that's what they need to do.

You clearly don't understand agile.

cinnamony wrote: »

Thanks all for the input.

The discussion to build this code actually took place 3 weeks before development began.
At the time I made it clear to management that I needed a clear and detailed written explanation of the output they required and what they expected it to do. As usual however, they left it to the last minute and by the time they bothered to come back to me with this the higher ups were asking for this report.

This morning I sent her an email detailing everything the code does and why it does what it does (ie because she asked), she also keeps referring to my task as creating a report when what Im actually doing is creating a PROGRAM that automates the report. Obviously very different.

I've emboldened the problem. Software is not built professionally on discussions. It's built according to defined and measurable criteria that are written in a specification.

My advice is to get out of there ASAP

OMM 0000

beauf wrote: »

#1 Put in place a change request, requirements process that they'll never adhere to.

So it then becomes their problem.

They are not following the process.

It is no longer your fault.

That's the real issue here. The OP is getting trouble for other people's incompetence. He needs to be smart (political) so their problems become their fault.

the_amazing_raisin

I think what would help here would be to focus on making one customer happy (your boss most likely) and get the report out in the way that she wants. Once you have that you've done the original job and changes after that are new features, which should help you break it down into smaller chunks and stop yourself from getting stressed

Also, which you perhaps don't need a full spec document, it can be very helpful to create a kind of mock-up of the output you're planning on generating. This is especially true for visual presentations, like what I think you're coding now. It doesn't have to be fancy, it can be done on a whiteboard, just make sure your customer understands what you think they want and has a chance to change it before you get too deep into coding.

Another bit of advice from a fellow developer, don't let people get too carried away with feature for the initial version. A lot of non-technical people are used to highly polished programs that have large teams and have been released and improved for years. They'll tend to pile on requests which ultimately are nothing more than polish.

Focus on the underlying program and giving them something that solves the problem, even if that means pushing back on some of the requests. It's very rare that a piece of software is released once in perfect condition and never touched again, there's a reason why there are constant updates to released software.

Final thought, the recession is over (supposedly) and the job market it booming, especially for developers. Every job has difficult times and frustrations, and there are reasons for staying that go beyond money (location, experience, flexibility, etc.). But if you feel truly unappreciated, then start looking at your options, you might find something more appealing

OMM 0000

John_Mc wrote: »

The business is entitled to change their mind midway through development but there's a consequence to it. i.e longer development time and increased cost. Agile is about putting this firmly on the product owner representing the business. It's on them if that's what they need to do.

Yes, that's fine, but the outcome is it is no longer OPs fault. That's the win here.

I'm not sure you're reading my posts...

John_Mc wrote: »

You clearly don't understand agile.

Eh? I was pointing Agile now means almost nothing. I know what REAL Agile is. I even had two weeks Agile training from one of the Agile creators.

The problem is people say they're doing Agile but what they really mean is "we have almost no process". If you were as experienced as me (20 years software development experience in 5 countries, currently work as a CTO) you'd know what I'm talking about.

Again the problem isn't proper Agile, done properly, the problem is how people don't understand what Agile is.

John_Mc

OMM 0000 wrote: »

Yes, that's fine, but the outcome is it is no longer OPs fault. That's the win here.

I'm not sure you're reading my posts...




Eh? I was pointing Agile now means almost nothing. I know what REAL Agile is. I even had two weeks Agile training from one of the Agile creators.

The problem is people say they're doing Agile but what they really mean is "we have almost no process". If you were as experienced as me (20 years software development experience in 5 countries, currently work as a CTO) you'd know what I'm talking about.

Again the problem is proper Agile, the problem is people's interpretation and use of Agile.

I'm a certified scrum master with 11 years as a professional developer.

I know the difference between waterfall and a requirements specification where as you don't. Says a lot about your 20 years experience if I'm honest.

Glass fused light

Is there a formal process of documenting the scope of each request or just an email chain or informal requesting process from each party?

From what you wrote there appears to be a communication gap. You need 2 things, regular face time with your manager to keep her updated and a project control method.
If its informal you need to go to your manager and agree a "quality control" scope document where the request is documented and a time scale is agreed with you providing your manager with updates on delays. The scope has to be signed off by all the responsible managers. If the scope of the output changes then it's a new project with new/revised timelines, which have to be communicated back to the involved parties.
And most important if your manager is blaming you for non-delivery your manager is signing off each new project and it's timeline before you start and signing off on delays before the other departments are notified.

The overtime will be the real issue for most, if you are travelling for 4hr to do a 8hr workday and in add conflict into the workplace you won't want to do more hours.
If the overtime is a organisational thing ie if the culture of the job is to stay late this will always cause conflict as people will blame you for delays. Claim the job could have been finished if only the automation happened yesterday or all your colleagues had to do extra time or rush the job today etc etc

The solution will require you to have people management skills as well as time management skills.

OMM 0000

John_Mc wrote: »

I'm a certified scrum master with 11 years as a professional developer.

I know the difference between waterfall and a requirements specification where as you don't. Says a lot about your 20 years experience if I'm honest.

I'm not going to argue with you online. I'm not sure what your goal is, apart from letting off steam.

We both agree there needs to be a spec.

I prefer a stricter process, you prefer a looser process.

Obviously I think they should be able to change the spec in the future, but there needs to be clear communication on how that will affect the project timeline. The emphasis should always be to minimise spec changes.

But from what the OP has said, I think letting them change the spec is risky, as it seems like they're unreasonable and have no idea what they're doing.

Basically the OP needs to get political and implement a process where he can't be blamed for other people's lack of understanding/organisation.

John_Mc

OMM 0000 wrote: »

I'm not going to argue with you online. I'm not sure what your goal is, apart from letting off steam.

We both agree there needs to be a spec.

I prefer a stricter process, you prefer a looser process.

Obviously I think they should be able to change the spec in the future, but there needs to be clear communication on how that will affect the project timeline. The emphasis should always be to minimise spec changes.

Basically the OP needs to get political and implement a process where he can't be blamed for other people's lack of understanding/organisation.

We both agree like others that there needs to be a written and signed off specification and then control and governance over changes to it.

I was merely pointing out that you don't need to go with Waterfall to achieve that.

OMM 0000

John_Mc wrote: »

I was merely pointing out that you don't need to go with Waterfall to achieve that.

Obviously...

Waterfall isn't about writing the spec. It's about forcing them to think through the spec before any development work begins.

If the OP allows a loose process, you just know these idiots will do a half assed job and change it a million times later.

I've seen this so many times. I am absolutely fine with using Agile if I am working with an experienced, responsible team.

John_Mc

OMM 0000 wrote: »

Obviously...

Waterfall isn't about writing the spec. It's about forcing them to think through the spec before any development work begins.

If the OP allows a loose process, you just know these idiots will do a half assed job and change it a million times later.

I've seen this so many times. I am absolutely fine with using Agile if I am working with an experienced, responsible team.

You seem to be suggesting that Agile is a "loose process". It's flexible to changing requirements, which is inevitable no matter how much you think about requirements, but it is controlled.

You need to think about things just as much with Agile as you do with SDLC. A backlog needs to be created, prioritised, estimated, developed etc.

Clearly the OPs manager hasn't a clue what they want and is flip flopping on requirements. You seem to think that Waterfall is the appropriate methodology in this case - give them something they asked for when it's completely finished, rather than incrementally as it is developed to get feedback.

I'll say it again - I think you're wrong and a bit ignorant about how Agile works and leave it at that.

OMM 0000

John_Mc wrote: »

You seem to be suggesting that Agile is a "loose process". It's flexible to changing requirements, which is inevitable no matter how much you think about requirements, but it is controlled.

You need to think about things just as much with Agile as you do with SDLC. A backlog needs to be created, prioritised, estimated, developed etc.

Clearly the OPs manager hasn't a clue what they want and is flip flopping on requirements. You seem to think that Waterfall is the appropriate methodology in this case - give them something they asked for when it's completely finished, rather than incrementally as it is developed to get feedback.

I'll say it again - I think you're wrong and a bit ignorant about how Agile works and leave it at that.

Have you read what I previously wrote?

I am saying REAL Agile is fine. However many companies claim they follow an Agile approach but really they don't. They just pretend it is Agile. There are many reasons for this. One of them is Agile is much looser than Waterfall. I think you can agree with this, as it is one of the main reasons Agile was created.

So I am not saying Agile is make up whatever you want. I am saying, in practice, a lot of companies do it wrong.

So my comments here are all within the context of the OPs problem.

We already know they are incompetent and blaming him for their incompetence. Generally, when dealing with incompetent people, you need a strict process. Hence why I recommend Waterfall, or at least a semi-Waterfall process.

Anyway, the OP can decide what's right for him.

cinnamony

Thanks everyone, very detailed information here which I appreciate.

I do have a written scope as well as email communication.

Here's what I did:

On initial discussion I request we sit down and draw up a list requirements for the code (in writting)

During the programming phase I sent my manager updates and sample output so she has a clear picture of what the code is doing.

After finishing the basic code she requested further features so I added these in.

I took the same approach here as before and frequently updated her as before.

All communication (ie updates etc) was done through email and demonstrations.

At some point during this I receive the emails from the other departments asking if this was ready to be deployed as my manager had told them it was almost complete.

I finish adding in the new features then receive the output from the other departments which is totally different from what I was requested.

My manager ONCE AGAIN asks for new output, once again this was done at the last minute and I let her know I need more notice in the future and that Id have to leave it till the next day.

The next day I finish implementing these new features and send her the output for verification.

I come into the office this morning and theres angry email from her, other departments asking if this is done, higher ups saying they need this info etc...

The reason why I dont want to move job is because I'm inexperienced and dont know a lot of programming languages (my background is in data science). Also due to the considerable commute I dont have time to do projects outside of work like github etc..

Despite my lack of experience I do believe I took the right steps in this process, however the people that I am working with seem to have no idea whatsoever of how much work development requires, that said I do admit I could have been more thorough.

OMM 0000

Was there an agreed to deadline?

Was the deadline based on reality or something your supervisor made up?

cinnamony

OMM 0000 wrote: »

Was there an agreed to deadline?

Was the deadline based on reality or something your supervisor made up?

When she initialy asked for the program I told her it could take up to two weeks, however I finished it in a week.

The output the department requires would take possible a month maybe more because my compamy outsourced their own database so we need to pay whenever we request data and it could also take weeks because the people they outsourced it to are terrible with communication and often ignore us. However they expected it to be done by now when I only just found out about it..

OMM 0000

cinnamony wrote: »

When she initialy asked for the program I told her it could take up to two weeks, however I finished it in a week.

The output the department requires would take possible a month maybe more because my compamy outsourced their own database so we need to pay whenever we request data and it could also take weeks because the people they outsourced it to are terrible with communication and often ignore us

OK. So they requested changes which would take a long time.

Did you tell them the changes would take a long time?

Did they understand that meant it can't be ready tomorrow? i.e. did they reply acknowledging your e-mail saying it will take an extra X amount of time?

jim salter

OMM 0000 wrote: »

You need to use Waterfall when dealing with idiots. It's the only way to force them to think through what they want, and force them to follow a defined process, where they have a clear responsibility.

Agile means too many things these days. From no spec to make it up as we go along, and everything in between.

Royce described "waterfall" as the way not to develop software describing incremental and iterative of at least 2 cycles the most effective way to develop (software)

Saying 'agile' "means too many things these days" exhibit a complete lack of understanding of the practises and principles.

OP: when you receive a request to automate report(s) it would be best if you requested the requirement to be clearly articulated, with acceptance criteria which clearly state the conditions of satisfaction for the competed piece of work. Without these basic things you can never be sure what your creating is what's actually wanted and when it's done. The acceptance criteria *should* eliminate 'scope creep'. Further to this frequent feedback loops (direct conversations around what your doing) with the requestor *should* ensure your are developing to what is needed and the requestor will (well, should) be aware of where you are in the process.

OMM 0000

jim salter wrote: »

Saying 'agile' "means too many things these days" exhibit a complete lack of understanding of the practises and principles.

Yes, I agree, and as I've said a million times the problem is many companies define Agile to mean whatever they want. I am not saying that is my definition. I specialised for a few years going into companies who claim they have an Agile process, pointing out they actually have little to no process, and then I would fix their process.

So when a company says "we have an Agile process", that could literally mean anything. It almost means nothing. You only know the reality when you've seen their process. It is quite possible you will be like "eh, this isn't Agile".

How many times am I going to have to explain this.

John_Mc

OMM 0000 wrote: »

Yes, I agree, and as I've said a million times the problem is many companies define Agile to mean whatever they want. I am not saying that is my definition. I specialised for a few years going into companies who claim they have an Agile process, pointing out they actually have little to no process, and then I would fix their process.

So when a company says "we have an Agile process", that could literally mean anything. It almost means nothing. You only know the reality when you've seen their process. It is quite possible you will be like "eh, this isn't Agile".

How many times am I going to have to explain this.

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.

OMM 0000

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.

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?

rizdub

OMM 0000 wrote: »

Yes, I agree, and as I've said a million times the problem is many companies define Agile to mean whatever they want. I am not saying that is my definition. I specialised for a few years going into companies who claim they have an Agile process, pointing out they actually have little to no process, and then I would fix their process.

So when a company says "we have an Agile process", that could literally mean anything. It almost means nothing. You only know the reality when you've seen their process. It is quite possible you will be like "eh, this isn't Agile".

How many times am I going to have to explain this.

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..

rizdub

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.

Looks like you don't like Waterfall or have not used it for long..

jim salter

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"?

jim salter

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..

Agile is not a process

Franz Von Peppercorn

jim salter wrote: »

Royce described "waterfall" as the way not to develop software describing incremental and iterative of at least 2 cycles the most effective way to develop (software)

Saying 'agile' "means too many things these days" exhibit a complete lack of understanding of the practises and principles.

OP: when you receive a request to automate report(s) it would be best if you requested the requirement to be clearly articulated, with acceptance criteria which clearly state the conditions of satisfaction for the competed piece of work. Without these basic things you can never be sure what your creating is what's actually wanted and when it's done. The acceptance criteria *should* eliminate 'scope creep'. Further to this frequent feedback loops (direct conversations around what your doing) with the requestor *should* ensure your are developing to what is needed and the requestor will (well, should) be aware of where you are in the process.

Agile is snake oil. However it’s useful for management and better than the situation the op is in.

All he needs is some kind of tracking system and proper estimations and change requests.

He also needs to leave that company.

jim salter

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?

In my opinion it is not the methodology/framework/mechanism that is the problem here, it is unreasonable people with no appreciation for the work that the OP is doing.

Regardless of how the OP decides to deliver the work the problem is always going to be the people.

OMM 0000

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...

jim salter

Franz Von Peppercorn wrote: »

Agile is snake oil. However it’s useful for management and better than the situation the op is in.

All he needs is some kind of tracking system and proper estimations and change requests.

He also needs to leave that company.

Great Post very articulate.

Agile is not snake oil, it is fixed mindset traditional management that has bastardized agile practises and principles.

Let's not forget it was 17 of the world's leading computer scientist in software, who were practising their methods long before 2001, that came together to create the Manifesto for Agile Software development.

People with a little knowledge about this seem to believe they know a lot.

John_Mc

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

jim salter wrote: »

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

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".

OMM 0000

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.

cinnamony

OMM 0000 wrote: »

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...

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.

jim salter

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

jim salter wrote: »

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

I don't disagree with any of that

OMM 0000

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

jim salter wrote: »

Great Post very articulate.

Thanks!

Agile is not snake oil, it is fixed mindset traditional management that has bastardized agile practises and principles.

Like communism it’s never been tried properly.

Let's not forget it was 17 of the world's leading computer scientist in software, who were practising their methods long before 2001, that came together to create the Manifesto for Agile Software development.

People with a little knowledge about this seem to believe they know a lot.

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.

jim salter

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

jim salter

Franz Von Peppercorn wrote: »

...

I’ve got all the certs.....

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

Like I said before...people with a little knowledge that think they know more than they actually do..

pleas advice

Don't go chasing waterfalls...

John_Mc

OMM 0000 wrote: »

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...

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.

Glass fused light

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

Can i just ask,

What in the jaysus is the willy waving about waterfall versus agile frameworks doing to assist the OP in his predicament.

He is not going to get the entire company to roll our either process in this space of time.

small steps baby direction.

So enough of the nonsense lads its adding nothing to the discussion.

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.