Home
About
Contact
Monday, June 09, 2008

On Friday we had some friends over and enjoyed the beautiful weather in Bergen. I and (let's call him Trond) were sitting outside talking a bit bout work, agile, .net and java. I fired up the grill to throw on some burgers and I went in and out quite a few times to get stuff I needed. First I went and got the meet I needed. At the same time I also got some lettuce, ketchup and mustard. I went out again and threw the burgers onto the grill, keeping the conversation going with Trond. Then I went back in, got some plates and some grill equipment I forgot last time. I went out again and starting flipping some of the burgers. I then realized we needed something to eat with, and went to get some knifes and forks, as well as a couple of beers. Back out again, I flipped the burgers, went in again and found something else I needed.

When I got out again Trond said: "I must say you really ARE agile! You even barbeque agile! Only getting what you need there and then and not planning too far ahead."

And he was right. This is how I am. Somebody might say chaotic, others agile :-) Maybe that's why I was so easily convinced about the agile way of working.

But seriously, one of the most important aspects of agile development (from my perspective) is the idea of postponing all decisions to the last responsible moment (note: it's responsible not possible). This will let you be more adoptive to changes and force you to not implement things you don't need (e.g. it's very tempting to implement something that you think you will need in the future). On a traditional project where "everything" is planned up front (a waterfall like project), you often run into problems where you see that the way we thought about the solution back then is not the way it is today. This might effect the architecture in a big way. If you're being told to stick to the planned architecture, you find yourself creating workarounds to fit the architecture, which probably is not the best solution.

Wednesday, July 02, 2008 12:36:49 PM (W. Europe Daylight Time, UTC+02:00)
I think you're right. And most people I know usually fix problems recently identified instead of "planning" through problems. That's why Big Planning Up Front seems artificial and fails.

However, sticking with a common known plan brings another benefit over "break and fix" mentality: it communicates the state of the system. Where you are and where you're going so everyone gets on the same page. I believe the balance between planning, adjusting through feedback, and communicating the updates to all stakeholders is a golden rule to follow.

And lastly, I've never tasted your burgers so I wouldn't know the success from this approach ;)

B-)
Wednesday, July 02, 2008 9:10:39 PM (W. Europe Daylight Time, UTC+02:00)
Actually my burgers got a bit too done. Probably because I had to go in and out so many times :-) But that can be compared to another XP/Agile "rule". Don't be Done, but Done Done! ;-)
OpenID
Please login with either your OpenID above, or your details below.
Name
E-mail
(will show your gravatar icon)
Home page

Comment (Some html is allowed: a@href@title, b, blockquote@cite, em, i, strike, strong, sub, sup, u) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.  

Live Comment Preview
RSS RSS - Comments Twitter LinkedIn
         
SEARCH
 
 
         
TOP POSTS
   
         
NAVIGATION
   
         
CATEGORIES
  .Net (39) Agile (22) Ajax (5) Architecture (2) Blogging (11) Books (1) BPEL (1) CSharp (6) DasBlog (5) Database (2) DDD (1) Deployment (11) DSL (1) Events (26) ExtremeProgramming (3) Fun (5) Gadgets (3) IIS (6) Java (1) Linq (2) MemoryLeaks (5) Microsoft (34) NDC (2) NNUG (26) Other (8) Patterns (3) Scrum (13) Security (2) Silverlight (4) Software (17) TeamManagement (8) TechEd (7) Testing (4) Tools (19) TvGuide (1) Vista (15) VisualStudio (14) WCF (6) Web (11) Windows (6) WiX (5) Work (12) Workflow (2)  
         
ARCHIVE
   
         
BLOGROLL
   
         
ON THIS PAGE...