You are managing a software development project, and one of the developers tells you that he added a new feature that he heard the sponsor talking about in a hallway conversation. The developer compl
You are managing a software development project, and one of the developers tells you that he added a new feature that he heard the sponsor talking about in a hallway conversation. The developer completed the work after hours, and it does add a lot of value to the solution. How should you manage this?
A. Thank the developer for his hard work and communicate this as a win in your next status report.
B. Document this as a change request and follow the Change Control process to ensure it is documented and approved.
C. As there were no costs incurred from the work and no schedule impact, you do not need to do anything.
D. Ask the developer not to implement the change as it was not approved, and explain that any scope changes must be reviewed and approved before implementation. Saving Changes...
Al TaylorI.T. Contractor| IndependentWaterloo, Ontario, Canada
I agree with Kiron and Sergio. Perhaps also a smack to the side of the head would be useful. Many years I was bullied into making an authorized change by a lead stakeholder and I got raked over the coals by my manager. Saving Changes...
the question didn't mention a PO. In any event, if the team is following a framework like Scrum, the backlog is expected to be the source of "truth" as far as what the team works on. Unless this item made its way to the backlog and had been appropriately prioritized by the PO, the developer should not have jumped on it.
Adrian - I'd agree that at this point the horse has left the barn so assessing the impact of this addition and making the sponsor aware of the total impacts would be needed. That would normally be done through project change control.
Kiron
Hi Kiron,
The question doesn't mention any business owner but someone should be responsible for decisions on business requirements and priorities. In Scrum that person is the PO.
In Scrum the team works on the sprint backlog which is defined by the development team and they are free to add to it during a sprint. The PO does not control the sprint backlog. However, as I mentioned, teams are often encouraged to add items to the PB as well. As you say, the PO should decide on the PB priorities and that would the most appropriate way to consider proposals for new items for a future sprint. Saving Changes...
George FreemanThought Leader | Author | Architect| Florida, United States
I believe that It’s safe to say that we all want our developers to provide the highest value possible on any given work-area within the “scheduled constraints.” In my experience, such outputs occur when developers feel vested in their efforts; that is, they believe they have something “long term” to gain by putting in “extra effort” to deliver something above par.
Fostering an environment where developers have this vesting, can (if appropriately managed) greatly benefit all parties. The opposite of this vesting provides results that often extend the project, as the end-state quality falls short of expectations, creating sign-off contention.
Each project is unique, and the environment may have NO tolerance for such activities. However, if there is tolerance, then the resource may simply need encouragement to disclose these “extra no-cost, no-penalty efforts,” so contingencies can be arranged. Stated differently, if you have a resource that puts in extra efforts to deliver quality, then I would be cautious about playing the “whack-a-developer” game, as you may stunt creativity and energy that you may desperately need later in your project.
...
2 replies by Kiron Bondale and VIJAY KUMAR
Mar 27, 2020 4:13 PM
Kiron Bondale
...
George -
no one is trying to stifle creativity or good ideas, but there should be "some" discipline around their introduction. Very rarely can one person add a feature to a product without the need to engage with others - if they have done so appropriately, great, but the way the question is worded, it sounded very much like they acted in a solo manner.
I've had to suffer through many projects where someone's good idea turned into a nightmare for upstream or downstream stakeholders which is why regardless of the requirements management approach and delivery life cycle, engaging the "right" stakeholders to contribute to requirements is essential.
This is also one of the rationales behind the "N" in the famous INVEST acronym for user stories - it takes a village...
I believe that It’s safe to say that we all want our developers to provide the highest value possible on any given work-area within the “scheduled constraints.” In my experience, such outputs occur when developers feel vested in their efforts; that is, they believe they have something “long term” to gain by putting in “extra effort” to deliver something above par.
Fostering an environment where developers have this vesting, can (if appropriately managed) greatly benefit all parties. The opposite of this vesting provides results that often extend the project, as the end-state quality falls short of expectations, creating sign-off contention.
Each project is unique, and the environment may have NO tolerance for such activities. However, if there is tolerance, then the resource may simply need encouragement to disclose these “extra no-cost, no-penalty efforts,” so contingencies can be arranged. Stated differently, if you have a resource that puts in extra efforts to deliver quality, then I would be cautious about playing the “whack-a-developer” game, as you may stunt creativity and energy that you may desperately need later in your project.
George -
no one is trying to stifle creativity or good ideas, but there should be "some" discipline around their introduction. Very rarely can one person add a feature to a product without the need to engage with others - if they have done so appropriately, great, but the way the question is worded, it sounded very much like they acted in a solo manner.
I've had to suffer through many projects where someone's good idea turned into a nightmare for upstream or downstream stakeholders which is why regardless of the requirements management approach and delivery life cycle, engaging the "right" stakeholders to contribute to requirements is essential.
This is also one of the rationales behind the "N" in the famous INVEST acronym for user stories - it takes a village...
Kiron
...
1 reply by George Freeman
Mar 27, 2020 5:28 PM
George Freeman
...
Hi Kiron,
I agree with your statement that there should be “some discipline around their introduction,” which goes along with my statement that they should be encouraged to disclose their desire so that proper considerations can be made.
The definition of “new feature” is also a variable in this. I would not condone an extra-effort that provided something outside of the vision and boundaries of the requirements. However, sometimes new features can be translated as “alternate or improved mechanics to satisfy a requirement,” among other translations.
The degree of empowerment (e.g., vision realization) given to the project manager is also a consideration in all of this, as well as whether this is being done in-house or outsourced. Good points made Kiron, thank you.
Saving Changes...
George FreemanThought Leader | Author | Architect| Florida, United States
Mar 27, 2020 4:13 PM
Replying to Kiron Bondale
...
George -
no one is trying to stifle creativity or good ideas, but there should be "some" discipline around their introduction. Very rarely can one person add a feature to a product without the need to engage with others - if they have done so appropriately, great, but the way the question is worded, it sounded very much like they acted in a solo manner.
I've had to suffer through many projects where someone's good idea turned into a nightmare for upstream or downstream stakeholders which is why regardless of the requirements management approach and delivery life cycle, engaging the "right" stakeholders to contribute to requirements is essential.
This is also one of the rationales behind the "N" in the famous INVEST acronym for user stories - it takes a village...
Kiron
Hi Kiron,
I agree with your statement that there should be “some discipline around their introduction,” which goes along with my statement that they should be encouraged to disclose their desire so that proper considerations can be made.
The definition of “new feature” is also a variable in this. I would not condone an extra-effort that provided something outside of the vision and boundaries of the requirements. However, sometimes new features can be translated as “alternate or improved mechanics to satisfy a requirement,” among other translations.
The degree of empowerment (e.g., vision realization) given to the project manager is also a consideration in all of this, as well as whether this is being done in-house or outsourced. Good points made Kiron, thank you. Saving Changes...
Another important aspect is who that developer is.
I have once met a developer, well actually he was more a technical architect, that had worked for a company for over 20 years. Technically he was a contractor having his own company but he had offered services to the same company for more than 20 years.
Working for so long both on support and on smaller and larger projects that developer had a huge knowledge about the business and he knew very well what the business needs. In my opinion he was more valuable for his business domain knowledge than for his IT technical skills. This mixture made him a key resource for that company.
Having all that knowledge he was able to decide by himself what needs to be developed many times even better than the actual business users. He was dealing directly with the business managers/users and he was deciding with them what needs to be delivered.
As a PM working with such a guy would make you feel completely powerless as whatever he wants to do the business would almost always agree. Your role or job title many times doesn't say much it is your actual knowledge that really gives you power to make decisions or influence the decision making process.
If someone has most of the answers and solutions to your problem you should let him solve the problems and not stop him with all kind of processes.
...
1 reply by Kiron Bondale
Mar 28, 2020 9:52 AM
Kiron Bondale
...
Adrian -
I don't refute that such cases do exist, especially where you have a developer who has been in many different roles and been focused on the same product for many releases/years.
However, I'd argue this is the exception, not the rule, and in almost all mid to large-sized companies there are control partners/gatekeepers who need to be engaged appropriately before changes get made to ensure considerations such as performance, security, privacy and so on are attended to.
I'd agree that we don't want to cripple innovation by unnecessary process, but there's a good reason that one of Disciplined Agile's principles is "Enterprise Awareness" which means we align with our enterprise's standards and policies.
Kiron
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Is not a matter of project management. Is a matter of system stability, where system is not software system. If you like to put this in the project management framework you can put it inside quality domain. If we agree that a developer can make what it wants we are lost. Where is the impact analysis here? Impact analysis mean to have the whole vision and how to add something will impact things in other places inside the architecture. People that works in software have experienced the situation that because a developer like to be "innovative" or "creative" or "client oriented" modifiy a piece of code into an application, test it locally, and create a disaster in the whole system because system is not software system only. Agree on behaivors like this have contributed to the software chaos from decades. With that said, there are situations that must be included into maintenance procedures where a developer must to act as a fire-fither then can touch the code but the developer knows the procedure to face this situations and restore things to maintain system stability after that. Obviously, at the end, is up to each one strategy. But it is no reason to justify this type of situations. Saving Changes...
Another important aspect is who that developer is.
I have once met a developer, well actually he was more a technical architect, that had worked for a company for over 20 years. Technically he was a contractor having his own company but he had offered services to the same company for more than 20 years.
Working for so long both on support and on smaller and larger projects that developer had a huge knowledge about the business and he knew very well what the business needs. In my opinion he was more valuable for his business domain knowledge than for his IT technical skills. This mixture made him a key resource for that company.
Having all that knowledge he was able to decide by himself what needs to be developed many times even better than the actual business users. He was dealing directly with the business managers/users and he was deciding with them what needs to be delivered.
As a PM working with such a guy would make you feel completely powerless as whatever he wants to do the business would almost always agree. Your role or job title many times doesn't say much it is your actual knowledge that really gives you power to make decisions or influence the decision making process.
If someone has most of the answers and solutions to your problem you should let him solve the problems and not stop him with all kind of processes.
Adrian -
I don't refute that such cases do exist, especially where you have a developer who has been in many different roles and been focused on the same product for many releases/years.
However, I'd argue this is the exception, not the rule, and in almost all mid to large-sized companies there are control partners/gatekeepers who need to be engaged appropriately before changes get made to ensure considerations such as performance, security, privacy and so on are attended to.
I'd agree that we don't want to cripple innovation by unnecessary process, but there's a good reason that one of Disciplined Agile's principles is "Enterprise Awareness" which means we align with our enterprise's standards and policies.
Kiron
...
1 reply by Adrian Carlogea
Mar 28, 2020 11:48 AM
Adrian Carlogea
...
Hi Kiron,
I am not saying that a developer that has a good solution to a problem should jump straight away to the production environment and deploy it immediately, this would obviously create chaos. :)
All I am saying is that developers that have good business domain knowledge and who are working directly with the business users/sponsors should be able to implement their solutions without having to seek approval from middlemen such as business analysts, product owners or project managers.
If the developers solutions are agreed by the business but require financial and plan changes then PMs and others should make those arrangements in order for the solution to be implemented. PMs, Scrum Masters, Product Owners, etc should not stop such developers by invoking process breaches.
Also the change management process should be followed and the solution should be tested before deployment.
Some years ago I worked for an Australian utilities company as a developer offering both support and developing enhancement to a software product. The work was done as part of operations and I was working directly with the users and developed whatever enhancement they requested. In order to deploy into production I did have to follows a strict change management process that did include going to a Change Advisory Board.
I don't refute that such cases do exist, especially where you have a developer who has been in many different roles and been focused on the same product for many releases/years.
However, I'd argue this is the exception, not the rule, and in almost all mid to large-sized companies there are control partners/gatekeepers who need to be engaged appropriately before changes get made to ensure considerations such as performance, security, privacy and so on are attended to.
I'd agree that we don't want to cripple innovation by unnecessary process, but there's a good reason that one of Disciplined Agile's principles is "Enterprise Awareness" which means we align with our enterprise's standards and policies.
Kiron
Hi Kiron,
I am not saying that a developer that has a good solution to a problem should jump straight away to the production environment and deploy it immediately, this would obviously create chaos. :)
All I am saying is that developers that have good business domain knowledge and who are working directly with the business users/sponsors should be able to implement their solutions without having to seek approval from middlemen such as business analysts, product owners or project managers.
If the developers solutions are agreed by the business but require financial and plan changes then PMs and others should make those arrangements in order for the solution to be implemented. PMs, Scrum Masters, Product Owners, etc should not stop such developers by invoking process breaches.
Also the change management process should be followed and the solution should be tested before deployment.
Some years ago I worked for an Australian utilities company as a developer offering both support and developing enhancement to a software product. The work was done as part of operations and I was working directly with the users and developed whatever enhancement they requested. In order to deploy into production I did have to follows a strict change management process that did include going to a Change Advisory Board. Saving Changes...
If possible, D would be my choice as we don't want to purposely create baseline variances and the developer may be unaware of upstream or downstream negative implications of this change. By going through change control we ensure that everyone that needs to be in the know and has input into the change.
If the change has already been implemented and can't be easily rolled back, then B would be the next best option.
Kiron
Kiron I also thought of answer D. But the PMP training I am going through these days ( on Simplilearn) says the Answer is "B". That confused me a Lot.
...
1 reply by Sergio Luis Conte
Mar 28, 2020 3:25 PM
Sergio Luis Conte
...
The point is this is not a valid exam question. PMI does not allow a question refering to an specific domain. I was part of the exam certification questions creation group by 10 years acting as Subject Matter Expert inside QA group. If that changed in the last 3 years the forget my comments. Unfoetunatelly some people sells training without enough knwledge
I hope if dogs ever take over the world, and they choose a king, they don't just go by size, because I bet there are some Chihuahuas with some good ideas.
