An important point to consider.

1. The project and client team write end-user functional requirements as User Stories and Scenarios
2. The stories are stored as plain text in SVN or GIT and made immediately available to the development and test teams
3. The development and test teams create a few executable padder files, wrapped around these stories, turning them into fully automatable browser tests
4. The executable files are run, they read the stories and interact with the browser to determine if the stories successfully pass

Pretty cool, huh! No more massive team specific documents, just good old plain textual stories that are shared by all on the project, including the client.

Making this happen across multiple technologies

• In Ruby, we’ve already used this parts of this approach on a live project using Cucumber (formally RSpec story runner). It worked pretty well. 
• In Java, easyb seems to be the a good forward. Here’s a little more about using easyb

I am WAY TOO EXCITED to see an implementation in Java! This opens massive opportunity to progress with a technology agnostic approach. Now to find a suitable solution for .Net and perhaps PHP

It’s another one of those many obvious tests that we all do, but at times i’ve certainly found myself accepting insecurity within a project team as one of those things because the team are new to the pressures or software projects are always uncertain and as such stressful. With a little consideration, it’s clearly more useful to use perceptions of insecurity as more direct indications that change is required.

What might we be looking for? A few possible ideas:

• How secure are the developers about the quality and stability of their code?
• How secure are the developers about rolling code to the various hosting platforms?
• How secure are team members about their relationship with others on the team?
• How secure is the project manager about hitting the deadline?
• How secure is the account manager about conversations with the client?
• How secure are senior management about project and team performance?

The overall intention of improving security is to make everyone feel relaxed. Software development is meant to be fun after all!

Source: Agile Toolkit Podcast ‘No fluff just stuff 2006 tour’

37Signals don’t like his style, but in person i very much got where he was coming from – work hard and succeed! As it happens, I’m not working at his pace currently as it’s time for a family life (well, as well as working hard, just not 6-7 days a week like i have in the past), but what he says about people not pulling their weight rings too many bells!

Calacanis has more advice on “How to save money running a startup (17 really good tips)“ here

As far as the interview with Ryan Carson suggests, he’s only in it for the betterment of the human race. A truly dull and uninvolved interview

The BBC did a much better job and actually asked him why he didn’t sell out! Well done Beeb

But, what happens when we, as developers, get too close? What happens when we get too involved in the code?

It all sounds rather obvious, but it can happen:

• We don’t take a regular step back.
• We lose the wider perspective.
• We lose visibility of what ‘finished’ looks like, what parts make up the whole and how close we are.
• We strain relationships with ambiguity, overly detailed feedback and uncertainty.

Getting this wrong can result in project failure. Getting this right takes a strong, close, confident and brutally honest relationship between all members of a project team. All members maintain a focus on the scope, plan and budget; especially the seniors. Daily catchup meetings provide a platform for team members to demonstrate their responsibly to the rest of the team and a platform for all members to consistently establish their awareness of the whole. Challenge is normal and data is king.

With all this in hand, projects flow and risk is clear and manageable. Team members are empowered and in every way are a part of the solution. Resource management is possible early and in perfect balance. Reporting and escalating is possible iteratively, keeping everyone empowered and in the loop.

How do developers get to this place? More to follow…

So, my mission is to uproot the agile working methodology and get an understanding of:

• What are its parts?
• What are its predecessors and its history?
• What is its scope and who does it impact (it’s clearly a lot more than TDD, although some people don’t seem to think so)?
• Is it actually possible to “do” or “not do” agile, or is it valid to adopt only some of it’s parts (This sounds like an obvious one, but i’m fed up with hearing “we do agile” and “we don’t”!)
• How can we benefit from its many parts?

I’ll be posting more as I progress my uprooting.

Also see http://en.wikipedia.org/wiki/NeXTSTEP

Quite an interesting history and explains why OS X is such a good OS

Well done Apple! A job exceptionally well done.