5 ms·

If you have to have everything on your requirements list, you can't be agile If you need to plan beyond the next sprint with any degree of accuracy, you're not

by dkarl 15y ago

If you have to have everything on your requirements list, you can't be agile If you need to plan beyond the next sprint with any degree of accuracy, you're not agile If you think you can "fix" an iteration by adding more people, you're not agile If you are prepared to change the end date of an iteration to "fit something in", you're not agile If you have to give a fixed date for delivery - it's very, very difficult to be agile. 90% of companies that are committing to Agile need to read this list, be honest with themselves, and choose a different process because there is something on this list they are not ready to give up.

projectileboy 15y ago
If you're not willing to negotiate anything on this list, your process probably isn't going to matter very much.
- dusklight 15y ago
  What do you mean?
  - PaulHoule 15y ago
    project management is about getting business results, not sticking to a certain process. we can't wave a magic wand and get a project done with features, quality, and budget at a certain date that we choose. we can use project management to understand what we can do realistically.
DanielRibeiro 15y ago
This discussion is pretty similar to one made on Agile’s Second Chasm (and how we fell in): http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
al_biglan 15y ago
"agile vs. Agile" you mix the cases in this :-) I wasn't "there" in 2001, but it seems to me that Agile (the proper noun) is nothing more or less than : We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Where do sprints and iterations fit into this? I think way too much has been made from the Agile ideal. Many things try to codify Agile into practice, Iterations are great, but why timebox them? Is timeboxing an Agile pattern? Then does a process like Scrumban fail out of being Agile? Does this differentiation help us as practitioners? IMHO: an Agile organization is one where all the members agree to the Agile Manifesto and use it to help guide their methodology and process selection and optimization.
- dkarl 15y ago
  I use big-A Agile to talk about the codified and sclerotic form of Agile taught by cookie-cutter consultants. Somewhere there is a sacred text, an Agile Leviticus, containing ceremonial forms that people adhere to with religious faith. Even if the forms fail and are adjusted or abandoned at one company, they will be revived in their original form at the next company, citing success at the first company as proof of their power. Thus Agile never changes no matter how often it fails, which is why it deserves to be a capital-A proper noun. Little-a agile is a characteristic of software development organizations that programmers and managers strive to achieve, pragmatically adopting the processes that help them achieve it. The Agile Manifesto can be used in service of either agile software development or Agile the consulting religion.
  - Someone 15y ago
    I know that in the more generic form: methodology is good, Methodology is bad. I think this applies to any methodology, including waterfall. Another way to phrase this is "never stop observing, never stop acting on observations". Acting does not equate doing something, however. Even if you do nothing, and let the wagon roll on, you must know why you are doing nothing.
aweisser 15y ago
I don't understand your last point: "if you have to give a fixed date for delivery - it's very, very difficult to be agile" An agile project delivers continuously. So you can deliver every time, especially at a fixed date. The fact is, that if you have to be feature complete at a fixed date, you can't be agile. Hence, you can't be feature complete at a fixed date in an agile project.
- kstenerud 15y ago
  "fixed date" in this case means "We have the following list of features we want in the product, to be launched as our big update. How many months will it take? (and we'll hold you to that exact date)" The further ahead you must forecast, the less accurate your estimate will be. In many organizations, the hapless architect is asked to give a solid date for a laundry list of features, many of which he can't research very well up front. Many technologies exist to solve a number of the problems, but the experienced architect KNOWS that each and every one of those technologies will fail to work, be poorly documented, be poorly supported, contain subtle bugs that affect nobody else but him, be incompatible with existing infrastructure, etc. There will be a great number of dead ends, which can only be discovered once the team has spent a good amount of time learning the technologies via documentation, web searches, object code disassembly, threatening vendors' families and pets, and so on. And fixing these emerging problems will involve other technologies, each with their own problems, resulting in a factorial solution set. This is why the traditional method of estimation has been to estimate how long you expect it to take with a lot of things going wrong, and then triple it (you triple it so that you can be "talked down" to double, even though that increases the risk of going over). In short, long term project completion forecasts are a fairy tale, and so anyone who expects you to adhere to them makes agility near impossible.
  - deleted 15y ago
    [deleted]

