How to design stuff that matters fast – Eewei Chen


Great session this afternoon with Eewei Chen as he walked us through some great rapid prototyping techniques for ideation.

Step 1: Create an empathy map / persona

Fill in the various sections creating a persona for the person you are building the app for.

The categories are:
– Behavior
– See (motivations)
– Do (features)
– Say
– Feel

Step 2: Map features – what do I want to do?

Take the features you mapped from step 1, and start flushing them out down here.

Step 3: Can I use it?

Now walk the use through using your app made up of your highest priority most valuable features.

Step 4: Elevator pitch

Step 5: Pitch it!

Special thanks to Eewei Chen for hosting such a great session. Eewei was prepared, he had the materials, all the personas were nicely laid our around the room, and you even pre-filled in our elevator pitch butcher paper.

Great session.

Thanks to Ariadna Font and Adrian Smith for being awesome partners.

I am already thinking about how we are going to spend our millions once we build it 🙂

Acceptance testing in the land of the startup by Joseph Wilk- agile2011


Just got back from an excellent session titled: Acceptance testing in the land of the startup by Joseph Wilk.

In it Joseph shared some challenges around:
– long build times with Cucumber (8 hrs but they got it down to 20min)
– the power of continual pairing of dev/ux and qa
– and the blurring of roles and how the ux designer was picking up rails skills

One of my favorite moments was when Joseph showed how they collapsed their kanban board down from this:

down to this:

Excellent stuff. Thanks for presenting Joseph.
And best of luck to your startup SongKick.

Dan Pink Drive Video


A couple have been asking where they can find the Dan Pink Drive video used in ‘The surprising science behind agile leadership’ session. It’s on youtube but you can also watch it here.

It’s not about the role – some thoughts so far on agile2011


I’m having a great time this week at agile2011. I am connecting with people. Having good discussions, and it’s just neat to see where the community and practices are headed.

But one thing I worry about is the emphasis and separation I see on roles and titles and the de-emphasis on team.

Let me give you an example. I was in a session yesterday where the presenter asked the room to list the motivations for a developer, UX designer, and product manager.

Developer had things like:
– make the code elegant
– know what needs to be built

– make the design elegant
– please the end user

Product manager
– make sure we meet our deadline
– make sure we work within our budget

(there more to each of these – just going off the top of my head)

It was a useful exercise to get everyone seeing what the world looked from other people’s perspectives, but it felt like these were things that everyone on the team should care about.

Everyone should want to please the customer – not just designers.
And should want elegant, scalable, tested code – not just developers.
And everyone should be aware of the constraints on the project – not just the PM.

When I shared these thoughts with the presenter his/her response was even more interesting. They agreed while that’s how it should work on an agile team, that’s not how it works on their team. Fair enough.

On his/her team all developers cared about was getting points! Really?

I get that not everyone is going to have the same level of passion as everyone else for certain things on teams.

But it feels like we are doing this:

When we should be emphasizing and striving for more of this:

I am believer in making it easy for people to transition by showing people how traditional roles change when working on an agile project (I don’t believe people will suddenly self organize).

But once they’ve got it, it’s good to remind people to move on and not to stop or be defined solely by their role or title. If they can (and want to) do more they should.

Treat your project like a startup

I’ve got a lot more to say on this, but it’s breakfast time and I am getting hungry (and am eager to discuss this with folks like you today while I am at the conference).

But the model I’d like to see us be pushing more is that of the startup.

Think of your project as a startup.

It’s your project.
It’s your product.
You are responsible.
No one else cares.
You’ve got to ship, and you’ve got to make sure it’s kickass, it works, it’s beautiful, all while working within the constraints of time and money that you’ve got.
There is no customer support – you are it.
There is no QA department – you are it.
Points don’t matter.
Earned value (whatever that is) doesn’t matter.
You shipping and going live matters.
And you are responsible. So make sure it’s ready.

If we just started think more along these lines, and less about “my role”, I think we’d ship better software, grow more personally as software professionals, and have a heck of a lot more fun.

If any of this resonates with you come talk to me today.
I’d love to hear your thoughts.

(and pardon any grammar or spelling – this was a stream of consciousness that I wanted to ship before breakfast)

Agile Samurai Business Cards


Something that’s been working for me at agile2011 are these business cards.

By putting the same image of the samurai on the card that appears on my book, without saying a word people instantly know who you are (if they’ve read your book).

For you authors out there who are looking for simple, fun way to promote your book, invest a couple hundred bucks, get a good designer, and get some good high quality cards made (because after all you’ve written a high quality book).

Here is a card Andy Hunt gave me after his presentation.

It’s good. It’s simple. And it’s an easy way for Andy to market and potential make contact with new aspiring authors.

So if you’ve invested all that time in writing a great book and you are out their attending conferences, get some good business cards to back it up.

And if you think you’ve got something to say, contact Dave and Andy and inquire about writing for the prags. They’re the best publishers out there and will support you all the way.

Agile 2011 Agile In A Nutshell slides


For those of you who are interested, here are the slides from yesterday’s Agile In a Nutshell presentation.

A big thank you to Jeff Nielsen and Joe Chao for putting on a great Boot Camp stage. And another big thanks to Uncle Bob Martin for the wonderful intro and set into the presentation.

Hope you enjoyed the session.

agile-in-a-nutshell slides (pdf)

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.

%d bloggers like this: