|
No ownership. Doesn't appear you have anyone on the team that actually cares if the thing is done. Taking ownership usually means annoying someone (like going over their heads or around them). No honors at the end; even after you get it done.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
We retired. Corporate management has always looked down at software development. Those "marketing types" that fill most of the C-level seats think that product development is something that can be done to a time-line and on demand. Project managers buffered their development teams from the ridiculous "product windows" demands and temper tantrums of those morons. Then they started demanding that they control how we do our jobs as development strategies began to proliferate - continuous development, agile, etc. Do they pay for training? Hell, no. Project managers were just supposed to know how to implement these new strategies, teach it to our teams and implement each. Of course, halfway through a project, some C-level moron read about another new strategy and demanded its implementation. It got to the point where the pressures and hassles of the job just were not worth the pay. I quit and found a position in which I was the sole developer, but even there financial and regulatory pressures started to mount. I retired and became a rancher. I work harder and longer in all kinds of weather and continue to program as a hobby - I am much happier!!
__________________
Lord, grant me the serenity to accept that there are some things I just can’t keep up with, the determination to keep up with the things I must keep up with, and the wisdom to find a good RSS feed from someone who keeps up with what I’d like to, but just don’t have the damn bandwidth to handle right now.
© 2009, Rex Hammock
|
|
|
|
|
"We retired." Nailed it in 2 words.
Good PMs make it look easy and at the end of a successful program get little to no credit. Because there was no drama and the deadlines and budgets were met everyone (management AND the devs) assume that it was easy.
No one sees that the PM was the human shield protecting the developers from the bull-ship tornado swirling about them. And the management team is oblivious to the agony of a million decisions the development team has to make every day.
The good PM knows "who knows what" and connects the right people at the right times so that developers can get the right answers quickly without unnecessary meetings and distractions.
The good PM knows the business top to bottom, or is willing to learn, and has the experience (and scars) to anticipate the impending wreck and make small adjustments early to avoid them.
These folks get passed over for the Drama Queens that let the crap seep through in both directions and "Save the program", putting in heroic effort that could have been avoided.
You can only do this so long before you get tired and hang it all up.
|
|
|
|
|
Fortunately for me, our engineering management has been streamlined over the last few years. My current manager and his predecessor have both been great. They both view their role as managing priorities for us and expectations for those outside our organization. Neither one gets too involved in technical decisions, except in how they affect meeting those priorities.
This is good for me, as I've reached an age where my tolerance for corporate structure cow patties is minimal.
Software Zen: delete this;
|
|
|
|
|
Everyone seemed to think Agile and Scrum was the way to go and it would solve all problems.
I have the impression that this is fading a bit, so my guess is soon you'll start seeing more hybrid models.
There are good things about agile, but I feel the same thing can be said about other methodologies. You only need to do it right 
|
|
|
|
|
In terms of 2 1/2 hours talking to business owners, I know everybody does agile differently, but my interpretation is that having devs interacting with business users is central to agile processes.
From the 'Manifesto':
Quote: Individuals and interactions over processes and tools
Quote: Customer collaboration over contract negotiation
From the 'Principles':
Quote: Business people and developers must work together daily throughout the project
Quote: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation
My personal experience in development is that the worst problems come from a lack of understanding of requirements, and that the more you have people as conduits for requirements between the business and devs, the more likely misunderstandings will arise. So, as painful as 2 1/2 hours away from the lovely code may be, in my view it's time well spent.
That's not to say that I don't think PMs are useful; I just don't think they should be a buffer between devs and the business.
|
|
|
|
|
Carl_Sharman wrote: having devs interacting with business users is central to agile processes.
It's simply to let the product owner know that someone is working on their project.
The product owner generally only cares about deliverables, and they continually conflate sprints with deployments.
The whole agile/scrum process is a pain in your typical developer's ass.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
OK, if it's 2 1/2 hours to deliver a statement update, then you have my deepest sympathy 
|
|
|
|
|
I totally understand your point. But there are a lot of levels of bureaucracy here, and who can talk to whom.
In this one particular case I had already been working with some of the business users as to requirements, and had provided them with a proof of concept to play with and get feedback. But now, for the last two weeks I had been requesting a signoff on the POC so we could proceed with the final product. And this was the scrum master's responsibility. Just a simple Yes or No, and if no I would have worked further with the business users to revise the design.
For the last two weeks I would be asked at our virtual standup what the status was for this project. I would reply each time that I was awaiting signoff. The scrumaster said he would take care of this. Finally after two week of this he said he would set up a meeting. Of course he set up a demo of the app - despite the fact that the usershad all been playing with this for some time. And no word on getting a signoff. That is when I took over with this 2 1/2 hour meeti g to get this all done.
I don't mind working with the users, getting requirements, etc. I've been working as a contractor/consultant for 15+ years, and I understand the need to wear many hats. But now I am working as a contractor within a team and you expect everyone to do their part.
At least I got the job done, got the final signoff and was able to move this to forward. Still lots of testing to do, and a few functional tweaks.
|
|
|
|
|
Ah, understood. Sounds very frustrating. Many times I've been pressured to start the work, pressured to finish, then end up waiting months for sign off. 
I hear so many stories of agile and how it seems to often create more problems than it solves. I suspect that if you have good people, committed and motivated, they can make a success of things regardless of process.
|
|
|
|
|
I find that a lot of the people who are scrum masters for dev projects have absolutely zero technical expertise. Their only training is the flavour of agile that the company uses. As a result when I try to explain my status, and it requires some level of technical comprehension, they are totally unable to process what I have told them and determine what next steps should be.
Agile, I think, is grossly misunderstood. It was never intended to be this rigid process. Rather My understanding was that agile was more of a philosophy and a general way of looking at developing software. Every team is different, so every approach to agile was meant to be different, to fit the dynamics of the team.
But now we get these rigidly defined Agile processes, with very little understand of why we do these things. Where I work, they have adapted something called SAFE, and from what I can see it off loads a huge amount of form filling out on developers. For example for any single story in this current project, they have a template that generates pre-made tasks, about 15 or so of them. And we are supposed to shape our work around these tasks, for every story, regardless of what is actually being worked on. Does not sound very agile to me....
|
|
|
|
|
I couldn't agree more.
We need to start a revolution in software development, called... er... Flexible! Where we shake off the shakles of Agile and Waterfall! Then watch sadly as the principles get co-opted by consultants and degrade into a soul-sucking form filling exercise.
|
|
|
|
|
Andreas,
You have my sympathy here. The scrumaster should be there to help remove impediments. IMO Getting sign off on something is simple as sending those concerned an email and telling people to approve / reject. (with a reason) and pointing out that a lack of response will be treated as approval.
|
|
|
|
|
PM here. Are some of us useless? No doubt, you'll find that in every labor cat. I agree with the person who said a good PM clears blocks and runs interference. But even when that's what we attempt to do, there's never certainty that the client won't flex the "it's our money" muscle and shut us down. It happens frequently. Clients don't like to be told uncomfortable truths about complexity and delay, they just WANT IT NOW!
And as far as buffering devs from the business process and clients, ther is NO one size fits all to this. Some devs (most, I'd wager) are great at requirements gathering and client interaction. But some devs are cave-dwelling trogs that frighten and confuse the client to the point that they need a buffer. I 100% guarantee you know at least one.
My point is that the PM position, like yours, requires subtlety, statesmanship, broad knowledge of the domain, and a deep knowledge of the strengths and *weaknesses* of the dev team. Yes, I know that's a word that some devs don't acknowledge.
Many of us do try to not be useless.
|
|
|
|
|
I have also met one or two good PMs but lately they definitely seem few and far between especially where I work.
It is not an easy job and I admire those who do it well.
|
|
|
|
|
I've worked on projects with good PMs, bad PMs, and no PMs. A good PM is worth his/her weight in gold; a bad PM is worse than no PM.
I suspect that PMs for projects are viewed by upper management the way that secretaries for middle management used to be viewed. Just as middle managers are now expected to perform all of the tasks that used to be performed by their secretaries, so developers are now expected to perform the tasks that used to be performed by PMs.
I don't agree that the cases are analogous, but then I'm not in the C-suite. 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Lots of great feedback from everyone here. I do recognize that there does needto be some level of interaction between developers and the business users, and it does require a certain amount of diplomatic skill that sadly some Devs do not possess. As a consultant and contractor, I had to develop these skills for myself, as in a lot of cases I was business analyst, PM, QA, architect and sysops on top of being the developer. Literally a one-man band 😉.
I feel that upper management embraced agile (for whatever reasons) and figured that they could replace PM's with scrum masters, without recognizing that a good PM is more than just a process pusher. Perhaps it ties back to bad PM's in part, and looking for some way to improve things.
I look at all this, and wonder what will become of software development on the whole in the future. I feel that this needs to change again if we are to really improve how things are done.
|
|
|
|
|
dealing with a "newer" application from the evil empire. *cough* powerBI *cough*
Stupid memory hog and a half.
Ok it does do easy pretty well. It also does pretty fairly well.
But none of that is what annoys me. Right now the biggest annoyance is the stupid interface that doesn't accept hotkeys. Close the current BI worksheet/data you would think control F4 or perhaps Ctrl-W Nope. You have to close the entire application.
Also, Alt-F-S you would think that would save. Nope Alt DOES NOT EVEN WORK!
Why the heck?
MS spent years teaching everyone to use the Alt Key and the Control key and now they take them away.
Just annoying.
But back to the closing of the current workbook. So I have to close the entire application before I can open another workbook. Or I have to have two workbooks open at the same time before I can close another one. and since this is a huge memory hog. Wellllllllll.
1 out of 5 would not recommend.
To err is human to really elephant it up you need a computer
|
|
|
|
|
rnbergren wrote: But back to the closing of the current workbook.
But what are you meaning by closing the current workbook?, are you meaning the current tab in the report designer?
|
|
|
|
|
nope I mean closing whatever project I am currently working on. It would be the same as closing a project in Visual Studio or closing an Excel Workbook or closing a database in Access, or a presentation in powerpoint.
You simply cannot close the current document etc... without closing the entire application and there are no hotkeys to do anything. Everything is a mouse click.
To err is human to really elephant it up you need a computer
|
|
|
|
|
rnbergren wrote: You simply cannot close the current document etc... without closing the entire application
In Power BI, you are always going to work with one document (in this case the report) or the Workbook in Excel. This report can then have multiple tabs (called pages which you would call sheets in Excel).
You can not close individual pages the same way you can not close individual sheets in an Excel workbook.
|
|
|
|
|
did you read my response or my question? seriously did you actually take the time to read it?
I only want to work in one project/report/document at a time. I just want to be able to close the flipping report and leave PowerBI open so I can open the next one I want to work on. That is all.
Also, I simply want ALL freaking hotkeys to actually work. Alt-F(ile)-S(ave) should work dang nabbit.
Ctrl-F4 should close it.
Please read my question before replying. I would appreciate it.Thanks
To err is human to really elephant it up you need a computer
|
|
|
|
|
rnbergren wrote: I just want to be able to close the flipping report and leave PowerBI open so I can open the next one I want to work on.
Maybe yes am misinterpreting your questions but then again, in visual studio is it possible to close an open project and leave visual studio open?
|
|
|
|
|
Alt F T
To err is human to really elephant it up you need a computer
|
|
|
|
|
rnbergren wrote: Alt F T
Now I just learnt 1 more VS keyboard shortcut today. Probably there exists an equivalent one in Power BI.
modified 19-May-22 12:00pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
