22

As I understand, the idea with Agile methodologies is that you deliver something functional and you deliver it often. The application gets into its final shape increment after increment.

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.

What gets delivered to the client in these first iterations? How do you show progress in the right direction when you build scaffolding code?

svick
  • 9,999
  • 1
  • 37
  • 51
JohnDoDo
  • 2,309
  • 2
  • 18
  • 32
  • 2
    Building an entire framework or foundation should be a decision made as late in the project as possible. – JeffO Jan 07 '14 at 18:05
  • @JeffO: what do you mean as late as possible? Can you expand that into an answer? – JohnDoDo Jan 07 '14 at 19:17
  • 5
    Ideally, it shouldn't be a decision at all. A framework shouldn't be created, it should emerge organically as a result of refactoring. No "good" (for my own subjective definition of "good") framework was ever designed from scratch, they were either extracted after the fact from existing applications or based on other frameworks that were. – Jörg W Mittag Jan 08 '14 at 02:38
  • 7
    @JohnDoDo building a foundation upfront assumes you know what the requirements of your application will be before it even exists. Every time I've seen people do this, they wound up with something that was rigid and very difficult to work with. More often than not, the users of that "framework" wind up fighting it more than embracing it. – Stefan Billiet Jan 08 '14 at 11:59

7 Answers7

16

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 out every scaffold item in the first sprint or 2. Maybe parts can wait and be added later.

Maybe your first sprint has "Create webpage X with dummy data" so that you can get something shiny to show your customer. And then the next sprint has "Change webpage X to use data from the database".

ozz
  • 8,322
  • 2
  • 29
  • 62
  • 6
    +1 for the last paragraph - it is a good idea to start development with a prototype intended for user validation. – Konamiman Jan 07 '14 at 15:55
  • 4
    "Maybe your first sprint has "Create webpage X with dummy data" so that you can get something shiny to show your customer.": IMO it depends on the customer and on the project's time scale: For a 2 month project, a customer may want to see something in 1 week or 2. For an 18 month project, one may find it OK to get a first demo in 1 or 2 months. In any case, while some customers may like to see a dummy page, others may want to see something more meaningful and get the feeling you are wasting their time. I think you cannot generalize. – Giorgio Jan 07 '14 at 16:33
  • Generally when you're ready to develop, you wouldn't build a prototype to get the customers sign off, that should be completed already. You might have a prototype which wasn't a "throwaway" somewhere in the requirement notes in which case you can wire it up to real data. By the time you're ready to start a sprint the timelines should be established and expectations should be set so showing them something for the sake of showing them something seems a bit off. You'll be better off saying you can expect screen X by date Y. – hanzolo Jan 07 '14 at 16:43
  • @Giorgio - I wasn't generalising. It was an example. I don't even know if he is building a website, or will have a database. – ozz Jan 07 '14 at 16:43
  • @hanzolo - I said "2 week sprints are TYPICAL". This sentence allows for other sprint lengths to exist :) – ozz Jan 07 '14 at 16:44
  • @Ozz - Totally, I've removed that last sentence from my comment – hanzolo Jan 07 '14 at 16:47
  • @Ozz: What I meant is that as a customer I would understand if programmers need a couple of weeks before they can show any meaningful result. Also, I would prefer to have one demo a month instead of having one a week in which I only see trivial functionality increments. – Giorgio Jan 07 '14 at 17:24
  • 4
    +1, but always, always keep the iceberg secret in mind when showing UI parts to your customer http://www.joelonsoftware.com/articles/fog0000000356.html – Doc Brown Jan 07 '14 at 17:42
  • @hanzolo - so, when did this prototype get built? Scrum doesn't have a "requirements" phase in which this stuff is developed--the requirements, design, construction, and tests all happen within the context of the sprint. – Matthew Flynn Jan 07 '14 at 21:13
  • 1
    @MatthewFlynn - Scrum may not have a true "requirements" phase, but that doesn't mean there are ZERO requirements or documentation available. I've never been involved with a project where a customer said "just go ahead and start building and we'll figure it out along the way". I think there's a term for that. Usually there should be some kind of elicitation phase of a project which includes some discussion and agreement as to what is going to be delivered. I've presented prototypes during the sales pitch – hanzolo Jan 08 '14 at 00:12
  • 1
    @hanzolo - A very successful project I worked on recently involved implementing a solution to deal with a new legal requirement that was part of the Affordable Care Act. The basic requirements were known, yes, but there was nothing in the way of a prototype or design in place as to what the solution might be. The project team (which included business analysts) figured it out within the context of the sprints. At best, the BAs would be talking to business folks about stories a sprint or two ahead of the rest of the team, but that was all we had to work with. It worked well. – Matthew Flynn Jan 08 '14 at 05:52
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 (you'll never need it) items. Unfortunately, those frameworks you are talking about are often a big liability in this area. The developers start building in all the stuff that the framework MIGHT have to support and suddenly you are 3 months in and don't have anything of business value to show for it. Then it turns out the framework doesn't even really support what they end up needing.

So the suggested approach is to build only what is actually needed now, and deliver it now.

This does NOT mean that you can't build reusable parts and the like, you just always do it in support of building a current need. Moreover, it does not mean you have to completely wear blinders to what's coming down the road--don't build things so that it's impossible to change/enhance them later. But the key is to always be delivering business value.

There often are some key things that absolutely need to be established before anything can be delivered, such as setting up environments and the like. For these things, a lot of teams find it useful to have a "Sprint 0" in which the groundwork is laid. Sprint 0 can be a bit longer than your other sprints, in that it is not applied to your product backlog or burn-down, but it should still be time-boxed to a reasonable duration.

Matthew Flynn
  • 13,345
  • 2
  • 38
  • 57
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 actually persuading customer to accept such a thing is completely different matter.) For example, you might show the customer's business experts your unit/acceptance tests that express what the domain should do and that code passes it with green result. Or even better, make the business experts help create those tests.

