After a brief hiatus to catch my breath following the conclusion of the Summer of NHibernate screencast series, I am pleased to announce that the initial installment of my next screencast series is now available for immediate download from a brand new (but just as butt-ugly 
) dedicated site: www.AutumnOfAgile.net.
Iteration -1 ????
This first installment is entitled ‘Iteration -1’ since its really not related per-se to the actual project for which the series will be documenting the development process. Instead, this installment is focused on explaining the Agile software development value proposition, its core fundamental assumptions and premises, and other high-level concepts that will form the foundation for the techniques that we will explore during the rest of the Autumn of Agile series. ‘Iteration 0’ will begin with the next installment where we will focus on understanding the project requirements and look at ways to organize and flesh-out our User Stories, I promise.
Warning: no Code Found Here
Just a friendly warning: there is no coding in this installment. Instead, this screencast is a delivery of a slide presentation that I gave much earlier this same year to some of our own staff to assist them in understanding more about Agile principles and methodologies and why they matter.
Iteration (pre)Planning
By way of setting some expectations, here is the present planned focus for the next several installments of the series as it looks today:
Iteration -1: Agile Value Proposition and Principles
Iteration 0: Project Overview and Organizing User Stories
Iteration 1: Development environment organization and beginning the design of the solution
Iteration 2: Domain Modeling
Iteration 3: Completing our first User Story with value
Iteration 4: no idea, this is Agile so we’ll know what to do when we get here 
Iteration X: we’ll see how many of these we actually need
Loose Planning
As you can see, I’m taking advantage of the Agile nature of the project to use Agile to plan my screencasts too; I know more or less what I want to cover, but don’t have a good handle on exactly when it will come up in the process of the development of the project. But I have a loose expectation of how long everything will take and so that’s good enough for me for now. I will be refining the schedule as we get further along and I have more info at my disposal with which to get more specific with my planning.
As always, your comments, feedback, input, and otherwise are much-appreciated.
WOW…. Dint expect you would start the series so soon… I am waiting for the second one already!! :). Way to go steve.
@Vinay:
Autumn marches forward (here in the northen hemisphere at least!) and so I must as well 🙂
Agile is Cool..
the traditional approach you explained is horrible because i was a victim of a project after spending weeks developing we are told to stop that the project financial has organise a presentation on the project and we have nothing to show. Since then i googled the net to find some other to develop, then i read about Extreme programming and Agile development.
but never had the chance to play around with it. but now you are just in time.
So, I’m not the only one pleasantly surprised to see Autumn of Agile follow so soon after the end of Summer of NHibernate!
Just curious, but based on the discussion of the class design stuff at the end of the screencast, where do you tend to draw the line when it comes to SRP, IoC, LSP etc? In other words, do you think there’s such a thing as too much, as lots of interfaces and dependency injection results in too much complexity, which results in a different maintenance issue?
Oh, you’re right… The colour scheme on the new website is pretty scary! (still better than most stuff on myspace tho)
@James:
This is a good point (the one about the over-architecting of things, not the one about the poor color scheme…well, ok the one about the bad color scheme is actually a good point too 🙂 ).
I think that its entirely possible to go too far with some of the principles of OO design that I like to follow; for me that’s why I consider them to be ‘principles’ rather than ‘laws’. I use them to *guide* my work rather than *define* it.
That said, many if not all of the Agile approaches to software project management are *heavily* dependent on the ‘suppleness’ of your solution design being able to change locally without affecting your solution globally. This is, after all, how one can actually get started coding before perfectly knowing every little detail of every little requirement beforehand.
I believe very strongly that when new req’ments surface (or existing ones are futher refined/clarified) in subesquent iterations, its the ability of your existing software to adapt to these in a very flexible manner that really enables the Agile approaches to work in the first place. Given this, its *generally* better to err on the side of over-flexibility rather than under-flexibility but I think you are 100% correct that this (like nearly all other design choices) is not without its downside if taken too far.
I once had a conversation with another of our developers where we were discussing this very issue (increasing complexity in the codebase to support future predicted changes) and I think that what this comes down to for me is that in any project there are those areas of the req’ments and spec that you feel are pretty solid (lower chance of a need to change) and those areas that you are less certain of (higher chance of a need to change) and that you focus in on 100% (well, as close as you can come to that) uncoupled code in those areas where you are less certain your design is ‘right’ and have some freedom to get less ‘perfect’ with your design in areas that you feel more ‘certain’ about the stability of the req’ments (and thus the ‘correctness’ of your code).
In times past, developers would tend to solve this “I just don’t know yet” problem by developing complex configuration subsystems that would let the code be ‘comtrolled’ by outside config files, a database, or whatever. I think to some degree, the intense focus on loosely-coupled systems represents another (and probably better) way to achieve the same kind of flexibility with a bit less effort than some massively-configurable business rules engine for example.
One of the very important Agile principles that supports this whole ‘not knowing everything before starting’ is the notion of delaying every decision in the system until the ‘last-responsible-moment’ and a lot of this complexity in the OO design is intended to support just that kind of capability.
In the upcoming series, we will definitely have the opportunity to watch me struggle thru exactly that very kind of challenge as I design and implement the solution, making constant trade-offs about what level of abstraction does or doesn’t make sense in different contexts.
I guess the comments I get will tell me if my choices are the same ones others would make 🙂
@Steve:
Thanks for the quick/well-reasoned reply – I’m glad we agree! 🙂
I guess the only thing that I’d probably add at this point is that refactoring is definitely your friend, so whilst it is always worth thinking about the flexibilty of your design, it’s also worth remembering that you can refactor things later on too, i.e. if (when?) you realise it’s no longer appropriate.
Incidentally, slightly more pastel colours might be better! 🙂
[…] Comments James on Autumn Of Agile: Iteration -1 Screencast is Availablesbohlen on Autumn Of Agile: Iteration -1 Screencast is AvailableJames on Autumn Of Agile: Iteration […]
Thanks for this – i also appreciate your great effort in nHibernate series- which really helped me.
@Steve
Is it possible to get your powerpoint files ? (same question for NHibernate)
Thanks,
@Kris:
Why? The reason I ask is that they are done in ppt 2007 and many people are still in 2003 or earlier. Would PDFs suffice…?
@Steve
When I “forgot” something an argument, a detail, … it’s easier to read than replay the video and find the right moment.
ppt2007 it’s ok for me. I can may be done a “pack” (PPT2007 + PDF)
Steve – Thank You! My Favorite Principle has to LSP! It has such an awesome name. I have used the building metaphor for years. I remember once telling someone that you can’t add a floor in between floors once the building is built What a schmo!
I am gladly punting the metaphor.
Chuck