An Empathy Map is an easy to use, lightweight tool for anyone interested in an alternative to Personas. Created by the folks over at XPLANE, it is quickly gathering popularity due to it being mentioned in Business Model Generation.

While Empathy Maps are available in .pdf form, I couldn’t help but feel that people could benefit from an online, collaborative version of it.

It only takes a Google Account, a few minutes of your spare time and best of all it’s free.

Create a Google Drawing

Give your drawing a background color

Draw a large rectangle

Using the shape & line tools, draw a face in the middle of the rectangle
(tip: I used pie for eye, arc line for mouth & nose, arc block for ear)

Use the line tool to create each section

Use the text tool to add the labels to each section

Import a sticky image into your document.

Use the text tool to overlay text onto your sticky

Drag the sticky over to your Empathy Map

Copy, paste and move the stickies around as needed

I’ve shared the Empathy Map I created in this demo if you wish to get a better idea of how it is structured. It is only a guide, and you can customize it in many different ways if you like.

Should you use Test Driven Development when creating your Minimum Viable Product?

At first glance, it seems like quite the conundrum.

Agile engineering principles strive for a test first approach, but if I don’t know who my customer is how can I determine what the quality should be?

My current line of thinking is this:

If you are using Test Driven Development to create your Minimum Viable Product, then it is more likely a Minimum Product.

A Minimum Viable Product (MVP) is the smallest batch of work you can complete to gain the most learning about your customers. It may or may not be code. If you are mercilessly TDD’ing your product then it is probably much more than a fake door or concierge experiment. You’ve already committed to a feature or features that solve a customer problem.

TDD isn’t going to bring a lot to the table unless you are building out features.

So instead of asking whether or not you should TDD your MVP, perhaps you should be asking yourself if you’ve really validated the customer need for your value proposition. I would hope so, or you are adding the overhead of TDD to a Minimum Product that may not even be viable.

As you may have noticed the posts “have been a slow” as of late. This is in part that I’m really, really busy but also because I’ve relocated to San Francisco.

I’ll be spending time getting integrated into the local communities here shortly. So far it has been a whirlwind from BayALN to being scheduled to co-teach Lean Startup at Golden Gate University.

Not to mention there is this little conference called SF Agile 2012 in which I’ve invited some people you may have heard of such as Steve Blank, Josha Kerievsky, Mark Cook and William Pietri to join me on a Lean Startup Thinking panel.

Did I also mention that I’m working for BigVisible?

So yes, things are a bit hectic but don’t worry, when I’m not inventing new methodologies over lunch I’ll be cooking up some more content here on my site.

The lines between political science and organizational culture continue to blur. Those who venture into organizations need to become well versed in the dynamics of power. One such explanation of these dynamics is Steven Lukes’ the “Three Faces of Power”.

Three Faces of Power

1. Decision Making – The power to make and implement decisions

2. Non-Decision Making – The power to set agendas and therefore limit what is even being discussed

3. Shaping Desires – The power to manipulate what people think they want

Lukes’ work is an extension of Max Weber’s Three Types of Authority, in which Lukes argues that Weber only focused on the first face of power, Decision Making.

Others such as Kenneth Boulding have described these power dynamics as the carrot, the stick and the hug.

Regardless of the names used, by simply being informed about these types of power you can become more aware of your surroundings.

The Engineering Manager ordered the Developer to change his task estimate.

An order from a Manager to a Developer is the most public form of power and is an example of how the Manger wants to be perceived. This first face of power is rather easy to spot and diagnose.

This meeting lead by the Director of Engineering only had task estimation standards on the agenda.

A Director who is controlling the meeting agenda is a bit more subtle and requires a level of awareness to see. What is it that they hope to accomplish by limiting the agenda in such a fashion? Limiting the agenda is a technique used to prevent issues that could cause opposition. Do they address issues if they arise in the meeting or do they misdirect? The second face of power tends to leverage delay, inconclusive questions and bureaucracy to avoid the needs of the weaker team members. Sound familiar?

The CTO convinced his team that accurate task estimates are the key to hitting quarterly goals.

A CTO who has convinced his management team that his interests are in their best interests is far more difficult to identify and diagnose. It isn’t always obvious that the actions of the team are a result of coercion from their boss. They can convince people that their wants and needs are actually harmful to them. This third face of power is often aligned with ideological institutions.

