Latest Carnival of the Agilists is up

The latest Carnival of the Agilists is up.

If you haven't seen of these before, it's a collection of links to essays, blog entries and resources on various topics from some of the best minds in the Agile software development community.

The editor rotates, so there's always a fresh perspective on what's worth reading.

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Scrum Reference Card

Ran across a useful (and free) quick reference PDF for the Scrum Agile method for managing software projects.

Scrum has really gained some momentum over the last few years, perhaps in part from the now ubiqiutous certification program (Certified Scrum Master). It's a deceptively simple framework for Agile project management, consisting mainly of a few rules around creating a product backlog, priotizing work into 30 day "sprints" or less, daily meetings or "scrums", self-organizing teams, and the key: inspecting and adapting continually to improve based on real-world feedback.

Anyway, here's the link, courtesty of Contrado in Australia:

Scrum Reference Card PDF

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Agile Project Management and Competitive Advantage

I wrote earlier about what I consider to be the core of why Agile methods work - small wins and increasing momemtum.

Now I'd like to offer a rationale for why anyone managing a software project should at least consider using an Agile approach for managing releases, if not for the actual development itself.

Turns out it's the same rationale as above - small wins.

The primary job of management is to ensure that customers are getting outstanding value (this makes them cheerfully continue as customers), while controlling costs, and reducing risks to the business.

In software development, value mostly takes the form of features - things that help the customer make more revenue, reduce costs, or increase productivity.

Of course, until the features are actually delivered, put into production, and leveraged by the customer, no value can be realized.

This means that your management won't know if they're doing their job until you've delivered software to someone, and they tell you it's solving the problem they had.

So if you put on your management hat, would you like to know this sooner or later?

Looking at the risk side of the equation, the more features that are in development for an extended time period, the higher the risk that customer needs will change. Not to mention technology, market conditions, company budgets, and leadership.

Now, there's obviously a limit to how frequently you can deliver value, isn't there?

Your customers couldn't handle a new release every month, right? What about every week? Shocking!

On the other hand, what if you delivered just one important feature that didn't break anything? Or that didn't require re-training, extensive documentation, tedious software installations, database migrations, follow-on patches, and numerous support calls to take advantage of?

What would your customers think then?

If software vendors (or internal IT development teams) could deliver incremental value whose benefit far exceeded the cost of upgrading, what might customers say about your company or team?

And if your competitors couldn't do this as effectively (for internal teams, your competitors are outsourcing firms), would your customers accept them as substitutes?

Agile methods aren't just about making your programmers happy, they're also about delighting your customers, saving your CEO's job, and mkaing your less agile competitors very unhappy.

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Is Your Software Team Sticky?

One of the most challenging things on a software project is making sure that the core ideas and vision of the system are well understood by all of the team members.

Without that shared vision, the team is likely to pull in different directions, even with frequent communication. Extreme Programming calls this "Metaphor", but I think that doesn't go far enough.

What's needed is something "sticky". Something easy to remember, logical, and simple that can form the basis of the little decisions that we make every day when creating software. A Prime Directive, if you will.

An example might help here.

Susie Songstress has a vision of a new website that will put singers and songwriters together to create beautiful music. She sees this as her life's work, and is dedicated to improving the world through music.

Susie hires a team of Agile software developers and explains her vision. They set to work brainstorming stories, asking Susie lots of questions, having her prioritize the work, and away they go.

Meanwhile, Susie goes to put on a concert to end hunger for a week, and asks the team to continue working. How can the team make good decisions while she's temporarily unavailable?

Susie leaves the team with a core message:

We help create the simplest, most effective forum for singers and songwriters to find and work with each other. We are an online Woodstock, dudes.

Armed with this core idea (which could be boiled down to "Online Woodstock, dudes"), the team is ready to make decisions with Susie in mind.

Their first challenge - Susie never mentioned what fields the registration page should have.

Fred, one of the developers, thinks all registration pages should ask for name, address, phone number, email, and birth date.

Ursula, an interaction designer, remembers Susie's message, and says: "If we were at Woodstock, dude, would we want to be hassled by the man for all this information?"

Fred says "Hmmm, I see what you mean - how about just a first name and an email address for now, with the other fields optional?"

OK, this is a bit contrived, but the point is that with the right core idea, teams can be empowered to make the best decisions they can when the customer is not available.

This is not a license to forgo conversations whenever possible with the customer, but it is a useful tool for embedding the project vision and values into as many people as possible, especially new or distributed team members.

How do you spread your vision?

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Small Wins: Agile Psychology

There are many theories as to why Agile methods work.

I'd like to suggest that a very small core element is responsible for much of the energy and ultimately the success of Agile development projects:

Small wins create momentum. Continous small wins create tremendous momentum.

OK, but what kinds of small wins are important in software projects?

• How about early positive feedback from customers?


• Or early clarification of an important feature (that leads positive feedback later)


• Early detection and resolution of defects before they lead to not-so-positive feedback.


• Early proof that you can build and deploy the software somewhere other than your own machine

These types of small wins have a subtle, but critical effect on everyone on the project team. Developers feel valued and are motivated to continue satisfying the customer. Customers feel heard and in control, and begin to develop trust for the development team. Stakeholders see regular progress, and begin to feel less anxious about project outcomes. Testers get an early look at the software, and are able to add value much earlier than in typical projects.

I went on a hike a few months ago that was basically an entirely uphill climb. There were no real twists or turns, just a straight incline. After about an hour on continuous climbing, I just gave up. This was partly because I was exhausted, but also because I had no idea how much further it was to the top. There were no clear indicators of progress, nothing to feel good about, just more turns of the road, and nothing but up to look forward to.

Similarly, software projects that offer no short-term wins can be depressing. Even the best team can feel unmotivated and lose steam when the project drags on and on without feedback, interim releases, or other signs of progress.

Agile methods promote frequent delivery and rapid feedback. For me, this isn't just a nice-to-have side effect, it's the only sustainable way to create great software.

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams