Where have the Project Managers gone?
-
I am aware that scrum masters and PM's are different roles. And their are no "Product Owners" just the business owners and they do not interact directly with the dev teams. It is a big government installation, so I do expect a lot less from them. But the disappearance a proper PM (and dev managers too for that matter) is a disturbing trend.
-
It used to be that in a dev team you would have a project manager. If you had a good PM, he would handle all the process issues, interact with business users, manage requirements, etc. Basically get all the development roadblocks out of the way so that the developers in the team could work unimpeded or delayed waiting on other groups. Now we have scrum masters, whose only concern seems to be that I's are dotted and T's crossed with respect to stories and tasks, but then offload all of the PM work on the developers. I just spent 2 1/2 hours talking to business owners for an app that needed upgrading, just to get concensus on a design change. I have asking the scrum master for the last two weeks to see that this gets done. His latest response was to call a meeting with everyone involved to do a "demo" - even though everyone has already seen the updated app and have been playing with it. We just needed a go/no go on the design. And of course there was no agenda, no explicit purpose stated for this meeting and what needed to be achieved. Are PMs extinct now that the work has gone "agile"? Is no one responsible now to get this administrative work out of the developers way?
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; -
It used to be that in a dev team you would have a project manager. If you had a good PM, he would handle all the process issues, interact with business users, manage requirements, etc. Basically get all the development roadblocks out of the way so that the developers in the team could work unimpeded or delayed waiting on other groups. Now we have scrum masters, whose only concern seems to be that I's are dotted and T's crossed with respect to stories and tasks, but then offload all of the PM work on the developers. I just spent 2 1/2 hours talking to business owners for an app that needed upgrading, just to get concensus on a design change. I have asking the scrum master for the last two weeks to see that this gets done. His latest response was to call a meeting with everyone involved to do a "demo" - even though everyone has already seen the updated app and have been playing with it. We just needed a go/no go on the design. And of course there was no agenda, no explicit purpose stated for this meeting and what needed to be achieved. Are PMs extinct now that the work has gone "agile"? Is no one responsible now to get this administrative work out of the developers way?
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 :laugh:
V.
-
I am aware that scrum masters and PM's are different roles. And their are no "Product Owners" just the business owners and they do not interact directly with the dev teams. It is a big government installation, so I do expect a lot less from them. But the disappearance a proper PM (and dev managers too for that matter) is a disturbing trend.
If there are no Product Owners you are not doing 'Agile' right...?
-
It used to be that in a dev team you would have a project manager. If you had a good PM, he would handle all the process issues, interact with business users, manage requirements, etc. Basically get all the development roadblocks out of the way so that the developers in the team could work unimpeded or delayed waiting on other groups. Now we have scrum masters, whose only concern seems to be that I's are dotted and T's crossed with respect to stories and tasks, but then offload all of the PM work on the developers. I just spent 2 1/2 hours talking to business owners for an app that needed upgrading, just to get concensus on a design change. I have asking the scrum master for the last two weeks to see that this gets done. His latest response was to call a meeting with everyone involved to do a "demo" - even though everyone has already seen the updated app and have been playing with it. We just needed a go/no go on the design. And of course there was no agenda, no explicit purpose stated for this meeting and what needed to be achieved. Are PMs extinct now that the work has gone "agile"? Is no one responsible now to get this administrative work out of the developers way?
My opinion is that scrum masters are completely unnecessary. While they may be decent people, the role seems to be one where they constantly refuse to define what their role is and refuse to get involved in anything technical - their only role seemingly to be to help "facilitate" communication. Agile seems to have become a bit of a tangled, overly complex cult-like mess in the past few years. I have worked with some excellent project managers in the past and my experience is that a decent project manager is worth more than their weight in gold.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
It used to be that in a dev team you would have a project manager. If you had a good PM, he would handle all the process issues, interact with business users, manage requirements, etc. Basically get all the development roadblocks out of the way so that the developers in the team could work unimpeded or delayed waiting on other groups. Now we have scrum masters, whose only concern seems to be that I's are dotted and T's crossed with respect to stories and tasks, but then offload all of the PM work on the developers. I just spent 2 1/2 hours talking to business owners for an app that needed upgrading, just to get concensus on a design change. I have asking the scrum master for the last two weeks to see that this gets done. His latest response was to call a meeting with everyone involved to do a "demo" - even though everyone has already seen the updated app and have been playing with it. We just needed a go/no go on the design. And of course there was no agenda, no explicit purpose stated for this meeting and what needed to be achieved. Are PMs extinct now that the work has gone "agile"? Is no one responsible now to get this administrative work out of the developers way?
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.
-
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 -
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, 2013OK, if it's 2 1/2 hours to deliver a statement update, then you have my deepest sympathy :^)
-
"If you had a good PM..." That's key - I've had way too many worthless PM's -- former programmers who were not good at programming, so took the PM classes to stay employed. Just called meetings recurring weekly and did nothing else. Had very little clue as to what the project needed to accomplish. In my view it's the person, not their job title.
"I've had way too many worthless PM's -- former programmers who were not good at programming, so took the PM classes to stay employed. Just called meetings recurring weekly and did nothing else" Same here. They are more than useless, and they make significant more money. They stop work for meetings several times a day. When you stop 6 Developers from working that's a ton of lost man hours. I have never seen any value in the PM position. Essentially, if they are not conducting a meeting, they have very little else to do. My best jobs have been the ones that had no PM. Keep It Simple, keep it moving.
-
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.
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.
-
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. :sigh: 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.
-
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. :sigh: 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 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.
-
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.
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.
-
It used to be that in a dev team you would have a project manager. If you had a good PM, he would handle all the process issues, interact with business users, manage requirements, etc. Basically get all the development roadblocks out of the way so that the developers in the team could work unimpeded or delayed waiting on other groups. Now we have scrum masters, whose only concern seems to be that I's are dotted and T's crossed with respect to stories and tasks, but then offload all of the PM work on the developers. I just spent 2 1/2 hours talking to business owners for an app that needed upgrading, just to get concensus on a design change. I have asking the scrum master for the last two weeks to see that this gets done. His latest response was to call a meeting with everyone involved to do a "demo" - even though everyone has already seen the updated app and have been playing with it. We just needed a go/no go on the design. And of course there was no agenda, no explicit purpose stated for this meeting and what needed to be achieved. Are PMs extinct now that the work has gone "agile"? Is no one responsible now to get this administrative work out of the developers way?
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.
-
It used to be that in a dev team you would have a project manager. If you had a good PM, he would handle all the process issues, interact with business users, manage requirements, etc. Basically get all the development roadblocks out of the way so that the developers in the team could work unimpeded or delayed waiting on other groups. Now we have scrum masters, whose only concern seems to be that I's are dotted and T's crossed with respect to stories and tasks, but then offload all of the PM work on the developers. I just spent 2 1/2 hours talking to business owners for an app that needed upgrading, just to get concensus on a design change. I have asking the scrum master for the last two weeks to see that this gets done. His latest response was to call a meeting with everyone involved to do a "demo" - even though everyone has already seen the updated app and have been playing with it. We just needed a go/no go on the design. And of course there was no agenda, no explicit purpose stated for this meeting and what needed to be achieved. Are PMs extinct now that the work has gone "agile"? Is no one responsible now to get this administrative work out of the developers way?
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.
-
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.
-
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.
-
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.