Please login or join to subscribe to this thread
Sonali, I would venture to say that the problem stems from a lack of communication. I've seen in many organization that requirements would be documented and given to the dev team without any discussion (I'm not going to jump on the agile wagon). Typically in these situations estimations were given on best guess and sometime just to get the monkey of my back. In reality however the task might take much longer due to complexity not understood, missing details etc. When they then try to make a deadline under pressure the result is sloppy work and missed deadlines.
So before I look at how to resolve discipline I would try and identify the cause. BTW you might already have done this?
These are not disciplinary gaps but normal things that happen in software development especially if Scrum is used and/or the time between software releases is small.
Look at Microsoft Windows, ever since they decided to release a new version of Windows 10 every 6 months almost all the releases were delivered with major defects. 6 months releases are too short for an operating system.
Estimations in software development mean nothing they are just guesses as it is simply impossible to make accurate estimations in this domain. If the management of a software development company does not understand this basic fact then those managers shouldn't have been there in the first place.
Anyway all these issue are not normally the responsibility of the PM but the responsibility of the software development manager and technical management.
There needs to be internal timelines for deliverables like by when unit testing has to be complete, adequate documentation of what was tested with results, determine the complexity of the code being newly developed for the project/module/feature, have expert or SME or peer review what was developed/coded along with test results. Have a common agreement of all these practices and timelines and encourage team members to adhere to it.
Also you could have a cutoff of how many bugs can be acceptable considering the complexity of the project /feature and have root cause analysis of why more defects are being introduced when fixing open defects. If things don't work well have management involved in all these discussions to help team members understand the importance of these practices.
Yes, this is a common scenario in IT industry. Most of the software developers have the same habit. It is just laziness because there is no action taken. Implement disciplinary actions, practically do the micro management for sometime and once things are on track and resources no longer needs hourly or couple of hours status update then leave them to their own. You need to tighten up the screws sometimes. Also make sure the requirements are documented, discussed, and agreed for scope, timelines and dependencies & constraints. I hope this will help.
First, let me say that being the head of an initiative has an "art" component which is to transform a group into a team, where team is people aligned to get a common objective. Second, if there is a group of people that behaves in a way that is not the needed to be part of the team the head of the initiative must understand why and if there is a reason that is impossible to solve then those people must be out of the team. Third, whole company is involved on each person behavior and belief (thing that are components of company culture) so before to take a decision the unit in charge of manage this type of things has to help you. And at the end, when I worked into a company that used a system of annual objectives to decide the yearly bonus then for those people some objectives relatated to the way it is needed as behavior were stated into the annual objectives.
I agree with Ajay here in a way.
That being said, you can ask EOD status by sharp 6 PM or so and basing on that, you can pose questions to them.
When I asked status in a company where I was working, they said, earlier managers( before me) never asked!!!. I told them that till I get a better handle, I needed it. So it took couple months.
I would suggest that UAT be part of each sprint, and only after passing UAT would the sprint deliverables enter the integration testing (final testing) before release. If they don't complete their UAT then the entire team will be held responsible for not meeting the goal of a working release by the end of the sprint. When others who are doing things the right way learn of the problems in the group they should self police, or all fail together. Sometimes failing is what's needed. Unfortunately, sometimes things get worse before they get better. :/
Lots of factors should be considered. nature of project, organization, a structure of project and organization, administrative policies, HR policies, etc. However, motivating the team is one of the most important roles of a project manager.
A few other ways to address potential lack of quality or discipline on the part of individual team members include:
- having the team define working agreements
- having the team define a Definition of Done for work items
- non-solo work (e.g. pairs programming)
Software development is a creative activity and because of this, unless we are talking about trivial tasks, it is impossible to give accurate estimates. Also bugs are inevitable no matter how many unit tests you are writing. Probably Microsoft developers do write unit tests but ever since the release cycle for Windows has moved to 6 months the system has had a series of sever bugs. It is much worse than previous systems that had a much longer release cycle.
In some cases developers do have to be disciplined if they don't perform their job properly but missing dead-lines or producing many bugs is not a criteria for determining that the developers are negligent. You need managers with technical background in software development to determine this or other mechanisms that exclude the opinions of the people that have never written a line of code in their lives.
You need to get your hands dirty in software development and get to a reasonably good level before you can understand these things.
Please login or join to reply