Speaking at Agile 2011

Leave a comment

agile 2011

I’ll be giving two talks this year at Agile 2011 in Salt Lake City Aug 8-12.

Agile In a Nutshell
The surprising science behind agile leadership

Agile in a nutshell is an intro for people who have heard the hype and are looking for a clear simple explanation of what agile is and how it works. Perfect for those looking to make the transition from traditional waterfall.

The surprising science behind agile leadership explains how self directed teams work, the science behind why so many choose to work this way, and the impact it’s going to have on you and your organization.

And if you are going, I would love meet. Here are a few sessions I plan on attending:

Coaching Success: Getting People to Take Responsibility & Demonstrate Ownership: Christopher Avery, Ashley Johnson

What do CIO’s *really* think of agile?: Edward Yourdon

Critical Success Factors for Acceptance Test Driven Dev’t: Jennitta Andrea

Design Thinking: Mary Poppendieck

How to design stuff that matters fast: Eewei Chen

Hope to see you there!


The rise of the generalist


People love labels. As soon as you meet someone they instantly want to classify you. Web designer? Gen-Y? Level 50 Shaman? Shffft – you’re labeled.

Same thing happens on software projects. Whenever we form teams we naturally want to know the role each of us is going to play: Developer? Analyst? Tester? PM? Bam – you’re labeled.

Labels are fine, but they can stop you from thinking. ‘It’s not my job’ to worry about how the application works, or that there’s a bug with the print screen. QA or someone else on the team will pick that up.

When you think you are defined by a role or a title you are.

But we all know the most valuable members on our teams are usually those who can where multiple hats.

It’s the developer who has a passion for testing.
The tester who can code.
The analyst who thinks about design.
And the designer who has a passion for the business.

As agile gets more mainstream, I think we are going to see more and more of this style of work.

The rise of the generalist.

Where no single team member is limited by a role or title. Multiple people simultaneously where multiple hats. Much like a startup.

Dan Pink sums it up best in Drive: The Surprising Truth Behind what motivates us.

If we are truly going to empower our people, and let them do whatever it takes, then we better get out of their way and support them in playing whatever role(s) they need to play.

So don’t let a title or role stop you from serving your customer. Use whatever innate skill and ability you’ve got.

And if this subject of how agile teams work is of interest to you, come see me speak at Agile 2011 in Salt Lake city where I will be presenting a talk titled The Surprising Science Behind Agile Leadership and what really motivates us.

The way of the Spartan Warrior


There’s more to successful projects than time and money, but if you ask the people with the money, they’ll tell you that time matters a lot.

In this post I am going to show you one sure-fire way to quickly figure out how realistic your budget and schedule are and how to reset expectations like a pro when you need to.

How much can you afford

One of the great strengths of agile development is the leeway you get in building any given feature or story.

You can build it cheap. You can give your customer something with just a few bells and whistles. Or you can build them the Taj Mahal if they want that.

This looseness around high-level stories gives customers a lot of flexibility when making decisions about features. They can go light on user interface spit and polish if they are building a back-office invoicing system. Or they can invest heavily in look and feel for the tablet application insurance adjusters are going to be taking with them to into the field.

The challenge for you (and your customer) is to get a sense of how much they can afford right at the start. We’d all like the deluxe version of whatever it is we are building, but not at the expense of the budget or the schedule. As Steve Jobs likes to remind us, “Artists ship.”

To help our customers figure out this balance, we need a way of quickly confirming that we

  • have enough time and money to build the system they want, and
  • have a sense of how much they can afford in terms of bells and whistles that would improve the product and experience.

One way to get there is to start Spartan.

The Way of the Spartan Warrior

The Spartan Way is built around one really simple, common-sense premise: If we can’t build the Ford Focus version of the system with the time and money we’ve got, there’s no way we can afford the BMW.

So the way we figure out what we can afford is to build a few bare-bones core features, measure how long that takes, and then take a fresh look at the plan and see how realistic things are looking.

Once you can see clearly that the current plan doesn’t support the scope of what’s on your plate, having this conversation with your customer is much easier.

Yes, we’d like to build the world’s greatest automated invoicing system, too. It’s just that we can’t get the bare functionality in place (much less any of these other whizbang features you’re asking for) with this schedule and timeline—we’ve tried!

No wishful thinking. No guessing. The truth is self-evident.

This is really the crux of agile planning. We don’t know when we are going to be done until we build something of value, measure how long that takes, and then update our plans accordingly. I realize that some people (i.e., executives) don’t like hearing this, but this is the reality of software delivery. All we are doing here is eliminating as much schedule risk as we can up front, giving them a heads-up early on about how things are looking.

What to do if the plan is wrong

If the the plan is wrong, we have two options for bringing reality back into the fold:

  1. We can reduce scope (recommended).
  2. Or we can flex on the date.

Reducing scope is how agile developers prefer to keep their commitments and avoid the pain that comes from asking for more time and money.

There is always going to be more to do than the time and money allow (that’s just the reality of any interesting project). And if we keep adding features we’ll never ship anything.

So when given the choice we’d rather fix our dates and flex on scope.

If, however, there is a core set of bare-bone features that just have to be delivered as a whole, we can commit to delivering that core set of features. We just have to be a little flexible on the date.

Even in this scenario we will still need to flex on scope a bit (because new things are always going to come up). But we can go in with the understanding that these high-level core features need to be there and that we are going to ship as soon as these are done.

Pushing out the date a little is OK, but it’s not a good habit to get into. For one thing, it’s just too easy. Secondly, it puts your project in danger of delivering no value. Until you get it into production you haven’t an ounce of value, and agile hates that.


So if you suspect that your project has some scheduling challenges, try building a few spartan core features, see how long that takes, and update your plan to reflect that reality. If things are going well, swell. Keep on truckin’.

Otherwise, work with your customer to set them up for success by either reducing scope or suggesting they be prepared to wiggle a bit on dates.

Doing this early will enable you to have this conversation with conviction in an open and honest way. And your customer will appreciate knowing the facts at the start of the project instead of near the end.

%d bloggers like this: