19

There's absolutely no "Agile" problem with having a fixed release date if you're prepared to move one of the other two edges of the "iron triangle": the requirements for what needs to be in that release, or the resources you have available. You can't fix all three - and in practice, the "resources" side of the triangle is very often either not very flexible ...


15

It is typical to have 2 week sprints. For me, the first sprint or 2 will likely have less "visible" features than later sprints for this exact reason (for some tenuous description of "less"). That being said, it certainly should not take you 2 weeks to build your entire scaffold and have nothing in the UI visible to show for it. Maybe you do not flesh ...


13

The Agile Manifesto suggests that Working Software is more valuable than comprehensive documentation, and the Scrum framework takes this notion to suggest that delivering tested, working software with business value to be a requirement every sprint. Why? Well, among other things, designers and developers often fall victim to spending lots of time on YNNI (...


13

The agile solution might be not to replace all in one go, but to phase the replacement in gradually. Introduce the new system gradually, bit by bit, keeping parts of the old system running. The old system isn't switched off all in one go, it just fades away. The new parts provide new functionality or other benefits, so the users are delighted to use them. ...


8

What gets delivered to the client in these first iterations? What has highest business value for the user. For example, if the applications has complex business rules, the first iteration(s) will only contain those business rules encoded in the form of code. Customer should be satisfied as long as you have code for those business rules. (The problem of ...


7

The official Agile answer is that this simply should not be allowed. Unfortunately, as you are experiencing, the reality is that this often happens. Sometimes this is because business requirements change too rapidly even for short sprints. Sometimes this happens because of pure bad planning on the part of the product owner. And unfortunately sometimes ...


7

If it is not a temporary endeavor, I think the term "project" does not fit well. But you did not only ask if the term "project" applies, but also "can these project management methods and frameworks be applied?". Sure, you can probably try to use a full-blown project management approach for iterative software development by interpreting each cycle as a mini-...


5

In Scrum, as defined by the Scrum Guide, the Sprint includes "Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective". So the answer to your question from Scrum's perspective is yes, planning your iteration (and also reviewing your iteration) are part of the iteration itself. However, Scrum is not the only way ...


5

The Sprint is the container for all the work that is done in the sprint, this includes Planning, Sprint Review and Retrospective and all the work in between. Nothing prevents you from adjusting the Burndown to start on day 2 and target teh day before the sprint review. The Spritn Burndown is never meant to be followed along the ideal line. The ideal line ...


5

Rather than re-writing the existing system (which as you mentioned will take quite some effort before the new system matches the existing functionality), consider the strangling vine approach. Basically, you implement new functionality using your new approach on top of the existing application. Eventually, as you address shortcomings of the old system to ...


5

The main concern (I have a similar problem with my job) is that if "The Process" demands that you deliver certain artifacts at certain times, and no one is allowed to challenge the almighty "The Process", then if you try, you will loose! It's not just a simple matter of it being a better way (Which iterative doc development is). So what you need to do is ...


4

It sounds like you are describing what Steve McConnell called Waterfall with Subprojects. In this methodology, you waterfall through conceptualization, requirements engineering, and architectural design. Then, for every major component, you then proceed through a detailed design, coding, and testing phase. At the end, you integrate the components in a system ...


4

Releasing small increments into the world might work for greenfield projects but even then the small number of features might not be too useful. Scrum advocates that after each sprint that the product is "Potentially Shippable". It does not have to be shipped but has to have the quality of a shippable product. If you do want to give users an incremental ...


4

There are many good answers here already -- I just wanted to point out one other feature. When you use planning poker, you get an instant measure of how big disagreements are on size of work. If I think it's a 2, and you think it's a 3, we can just call it a 3 and move on. But if I think it's a 1 and you think it's a 5, we'd better discuss.


4

Agile did start as purely software development methodology, meant to fully replace waterfall and other process-heavy methodologies. All people who created Agile Manifesto were either SW developers or managed software development projects. It even says "Working Software over comprehensive documentation". And it's Agile Principles are clearly concerned with ...


3

Planning is part of the sprint. It seems like you are looking at a sprint as if it was a block of time set aside for programming and testing. That is not what a sprint is. A sprint is a block of time set aside for a team of people to work together on a problem. Part of that work is coding, but part of that work is planning, part is the demo and ...


3

What we try to do is to deliver in the first iterations the simplest application possible (a hello world version of what we are delivering). We see 3 important benefits in this: Setup the delivery procedure (always one of the most difficult parts imho) (get environments, servers in place, update security for this environment). As we will deliver often, it ...


3

I think the problem in many Agile camps is with the word deadline. The risk with a deadline is that you assume you know what needs to be done. As you point out, you can't have a deadline for an unknown. What is described in Philip's answer is far less a deadline than a constraint. We could say that we have funding until March and so we must make the best ...


2

I worked on a massive line of business application replacement for a major national cable tv network. The new system development was done with SCRUM, it was about a 18-24 month development project to re-implement almost all the major sub-systems; which were approaching 10 years old. There was a planning phase of like 6 months before the development started,...


2

I still think agile adds a lot of value in this scenario. It's just that you have a very defined end goal of 'replace the current system.' Agile techniques and processes can still get you there more effectively. For instance: You can still deliver on the system iteratively and in small sprints. You can still use agile techniques to prioritise the ...


2

Since you know what you want your project to do (for the most part), and there's no constant interaction with a "customer", using an iterative approach may introduce unnecessary overhead. I feel that iterative approaches are best suited to small teams that can communicate frequently with a customer that may change requirements on the fly. Seems like you ...


2

I believe what you're looking for is The Spiral Model. From the wikipedia page, "The spiral model combines the idea of iterative development (prototyping) with the systematic, controlled aspects of the waterfall model. "


2

Everything you say in your question is absolutely true, though I have a feeling that many companies don't actually go through quite the same thought process as you. Your thought process is (more or less, for any significant piece of code) "I need a day to write it, a day to debug it, and a day to refactor it." Your company is saying "You need a day to ...


2

You can deliver pretty much anything you want. The building the infrastructure idea is simply wrong/not agile/unsustainable. For example: building a fully functional Hello World app can be built in hours. Bringing up a server (even temporarily) in the cloud or as a VM can be done in hours. These are enough to start developing. Then, if you need CI, you can ...


2

But in the early iterations you might build the framework or foundations on which the application will stand so it's something important but not visible to users. This is wrong, since you do not need to build a framework you may use in the future. The idea is to build only what is needed (see also YAGNI). In the sprint zero, you need to prepare for the ...


2

Yes. Unless they've changed it since I last studied in about 2004, the PMBOK definition of a project does require the endeavor to be finite in duration with solid objectives and scope. That being said, I think that modern software projects can be treated and managed effectively as a "project". There is nothing in the PMBOK definition of a project that says ...


2

Yes, it can exist. It would mean that you build the whole product from start to finish, then throw it all away and start all the way from the beginning. This is actually sometimes practiced during the prototyping phase, but usually not for the actual product. I guess it is more common in research than in commercial development. E.g. MIT used to develop a ...


2

Saying that waterfall has one set of SDLC phases and agile methods have their own phases is incorrect. Both plan-driven and adaptive methods are ways of looking at systems development. Regardless of which methodology you are using, you are going to do the same thing - you're going to initiate an effort or team, you're doing to define some concept of what it ...


2

Agile is a technique, not an outcome. Comparing to lawn-mowing, one iteration is like one line of grass that you have mowed. If someone says "mow your entire lawn in 15 minutes", and you are using agile, perhaps you will complete 30% by the end. Then you will iterate some more later and finish it.


Only top voted, non community-wiki answers of a minimum length are eligible