5 ms·

I've found that when the term "agile" is tossed around to people who aren't familiar with software development, the expectation is usually that more work can be

I've found that when the term "agile" is tossed around to people who aren't familiar with software development, the expectation is usually that more work can be done in less time. Design and requirements gathering is scrapped, and working software is expected after the first sprint. > It is possible for a mix of waterfall and iterative where early phases (requirements analysis, high level design) are done in a waterfall style while later phases (detailed design, code, test) are done in an iterative manner. I prefer this approach where time is explicitly dedicated to planning out the solution, which all stakeholders agree to. It also respects that as you begin implementing the solution you'll learn more about the problem domain and adjust accordingly.

afpx 7y ago
If I remember correctly, the agile manifesto was written, in large part, as a reaction to RUP, Spiral and other heavy weight iterative and incremental processes (not waterfall, btw). Its point was to redirect teams back to the prize. In the 90s, teams were becoming too focused on the process instead of the software and customer / user. I don’t believe I’ve met anyone who ever said, “Hey, let’s do Waterfall!” More often, processes became waterfall-like when feedback loops would become too long. Sometimes, teams wouldn’t get feedback for months. Interestingly, some of the scrum teams I’ve worked with recently have succumbed to the same thing because product owners aren’t active in the process. But, you’re right - “agile” is often followed as a way to get more done with fewer people. But, unless you’re starting with a heavy weight process to begin with, you’re not going to see much productivity gain. A process isn’t going to miraculously make your developers write code faster. But, used properly, it can lessen the risk of rework.
- disposedtrolley 7y ago
  > In the 90s, teams were becoming too focused on the process instead of the software and customer / user. Sadly I see a lot of this today too. I know someone who has worked on an "agile" project with two half hour long standups a day, two hour sprint planning, hour long retrospective, and various other "ceremonies". I'm not sure how much of the sprint comprised of actual work. > Sometimes, teams wouldn’t get feedback for months. Feedback is so crucial. It frustrates me that business process and politics sometimes gets in the way. > unless you’re starting with a heavy weight process to begin with, you’re not going to see much productivity gain Agree 100%, The scenarios I've mentioned have always been short term (~4 weeks) client engagements where there should've been absolutely no room for needless process. I worked on a project once where we had weekly sprints (!) with a playback with key stakeholders each Friday. Each week the stakeholders would change, so each week we needed to spend at least a day planning for the presentation.
- machinecoffee 7y ago
  I can't imagine why anybody would see RUP as a bad process to follow. Things I like about it are: 1. It's focus on the User and the business case. In the RUP documents you have to describe what business problem you're trying to solve and make a complete list of stakeholders (this can be a wide variety of people, not just the main app user). 2. During the elaboration phase you have to describe the list of requirements and tie them to a business case - so you're forced to think about the problem you're solving. 3. During design phase you have to tie each class/module back to a specific requirement (this forces developers to focus on the real problem as stated) 4. Use cases are a fantastic tools for describing system interactions with the user, and force designers & developers to think about and provide solutions to the not-happy path in a very quick iterative way. In your use cases you should address the main requirements of your stakeholders and tie them back to the requirements doc. 5. RUP has a specific phase for transition to live, and so forces you to think about deployment, architecture, config and maintenance even before code has been written. Yes, your IT dept is a stakeholder. 6. RUP doesn't care what you use during the construction phase - following an agile methodology would be ideal in fact. 7. RUP doesn't care what you use as a project management process - it will have documents that clearly show the scope of your work and the list of prioritized requirements you have to fill before you're done, which is great for tracking progress. 8. RUP is iterative, so if you discovered something important missing during construction - go back to elaboration and work the new requirements through your design. 9. Creating and keeping up to date a fairly small set of well designed documents will lift the quality of your product. This is just my personal experience, but I found I learned a lot following the methodology and Rational's standard documents. Not only did I produce better solutions, I also found that the documentation could be shared and collaborated on with other people within the organisation, and so Business Analysts, testers and the system managers were all stakeholders and contributors throughout the whole lifetime of the project. They loved that.
  - lasereyes136 7y ago
    > can't imagine why anybody would see RUP as a bad process to follow. Are you kidding, the 90s were filled with same for and against arguments of RUP as we have about Agile and Scrum now. No process is right for everything so you will have people misuse a tool and blame the tool. The same orgs that micromanage Agile teams would micromanage RUP teams and people will be just as angry about it. RUP is a tool and is as good or bad as the people using the tool. That said, I agree with you that RUP has some benefits.