There is also question of

you might build the framework or foundations

Which I believe is much more important than what is actually delivered. There is big thing for Evolutionary Design, which says, that you should create the architecture over time instead of trying to create it in the beginning. As for foundation, this usually means some kind of database or UI framework. In which case, there is idea of "Good architecture is one which allows you postpone important decisions." And choosing database or UI is an important decision. For example, you might be fine with just in-memory storage for data instead for trying to use DB from the very first iteration.

Carson63000
  • 10,510
  • 1
  • 28
  • 50
Euphoric
  • 36,735
  • 6
  • 78
  • 110
4

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 is important to get this right as soon as possible.
  • Give the users a first glimps of how the application will look like. This helps the users and the developers to understand what they really want and need.
  • Have a basic idea about how the architecture of the application will look like (the application should cover the basic 'layers' or components of the application).
user99561
  • 334
  • 1
  • 5
3

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 add a CI story, if you neeed a physical server, sure, add a story for that.

But start delivering on Day 1 and never stop!

Sklivvz
  • 5,242
  • 19
  • 34
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 real work. Lots of people argue what should be done in this sprint, but in my opinion, it is finished when you can start working on the items in the backlog. This step includes setting PCs, setting build process, picking frameworks, etc.

When you are done with sprint zero (or iteration zero), you can start working on your application. Take items from the backlog, and finish them one by one. After you finish iteration one, you are going to have something useful. The first iteration usually includes some of most important features.

What gets delivered to the client in these first iterations? How do you show progress in the right direction when you build scaffolding code?

After iteration zero, obviously you do not have anything to deliver. The deliverable comes after iteration one. It contains features that you set for the iteration.

If your question is "how to pick what goes into iteration X?", then take a look into these videocasts (videos for iteration 0 A and part of B).

BЈовић
  • 13,981
  • 8
  • 61
  • 81
  • +1 for being the only one to mention iteration zero – crad Jan 09 '14 at 23:48
  • I do not consider setting build process and picking frameworks tasks for sprint zero. How can you know which framework you need if you don't know what to build? I always limit sprint 0 to a bare minimum. Get people PCs and find a space where they can sit. Find out who you need to talk to from the business. Setup a first planning meeting. I apply YAGNI to the rest. – user99561 Jan 10 '14 at 08:51
  • @user99561 Frameworks are big decisions, and usually hard to change. For example, you should know whether you are going to use gtest or cppunit for unit tests before starting to write code. Changing it later is going to be huge pain in the ass and lots of time wasted. – BЈовић Jan 10 '14 at 09:13
  • @BЈовић : Yes frameworks are big decisions, that is why you should postpone the decision. There is no point deciding on a framework if you don't know what needs to be developed and how the application and architecture will look like. You should decide on what framework to use on the last possible moment. Otherwise you definitely run the risk that you have to change it. – user99561 Jan 10 '14 at 13:43
  • @user99561 If you do not know what needs to be developed, then you can not even start :) The requirements and user stories have to be written down, otherwise the iteration 1 can not even start. – BЈовић Jan 10 '14 at 14:35
  • @BЈовић : requirements and user stories can be written down in the planning meeting, at the start of iteration 1. I just wanted to make the point that you need to think very carefully about having a sprint 0, it doesn't deliver any business value to the user. All decisions made in sprint 0 can also be made in sprint 1 or later, while delivering business value to the user, and while having a much better understanding of what needs to be delivered. You mentioned YAGNI, I add make decisions as late as possible. Both result for me into a very limited sprint 0, or no sprint 0 at all if possible. – user99561 Jan 10 '14 at 17:27
  • @user99561 You are kidding, right? In an agile shop, there isn't iteration 1 without requirements and user stories. I do agree with delaying decisions, but at the start of iteration 1, all has to be clear (or at least major stuff). – BЈовић Jan 13 '14 at 06:59
1

Early iterations, especially the 1st, will contain or should at least plan for architectural spikes, which include a certain amount of discovery time and maybe some architectural prototyping.

Like you said, generally, there are structural requirements which may not mean much to the stakeholder / customer, but are required to form a strong platform or pattern orientation. You cannot get around this as you can't start building B until A is complete.

Part of the Agile approach is to have the customer close so documentation is not needed because all you need to do is pick up the phone / send email, and it's expected. The customers expectations should be set appropriately and any work completed should be very terse and NEEDED. No gold plating, no "You might need it", etc.. Build what you need in A to move onto B.

Depending on how you're attacking the project, you may only build out the required foundation in order to complete a certain module, so during the sprint planning meeting you would lay out the plans for the current sprint based on the priorities set forth by the customer, depending on what is needed for that sprint, there may be some foundational requirements, so that's what goes into sprint 1. After the 1st sprint is complete and A has been built and then plan to complete B.

If you've agreed on a timeline with the customer, as long as you're going to meet that agreement, the customer probably won't care what you do 1st or 2nd. You could always show them the unit test results, but if you say we'll have something for you to see after sprint 2 (or 3), and you deliver, it will set a strong precedence. Customers are expected to be reasonable as much as developers are and both are working towards the same goal. A completed project which meets the needs of the customer and works as expected. So worrying that there's nothing to see after sprint 1 is a moot point because the customer just wants to make sure that after sprint 20, the project will be done(-ish).

hanzolo
  • 3,111
  • 19
  • 21