Problems with management

cinnamony · 26-07-2018 10:28AM #1

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 · 26-07-2018 10:32AM

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 · 26-07-2018 10:33AM

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 · 26-07-2018 10:34AM

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 · 26-07-2018 10:37AM

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 · 26-07-2018 10:37AM

#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 · 26-07-2018 10:38AM

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 · 26-07-2018 10:41AM

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 · 26-07-2018 10:44AM

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 · 26-07-2018 10:47AM

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 · 26-07-2018 10:49AM

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 · 26-07-2018 10:52AM

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 · 26-07-2018 10:56AM

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 · 26-07-2018 10:57AM

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 · 26-07-2018 11:00AM

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 · 26-07-2018 11:01AM

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 · 26-07-2018 11:04AM

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 · 26-07-2018 11:07AM

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 · 26-07-2018 11:09AM

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 · 26-07-2018 11:15AM

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 · 26-07-2018 11:20AM

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 · 26-07-2018 11:26AM

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 · 26-07-2018 11:28AM

Was there an agreed to deadline?

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

cinnamony · 26-07-2018 11:35AM

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 · 26-07-2018 11:39AM

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 · 26-07-2018 11:54AM

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 · 26-07-2018 12:01PM

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 · 26-07-2018 12:06PM

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 · 26-07-2018 12:14PM

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 · 26-07-2018 12:22PM

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 · 26-07-2018 12:26PM

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

Problems with management

Comments