Brad Storm at MIT Sloan

Instead of putting them up against each other, why don’t we think of them combined? In fact, combining the two words I like the best within software, Agile and Architecture, (oh, the phrase “it works!” is still my favourite though), an Agile Architect seems like a pretty good role to have on board! But what are the characteristics of an Agile Architect?

(more…)

After reviewing my previous post, I realised that the agile developer should be presented in an even simpler form. Seriously, that’s what an agile developer do: develop things as simple as possible, but no simpler. Ensuring that what is created match what is wanted by the customer, and the code written actually works.

(more…)

After attending a MSDN live meeting in Bergen today, I was introduced to several of the new technologies with the Microsoft.Net 3.0 framework. There were two things that caught my attention that I will describe in more detail here: (more…)

I came over a blog talking about being a software architect in an agile world (codebetter.com/…). Agile missionaries weren’t very fond of the term “architect” as it too many times ment a person drawing up som schemes for the developers to implement, a part of the waterfall-dinosaur development process, soon to be extinct. Still, is there a place for architects in todays software development?

(more…)

So, there you are, the iteration is on and you get assigned / choose a task for you to do. Some project manager has decided what tasks should fill this iteration and it’s up to you, the developer, to come through with a solution. As a developer you have to relate to several parameters:

• What’s the time frame for this task?
• What is this task really about (details and purpose)?
• How does this task fit into the big picture (the application as a whole)?

To answer these questions, agile development introduce the DOMAIN WALKTHROUGH

(more…)

Practice doesn’t make perfect. Perfect practice makes perfect. If you want to be the best football team, you need to have the best practices. That’s why I’m stressing practice HARD:

(more…)

There’s a lot of focus on agile methodologies. And the coices are almost endless: Scrum, extreme programming, feature driven development, the crystal family, agile RUP and many, many more. Although they all have their own domain, their own rules and tricks, they’re also well connected through the Agile Manifesto (www.agilemanifesto.org).

In short, agile development is about creating quality software according to what the user wants, not necessarily what the customer has specified up front. To do this, the agile team strips down the requirement spesifications and starts working on it, piece by piece. Every part is discussed, tested, developed (in that order), refactored, tested again and acknowledged by the customer. The agile teams are self-organized, transparent in their work and with a great team-spirit attitude.

But for the lone programmer, who want’s to become a member of this agile party, what can he do? What happens when the team member commits to a task and goes back to his desk, asked to come back with some working code that meets the requirements? This is what this blog is all about. Welcome to the agile developer: the guy who delivers quality software within a changing environment of uncertainty, excactly as the customer wants it.

(more…)

After much experiencing, I’ve come to the conclusion that much can be gained by introducing a zone cover in younger football leagues to accomodate the limited passing abilities of the young quarterback.

The idea comes from the phrase “Rush a good quarterback, cover a poor quarterback”. Most young quarterback, although with a descent arm, have a tendensy to avoid reading the defensive alignment and keeps looking for the open receiver. This is something a defense can exploit for big turnover possibilities.

(more…)