Talk: Meet Trello

A couple of months ago I gave a presentation on Trello for a lunch and learn at Dynamo. Trello is a collaborative project planning tool that I was trying out at the time. This presentation shares my findings on how to use Trello for project management in an agile development context. Enjoy!

Meet Trello from DynamoMTL on Vimeo.

Ron Jeffries on Requirements

This is one of my favourite quotes on requirements:

Most of us were taught to write down all our requirements at the very beginning of the project. There are only three things wrong with this: “requirements,” “the very beginning,” and “all.” At the very beginning, we know less about our project than we’ll ever know again. This is the worst possible moment to be making firm decisions about what we “require.”

From Estimation is Evil, Ron Jeffries: Signatory of the Manifesto for Agile Software Development 

Good quote on the misunderstandings of software development

Much of present-day software acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy. (Brooks 1987 cited Larman and Basili 2003, p.52).

Source: http://www.sebastiangreger.net/writings/concept-design-in-agile-environment/

User Story Format

Something I am constantly looking up is a format for user stories. While reading The RSpec Book tonight it remind me to write this down. I thought my blog would be a good place for it.

Connextra Format (named after the company)

As a [stakeholder], I want [feature] so that [benefit].

Popular Variant

In order to [benefit], a [stakeholder] wants to [feature].

Email to a Friend: Where to start with Agile Development

Recently a friend emailed me asking how to get started with an agile development methodology. This was my reply (after a little editing to make it more "blog friendly"):

User Stories are the Foundation

For me personally, the foundation of agile is working with user stories. You must have a clear understanding of what user stories are. I would recommend checking out Use Stories Applied by Mike Cohen. This will give you a great foundation. From an estimation point of view, you might want to consider Agile Estimating and Planning by the same author. But not a requirement.

Choose a Methodology

If you’re going to use Scrum (I see that you mentioned “sprints”), to get a good understanding of the lingo and how to plan sprints etc, read Agile Software Development with Scrum

These books should give you a good foundation. They are easy read and not 400 page tombs. You should be able to get throw one in a weekend. They are based on agile after all so they shouldn’t be lengthy reads!

Get Customer Buy-in

The most important thing is that you will need to get buy in from everyone involved. “Agile Software Development with Scrum” provides some good information on this. Maybe a presentation on Scrum would be a good idea to get buy-in. Definitely choose a specific methodology and then customize as required. Since you have no experience, you need a path to follow, and you might run into trouble “just doing agile”. Having a specific methodology (probably not the best noun to use when talking about agile) will be rest assuring to the team.

Make Progress Visible

Of course, the most part is visibility. You want to be able to show visible progress early compared to traditionally managed projects. This comes in deliverables, but also what the priorities are and what people are working on right now. Don’t get too eager to deliver something too quickly. I like Scrum, because sprints are traditionally 30 days, and you never get anything substantially done early than that. Having said that, these guys got something up and running in a week.

If everybody is on site, then a war room with user stories pinned to the wall is a good start; this would be my preference. Otherwise you can use tools such as PivotalTracker or one of the new kids on the block AgileZen.

Manage User Stories

Managing a large collection of user stories is difficult. I think the concept of a story map is a great way to organize them. It gives structure to a loose collection or requirements, which builds confidence all round.

Conclusion

So in conclusion;

• understand user stories,
• organize them with a story map,
• have a war room,
• use remote user story tools only if required,
• choose a specific agile methodology (try Scrum),
• manage expectations.

And remember, make sure you are really doing agile, as it only works if you have all the pieces working together, such as customer buy-in.

Manage expectations, it will take a sprint or two before you are comfortable with the process.