by dkarl 15y ago

projectileboy 15y ago

If you're not willing to negotiate anything on this list, your process probably isn't going to matter very much.

dusklight 15y ago
What do you mean?
- PaulHoule 15y ago
  project management is about getting business results, not sticking to a certain process. we can't wave a magic wand and get a project done with features, quality, and budget at a certain date that we choose. we can use project management to understand what we can do realistically.

DanielRibeiro 15y ago

This discussion is pretty similar to one made on Agile’s Second Chasm (and how we fell in): http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how-we-fell-in/ http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...

al_biglan 15y ago

"agile vs. Agile" you mix the cases in this :-) I wasn't "there" in 2001, but it seems to me that Agile (the proper noun) is nothing more or less than : We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Where do sprints and iterations fit into this? I think way too much has been made from the Agile ideal. Many things try to codify Agile into practice, Iterations are great, but why timebox them? Is timeboxing an Agile pattern? Then does a process like Scrumban fail out of being Agile? Does this differentiation help us as practitioners? IMHO: an Agile organization is one where all the members agree to the Agile Manifesto and use it to help guide their methodology and process selection and optimization.

dkarl 15y ago
I use big-A Agile to talk about the codified and sclerotic form of Agile taught by cookie-cutter consultants. Somewhere there is a sacred text, an Agile Leviticus, containing ceremonial forms that people adhere to with religious faith. Even if the forms fail and are adjusted or abandoned at one company, they will be revived in their original form at the next company, citing success at the first company as proof of their power. Thus Agile never changes no matter how often it fails, which is why it deserves to be a capital-A proper noun. Little-a agile is a characteristic of software development organizations that programmers and managers strive to achieve, pragmatically adopting the processes that help them achieve it. The Agile Manifesto can be used in service of either agile software development or Agile the consulting religion.
- Someone 15y ago
  I know that in the more generic form: methodology is good, Methodology is bad. I think this applies to any methodology, including waterfall. Another way to phrase this is "never stop observing, never stop acting on observations". Acting does not equate doing something, however. Even if you do nothing, and let the wagon roll on, you must know why you are doing nothing.

aweisser 15y ago

I don't understand your last point: "if you have to give a fixed date for delivery - it's very, very difficult to be agile" An agile project delivers continuously. So you can deliver every time, especially at a fixed date. The fact is, that if you have to be feature complete at a fixed date, you can't be agile. Hence, you can't be feature complete at a fixed date in an agile project.

kstenerud 15y ago
"fixed date" in this case means "We have the following list of features we want in the product, to be launched as our big update. How many months will it take? (and we'll hold you to that exact date)" The further ahead you must forecast, the less accurate your estimate will be. In many organizations, the hapless architect is asked to give a solid date for a laundry list of features, many of which he can't research very well up front. Many technologies exist to solve a number of the problems, but the experienced architect KNOWS that each and every one of those technologies will fail to work, be poorly documented, be poorly supported, contain subtle bugs that affect nobody else but him, be incompatible with existing infrastructure, etc. There will be a great number of dead ends, which can only be discovered once the team has spent a good amount of time learning the technologies via documentation, web searches, object code disassembly, threatening vendors' families and pets, and so on. And fixing these emerging problems will involve other technologies, each with their own problems, resulting in a factorial solution set. This is why the traditional method of estimation has been to estimate how long you expect it to take with a lot of things going wrong, and then triple it (you triple it so that you can be "talked down" to double, even though that increases the risk of going over). In short, long term project completion forecasts are a fairy tale, and so anyone who expects you to adhere to them makes agility near impossible.
- deleted 15y ago
  [deleted]