These are just a few examples of the faces of power you may experience every day in a large organization.

I believe that being aware of these faces of power help me become oriented during an organizational transformation. Perhaps you’ll find value in them as well.

Ever walk into the kitchen of a technology company? Chances are you’ll find a mind boggling supply of candy, snacks, treats and a variety of caffeinated drinks. One could just pass this off as the bad eating habits of pale geeks who go home after work and live in their parent’s basements, but I’m beginning to believe something deeper is at work here.

New research leads me to believe that we may be collectively suffering from ego depletion.

Ego depletion is the idea that self-control or willpower is an exhaustible resource that can be used up. Interestingly enough, sugar (or glucose) intake helps us prolong our ability to make decision after decision throughout the day.

Initially it sounds far fetched, until you think about all of the decisions you make throughout a work day and how they correlate with your sugar intake.

Consider the number of decisions you had to make in order to get to work this morning. Now once you’ve sat down and booted up your machine, imagine how many decisions you make before you start to even code. After you’ve started coding (or writing your tests if practicing TDD) imagine how many decisions you continue make in the span of just 1 minute.

If you do the math you begin to realize that you make a staggering amount of decisions throughout the course of just one work day. Many of these decisions are under pressure with serious implications.

In addition to ego depletion, research has found that these decisions can be broken down into pre-decision and post-decision processes.

A prolonged period of pre-decision is not ideal for a team that thrives on quick feedback loops.

I believe we can use this new found research to help our teams be in situations where they can make the best decision possible.

Daily Standups - Urge teams to have the daily standup in the morning if possible. It is our daily plan and we need our team focused as we make decisions on what we are about to do.

Retrospectives - Bring candy or snacks into the retrospective. Team members are more likely to forget their manners when suffering from ego depletion. It isn’t just people, it even happens with man’s best friend too.

Iteration Demos - Schedule these early and bring muffins, donuts or pastries along with some form of juice. If the Product Owner is accepting the work, he or she needs to have the mental fuel to make the tough decisions.

Feedback Loops - How long does it take to compile and run tests locally? How long does it take to deploy a build to test or production? How long does it take to get an answer from the business on feature question? All of these affect pre-decision time spans and deplete willpower.

Some of these suggestions may sound like common sense, but I believe if we can align our techniques with these findings that the result will be a team that is in an environment where they can repeatedly make good decisions.

impediment – a hindrance or obstruction in doing something: “an impediment to progress”.

When you are an acting ScrumMaster or Agile Project Manager, it is common to seek out impediments so that you can help to remove them. Before you know it, impediments seem to be all around you ranging from the individual, team and organizational levels. A person can quickly feel consumed and overwhelmed by this new found responsibility.

A few years ago I was having a conversation with a colleague about all of the impediments I’d uncovered and how I needed to remove them as soon as possible. About half way through the conversation he interjected “These are not impediments, these are merely the tasks we need to complete our user stories”.

Then it dawned on me, I was so focused on removing impediments that I had begun to view our tasks as blockers to progress.

I was wearing impediment colored glasses.

Luckily for me I was pulled me back into reality before I started having conversations with the team on how every task was a blocker. I may not have made it out of the team room alive.

So how can you determine what is and what is not an impediment?

Tip #1 – People are not impediments
As tempting as it may be, do not label people as impediments. Once you label a person, you begin to subconsciously dehumanize. People can certainly be challenging to work with, but once you cross that bridge to labeling them as blockers it can be difficult to bring them back. If you find yourself doing this, you may very well be wearing impediment colored glasses.

Tip #2 – Impediments are often types of waste
If you find yourself struggling to determine whether something is or is not a blocker, try comparing it to the common types of waste in lean.

• Transport
• Inventory
• Motion
• Waiting
• Overproduction
• Over Processing
• Defects

These types of wastes do not always line up 1-to-1 with your blockers, but they can be a helpful guide in determining whether or not you are off base with your assessment.

Tip #3 – Ask your team what they think
It was a team member who pulled me back into reality, however not all team members are assertive. Who’s to say that the ScrumMaster is the sole designator of impediments? Ask your team what they think. It will give you the opportunity to do a bit of root cause analysis. Quite often, what you see as a blocker is only a symptom of something deeper.

These are just a few tips that I’ve found useful navigating the treacherous landscape of impediments.

What else has helped you identify blockers with your team?

