Project after project, properly implemented Agile development is proving that it can deliver high-quality software rapidly and on budget. This success has generated as much enthusiasm as it has rhetoric. Agile is often portrayed as being so radically different from waterfall development that it doesn’t need any of it attributes, including the project manager.
This is only partially true. Agile is changing what it means to be a project manager. The project manager is dead. Long live the agile project manager.
Building software is different. In a traditional waterfall project, the project manager is in charge of delivering software in a command-control environment. The project manager comes up with a plan based on the deadline and budget allocated by the client. He decides how many people and how much time will be necessary to deliver it. He assigns tasks and deadlines to the developers and makes sure they accomplished according to the plan. If and when the plan starts to go awry, the project manager takes measures to get the project back on track. In other words, the project manager tries to execute a plan that predicts the project’s progress.
This is only partially true. Agile is changing what it means to be a project manager. The project manager is dead. Long live the agile project manager.
Building software is different. In a traditional waterfall project, the project manager is in charge of delivering software in a command-control environment. The project manager comes up with a plan based on the deadline and budget allocated by the client. He decides how many people and how much time will be necessary to deliver it. He assigns tasks and deadlines to the developers and makes sure they accomplished according to the plan. If and when the plan starts to go awry, the project manager takes measures to get the project back on track. In other words, the project manager tries to execute a plan that predicts the project’s progress.
Agile isn’t about sticking to a plan. It is about reaching a destination.
Not all software projects, however, go according to plan. Failure of waterfall software projects is often blamed on the project manager’s lack of expertise and/or the relative immaturity of software engineering methodologies. In reality, building software isn’t an exercise in prediction; it is an exercise in adaptation.
Agile isn’t about sticking to a plan. Instead it is about reaching a destination – the delivery of the software. To take the travel metaphor one step further, an Agile project manager is a guide who responsible for steering his team. Success isn’t measured by how well the team followed orders given before departure, but by how efficiently it navigated its way around obstacles and through bad weather to the final destination.
As a guide rather than a supervisor, an Agile project manager has to have three key attributes: leadership, motivation and vision.
Agile isn’t about sticking to a plan. Instead it is about reaching a destination – the delivery of the software. To take the travel metaphor one step further, an Agile project manager is a guide who responsible for steering his team. Success isn’t measured by how well the team followed orders given before departure, but by how efficiently it navigated its way around obstacles and through bad weather to the final destination.
As a guide rather than a supervisor, an Agile project manager has to have three key attributes: leadership, motivation and vision.
From managing projects to leading people
The agile project manager has to be a leader of people not a giver of orders. In Agile development, “project manager” is a misnomer. A more appropriate title would be “people manager” or “project coordinator”. This is because Agile projects are organized in a completely different way than waterfall ones. All Agile projects, big or small, operate according to an Agile Cycle: prepare, build, feedback, adapt. The project manager sets the pace of the cycle.
In the preparation phase, the project manager helps the team set its own action plan. The team decides what it can and can’t do. It decides who is going to tackle which tasks (the project manager doesn’t assign them).
The agile project manager has to be a leader of people not a giver of orders. In Agile development, “project manager” is a misnomer. A more appropriate title would be “people manager” or “project coordinator”. This is because Agile projects are organized in a completely different way than waterfall ones. All Agile projects, big or small, operate according to an Agile Cycle: prepare, build, feedback, adapt. The project manager sets the pace of the cycle.
In the preparation phase, the project manager helps the team set its own action plan. The team decides what it can and can’t do. It decides who is going to tackle which tasks (the project manager doesn’t assign them).
The project manager stays out of the team’s hair.
In the build phase, the project manager stays out of the team’s hair. He doesn’t micromanage. Instead the project manager makes sure that the team has the resources required to accomplish the tasks taken on. And the project manager protects the teams from outside interference.
In the feedback phase the team examines what happened during the iteration -- what went right and what went wrong. At this point, the project manager is there to remind the team of issues it might have forgotten and to inform them of any external changes that might affect subsequent iterations. Finally, changes are made for the next iteration based on the feedback.
In the feedback phase the team examines what happened during the iteration -- what went right and what went wrong. At this point, the project manager is there to remind the team of issues it might have forgotten and to inform them of any external changes that might affect subsequent iterations. Finally, changes are made for the next iteration based on the feedback.
I like it here
The project manager has to create a collaborative work environment. In an Agile project, roles—not tasks—are assigned to team members. Each role comes with rights and responsibilities. The project manager’s job is to define the rights and responsibilities of each role in collaboration with the person performing it. It is also to make sure that team members respect each others rights and meet their responsibilities.
This is equally true when it comes to the team’s interaction with stakeholders. One of the hallmarks of an Agile project is the very open communication pathways between the developers and the client. Too much communication, however, can become a distraction. The project manager is therefore a firewall, preventing the team from being derailed during an iteration.
Protecting the team also requires preventing it from becoming over reliant on one person. It is important to encourage collaboration and apprenticing. The more versatile the team members are, the easier it is to overcome the unexpected departure of a team member.
The project manager has to create a collaborative work environment. In an Agile project, roles—not tasks—are assigned to team members. Each role comes with rights and responsibilities. The project manager’s job is to define the rights and responsibilities of each role in collaboration with the person performing it. It is also to make sure that team members respect each others rights and meet their responsibilities.
This is equally true when it comes to the team’s interaction with stakeholders. One of the hallmarks of an Agile project is the very open communication pathways between the developers and the client. Too much communication, however, can become a distraction. The project manager is therefore a firewall, preventing the team from being derailed during an iteration.
Protecting the team also requires preventing it from becoming over reliant on one person. It is important to encourage collaboration and apprenticing. The more versatile the team members are, the easier it is to overcome the unexpected departure of a team member.
A developer who likes where he works is a developer who works better.
In the office, the project manager is responsible for making sure that the workspace is conducive to productivity. A developer who likes where he works is a developer who works better. The project manager needs to be open to requests for workplace improvements.
The project manager also needs to ensure that iterations don’t become monotonous. He shouldn’t hesitate to inject a refactoring iteration every now and then to break up the routine. Nor should he be afraid to move people from one role to another. This will improve communications and understanding within the team and encourage knowledge sharing. Finally, he should make sure the team works a normal work week. Progress should be measured by the results the project products, not the number hours the team puts in. It has been proven time and time again that working long hours just produces more junk code -- it doesn’t help to make up for lost time.
The project manager also needs to ensure that iterations don’t become monotonous. He shouldn’t hesitate to inject a refactoring iteration every now and then to break up the routine. Nor should he be afraid to move people from one role to another. This will improve communications and understanding within the team and encourage knowledge sharing. Finally, he should make sure the team works a normal work week. Progress should be measured by the results the project products, not the number hours the team puts in. It has been proven time and time again that working long hours just produces more junk code -- it doesn’t help to make up for lost time.
I have a dream
The project manager champions the project’s vision. Developers don’t wake up every morning with a burning desire to write code. What motivates them is the intellectual challenge that the project represents. It is the project manager’s job to stimulate the team by articulating the project’s vision so that everyone understands it. The vision should have both a customer focus and a technical focus. The project manager shows where the two converge -- why the business value of the project will be enhanced by the technical excellence of the software delivered. Over the life of the project, the project manager is there to nurture the vision so that no one forgets what the destination is.
The project manager champions the project’s vision. Developers don’t wake up every morning with a burning desire to write code. What motivates them is the intellectual challenge that the project represents. It is the project manager’s job to stimulate the team by articulating the project’s vision so that everyone understands it. The vision should have both a customer focus and a technical focus. The project manager shows where the two converge -- why the business value of the project will be enhanced by the technical excellence of the software delivered. Over the life of the project, the project manager is there to nurture the vision so that no one forgets what the destination is.
Developers don’t wake up
every morning with a burning desire
to write code.
every morning with a burning desire
to write code.
Articulating the vision of the project also requires explaining it to the users and all the stakeholders. Having a dream is important, but sometimes the route can appear unclear or intimidating. It is the project manager’s job to break the journey down into manageable, achievable iterations. Finally, while the project manager should champion the vision, he isn’t its sole inventor. The vision is a team effort. The project manager must create an environment in which all team members contribute to defining the dream.
Conclusion
As you can see, the Agile project manager’s job varies depending on which stage of the Agile Cycle you’re in:
As you can see, the Agile project manager’s job varies depending on which stage of the Agile Cycle you’re in:
- At the start of an iteration, the project manager is a leader who guides the team in the right direction.
- During an iteration, the project manager is a supporter, protecting the team from the elements and making sure it is got what it needs to work efficiently in good conditions.
- At the end of the iteration, the project manager is a facilitator who helps the team learn from its feedback and implement changes and improvements.
Comment
Thread closed
Dec 20, 2006 10:54 AM -
Bhupesh Nadkarni
With due respect, the author of this article perhaps has not come across right kind of project managers or he or she has no knowledge of PMBOK.
I got this feeling reading some of the paragraphs for e.g. the paragraph �??Building software is different. In a traditional waterfall project, the project manager is in charge of delivering software in a command-control environment. The project manager comes up with a plan based on the deadline and budget allocated by the client. He decides how many people and how much time will be necessary to deliver it. He assigns tasks and deadlines to the developers and makes sure they accomplished according to the plan. If and when the plan starts to go awry, the project manager takes measures to get the project back on track. In other words, the project manager tries to execute a plan that predicts the project�??s progress.�?? is completely wrong. Perhaps some PM�??s do act wrongly, that does not mean that the model itself preaches such things.
It is clearly stated in PMBOK that all the estimations have to be done by the person directly performing the task and not the PM. Deadlines and Budget are always allocated by client, whether it is agile or any other model, what is important is how the triple constraints are handled. In such cases where the client determines the deadline and budget the scope can be determined by the project team.
Another paragraph in the article is �??Not all software projects, however, go according to plan. Failure of waterfall software projects is often blamed on the project manager�??s lack of expertise and/or the relative immaturity of software engineering methodologies. In reality, building software isn�??t an exercise in prediction; it is an exercise in adaptation�??
This is again something that is wrongly understood. A plan is always dynamic, a plan at the start of the project provides a helicopter view, but as the things start becoming clear during the project phase, plans have to be updated regularly. Most people do not bother to do this activity; as a result the stakeholders are always in dark on project progress.
In my viewpoint there are several valid reasons why waterfall model is a failure. Any model if wrongly implemented is certain to fail, whether it is Waterfall or UP or spiral or AGILE
Finally, from the conclusions of the article, I don�??t see anything newly stated. PMBOK exactly talks about the same roles for PM. So what�??s Agile PM?
With due respect, the author of this article perhaps has not come across right kind of project managers or he or she has no knowledge of PMBOK.
I got this feeling reading some of the paragraphs for e.g. the paragraph �??Building software is different. In a traditional waterfall project, the project manager is in charge of delivering software in a command-control environment. The project manager comes up with a plan based on the deadline and budget allocated by the client. He decides how many people and how much time will be necessary to deliver it. He assigns tasks and deadlines to the developers and makes sure they accomplished according to the plan. If and when the plan starts to go awry, the project manager takes measures to get the project back on track. In other words, the project manager tries to execute a plan that predicts the project�??s progress.�?? is completely wrong. Perhaps some PM�??s do act wrongly, that does not mean that the model itself preaches such things.
It is clearly stated in PMBOK that all the estimations have to be done by the person directly performing the task and not the PM. Deadlines and Budget are always allocated by client, whether it is agile or any other model, what is important is how the triple constraints are handled. In such cases where the client determines the deadline and budget the scope can be determined by the project team.
Another paragraph in the article is �??Not all software projects, however, go according to plan. Failure of waterfall software projects is often blamed on the project manager�??s lack of expertise and/or the relative immaturity of software engineering methodologies. In reality, building software isn�??t an exercise in prediction; it is an exercise in adaptation�??
This is again something that is wrongly understood. A plan is always dynamic, a plan at the start of the project provides a helicopter view, but as the things start becoming clear during the project phase, plans have to be updated regularly. Most people do not bother to do this activity; as a result the stakeholders are always in dark on project progress.
In my viewpoint there are several valid reasons why waterfall model is a failure. Any model if wrongly implemented is certain to fail, whether it is Waterfall or UP or spiral or AGILE
Finally, from the conclusions of the article, I don�??t see anything newly stated. PMBOK exactly talks about the same roles for PM. So what�??s Agile PM?
Dec 20, 2006 4:46 PM -
Michael Poulin
Does it make sense writing a comment while it isn't, actually, visible?
Does it make sense writing a comment while it isn't, actually, visible?
Dec 21, 2006 9:36 AM -
Bharat Godha
Under Para...Agile isn't about sticking to plan rather reaching a destination - the delivery of the software....
Isn't there a plan... a plan for each iteration rather then for entire project...
Under Para... In the preparation phase... team decides what it can and can't do...
Does developer really have a choice what is to be implemented and what's not? Is developer telling that they cannot implement something that is required or its not feasible? Doesn't customer decide what he wants and what not in a release...
Under Para... In the preparation phase�?� team decides who is going to tackle which tasks...
Practically is it always feasible to rely on team members to decide about the task assignment... there has to be someone involved in addition to the team members... project manager / coordinator? Who does / doesn't want a challenging job?
Under Para... I like it here... The project manager has to create a collaborative work environment... The project manager's job is to define the rights and responsibilities...
How much different is there in telling a person what he should do & what not and giving a role to a person & define the role. Isn't defining & assigning the role to a person is telling indirectly what a person can / should do and what can�??t / shouldn�??t?
Time line is defined for every project. And in most cases driven by client and thus in order to deliver the project within pre-defined time lines, shouldn't there be a plan for the entire project (helicopter view) and adjusted plan for each iteration or module?
Under Para...Agile isn't about sticking to plan rather reaching a destination - the delivery of the software....
Isn't there a plan... a plan for each iteration rather then for entire project...
Under Para... In the preparation phase... team decides what it can and can't do...
Does developer really have a choice what is to be implemented and what's not? Is developer telling that they cannot implement something that is required or its not feasible? Doesn't customer decide what he wants and what not in a release...
Under Para... In the preparation phase�?� team decides who is going to tackle which tasks...
Practically is it always feasible to rely on team members to decide about the task assignment... there has to be someone involved in addition to the team members... project manager / coordinator? Who does / doesn't want a challenging job?
Under Para... I like it here... The project manager has to create a collaborative work environment... The project manager's job is to define the rights and responsibilities...
How much different is there in telling a person what he should do & what not and giving a role to a person & define the role. Isn't defining & assigning the role to a person is telling indirectly what a person can / should do and what can�??t / shouldn�??t?
Time line is defined for every project. And in most cases driven by client and thus in order to deliver the project within pre-defined time lines, shouldn't there be a plan for the entire project (helicopter view) and adjusted plan for each iteration or module?
Jan 24, 2007 10:19 AM -
Banibrata Dutta
IMHO, PMBOK never states that their chosen model is Waterfall. PMBOK has picked-up lot of good features from AGILE methodologies in addition to host of other Methodologies. So what ?
If you have lots of examples of people churning out successes one after the other, i.e. projects completed/delivered on-time, in-budget, as-per-agreed scope and with high-quality, you have the "magic sauce".
Maybe "Agile PM" is not that much different from other successful PM's (not claiming to be Agile), so what ?
IMHO, this is a good article, and just a point of view. I'd leave it at that. In addition, try to pick the good points, which I feel will help me.
IMHO, PMBOK never states that their chosen model is Waterfall. PMBOK has picked-up lot of good features from AGILE methodologies in addition to host of other Methodologies. So what ?
If you have lots of examples of people churning out successes one after the other, i.e. projects completed/delivered on-time, in-budget, as-per-agreed scope and with high-quality, you have the "magic sauce".
Maybe "Agile PM" is not that much different from other successful PM's (not claiming to be Agile), so what ?
IMHO, this is a good article, and just a point of view. I'd leave it at that. In addition, try to pick the good points, which I feel will help me.
Feb 11, 2007 10:43 AM -
Matt
Good Article, however I will say Agile sprint is succesffull if there is a good team. Otherwise I always believes in a project manager who can plan ,control the team and tasks from the begining to the end.
I must say agile's socialistic way of execution may not bring success always.
All you know todays challenge is not getting a project or to execute it successfully. The challenge is to get good and dedicated workforce ! . As far as there is a concern on this Agile is just a buzz word!
Good Article, however I will say Agile sprint is succesffull if there is a good team. Otherwise I always believes in a project manager who can plan ,control the team and tasks from the begining to the end.
I must say agile's socialistic way of execution may not bring success always.
All you know todays challenge is not getting a project or to execute it successfully. The challenge is to get good and dedicated workforce ! . As far as there is a concern on this Agile is just a buzz word!
Feb 15, 2007 5:40 PM -
Ganesh
Projects succesful delivery depends on various factors including customer centric,team centric-Project Manager is just another role-Word Manager should be dropped as he ia facilitator in true sense.He should also have active roles in project and to get the pulse of 1st hand development.Agility is all about how to adapt to change and provide better value to customer.It should be team centric with delivery from team and manager is just another role of facilitator.Customer should be part of agile team-Customers + Managers + Dev team =Agile Team..Success=Coordination + Anticipation + Adaptation Goals are key drivers.
Projects succesful delivery depends on various factors including customer centric,team centric-Project Manager is just another role-Word Manager should be dropped as he ia facilitator in true sense.He should also have active roles in project and to get the pulse of 1st hand development.Agility is all about how to adapt to change and provide better value to customer.It should be team centric with delivery from team and manager is just another role of facilitator.Customer should be part of agile team-Customers + Managers + Dev team =Agile Team..Success=Coordination + Anticipation + Adaptation Goals are key drivers.
Thread closed
Scaling Lean Thinking and Agile Methods to Offshore development - Part I (Craig Larman)
Scaling Lean Thinking and Agile Methods to Offshore development - Part II (Craig Larman)
Introduction to Agile Developement Pratices - Part I (Amr Elssamadisy & Ashley Johnson)
Introduction to Agile Developement Pratices - Part II (Amr Elssamadisy & Ashley Johnson)
Introduction to Agile Developement Pratices - Part II.2 (Amr Elssamadisy & Ashley Johnson)
Distributed Agile Development - Part I (Susan Fojtasek & Mike Abney)
Distributed Agile Development - Part II (Susan Fojtasek & Mike Abney)
Agile Documentation - Part I (Marcus Anhve)
Scaling Lean Thinking and Agile Methods to Offshore development - Part II (Craig Larman)
Introduction to Agile Developement Pratices - Part I (Amr Elssamadisy & Ashley Johnson)
Introduction to Agile Developement Pratices - Part II (Amr Elssamadisy & Ashley Johnson)
Introduction to Agile Developement Pratices - Part II.2 (Amr Elssamadisy & Ashley Johnson)
Distributed Agile Development - Part I (Susan Fojtasek & Mike Abney)
Distributed Agile Development - Part II (Susan Fojtasek & Mike Abney)
Agile Documentation - Part I (Marcus Anhve)
May 25, 2008 - Towards an evolutionary design by Venkat Subramaniam
May 20, 2008 - The Agile Zone - Papers
May 19, 2008 - Summary of Slack
Jun 11, 2008 - Twitter Updates for 2008-06-11
Jun 9, 2008 - Twitter Updates for 2008-06-09
Jun 8, 2008 - Twitter Updates for 2008-06-08
May 28, 2008 - Beta testing the Ballmer Tee
Apr 20, 2008 - Dear lazyweb, please pimp our balcony
Jun 10, 2008 - It's GIT'ing better all the time.
Jun 8, 2008 - Road-trip!