afpx 7y ago

If I remember correctly, the agile manifesto was written, in large part, as a reaction to RUP, Spiral and other heavy weight iterative and incremental processes (not waterfall, btw). Its point was to redirect teams back to the prize. In the 90s, teams were becoming too focused on the process instead of the software and customer / user. I don’t believe I’ve met anyone who ever said, “Hey, let’s do Waterfall!” More often, processes became waterfall-like when feedback loops would become too long. Sometimes, teams wouldn’t get feedback for months. Interestingly, some of the scrum teams I’ve worked with recently have succumbed to the same thing because product owners aren’t active in the process. But, you’re right - “agile” is often followed as a way to get more done with fewer people. But, unless you’re starting with a heavy weight process to begin with, you’re not going to see much productivity gain. A process isn’t going to miraculously make your developers write code faster. But, used properly, it can lessen the risk of rework.

disposedtrolley 7y ago
> In the 90s, teams were becoming too focused on the process instead of the software and customer / user. Sadly I see a lot of this today too. I know someone who has worked on an "agile" project with two half hour long standups a day, two hour sprint planning, hour long retrospective, and various other "ceremonies". I'm not sure how much of the sprint comprised of actual work. > Sometimes, teams wouldn’t get feedback for months. Feedback is so crucial. It frustrates me that business process and politics sometimes gets in the way. > unless you’re starting with a heavy weight process to begin with, you’re not going to see much productivity gain Agree 100%, The scenarios I've mentioned have always been short term (~4 weeks) client engagements where there should've been absolutely no room for needless process. I worked on a project once where we had weekly sprints (!) with a playback with key stakeholders each Friday. Each week the stakeholders would change, so each week we needed to spend at least a day planning for the presentation.
machinecoffee 7y ago
I can't imagine why anybody would see RUP as a bad process to follow. Things I like about it are: 1. It's focus on the User and the business case. In the RUP documents you have to describe what business problem you're trying to solve and make a complete list of stakeholders (this can be a wide variety of people, not just the main app user). 2. During the elaboration phase you have to describe the list of requirements and tie them to a business case - so you're forced to think about the problem you're solving. 3. During design phase you have to tie each class/module back to a specific requirement (this forces developers to focus on the real problem as stated) 4. Use cases are a fantastic tools for describing system interactions with the user, and force designers & developers to think about and provide solutions to the not-happy path in a very quick iterative way. In your use cases you should address the main requirements of your stakeholders and tie them back to the requirements doc. 5. RUP has a specific phase for transition to live, and so forces you to think about deployment, architecture, config and maintenance even before code has been written. Yes, your IT dept is a stakeholder. 6. RUP doesn't care what you use during the construction phase - following an agile methodology would be ideal in fact. 7. RUP doesn't care what you use as a project management process - it will have documents that clearly show the scope of your work and the list of prioritized requirements you have to fill before you're done, which is great for tracking progress. 8. RUP is iterative, so if you discovered something important missing during construction - go back to elaboration and work the new requirements through your design. 9. Creating and keeping up to date a fairly small set of well designed documents will lift the quality of your product. This is just my personal experience, but I found I learned a lot following the methodology and Rational's standard documents. Not only did I produce better solutions, I also found that the documentation could be shared and collaborated on with other people within the organisation, and so Business Analysts, testers and the system managers were all stakeholders and contributors throughout the whole lifetime of the project. They loved that.
- lasereyes136 7y ago
  > can't imagine why anybody would see RUP as a bad process to follow. Are you kidding, the 90s were filled with same for and against arguments of RUP as we have about Agile and Scrum now. No process is right for everything so you will have people misuse a tool and blame the tool. The same orgs that micromanage Agile teams would micromanage RUP teams and people will be just as angry about it. RUP is a tool and is as good or bad as the people using the tool. That said, I agree with you that RUP has some benefits.