AgileDC is a wrap and I’m pleasantly surprised by the turnout (400!) and quality of presentations. Other than me being absent during the keynote (you know the one where Sanjiv was looking for me) and the fact that my car was locked in the overflow lot with David Bulkin… I have no complaints!

I will call out two specific moments that really caught me by surprise and made the conference for me:

Siraj Sirajuddin’s session on The Influencers Mantra – This session blew my mind. It challenged the way I approach agile adoptions and stripped many biases away in the process. Siraj has a mojo about him that is rare. His session could have easily been several hours on one bullet point alone.

LeanKitKanban conversation with Jon Terry – I had met Jon once before at Agile2011 where we spoke about all of the cool things that the Startup America Partnership was doing, but this was the first time that it dawned on me how LeanKitKanban was different. It is a kanban tool applied as kanban. It also allows you to do what you need and then gets out of your way. I cannot say I work with too many tools that can do this elegantly. I found it refreshing to see people bootstrapping it up and not attempting to please everyone by turning their product into bloatware.

The other highlight of my experience was of course the Retrospective Workshop I facilitated sans-slides. I think this freaked out the conference help as they had to track someone down that could turn off the projector and raise the screen. It was based on an earlier workshop in which I’m iterating on using a Course Canvas. Needless to say people were skeptical at first but I won most of them over by the end. The ROTI graph only had 1 vote below average, which I find promising.

I’ve posted a few videos of the session below. Bonus points if you can find Dave Rooney.

One last note, if you are active on Twitter here are many of the handles of the local DC area agilists that were in attendance. I highly recommend following them!

Sanjiv Augustine
Siraj Sirajuddin
Tonianne DeMaria Barry
Paul Boos
Derek Huether
George Dinwiddie
Bob Payne
Max Keeler
Devin Hedge
Manoj Vadakkan
Richard Cheng

AgileDC will need a bigger venue next year and I’m looking forward to it!

In attempting to create courses and workshops to educate people on agile techniques, I found that I’ve struggled to find the right flow.

So I created a tool to help me do just that.

Introducing the Course Canvas.

It uses techniques rooted in agile and visual management to allow me to craft a course with less effort than a cumbersome outline.

It is also a Minimum Viable Product, as I only built just enough to learn whether or not you will find it useful.

Take it for a spin and let me know what you think.

The folks at DZone were kind enough to invite me over for a chat during Agile2011 to have a conversation about agile, kanban and lean startup.

In case you have not already heard, there is a recent press release on Scrum.org with regards to the adoption of Scrum Extensions.

Today’s announcement marks a new era in Scrum’s evolution by making available a public mechanism for providing feedback on the Scrum Guide and a model for proposing extensions to the basic framework.

Now I’m all in favor of extending Scrum, and even the name Scrumology (apologies to Kane Mar who probably gets a fair amount of my hate mail) was my take on all of the ways in which you may need to extend it to succeed in your organization. In fact, I’ve taken quite a bit of criticism for my rather progressive take on the Scrum philosophy over the years.

So on one hand, I feel somewhat validated that Scrum.org has opened it up for extensions.

On the other hand, Scrum no longer belongs to Jeff Sutherland & Ken Schwaber.

Scrum belongs to you.

It belongs to Project Managers who stepped into the ScrumMaster role and felt the pain of letting go of years of ingrained command and controlism.

It belongs to the Product Owners who doubled their workload as they assumed all of the duties of the role while still performing their Product Management job.

It belongs to the Developers who threw up their hands in frustration when they realized their existing engineering practices were woefully outdated and had to be radically changed in order to potentially release every iteration.

It belongs to the Testers who realized having stories thrown over the wall to them on the last day of the iteration was unacceptable.

It belongs to the Graphic Designers who let go of their holistic design tendencies and learned to compromise in iteration releases.

It belongs to anyone who tried Scrum and watched it fail in a spectacular fashion because the organization was not structured to support it.

I could go on and on as there as so many stories to tell, but my point is that we’ve been trying and failing at Scrum for many, many years now. We’ve learned Scrum the hard way, where theory is stripped away and we are left with the reality in front of us.

I have the utmost respect for Jeff Sutherland & Ken Schwaber, but this notion of submitting Scrum Extensions for approval is a troubling one to me. I can only hope that they will not assume the role of yet another gatekeeper.