« How "Agile" Is The Concept of Scrum? | Main | Interview on Agile Coaching at QCon London 2010 »

31 March 2010

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00e54ee21bf288340133ec5daf6e970b

Listed below are links to weblogs that reference Is Working Outside-In Always Better?:

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

Account Deleted

Thanks Rachel for bringing up this topic.

When I was doing my little "Avatars of TDD" experiment (http://blogs.agilefaqs.com/2007/12/14/avatars-of-tdd/), I found TDD practitioners could take the same problem and approach it using either the Outside-In or the Inside-Out approach quite nicely. Obviously each person had their preferences. Also the tool used, the choice of programming language and paradigm influenced their technique quite a bit. I could see trade-offs in both scenarios. So I don't believe in ONE best way.

Personally I don't choose just one style. Depending on various criteria (listed below) I choose which approach I'm going to start with. I & most programmers I know go back and forth between Outside-In and Inside-out.

I tend to make the decision based on the following criteria (just a list of things that comes to my mind right now, I'm sure there are many more criteria):

* Familiarity with the problem - How clear the problem & its solution is.
* Stage of the feature/Project
* Prior Knowledge/Experience with the technology stack and implementation details
** If its completely unknown, one might spike it out or build a throw-away prototype. Having the prototype in front of you, can influence which way you start.
* Whether your goal is to go breath first or depth first.
* Whether your goal is to get low hanging fruits first (easy first) or core first (highest risky items first)
* Whether you are driving the design or validating the design (test driven or test first).

Inside-Out and Outside-In also applies at a product level. Which massively influences our development style. For Ex: if the original idea about a feature/product is about a core feature that needs to be built. We could start building just the core idea, getting feedback and then slowly flush out the rest of the system as we build inside out.

It appears to me that, this topics needs a lot of context. Any discussion outside that context might dumb down the importance of this topic.

Philippe Kruchten

Wouldn't the Technical Product Owner be very close from what other people like me would call the "software architect"? Or as someone suggested to me last week in a workshop in Sydney, the "Architecture Owner".

Note that here is more in software architecture than just infrastructure, though infrastructure plays a big role.

Philippe

Rachel Davies

Philippe, yes, I'd say a good candidate for Technical Product Owner would be a software architect (not all organizations have formal role of architect). I'd say a Technical Product Owner might represent infrastructure needs from system admins too.
Rachel

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.