D'Arcy from Winnipeg
Solution Architecture, Business & Entrepreneurship, Microsoft, and Adoption

Dev Teach Day 2 - Jeremy Miller and How Design Gets Done on an Agile Project

Tuesday, November 27, 2007 7:26 AM

First session of the day is Jeremy Miller and talking about designing for agile projects. The first thing that I noticed is that Jeremy looks different from his picture...he's taller than I expected and his hair has grown out a bit...his selection of sweater is Vancouver-Fall Sheik...WTF, am I Justice Gray all of a sudden?

Room is starting to fill up...these seats are really close together. Holy crap...standing room only...there's a bunch of people standing in the back...15 or so people probably.

Woah...Jer is ANGRY...he's used the term "Fud" already to describe what he heard at a recent tech event regarding design...I'm glad I'm not in the first row...his fists are clenching...he's turning green...no...no, it's ok...he's good...

Jer drops a comment about Bellware disagreeing with him on something...the curse of the angry Smurf surfaces again...Jer let's it slide and moves into his next point though...

On a serious note, Jeremy's presentation was fantastic and gave a great overview of how to design using Agile projects. The basic message that I got from it was:

- Design continuously
- Design simply
- Design together

Designing continuously means that there is no BDUF (big design up front). You design continuously, providing value early and often based on the highest priority features...and you work vertically by features. This means that you design only what you need for that feature. That means that you don't go and spec out the entire database schema, or build the entire data layer, or anything else that is beyond the scope of the feature you're focussing on right now. Jeremy used the term "Work Vertically By Features" to sum this idea up.

Designing simply doesn't mean designing easy...it means that you design (and code) your solution in a way that is easy to understand by someone else. A simple design can still be complex, as long as its designed in a way that, again, is easy to understand by someone else; the code isn't something that you need to reference reams of documentation to understand.

Designing together talks about how the teams are setup in an agile project. Socialize, talk, and challenge the design regularly, and make sure the team knows the 'Why' behind a design. Teams should also be flat: don't separate into UI, Logic, DAL developers; keep them flat and empower them to develop end to end for the feature being worked on.

There was a tonne of information that fleshed these out even more, but this gives you an idea of the key messages. He also mentioned that some authors to check out for more on this type of topic is RobertĀ MartinĀ and Martin Fowler.

Now one thing that wasn't covered in this session was how to approach topics around estimating Agile projects and how to deal with questions around budget, cost, and estimating. David Laribee has a session this afternoon that will deal with this more...watch for a report on it.

D




Feedback

No comments posted yet.


Post a comment