![\"How](\"https:\/\/e360-media.s3.amazonaws.com\/2022\/04\/06131004\/image.png\")
<\/figure><\/div>\n\n\n\nThe Agile Manifesto recognizes this right off in its first paired value:<\/p>\n\n\n\n
1: Individuals and Interactions over Processes and Tools<\/strong><\/h3>\n\n\n\nSystems thinking in a project is important because consistency is critical to generating repeatable, predictable results. This helps us ensure we can meet the value expectations of our stakeholders with confidence. When those systems become overly bureaucratic or restrict our ability to respond to our stakeholders\u2019 evolving needs, they become detrimental to achieving the necessary value. The Agile mindset starts by recognizing it is ALL ABOUT THE PEOPLE!<\/p>\n\n\n\n
2: Working Software (product) over Comprehensive Documentation<\/strong><\/h3>\n\n\n\nMuch like systems thinking being important yet secondary in a paired value, comprehensive documentation is essential in that it helps us to not only avoid prior mistakes and build on prior successes (assuming we actually use our Lessons Learned\/Retrospectives correctly) but also provides for long-term supportability of whatever change to the operational environment our project has created. Without this, long-term value sustainment is challenged, and our project may lose value perception long-term as the solution becomes burdensome to support when the project team moves on. However, documentation is far less valuable if the product simply doesn\u2019t work or deliver the intended value. I had a client years ago who had a very cumbersome, home-grown production system. My team was working hard to update and create proper documentation, but if the system went down, the customer lost $1 million\/minute in the inability to move the product. Documentation was critical, but if the system ever went down, no one cared about creating or updating documentation until the system was back up and running.<\/p>\n\n\n\n
3: Customer Collaboration over Contract Negotiation<\/strong><\/h3>\n\n\n\nI tell my students this regularly\u2026 value delivered in a project must be relevant at the time of delivery rather than at the negotiation time. Especially with the speed of change in business experiences in the digital age, what was negotiated a couple of years (or even six months) ago likely is not exactly what is needed at the actual point of delivery. Not only is business and technology rapidly changing, but understanding, societal and corporate values, and even associated personnel are constantly shifting. Add in the frequent disconnect between what a customer says they want upfront to what they actually expect at delivery (hence the reason Business Analysts\/Product Owners can be so crucial to a project). We have a situation where dogged adherence to an initially negotiated result can lead to contractual compliance but project failure when the needed value isn\u2019t achieved. We must constantly be listening to what our various stakeholders are saying. Then we adapt (and plainly communicate) expectations within our project constraints. If not, you may successfully deliver to every contractual obligation only to have the customer (or your internal stakeholders) look up and say, \u201cThis wasn\u2019t worth it.\u201d Now, not only was your contract not truly successful, but it may also become a detriment to future opportunities as customers will certainly talk to other potential customers.<\/p>\n\n\n\n
4: Responding to Change over Following a Plan<\/strong><\/h3>\n\n\n\nSince project management is not just tactical but is also a strategic competency, it seems appropriate to use a quote from a well-known military leader (and former President of the United States). \u201cIn preparing for battle, I have always found that plans are useless, but planning is indispensable.\u201d (Dwight D. Eisenhower)<\/p>\n\n\n\n
Plans are built upon a goal. They provide us with a logical progression of steps to achieve that goal. Sometimes, the best plans feel like an old Choose Your Own Adventure<\/em> book where you extrapolate potential decision\/change points and can build a series of \u201cwhat if\u2019s,\u201d allowing you to pivot quickly at those points as appropriate information becomes available. In reality, since projects are performed by human beings creating value for other human beings in an ever-changing environment, you simply cannot plan for every contingency. Rote adherence to a plan made with limited information, even when new information comes to light, is a recipe for pain born of either hubris or fear. We start with a plan yet have to embrace the reality that planning to succeed means embracing the need for change and allowing our plans to evolve to the latest information and value definitions. This ties to the project management concept of Progressive Elaboration.<\/p>\n\n\n\nThis concept is critical to the Agile mindset, because it allows for quick response to change, embraces the need for change to achieve the project’s goal, and is open to new ideas and directions. This flexibility helps ensure that Agile projects deliver more value to their stakeholders because the Agile team is not married to any one plan, but rather is focused on delivering the most valuable items first.<\/p>\n\n\n\n
The Agile mindset is also essential for Agile teams to be able to quickly adapt to changes in their environment (changes in technology, stakeholder demands, etc.). The Agile team cannot afford to spend time planning and then executing against a plan that may no longer be valid. Instead, they must be able to quickly identify the changes and adapt their plan (and their actions) accordingly.<\/p>\n\n\n\n
Broad Application of the Agile Mindset<\/h2>\n\n\n\n
As you ponder the information above, I\u2019d like you to consider how this would apply to an established Agile methodology and how true each of these is even in a Waterfall project management approach. At the end of the day, it is all about providing relevant value to our stakeholders. Failure to recognize the stakeholders, the changing nature of projects and value definition, the need to allow your plans to evolve, and the simple reality that projects happen in a constantly changing environment leads to unnecessary pain and, often, to the ultimate failure of too many projects.<\/p>\n\n\n\n
The Agile mindset can also be used to handle agile’s most common failure… scope creep. Scope creep happens when the project’s original goals expand beyond the agreed-upon boundaries. This can be due to changes in customer requirements, changes in the business environment, or simply a change in the agile team’s understanding of what needs to be done. The agile team must be able to quickly identify when scope creep is happening and take appropriate action to bring the project back within its original boundaries. This may include renegotiating with the stakeholders, changing the project’s agile methodology, or even canceling the project.<\/p>\n\n\n\n
There is a considerable amount of value in maintaining an Agile mindset for any project, not just Agile projects. An Agile mindset applied to any project can significantly reduce that pain and increase your overall success.<\/p>\n\n\n\n
Learn More<\/h2>\n\n\n\n
Much like systems thinking being important yet secondary in a paired value, comprehensive documentation is essential in that it helps us to not only avoid prior mistakes and build on prior successes (assuming we actually use our Lessons Learned\/Retrospectives correctly) but also provides for long-term supportability of whatever change to the operational environment our project has created. Without this, long-term value sustainment is challenged, and our project may lose value perception long-term as the solution becomes burdensome to support when the project team moves on. However, documentation is far less valuable if the product simply doesn\u2019t work or deliver the intended value. I had a client years ago who had a very cumbersome, home-grown production system. My team was working hard to update and create proper documentation, but if the system went down, the customer lost $1 million\/minute in the inability to move the product. Documentation was critical, but if the system ever went down, no one cared about creating or updating documentation until the system was back up and running.<\/p>\n\n\n\n
3: Customer Collaboration over Contract Negotiation<\/strong><\/h3>\n\n\n\nI tell my students this regularly\u2026 value delivered in a project must be relevant at the time of delivery rather than at the negotiation time. Especially with the speed of change in business experiences in the digital age, what was negotiated a couple of years (or even six months) ago likely is not exactly what is needed at the actual point of delivery. Not only is business and technology rapidly changing, but understanding, societal and corporate values, and even associated personnel are constantly shifting. Add in the frequent disconnect between what a customer says they want upfront to what they actually expect at delivery (hence the reason Business Analysts\/Product Owners can be so crucial to a project). We have a situation where dogged adherence to an initially negotiated result can lead to contractual compliance but project failure when the needed value isn\u2019t achieved. We must constantly be listening to what our various stakeholders are saying. Then we adapt (and plainly communicate) expectations within our project constraints. If not, you may successfully deliver to every contractual obligation only to have the customer (or your internal stakeholders) look up and say, \u201cThis wasn\u2019t worth it.\u201d Now, not only was your contract not truly successful, but it may also become a detriment to future opportunities as customers will certainly talk to other potential customers.<\/p>\n\n\n\n
4: Responding to Change over Following a Plan<\/strong><\/h3>\n\n\n\nSince project management is not just tactical but is also a strategic competency, it seems appropriate to use a quote from a well-known military leader (and former President of the United States). \u201cIn preparing for battle, I have always found that plans are useless, but planning is indispensable.\u201d (Dwight D. Eisenhower)<\/p>\n\n\n\n
Plans are built upon a goal. They provide us with a logical progression of steps to achieve that goal. Sometimes, the best plans feel like an old Choose Your Own Adventure<\/em> book where you extrapolate potential decision\/change points and can build a series of \u201cwhat if\u2019s,\u201d allowing you to pivot quickly at those points as appropriate information becomes available. In reality, since projects are performed by human beings creating value for other human beings in an ever-changing environment, you simply cannot plan for every contingency. Rote adherence to a plan made with limited information, even when new information comes to light, is a recipe for pain born of either hubris or fear. We start with a plan yet have to embrace the reality that planning to succeed means embracing the need for change and allowing our plans to evolve to the latest information and value definitions. This ties to the project management concept of Progressive Elaboration.<\/p>\n\n\n\nThis concept is critical to the Agile mindset, because it allows for quick response to change, embraces the need for change to achieve the project’s goal, and is open to new ideas and directions. This flexibility helps ensure that Agile projects deliver more value to their stakeholders because the Agile team is not married to any one plan, but rather is focused on delivering the most valuable items first.<\/p>\n\n\n\n
The Agile mindset is also essential for Agile teams to be able to quickly adapt to changes in their environment (changes in technology, stakeholder demands, etc.). The Agile team cannot afford to spend time planning and then executing against a plan that may no longer be valid. Instead, they must be able to quickly identify the changes and adapt their plan (and their actions) accordingly.<\/p>\n\n\n\n
Broad Application of the Agile Mindset<\/h2>\n\n\n\n
As you ponder the information above, I\u2019d like you to consider how this would apply to an established Agile methodology and how true each of these is even in a Waterfall project management approach. At the end of the day, it is all about providing relevant value to our stakeholders. Failure to recognize the stakeholders, the changing nature of projects and value definition, the need to allow your plans to evolve, and the simple reality that projects happen in a constantly changing environment leads to unnecessary pain and, often, to the ultimate failure of too many projects.<\/p>\n\n\n\n
The Agile mindset can also be used to handle agile’s most common failure… scope creep. Scope creep happens when the project’s original goals expand beyond the agreed-upon boundaries. This can be due to changes in customer requirements, changes in the business environment, or simply a change in the agile team’s understanding of what needs to be done. The agile team must be able to quickly identify when scope creep is happening and take appropriate action to bring the project back within its original boundaries. This may include renegotiating with the stakeholders, changing the project’s agile methodology, or even canceling the project.<\/p>\n\n\n\n
There is a considerable amount of value in maintaining an Agile mindset for any project, not just Agile projects. An Agile mindset applied to any project can significantly reduce that pain and increase your overall success.<\/p>\n\n\n\n
Learn More<\/h2>\n\n\n\n
Since project management is not just tactical but is also a strategic competency, it seems appropriate to use a quote from a well-known military leader (and former President of the United States). \u201cIn preparing for battle, I have always found that plans are useless, but planning is indispensable.\u201d (Dwight D. Eisenhower)<\/p>\n\n\n\n
Plans are built upon a goal. They provide us with a logical progression of steps to achieve that goal. Sometimes, the best plans feel like an old Choose Your Own Adventure<\/em> book where you extrapolate potential decision\/change points and can build a series of \u201cwhat if\u2019s,\u201d allowing you to pivot quickly at those points as appropriate information becomes available. In reality, since projects are performed by human beings creating value for other human beings in an ever-changing environment, you simply cannot plan for every contingency. Rote adherence to a plan made with limited information, even when new information comes to light, is a recipe for pain born of either hubris or fear. We start with a plan yet have to embrace the reality that planning to succeed means embracing the need for change and allowing our plans to evolve to the latest information and value definitions. This ties to the project management concept of Progressive Elaboration.<\/p>\n\n\n\n This concept is critical to the Agile mindset, because it allows for quick response to change, embraces the need for change to achieve the project’s goal, and is open to new ideas and directions. This flexibility helps ensure that Agile projects deliver more value to their stakeholders because the Agile team is not married to any one plan, but rather is focused on delivering the most valuable items first.<\/p>\n\n\n\n The Agile mindset is also essential for Agile teams to be able to quickly adapt to changes in their environment (changes in technology, stakeholder demands, etc.). The Agile team cannot afford to spend time planning and then executing against a plan that may no longer be valid. Instead, they must be able to quickly identify the changes and adapt their plan (and their actions) accordingly.<\/p>\n\n\n\n As you ponder the information above, I\u2019d like you to consider how this would apply to an established Agile methodology and how true each of these is even in a Waterfall project management approach. At the end of the day, it is all about providing relevant value to our stakeholders. Failure to recognize the stakeholders, the changing nature of projects and value definition, the need to allow your plans to evolve, and the simple reality that projects happen in a constantly changing environment leads to unnecessary pain and, often, to the ultimate failure of too many projects.<\/p>\n\n\n\n The Agile mindset can also be used to handle agile’s most common failure… scope creep. Scope creep happens when the project’s original goals expand beyond the agreed-upon boundaries. This can be due to changes in customer requirements, changes in the business environment, or simply a change in the agile team’s understanding of what needs to be done. The agile team must be able to quickly identify when scope creep is happening and take appropriate action to bring the project back within its original boundaries. This may include renegotiating with the stakeholders, changing the project’s agile methodology, or even canceling the project.<\/p>\n\n\n\n There is a considerable amount of value in maintaining an Agile mindset for any project, not just Agile projects. An Agile mindset applied to any project can significantly reduce that pain and increase your overall success.<\/p>\n\n\n\nBroad Application of the Agile Mindset<\/h2>\n\n\n\n
Learn More<\/h2>\n\n\n\n