Balsamiq is an excellent tool for rapidly creating purposefully low-fi wireframe mockups

Napkee enables you to import Balsamiq mockups and turn them into HTML prototypes! Lovely!

Axure is excellent for rapidly creating interactive prototypes.

Liferay Portal is a pretty awesome portlet container that, with a bit of UX (HTML, CSS and JSP) hacking, enables you to rapidly produce fully functional portals. It comes with a vast array of portlets out of the box, saving you a whole load of time.

JQueryUI is a lovely toolkit for quickly developing interactive prototypes. I’m not completely convinced by it as a production tool (heavy JS? but i could be wrong), but excellent for prototyping

Part 1: Collectively clarify what happens on projects now (on projects that do not use stories)

It was a highly interactive session and i first asked attendees to collectively draw on a whiteboard the project process as they saw it, with all of the project’s actors, products and interactions.

What was drawn resembled a kind of mashup of a UML activity diagram with swim lanes & a gantt chart. It showed what the individual actors in the process did and when, and who fed into who in the process.

Part 2: Clarify what documents are written and the associated risks and costs

When the whiteboard was complete, I asked the attendees to consider a number of things:

1. At what points during the process are documents produced and by who?
2. Of those documents produced, which are directly focused on the business and user requirements?
3. Of the many producers of those documents, which of these producers had their focus on the business and user requirements?
4. Of the many documents produced, which were open to interpretation and translation?
5. What are the perceived risks of having so many documents and periods of documentation translation?

When this work was complete, a few points became clear to the group:

1. The project team, as defined on the whiteboard, was greatly separated into areas of expertise and each was concerned about their area of expertise
2. Interactions between actors were mostly through written documents
3. Few actors following this project process retained a direct focus on the business and end user requirements
4. A lot of documentation was being written and much of it was being duplicated, at times to protect actors within the process
5. Vast amounts of document interpretation and translation was going on to produce each document

Part 3: Consider stories

After this part of the session was complete, i gave some examples of the wonderfully simple story DSL and then suggested that many of these documents could be replaced by stories and scenarios:

1. I explained that stories can be used to clarify both high-level requirements and detailed solution definitions. I described how stories can be expanded through the use of scenarios.
2. I described how everyone on the project, including the client, can understand the wonderfully simple DSL and contribute to the bank of stories.
3. I then came in with the ace Stories can be used to drive automated browser tests! Man, they fell off their seats at the point!

It was an awesome session. A lot was discussed and understood.

My intention is to have the Rails app on a separate server from the Hudson server and have the Rails app return Hudson-friendly XML from RSpec and Cucumber tests. When i get this to work, it’ll enable me to roll this out at work, with a central Hudson server (perhaps) that interacts with multiple app servers of various technologies and, along with the wonders of Sonar, gives a view into code test coverage, pass rate and complexity. I feel that i might struggle convincing Sonar to play with Ruby, but we’ll see.

Why Hudson?

To be completely honest, at work, i didn’t make that decision and am yet to chase down exactly why it was chosen over CruiseControl, but I completely trust those that made the decision on their project. I’m a big believer in standardising and am as such following suit and trying out Hudson.

I started the quest ages ago and have progressed it, but more in practice than in reading. Now’s the time for the reading to pick up again…

“The basic premise is that before any code is written, a team takes a story (or rough idea of a requirement) and fleshes out that story by producing an executable ’story test’.

Opponents say that STDD is ‘cowboy coding’, or ’snake oil’, or just ‘a hindrance to real work.’ Proponents argue that STDD produces the simplest system possible and is the wave of the future, the new frontier.”

All written in 2004! I’m just happy it’s finding its feet in smaller web agencies now. Well, at least the one work for (yes, i’m kind of pushing it)!

Here’s also a lovely PDF:

http://www.industriallogic.com/papers/storytest.pdf

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’

Scalability is an old story, but meebo.com’s challenge was different. They needed to scale in ways that asynchronous web apps (facebook, myspace, twitter etc.) do not.

• They use the long-polling technique that results in the web server maintaining thousands of open connections with each user and that has significant affects on the server. 
• They have a single gaim instant messenger process per user to allow the user to connect to MSN Chat, Google Chat, etc. and this had other effects (and significant benefits).
• They initially used Apache and it had some affects.

It was clearly a fun challenge to have and as their user numbers ramped up, they followed a streamlined and effective approach that resulted in a lean, fit for purpose and extensible app. A great success story.

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.