Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, IT Project Management
If all requirement documents were explicit and aligned with objectives, would Agile require a life jacket when swimming near a Waterfall?
Network:356



Requirement documents rarely, if ever, meet the standard portrayed in my question. However, if they did would Agile require a lifejacket to survive? Obviously not, but just this week I was hearing the debate as I have heard it for over a decade. Where is your organization at, what are your personal thoughts and beliefs?
Sort By:
Network:9591



Agile is not only used in projects where change is dynamic. There are many reasons for using Agile. Both waterfall will sink or swim depending on their application.
Network:1533



I will assume that you are talking about Agile based methods. Requirements documents depends on the method you are using. One of the things that Agile based methods take care is to align requirements with objectives. Agile based methods were created based on quality which assures that. Obviously, into all this speech, the key is to define what "requirements" mean and taking into account that two main type of requirements exists: product requirements and project requirements. Project requirements are defined from product requirements and both are covered for Agile based methods. On the other side, if you have on your mind things that you could hear from some people about the Manifesto for Agile software Development nothing inside the Manifesto is talking about no documentation.
Network:6
If a "Required" document does not meet the standard and if it did the project execution method was unstable, than one should ask which of the two or do both require changing? wee must also ask the question, "If we know that this is commonly the case why haven't we changed the status quo? In my opinion the greatest hurdle to managing anything is when it "will work" we spend little effort on making the process work better. We are commonly trying to categorize a process and then apply said process to most if not everything. Neither way yields true development of a process or the people who support it. I would be very interested in hearing your opinion on this line of thought (both for and against).
...
2 replies by George Freeman and Shawn Quigley
Apr 07, 2018 10:16 AM
George Freeman
...
Hi Shawn,

I like your thoughts, which I reworded into the following:

- One of the greatest hurdles in managing projects (or anything) is that we don’t challenge “that which we consider - acceptable” to be better.

- If something falls short of a standard (e.g. requirement documents) then one should challenge whether that “something” or the Project Execution Method (or both) require changing.

- We too often take a methodology or high-level process and apply it blindly across-the-board, thus not rendering true development value to sub-processes or to the people who support it.

These are good challenge-based statements that we need to have in mind at all times. Yes, if we follow prescribed practices we shouldn’t fall into these traps, but we all know that we “all do” at times. Thank you for your thoughts!
Apr 07, 2018 3:42 PM
Shawn Quigley
...
to say any process is good for anything is foolish, but knowing what the objectives of the processes are allows for adaptation. That is where true growth of a project team occurs. all to often we are locked into that worked last time; I would state that no two projects are the same, not even if the second project is a repeat of the first and so no. It is as I stated earlier, we attempt to categorize things when we don't need to name something, what we need is an understanding of it: Systems Thinking. We also need an Open Mental Model to allow us to seek understanding no matter where it comes from.
Network:1704



In this regard, the benefit of being more 'agile' is to focus on the value of what is needed. When companies produce 100 page BRD's, then the development team goes into their silo to produce the product, by the time they finish things changed and what was once seen as valuable no longer is.

Agile allows for the team to focus on that value, always striving to produce a MVP with shorter incremental deliveries, stakeholder transparency, sessions for inspection and adaptation to ensure effort and value are still aligned, with quicker TTM and ROI
Network:46227



Requirements documented at a point in time (early in the project lifecycle), are just that, our understanding at a point in time.

We often learn more as the project progresses. Then the requirements become more clear, and may shift. No matter how well the standards for documentation were followed, it is always difficult to anticipate how the requirements will evolve as we get smarter.

So I think Agile principles would still be useful, in allowing the project to adapt to the evolving understanding of the requirements.
Network:356



Apr 07, 2018 7:44 AM
Replying to Shawn Quigley
...
If a "Required" document does not meet the standard and if it did the project execution method was unstable, than one should ask which of the two or do both require changing? wee must also ask the question, "If we know that this is commonly the case why haven't we changed the status quo? In my opinion the greatest hurdle to managing anything is when it "will work" we spend little effort on making the process work better. We are commonly trying to categorize a process and then apply said process to most if not everything. Neither way yields true development of a process or the people who support it. I would be very interested in hearing your opinion on this line of thought (both for and against).
Hi Shawn,

I like your thoughts, which I reworded into the following:

- One of the greatest hurdles in managing projects (or anything) is that we don’t challenge “that which we consider - acceptable” to be better.

- If something falls short of a standard (e.g. requirement documents) then one should challenge whether that “something” or the Project Execution Method (or both) require changing.

- We too often take a methodology or high-level process and apply it blindly across-the-board, thus not rendering true development value to sub-processes or to the people who support it.

These are good challenge-based statements that we need to have in mind at all times. Yes, if we follow prescribed practices we shouldn’t fall into these traps, but we all know that we “all do” at times. Thank you for your thoughts!
Network:356



I’m in total agreement with the value proposition of Agile! I have implemented hybrid forms on most of my projects, but from a requirements perspective I have had to “hold the line” on tradition even when I know the requirement contents will not withstand realization.

Changing culture doesn’t happen overnight, so PM’s must use the tools and techniques they have at their disposal to adapt an approach that will work for their environment.
Network:6
Apr 07, 2018 7:44 AM
Replying to Shawn Quigley
...
If a "Required" document does not meet the standard and if it did the project execution method was unstable, than one should ask which of the two or do both require changing? wee must also ask the question, "If we know that this is commonly the case why haven't we changed the status quo? In my opinion the greatest hurdle to managing anything is when it "will work" we spend little effort on making the process work better. We are commonly trying to categorize a process and then apply said process to most if not everything. Neither way yields true development of a process or the people who support it. I would be very interested in hearing your opinion on this line of thought (both for and against).
to say any process is good for anything is foolish, but knowing what the objectives of the processes are allows for adaptation. That is where true growth of a project team occurs. all to often we are locked into that worked last time; I would state that no two projects are the same, not even if the second project is a repeat of the first and so no. It is as I stated earlier, we attempt to categorize things when we don't need to name something, what we need is an understanding of it: Systems Thinking. We also need an Open Mental Model to allow us to seek understanding no matter where it comes from.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"Conventional people are roused to fury by departure from convention, largely because they regard such departure as a criticism of themselves."

- Bertrand Russell

ADVERTISEMENT

Sponsors