how to handle a team member to have him cooperate and give the details necessary to have a precise and accurate project plan ??
The team member is in development team and more breakdown of the task is required to have an accurate timeline . I believe the team member think breaking down the task is a burden and waste of time , he doesn't see the benefit of breaking down the development task . on the other hand we end up always behind schedule because all the tasks haven't been thought in advance and he keep saying just give me the deadline and I will do it . I try to take on more on the servant leadership and that's precisely how I approached him , I grabbed a chair , sat next to him and was chatting about what needs to be done and how are we going to do it and I was like let's breakdown the tasks . then he freaked out. Saving Changes...
Symon ThelappillilTechnical program manager| Intel Technology India Pvt Ltd.Bangalore, Karnataka, India
Few folks have difficulty in identifying tasks, its a thought process issue. Those guys should be made to have discussions with senior developers / architects to make sure that they are grounded and made aware that their activities are monitored
For the folks who knows about task division, the approach need to be different. Team members should feel important to update tasks. There are several ways to do the same
1. Give recognition for the other team folks who complete the tasks on time
2. Show case that higher management is interested in seeing completed tasks. This can be achieved by triggering queries coming from senior management to the developer on the particular so that he understands the need to update the project management tool
3. Any help or success team member require / generate be made contingent upon same reflecting in the project management tool as a task
4. Any review or release activity should be started only with task updation
Once the team member is attuned to add tasks, do recognize the same so that they continue to do the same Saving Changes...
I'd start by understanding why the team member "freaked out" - it might be because of past experience of getting burned when he provided detailed estimates in advance of having sufficient confidence in the numbers.
What was the scope of the exercise - was it just for the next few weeks worth of work or were you trying to get a detailed breakdown for a much longer duration?
Kiron
...
1 reply by DINA MUHAMAD
Nov 14, 2018 11:50 PM
DINA MUHAMAD
...
The scope is for two weeks which should be doable . what team building activity could help in these situation . My management style is not bugging team members and not micromanagement them and also I want to feel I am in control and not missing any details to have successful completion in terms of timeline.
I'd start by understanding why the team member "freaked out" - it might be because of past experience of getting burned when he provided detailed estimates in advance of having sufficient confidence in the numbers.
What was the scope of the exercise - was it just for the next few weeks worth of work or were you trying to get a detailed breakdown for a much longer duration?
Kiron
The scope is for two weeks which should be doable . what team building activity could help in these situation . My management style is not bugging team members and not micromanagement them and also I want to feel I am in control and not missing any details to have successful completion in terms of timeline. Saving Changes...
Are you a developer yourself? Are you able to do the team member's work yourself? If not then you should never ask a developer such a thing. Non-technical people should never get into the details of the work performed by the project team members.
I don't know what your exact situation is but developers often change the low level tasks that they have to do while they complete a requirement. For instance the developer thinks at the beginning to do the work in a way but while working he figures out that his initial idea is not good so he needs to rethink it.
Probably many developers would freakout if they are asked to breakdown their work in very small low level tasks.
I don't want to offend you and I may even be wrong but this sounds like the scenario in which the non-technical PM does not understand the work in details and asks for things that he thinks would be helpful but in reality such requests just make the life harder for the team member.
Senior developers usually ask entry level developers to breakdown the task in very small low level tasks but this is usually just for learning. Otherwise is extreme micromanagement even when the one that makes the request is very technical.
...
1 reply by DINA MUHAMAD
Nov 26, 2018 7:45 AM
DINA MUHAMAD
...
I agree with you . I wasn't looking for low level tasks . I was trying to help him to think in advance about what he needs to do get things done on time . Eventually he realized that and now everything is broken down to an acceptable level and hopefully we will meet the deadline.
Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
Agree with Kiron, there seems to be an underlying issue. The unwillingness to breakdown a task is often because they do no want to be accountable i.e. I did not say it will take 2 days. It might be because they got blamed for delays when they provided estimates before?
@Adrian you are completely wrong. You do not have to be a techie to expect the team to provide their input. The PM does NOT have to understand the work in detail. And why it would make the life of a team member harder is beyond me, actually it is to make it easier. This is exactly what happens in Scrum. Tasks are broken down into manageable pieces and the TEAM provides the estimates for each task, not the PM, SM or Coach.
...
2 replies by Adrian Carlogea and Sergio Luis Conte
Nov 15, 2018 4:52 AM
Adrian Carlogea
...
As far as I know in Scrum not the task is broken into manageable pieces but the requirement. A User Story is not a task that can be done by a developer. A US does not tell what the developer must do but it just tells what the user expects.
When a developer is assigned a US he must define the tasks needed to complete that US. Tasks include things like, changing different pieces of code, each change being a task on itself, changing configuration file, data models, installing other applications, etc.
If you are non-technical you should not go beyond splitting the requirements into smaller pieces. But even splitting the requirements could be problematic.
For instance a US may ask the generation of some reports. The developer completes the US by doing the required tasks. On 2 or 3 Sprints later another US may ask other reports but they should be generated as the first ones. Later on other report USs. If all the reports are in a big requirement the developer can write some sort of API or generic code for all of them and overall would result in a better technical solution. Depending on the nature of the work splitting the requirements in smaller ones could affect negatively the technical solution.
So in conclusion the definition of the low level tasks needed to complete a requirement is the job of the developer and non-technical people must NOT interfere with this work.
Nov 15, 2018 8:10 AM
Sergio Luis Conte
...
@Anton, I think @Adrian is talking about the way to ask developers for that. In my personal experience forget about to ask a developer about those type of things. They have the knowledge to answer you but the behavior characteristics and mainly the focus of development people are not willing to work on that. I was a developer and I am working with developers and while they always help me I understood the way "to move" then or to motivate then to do that is quit different than other areas. About developers, one of the best works I read is "Peopleware".
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Generally speaking, I fully agree with @Adrian Carlogea here. I was a developer and part of the developers team and I fully understand about that. Sometines, I am not saying this apply to you, people do not understand the way of thinking and behave of others and tried to push them to do things they are not able or not are willing to do. The best thing that happned in my personal career is I have the opportunity to work in different places of the "pyramid" inside the software/IT division mainly and the same when I was promoted to other areas. Because of that, I understood that Newton´s Laws can be applied to understand how people behave when we ask something from them. Saving Changes...
Agree with Kiron, there seems to be an underlying issue. The unwillingness to breakdown a task is often because they do no want to be accountable i.e. I did not say it will take 2 days. It might be because they got blamed for delays when they provided estimates before?
@Adrian you are completely wrong. You do not have to be a techie to expect the team to provide their input. The PM does NOT have to understand the work in detail. And why it would make the life of a team member harder is beyond me, actually it is to make it easier. This is exactly what happens in Scrum. Tasks are broken down into manageable pieces and the TEAM provides the estimates for each task, not the PM, SM or Coach.
As far as I know in Scrum not the task is broken into manageable pieces but the requirement. A User Story is not a task that can be done by a developer. A US does not tell what the developer must do but it just tells what the user expects.
When a developer is assigned a US he must define the tasks needed to complete that US. Tasks include things like, changing different pieces of code, each change being a task on itself, changing configuration file, data models, installing other applications, etc.
If you are non-technical you should not go beyond splitting the requirements into smaller pieces. But even splitting the requirements could be problematic.
For instance a US may ask the generation of some reports. The developer completes the US by doing the required tasks. On 2 or 3 Sprints later another US may ask other reports but they should be generated as the first ones. Later on other report USs. If all the reports are in a big requirement the developer can write some sort of API or generic code for all of them and overall would result in a better technical solution. Depending on the nature of the work splitting the requirements in smaller ones could affect negatively the technical solution.
So in conclusion the definition of the low level tasks needed to complete a requirement is the job of the developer and non-technical people must NOT interfere with this work.
...
1 reply by Sergio Luis Conte
Nov 15, 2018 8:15 AM
Sergio Luis Conte
...
More on that @Adrian. There is not line or statement in Scrum that said that User Stories must be used. Just to read scrumguide.
Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Nov 15, 2018 3:43 AM
Replying to Anton Oosthuizen
...
Agree with Kiron, there seems to be an underlying issue. The unwillingness to breakdown a task is often because they do no want to be accountable i.e. I did not say it will take 2 days. It might be because they got blamed for delays when they provided estimates before?
@Adrian you are completely wrong. You do not have to be a techie to expect the team to provide their input. The PM does NOT have to understand the work in detail. And why it would make the life of a team member harder is beyond me, actually it is to make it easier. This is exactly what happens in Scrum. Tasks are broken down into manageable pieces and the TEAM provides the estimates for each task, not the PM, SM or Coach.
@Anton, I think @Adrian is talking about the way to ask developers for that. In my personal experience forget about to ask a developer about those type of things. They have the knowledge to answer you but the behavior characteristics and mainly the focus of development people are not willing to work on that. I was a developer and I am working with developers and while they always help me I understood the way "to move" then or to motivate then to do that is quit different than other areas. About developers, one of the best works I read is "Peopleware". Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Nov 15, 2018 4:52 AM
Replying to Adrian Carlogea
...
As far as I know in Scrum not the task is broken into manageable pieces but the requirement. A User Story is not a task that can be done by a developer. A US does not tell what the developer must do but it just tells what the user expects.
When a developer is assigned a US he must define the tasks needed to complete that US. Tasks include things like, changing different pieces of code, each change being a task on itself, changing configuration file, data models, installing other applications, etc.
If you are non-technical you should not go beyond splitting the requirements into smaller pieces. But even splitting the requirements could be problematic.
For instance a US may ask the generation of some reports. The developer completes the US by doing the required tasks. On 2 or 3 Sprints later another US may ask other reports but they should be generated as the first ones. Later on other report USs. If all the reports are in a big requirement the developer can write some sort of API or generic code for all of them and overall would result in a better technical solution. Depending on the nature of the work splitting the requirements in smaller ones could affect negatively the technical solution.
So in conclusion the definition of the low level tasks needed to complete a requirement is the job of the developer and non-technical people must NOT interfere with this work.
More on that @Adrian. There is not line or statement in Scrum that said that User Stories must be used. Just to read scrumguide. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Freaking out is the aggressive reaction when feeling attacked (he could also just have run away or silently nodding without a visible reaction). In the end, your applied servant leadership technique put pressure on him.
There can be many reasons why he felt attacked, status/gender difference, not feeling respected (because he already rejected and you come back), uncertainty how to break the task further down, feeling you are taking away his freedom how to work (and you said you want to have more control), and perceived unfairness (being the only one being asked).
Suggest you find that out. Changing his behavior to do anthing, you can try Grenny's 6 fields of influence:
1-2 motivate him to do it AND enable him how to do it.
3-4 Get buy-in by the team to agree on doing it (building group pressure) AND giving the team the means to do it (e.g. creating a team charter).
5-6 Lastly, establish an environment for doing the thing you want (e.g. publish deadline shifts, customer feedback, .) AND find means to enable this environment.
Hope this helps. Let me know if you want more specific help.
...
1 reply by DINA MUHAMAD
Nov 26, 2018 7:51 AM
DINA MUHAMAD
...
Yea . I somehow struggled with the development team . I mentioned that to my manager to talk to them to be cooperating and supportive but he told it is your own problem and we shouldn't use the authoritative power for them to cooperate which I somehow understand . The maturity level of project management concept is relatively low ,although we are progressing and at least now we have put some templates in place and I am enjoying seeing the progress and the change in the culture.
