Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Innovation, Organizational Project Management
what is Agile Project Management
Network:70



What are main differences between conventional project management and agile project Management.
Sort By:
Page: 1 2 3 <prev | next>
Network:264



Jun 11, 2019 9:12 AM
Replying to Sergio Luis Conte
...
Sorry for said that but the problem with most of the comments above are the same. Agile IS NOT about values and principles. That is Agile applied to software where the framework is the Manifesto (but the way the word "software" inside the name is used for a reason). If you like to understand about Agile just take a look to book "Response Ability" written for Rick Dove which contains most of the deliverables created where Agile and agility concept were defined: USA DoD/NSF Agility Forum in 1990. But, just in case people decide to use the Manifesto as the basement for other domains then the Manifesto must be customized. It works, I have made an experience with several companies along the 3 years I was the leader of the community of interest about agile inside the PMI Buenos Aires chapter. Bur if people do not understand the basement first, do not understand it is a matter of enterprise architecture then will fail.
Mr. Dove is very proud of that book, Sergio. It's $70 even for the Kindle version. Thankfully we've had your history lessons to save us a few dollars.

I am fascinated by the history of business management and culture, specifically the interaction / learning between software and non-IT organizations in the age of Lean and Agile. We know the Manifesto for Agile Software Development was written for software, as you say, but it was built on decades of lessons from other domains as well as existing software development frameworks. Now those same lessons are applied beyond software development and both continue to evolve. It will be interesting to see what changes are in store over the next 5-10 years.
...
1 reply by Sergio Luis Conte
Jun 11, 2019 10:14 AM
Sergio Luis Conte
...
If somebody try to apply the Manifesto for non software then will fail into their intentions because it is just for a component inside the enteprise architecture. You can see that when you see the efforts that software people are doing tying to invent things to scale. For a chance of the destiny I was part of the movement (including the software movement).You do not need to go to the book. Check this: http://www.parshift.com/index.htm
Network:1894



Jun 11, 2019 9:53 AM
Replying to Wade Harshman
...
Mr. Dove is very proud of that book, Sergio. It's $70 even for the Kindle version. Thankfully we've had your history lessons to save us a few dollars.

I am fascinated by the history of business management and culture, specifically the interaction / learning between software and non-IT organizations in the age of Lean and Agile. We know the Manifesto for Agile Software Development was written for software, as you say, but it was built on decades of lessons from other domains as well as existing software development frameworks. Now those same lessons are applied beyond software development and both continue to evolve. It will be interesting to see what changes are in store over the next 5-10 years.
If somebody try to apply the Manifesto for non software then will fail into their intentions because it is just for a component inside the enteprise architecture. You can see that when you see the efforts that software people are doing tying to invent things to scale. For a chance of the destiny I was part of the movement (including the software movement).You do not need to go to the book. Check this: http://www.parshift.com/index.htm
...
1 reply by Aaron Porter
Jun 11, 2019 11:06 AM
Aaron Porter
...
If you remove principles 1, 3, & 11, and make minor modifications to 4, 6, 7, & 8 (removing or modifying references to software and developers), you can apply the principles to any project. You could probably modify 1 & 3 to work with any project, as well.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Network:877



Jun 11, 2019 10:14 AM
Replying to Sergio Luis Conte
...
If somebody try to apply the Manifesto for non software then will fail into their intentions because it is just for a component inside the enteprise architecture. You can see that when you see the efforts that software people are doing tying to invent things to scale. For a chance of the destiny I was part of the movement (including the software movement).You do not need to go to the book. Check this: http://www.parshift.com/index.htm
If you remove principles 1, 3, & 11, and make minor modifications to 4, 6, 7, & 8 (removing or modifying references to software and developers), you can apply the principles to any project. You could probably modify 1 & 3 to work with any project, as well.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
...
2 replies by Sergio Luis Conte and Wade Harshman
Jun 11, 2019 11:21 AM
Sergio Luis Conte
...
But you will still focused on the process (the project) and that is the first big mistake.Is not about process. Is about strategy, share values, structure, style, skills, systems, staff.
Jun 11, 2019 12:56 PM
Wade Harshman
...
There has been a good deal written about the shared principles between Agile development and Lean (lean manufacturing or lean software development). Certainly the history is intertwined and I think it's fair to say that, as they currently exist, Agile and Lean are compatible. Although there is a distinction to be made, Lean practitioners and Agile practitioners continue to learn from one another. Perhaps they will eventually combine and create a new buzzword and we'll all need to get new certifications.
Network:877



Jun 10, 2019 8:01 PM
Replying to Eric Isom
...
There are many project management approaches/methodologies/frameworks that fall under the umbrella of Agile. Agile is a response to the utter failure of traditional/waterfall/predictive project management to successfully deliver projects that have a high degree of uncertainty or change. Agile embraces change as both inevitable and desirable in such situations.

I recommend you start with the Agile Manifesto at http://agilemanifesto.org/ , including the principles page at http://agilemanifesto.org/principles.html

