Don't just review at the end

One essential part of Scrum, that few practitioners argue about, is the end of sprint review. This is a great place to showcase the work completed within the that sprint to any interested parties, but in some teams this is also the first time the product owner gets to see the completed stories.

What happens if a feature isn't quite right, or if we've misunderstood what was wanted? We run the risk of features not being accepted.
Even on a 1 week sprint, waiting until the end to review is too long.

Instead of waiting, collaborate with the product owner throughout development through a series of informal reviews. The earlier you start these the better. By doing this we get feedback earlier, so if something needs to change you haven't gone too far down the wrong path.

Even if you've created mockups its not until the feature starts to become real that we find out if everything is practical or possible.

Frequent informal reviews can this lead to optimizing the created value within the story by producing a better end result. It can also lead to a happier product owner.

Please let me know what you think.

Don't use Scrum because it has no technical practices

Spend enough time in the agile community and you'll hear someone make the above statement at some point. This is normally referring to the fact that Scrum doesn't make an explicit recommendation to use practices such as Test Driven Development (TDD) or Continuous Integration (CI) etc.
To me this sounds like a way to rationalize a decision not to do Scrum. That's their decision, Scrum isn't for everyone and it's not the only successful way to be agile (XP, Kanban etc). I just don't think the above argument is a valid one and shouldn't be used to sway someone in favour of another agile methodology.
Scrum doesn't need to explicitly outline these practices because it's a framework that can be used outside of software development as well as within. When done well it implements all of the practices and values, whereas some of the technical practices might not be right for your development environment.
I'm not saying that Scrum practitioners shouldn't use the above technical practices I just don't think that they need to be mandated (I personally recommend TDD, CI etc for my teams where appropriate).
Also because Scrum is a framework it gives us the flexibility to use any current or emerging practices, technical or otherwise. In fact most scrum practitioners I've spoken to encourage people to actively seek out and experiment with other ideas provided that they don't conflict with the Agile Manifesto or Scrum values. This was also mentioned in a Scrum Alliance update by Mike Cohn where he states that Scrum is not enough.
Finally, practices such as TDD and CI have successfully migrated out of XP and have taken a life of their own. I see more technical and non-technical practices doing that in the near future. This will allow skilled practitioners to mix and match based on the environment.
If you agree or disagree please let me know. I'd love feedback.

Physical vs virtual sprint storyboards

Every now and then the idea of adopting a virtual story board (or a more comprehensive agile management system) comes up in a retrospective.  As new reasons to adopt one come up I explain my reasons not to do so. Of course it's up to the team as a whole to decide.

Until someone comes up with a whiteboard size touch screen that a team can interact with and work with just as effectively I'm not sure I'll change my position.  Feel free to try and change my mind though.
In this age we seem to have the need to put everything we do or interact with into some sort of application. Anything that isn't is deemed old fashioned or inefficient.  I feel that sometimes we throw the baby out with the bath water.  Remember the first value of the agile manifesto:

Individuals and interactions over processes and tools.

With traditional storyboards we have a common place to gather and re-plan everyday, in real time. At the end of planning or daily stand-up we have an updated board that everyone in the team can see at anytime. The visibility of the board helps us be accountable to each other.   Another benefit is that if a team member adjusts the board in some way, the team has an immediate visual clue.  This can get lost in an application where updates can be made transparently.

During planning any member of the team can participate in writing stories, creating tasks, assigning estimated hours and signing up for tasks, rather than having one person responsible.
There's also something to be said for physically signing up for tasks as opposed to doing it in an application.  It makes me feel like I've made more of a commitment.

Recently our managing director likened our efforts to WWII generals with their battle plans. I love this analogy as I feel it fits well with what we're trying to do and makes me feel like she gets it.
Another thing that is hard to overlook is that it's easy to get up and running. All we need is an empty wall, index cards, sharpies and blue tack.

Though I love technology in a meeting it can be a distraction. This is especially true for the stand-up as we need to be focused.  Communication is key and things like computers, mobile phones etc can disrupt our focus.

It's also very easy not to look at a digital board as you have to actively access the appropriate part of the application.

We can also adjust our process, if the team decides to, that might be in ways not supported by an application.  You don't have your processes dictated by a tool.

Admittedly there are some drawbacks.  The ones that I've encountered are as follows:

The board has to be torn down and recreates every sprint.
It's hard for people that are working out of the office to see and update.
Charts such as burndown charts, cumulative flow diagrams etc have to be generated manually.

I'm sure there are others, feel free to comment below with other examples.

The first and last items are really non-issues for me as they don't really take too long, but they are tedious to do.

The second item is a legitimate concern for permanently offsite team members. For those that are working from home for a day I normally suggest that they sign up for tasks before they leave the day before.  There isn't an easy answer to this that I can think of unfortunately. We're going to experiment with a wireless webcam.

Is that really enough of a business case for adoption of a tool? I'll leave it up to you to answer, you can probably guess mine.

[Update]
I've just started taking photos of the storyboard and uploading them to our wiki after the daily stand-up.  We'll see how that goes.