Agile Development -- a "building a house" analogy

[Darren Dirt]

http://www.nsftools.com/blog/blog-08-2005.htm#08-24-05

TL;DR key excerpt:

Month #1: I chose a floorplan and got a foundation. Good work. Not exciting, but it's a start, and I know that foundations are important or something. Let's go for a bathroom next month.

Month #2: The exterior walls are up because some foreman guy said that was the next step, but still no bathroom. I really want something that's finished. Come on, we're being iterative and agile here. Give me a deliverable.

Month #3: They succumbed to my iterative approach and I finally have my bathroom. Oh, sweet bathroom. The walls are a little rough, but at least we're not spending time on that stupid "architecture" and "framework" crap. I'm getting results I can see. Next month I want a family room.

Month #4: Family room is done, but I've noticed that the drywall in the bathroom and family room is looking pretty bad, because there's been a lot of rain and there's still no roof. Why is there no friggin' roof? Okay, let's work on the roof for our next iteration, but I want all the drywall fixed too.

Month #5: We have a roof and new drywall in the two finished rooms, so I'm going to pick a new room to work on this month. How about the upstairs bonus room? Wait, stop yelling at me! What do you mean I didn't tell you I wanted an upstairs bonus room? Can't you just tack one on? That's what builders do, isn't it? Just build it! This is my house, and that's what I want.

etc., etc., etc...

http://www.nsftools.com/blog/comments.php?commentid=082405 , cf. "Big Design Up Front" http://www.joelonsoftware.com/articles/AardvarkSpec.html

[Thorin]

Building a house is a poor analogy for describing how software is created, because the cost of re-architecting a house once construction has started is so many times higher than the cost of re-architecting a piece of software.

Agile development, in my mind, always had some kind of vision for the software being made, but many of the details aren't sussed out until it's time to develop each piece.  To me, this means an agile project has a kick-off meeting and an initial brainstorming session that yields a decent amount of high-level use cases.  These use cases will have to be boiled down to finer-grained detail, but they give a good sense of what the overall software should do.  This is stated in a similar way on the Wikipedia entry for Agile Software Development:

The Agile Manifesto states:

   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.

Anyway, this blogger complains about how Agile doesn't work after trying it on one project by himself.  Having an agile expert at hand to help guide him probably would've made his experience better.

Looking at that Wikipedia entry more...

Agile methods are sometimes characterized as being at the opposite end of the spectrum from "plan-driven" or "disciplined" methods. This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined". A more accurate distinction is that methods exist on a continuum from "adaptive" to "predictive".

[..]

Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future.

[..]

Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently.

Now go back to the blogger's complaint:

I am, as you are reading this, in the middle of the third total rewrite of the application. I think this time it's finally going to work, but I'm just fed up with the whole mess.

Sounds to me like he's trying too hard to be predictive - instead of rewriting the entire application, just rewrite the portion that needs changing and the portions that depend on it.

Of course, this is always easier said than done.  However, sometimes you just need to stop looking at the big picture and focus on one piece of the picture.

[Thorin]

By the way, you didn't bother offering your own opinion, just cut and pasted someone else's opinion.  What do you think about agile development?

[Darren Dirt]

By the way, you didn't bother offering your own opinion, just cut and pasted someone else's opinion.  What do you think about agile development?

I always liked it as an idea*, from when I first about it and its variants. Depending on the toolset, it's tough to implement in reality in any decently-sized project, especially if unit testing and refactoring are not easy via the toolset (of the linked stuff above, one of them is from the perspective of a fellow Lotus developer, who strongly believes it to NOT be a good "agile" environment... I tend to agree, although because of the nature of my projects [smallish] and the size of my dev team [me] I also tend to act agile-esque in how I get my stuff done at work the last few years...)



* an in hindsight, in very general terms, I always from since I can remember tried to develop "in reverse", imagining the finished product -- if not the finished user manual -- complete and being efficiently used by the happy end users ... then I kinda divided up the total app into pieces that would work on their own, so if as I got thru some of the development I realized I needed to redesign things, I had less likelihood that I would have to rewrite "everything". I never did like the old 1970s methodologies where you had to figure every detail out before you started any coding (i.e. the "80% design, 20% actual coding" myth) to me that seemed to limit the flexibility that experience tells you is required to make a decent business solution (i.e. the client never tells you everything, and even if they do, you will never know in advance the technical obstacles that might get in the way of you getting everything requested working together, and even if you do it's unlikely to be done in the time the client expects, and even if it is, by that time the client will have a bunch of new and probably contradictory ideas of how they want the damn thing to work by then...) so without realizing it I was "looking" for the "agile" philosophy, before I was even "trained" in the dev field (when I just hacked away for fun in my pre-teen and teenage years, spaghetti code be damned...) I really haven't had any chance to actually do "full, genuine" agile development, though. A lack of both tools and time/opportunity, I guess.

[Thorin]

It might be that you just haven't had a team member who is experienced with agile development to push you to try things that you haven't tried before.

For instance, I used to talk about proper automated unit testing, but didn't do it until I worked with a developer who did.  Seeing how he wrote his code, I started doing it as well, and then ended up liking how my development cycle went.

[Darren Dirt]

It might be that you just haven't had a team member who is experienced with agile development to push you to try things that you haven't tried before.

For instance, I used to talk about proper automated unit testing, but didn't do it until I worked with a developer who did.  Seeing how he wrote his code, I started doing it as well, and then ended up liking how my development cycle went.

Like I said, 99.44% of my "projects" are all up to me (at least, the parts I work on -- the Websphere/JSP part is done by a couple of good guys, but we're not exactly part of a "team" in the sense where we can break up the tasks and agree on standard ways of doing stuff etc.)


In a future career locale, I'll probably voice my interest in AP/EP and hopefully somebody'll let me give 'er a try...

[Mr. Analog]

The only time I've ever had success in large team development is with two things:

1. A team committed to working in an Agile fashion
2. Management that understood it and promoted it

The problem we ended up with is that the client didn't know what they really wanted and were disengaged from the agile process (we'd give them releases at the end of two week sprints but they didn't seem to understand that what they were seeing was what they were getting). That's the accepted story by the way, the working theory within the team was when our PM left prior to UAT the business took advantage of the new, shall we say naive, PM that didn't do any real prep or crosstraining for taking over the project, but I digress...

The important thing to kinda grep about agile is that a lot of people think it's a rigid set of rules, it's not, it's just a way of organizing information and creating milestones (something managers and programmers tend not to be very good at). By pairing down big goals into small iterative goals they become easier to consume and of course change.

It's best suited for projects that undergo a lot of expected course corrections during development and if you start to veer off course you can self-correct by reviewing the burn down chart and listening to client feedback. In fact I've been able to take elements of agile development and bring them into purpose for an ongoing AMS project.

Some purists will declare you can't bring parts of agile to a project without losing the importance of the process as a whole, and to a degree they are right, but I've worked on a couple projects now that have benefited from formalizing around agile and modifying it to fit.

As for analogies, software isn't a donkey, nor is it a 19th century mill though I'm sure there are people out there that could draw parallels between them at the drop of hat. Software is software and it is what IT is