The most popular Agile approach is Scrum. I recommend the book Scrum: The Art of Doing Twice the Work in Half the Time, by Jeff Sutherland, co-founder of Scrum. It's an interesting and non-technical introduction to Scrum.
I would argue that the problem with traditional/waterfall/predictive is the people, more than the process (although sometimes it is the process). Granted, there are projects that are better run using an approach like Scrum. Likewise, there are projects I would not use Scrum on, such as upgrading SAP CRM from EHP 6 to EHP 8 and migrating to HANA.

If you were to take a poll, I would wager that you would find more people have received actual training on Scrum or other agile approaches than have received actual training on traditional approaches. Most of the people I've worked with on traditional projects, over the past 16 years, have all had slightly, or grossly, different opinions on how a waterfall project should be run. Once I started coaching my teams on how a given project would be run, my projects started getting more successful. This coaching came after careful consideration of the correct approach for the project.
Network:1894



Jun 11, 2019 11:06 AM
Replying to Aaron Porter
...
If you remove principles 1, 3, & 11, and make minor modifications to 4, 6, 7, & 8 (removing or modifying references to software and developers), you can apply the principles to any project. You could probably modify 1 & 3 to work with any project, as well.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
But you will still focused on the process (the project) and that is the first big mistake.Is not about process. Is about strategy, share values, structure, style, skills, systems, staff.
...
1 reply by Aaron Porter
Jun 11, 2019 2:17 PM
Aaron Porter
...
I think you may be making an assumption. I'm talking about applying core principles to any process. The process I follow in a project can take strategy, shared values, structure, style, skills, systems, and staff into account regardless of whether it is predictive, adaptive, or iterative.
Network:264



Jun 11, 2019 11:06 AM
Replying to Aaron Porter
...
If you remove principles 1, 3, & 11, and make minor modifications to 4, 6, 7, & 8 (removing or modifying references to software and developers), you can apply the principles to any project. You could probably modify 1 & 3 to work with any project, as well.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
There has been a good deal written about the shared principles between Agile development and Lean (lean manufacturing or lean software development). Certainly the history is intertwined and I think it's fair to say that, as they currently exist, Agile and Lean are compatible. Although there is a distinction to be made, Lean practitioners and Agile practitioners continue to learn from one another. Perhaps they will eventually combine and create a new buzzword and we'll all need to get new certifications.
Network:1216



I often sidestep the semantics of agile by noting that project managers (and others) typically have two aspirations.

-- The first is to be fast (or faster than before).
-- The second is to be flexible.

Generally, it is more difficult to promote flexibility, especially when the project's product involves something tangible. Software is generally more amenable to techniques that allow for fast and flexible work. Tangible products often have a nature that make it difficult to reprioritize, or change commitments, or reverse.

I'd encourage readers to look at the product (software versus tangibles) and you'll see that the various techniques are more suitable for one or the other.
...
1 reply by Sergio Luis Conte
Jun 11, 2019 1:15 PM
Sergio Luis Conte
...
Agile is about to be agile gaining in agility. Lean is about to be flexible. Both are not the same. The main diffence is: agility is about to respond and to create unplanned events in the environment. Software is the best product to gain in agility if and only if is not lost sight of arrchitecture. The same for the whole enterprise.
Network:1894



Jun 11, 2019 1:06 PM
Replying to Greg Githens
...
I often sidestep the semantics of agile by noting that project managers (and others) typically have two aspirations.

-- The first is to be fast (or faster than before).
-- The second is to be flexible.

Generally, it is more difficult to promote flexibility, especially when the project's product involves something tangible. Software is generally more amenable to techniques that allow for fast and flexible work. Tangible products often have a nature that make it difficult to reprioritize, or change commitments, or reverse.

I'd encourage readers to look at the product (software versus tangibles) and you'll see that the various techniques are more suitable for one or the other.
Agile is about to be agile gaining in agility. Lean is about to be flexible. Both are not the same. The main diffence is: agility is about to respond and to create unplanned events in the environment. Software is the best product to gain in agility if and only if is not lost sight of arrchitecture. The same for the whole enterprise.
Network:877



Jun 11, 2019 11:21 AM
Replying to Sergio Luis Conte
...
But you will still focused on the process (the project) and that is the first big mistake.Is not about process. Is about strategy, share values, structure, style, skills, systems, staff.
I think you may be making an assumption. I'm talking about applying core principles to any process. The process I follow in a project can take strategy, shared values, structure, style, skills, systems, and staff into account regardless of whether it is predictive, adaptive, or iterative.
...
1 reply by Sergio Luis Conte
Jun 11, 2019 3:14 PM
Sergio Luis Conte
...
Good to read that.
Network:1894



Jun 11, 2019 2:17 PM
Replying to Aaron Porter
...
I think you may be making an assumption. I'm talking about applying core principles to any process. The process I follow in a project can take strategy, shared values, structure, style, skills, systems, and staff into account regardless of whether it is predictive, adaptive, or iterative.
Good to read that.
Page: 1 2 3 <prev | next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Anyone can become angry - that is easy, but to be angry with the right person, to the right degree, at the right time, for the right purpose and in the right way - that is not easy."

- Aristotle

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events