Richard Kasperowski agile, mobile, and more

The best of the best: family-size team in a family-size space

noreply@blogger.com (Richard) — Tue, 27 Mar 2012 12:00:00 +0000

I build great software with great people. We need a great space in which to do it.

For the last year, we’ve been experimenting with an open plan collaboration space. Instead of working as individuals in cubicles, we work together in a space with no walls between us. For the first six months, we loved it. Knowledge and learning were in the air, and they spread spontaneously amongst team members. Everyone knew what was going on without asking. Junior team members barely had to ask for help, and their skills increased dramatically. We coalesced as a very good team and wrote some very good software.

Then we enlarged the space and added more people. We started complaining that it was crowded. It looked messy and unattractive. Knowledge and learning were still in the air, but the space was noisy and distracting.

We learned that open plan collaboration space is great for team collaboration, as long as the team and the space are family size—no more than seven people, in a space that’s about as big as a family room in your house. Enlarge the team or the space beyond family size, and it feels crowded, messy, and chaotic.

I awoke a few days ago with the inspiration for better space. We played Perfection Game together, and we arrived at this:

I work in my living room.

I'm working on great things in a great place: my living room. I'm sitting in a comfy chair with my computer on my lap. There's a table in case I need to draw something by hand. I have bountiful espresso, fruit, and snacks nearby.

It’s so much fun, so cozy and welcoming, that my friends want to be there every day with me.

Sometimes I need quiet time, so we have nearby rooms where we sit alone once in a while.

Logistically, for a small tribe of about 20 people, we’ll need to split up into three family-size units, with one collaboration space each. Each collaboration space will be the size of a living room. All the spaces will be adjacent to each other, so we can still work together as a super-team. Each room might have a different theme: the living room, the art room, the game room, etc.

We’ll build out our new space this month, and continue our experiment for the best possible workspace.

Perfection Ping Pong

noreply@blogger.com (Richard) — Tue, 20 Mar 2012 12:00:00 +0000

Source: http://en.wikipedia.org/wiki/File:Ping-Pong_2.jpg

Perfection Ping Pong is derived from the Perfection Game, one of the McCarthy Technologies Core Protocols, and inspired by TDD Ping Pong. This game will support you in your desire to aggregate the best ideas with people who are available only via communication channels such as email and IM.

Player A and Player B are partners in this game. Player A "serves" an idea for perfection to Player B. Player B "returns the serve" by perfecting the idea. Players "paddle" the idea back and forth until it is perfect.

Steps

Player A writes the description of an act or an object. He sends it as email or IM to Player B.
Player B composes a written response. He rates the value of the performance or object on a scale of 1 to 10 based on how much value the Perfector believes he or she can add.
Player B writes, “What I liked about the performance or object was X,” and proceeds to list the qualities of the object he thought were of high quality or should be amplified.
Player B offers the improvements to the performance or object required for it to be rated a 10 by saying “To make it a ten, you would have to do X.”
Player B sends his response to Player A.
Player A responds similarly, beginning at step 2
Players continue until the idea is perfect.

Commitments

Accept perfecting without argument.
Give only positive comments: what you like and what it would take to “give it a 10.”
Abstain from mentioning what you don’t like or being negative in other ways.
Withhold points only if you can think of improvements.
Use ratings that reflect a scale of improvement rather than a scale of how much you liked the object.
If you cannot say something you liked about the object or specifically say how to make the object better, you must give it a 10.

Notes

A rating of 10 means you are unable to add value, and a rating of 5 means you will specifically describe how to make the object at least twice as good.
The important information to transmit in the Perfection Game protocol improves the performance or object. For example, “The ideal sound of a finger snap for me is one that is crisp, has sufficient volume, and startles me somewhat. To get a 10, you would have to increase your crispness.”
As a perfectee, you may only ask questions to clarify or gather more information for improvement. If you disagree with the ideas given to you, simply don’t include them.

Agile Games 2012: Open Space and Games with Motion

noreply@blogger.com (Richard) — Tue, 13 Mar 2012 12:00:00 +0000

The Agile Games conference is great. I have the privilege of participating in this year’s conference as a facilitator. On Friday, April 20, I will lead a game session called “Self Management: 5 Games with Motion.” We’ll play kinesthetic games that explore command-and-control versus self management. These are some of the most outrageously fun games you’ll ever play—I dare you to bring them back to your office and play them at work with your team!

On Saturday, April 21, I will facilitate a full day of Open Space. I attended my first Open Space a few years ago, facilitated by Harrison Owen, the inventor of Open Space. Harrison’s amazing facilitation and the power of Open Space blew my mind; it marks a milestone in my life. I facilitated the world’s longest Open Space with my team last year, and I’ll use that experience lead a great Open Space at this year’s conference. I hope to inspire great conversations about Agile, Agile games, and building great software with great people.

Register for this year’s Agile Games conference. You’ll love it!

Don’t suck at meetings

noreply@blogger.com (Richard) — Tue, 31 Jan 2012 13:00:00 +0000

You opt in and show up at a meeting. You type an email to your boss. Or maybe you IM someone in another building. Sometimes you tweet something or send a text message.

Would you do that if you were having dinner with a close friend? Would you act like your friend isn’t worthy of your full attention, like your friend isn’t holding your interest so you need to do something else in his presence?

Why are you doing it to your coworkers at the meeting? Do you hate them, resent them, want them to fail?

Let’s assume this is a meeting that doesn’t suck, or at least doesn’t suck too much. You were invited, not commanded to attend. The desired outcome is clear, and it’s obvious that this meeting will help you meet the goal.

So don’t waste the meeting. Work together toward the goal, and get it done.

Start by deciding whether you will contribute to the outcome, learn from the conversation, or both. If so, opt in.

Next, respect your coworkers’ time. Be punctual—don’t waste their time by showing up late. Be prepared: do your homework before you get there so you can contribute.

Be present at the meeting. Don’t do anything that’s not related to the meeting and its goal. No email, web surfing, IM, texting, or anything else. Be completely present in the moment, or be completely absent and leave the room.

If at any time, you find that you aren’t learning or contributing, check out and leave the room. It’s OK. No one will hold it against you; better yet, they’ll respect your decision not to waste their time.

It’s all about being All In, or totally out. Hell Yeah, or not at all. Totally Present, or totally absent. Opt In completely, or opt out.

Meetings don’t have to suck. It’s your choice.

Related reading:

Dan Mezick’s Culture Game

Open Space Technology: Pushing the Limits

noreply@blogger.com (Richard) — Tue, 03 Jan 2012 13:00:00 +0000

Source: http://www.deborahschultz.com/deblog/2006/07/the_law_of_two_.html

Six weeks of Open Space—it’s a new world record! I facilitated a six-week-long Open Space with my software development team. As far as we know, this is a unique experience: we are the only people in the world to have held an Open Space for such a long time. We pushed the limits of Open Space Technology, discovering for ourselves some of the things it is great at, as well as some of its limitations. Here are the highlights of what we learned.

A real problem
Our problem is the BigCo reorg. BigCo is shutting down an important BigProduct software dev team located in another country. Our team is less experienced and assists the other team. In two months, though, the other team won’t exist, and our team will be the BigProduct dev team. How do we become the BigProduct dev team, with full responsibility for the product’s success, in six weeks?

BigProduct has a large codebase. The software is much too complex for anyone to be able to design a curriculum and hold training courses in such a short amount of time. There is no way we could define the right set of generalized classes and specialist tracks, no way we could appoint the right people for the right speciailties, via central planning. Open Space Technology seemed like the best way to conduct our knowledge transfer and to become the BigProduct dev team. Our Open Space thrived for six weeks because we had a real, urgent problem to solve, and Open Space was the best way to address it.

Shared responsibility
The most important aspect of Open Space is shared responsibility. Everyone is equally responsible for the successful outcome. As a participant, there is no scapegoat to blame if you don’t achieve your Open Space goal. It’s not the curriculum designer’s fault if you didn’t learn the skills you need—you are the course designer. It’s not the visiting knowledge leaders’ fault if they didn’t teach the right skills the right way—you are responsible for creating the sessions and guiding the knowledge leaders. If you aren’t getting what you need from today’s sessions, it’s no one else’s fault. Use the Law of Two Feet, and make sure you are always contributing or always learning. If you’d be better off sitting by yourself studying code, do it!

Authority
The Law of Two Feet grants you formal authority to do whatever it takes to achieve the goal. Everyone is explicitly authorized to make the Open Space successful. You set up the sessions you need, you make sure you get what you need from the sessions. If you don’t like it, you change it. You don’t have to ask. You don’t have to wait for permission. You are authorized.

Many short Open Spaces
We actually held a series of Open Spaces. We started with a one-day Open Space prelude, followed by six one-week long Open Spaces. The one-day prelude was a great warm-up, showing the team how Open Space works. The weekly Open Spaces were like weekly sprints, giving us regular opportunities to inspect and adapt every week. At the beginning of each week, we established the curriculum for the rest of the week, based on which knowledge leaders were visiting, which topics we had already covered, what we needed to review, and what we need to learn fresh. The closing ceremony at the end of each week was a great way to review our progress and prepare for the following week.

Send an invitation
Every Friday afternoon, we told each other that the next opening ceremony would be on Monday morning. Every Monday morning, most of us forgot. People were doing the right things, studying and learning; they honestly forgot the weekly rhythm and Monday morning schedule. I learned to send a formal invitation to the opening and closing ceremonies every time.

Repeat yourself
As the facilitator, I thought it would be insulting to repeat the opening message and instructions every time—we had already done it, everyone heard it already, why should I waste their time with it? But when I skipped the ceremony, it was chaos! We lost focus on the problem, forgot to announce our sessions, and didn’t know which sessions had been planned.

The lesson is to always start at the beginning. Use the opening ceremony to inspire the team and transform the mood from “we’re hanging out, shooting the breeze,” to “we are starting something important right now—let’s pay attention to each other and make it work.” Establish the space, set the mood, reinforce the goal, and establish formal authority and mutual responsibility, every time. Explain the marketplace rules so the session ideas flow and people know what sessions to expect for the rest of the week.

Self doubt about achieving our goal
Did we learn everything we needed? Did we all become experts? Does everyone have broad knowledge of the system? Did the right people become specialists in the right topics? Are we ready to be the BigProduct dev team? Maybe we should have conducted a single weeklong Open Space, with the goal, “Establish the training program for the next five weeks, organize the trainers, and assign the students to the right training tracks”, followed by five weeks of programmed training.

Change it up
Inspecting and adapting, we noticed that we were doing too much learning by lecture, and not enough learning by doing. We ended most weeks with the advice that we should hold sessions that are in the style of a code camp, but we started most weeks by setting up lecture sessions. During Week 5, we forced a week of code camps. Every session had to be a code camp, or you had to postpone your session until the next week. This worked, helping people practice their skills rather than listen to people talk about the skills.

Don’t do it alone
Conducting Open Space is too much work for the facilitator to do by himself. Get volunteers to help you set up the space, arrange the chairs, make the posters and tape them to the walls, order food, and do everything else you need help with. You not only spread the load, you share the responsibility. Every volunteer has a stake in the success of the Open Space, and they try harder to make it succeed.

Daily news, not daily stand-up
At the end of each day, everyone already knows what happened today: we organized and attended sessions. But what’s new? What changed since this morning? What is different about tomorrow’s schedule that we didn’t already know? Whose travel plans have changed? Where is the Fun Event session being held? Focus the new and important.

Easy to read session grid
We started with an informal sessions list, with one column on the wall for each day’s sessions. It wasn’t a true grid, with a row for each time slot. We skipped that detail, thinking it was unnecessary, but we were wrong. It wasn’t obvious which sessions were at what time during the day, and people got confused and frustrated. Gaffer’s tape to the rescue: we divided the columns into two rows, dividing the day into morning and afternoon sessions, and making it easier to show up at the right place at the right time.

Your experience?
What are your experiences with Open Space Technology? Have you conducted a short Open Space, a long one, or something in between? What did you learn about Open Space? What did you learn about your team and yourself?

Nokia N9 Wi-Fi Hotspot fix

noreply@blogger.com (Richard) — Mon, 07 Nov 2011 13:00:00 +0000

The Wi-Fi Hotspot app on my Nokia N9 doesn't work on AT&T. To fix, follow these instructions from the maemo.org forum:

2. start Terminal
3. type the following
Code:
devel-su
echo 1 > /sys/devices/platform/wl1271/allow_adhoc
it will prompt for a password after the first command, the password is "rootme"

Then start the Wi-Fi Hotspot app. Solved!

Get Ready to Get Done: Definition of Ready

noreply@blogger.com (Richard) — Thu, 13 Oct 2011 12:00:00 +0000

Once upon a time, the team was having trouble getting things Done. We asked why, five times. We found a root cause: we struggle to get backlog items Done because we aren't Ready on sprint planning day.

So we brainstormed a Definition of Ready. We use it as a checklist to ensure we understand each backlog item well enough that every team member has a mental outline of the tasks required to get it Done. The Product Owner and the team agree that they are jointly responsible for ensuring two sprints worth of backlog items are Ready before sprint planning day. Now the team is better at getting things Done, and we’ll all live happily ever after.

Here is our Definition of Ready.

To be Ready, each product backlog item must have this information:

Definition of Ready
Criterion	Description
Short name	A canonical short name that we use as we discuss the backlog item
User story	If we can’t describe it as a user story, it probably has no business value, and we probably shouldn’t do it. We use the “as a role …, I want …” style of user story (http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template).
Use cases	If there are use cases that help describe the story better, we list them.
Current product behavior	Make sure we understand the product’s current behavior, before we implement this backlog item
Future product behavior and consequences	Make sure we have a clear vision of the product’s future behavior, after we implement this backlog item
Acceptance criteria	A list of testable conditions that tell us whether we implemented the backlog item successfully, following my acceptance criteria template
Test outline	Our test plan for this backlog item
Demo script	Our demo script, showing how we will demo successful implementation of this backlog item. Acceptance criteria, test outline, and demo script obviously overlap each other--we think that’s OK because it helps us consider more aspects of Done.
Data storage concerns	One of our teams is working on a database migration project. Are there any data storage, data mapping, or other database related considerations for this backlog item?
Code flows and sequence, data flow	What might the code look like? How might the data flow through the code?
Proof of concept / prototype	If possible, we build a small prototype showing the feasibility of this backlog item, informing our other implementation decisions.
Review by other architect and tech team	We love peer review. We force another architect and technical team to review our plan.
Security review	We have a security expert. We force him to give us advice.
UX spec	If this backlog item has a user interface, we force the UX team to provide a specification.
Complexity/size estimate	We have estimated the backlog item’s size in story points.

Hardening sprints? Sorry, you’re not Agile.
If you're not Done, you're not Agile
Acceptance criteria template
Is it done?
Jeff Sutherland’s paper, “Scrum and CMMI--Going from Good to Great: Are you ready-ready to be done-done?”, available here and here

Dear Future Product Owner

noreply@blogger.com (Richard) — Tue, 23 Aug 2011 12:00:00 +0000

Dear Future Product Owner,

Congratulations on your new job. I want you to play a strong Product Owner role. I am excited about this. We haven’t had a strong Product Owner.

The backlog is yours. You define it: you tell us what you want, and you understand what our customers want. You prioritize it: you tell us the rank-ordered business value of the backlog items. You arrange and lead weekly backlog grooming sessions.

The release plan is yours. You understand the business goals and desired delivery dates. You understand when our customers want what they want. Given the team’s estimate of the velocity at which they can complete backlog items, you assemble the time line, understand its consequences, and collaborate with the team and the customers to reconcile differences. (Our ScrumMaster will assist you with the team’s estimates and velocity.)

Here is some relevant guidance from the Nokia Test:

Product Owner has clear product backlog estimated by team before Sprint Planning meeting
PO has release roadmap with dates based on team velocity
PO motivates team
Product Backlog clearly specified and prioritized by ROI before Sprint Planning Meeting (READY)
PO has release burndown with release date based on velocity
PO can measure ROI based on real revenue, cost per story point, or other metrics
PO release plan based on known velocity

Stop wasting your time: use Agile

noreply@blogger.com (Richard) — Tue, 16 Aug 2011 12:00:00 +0000

A colleague writes:

Is Information Overload Wasting 40% of Your Time?

In general, multiple studies have indicated that >50% of people feel like they are experiencing "Information Overload”.

At the more detailed level, Basex (a consulting firm that focuses on this area) derived the following from a survey intended to determine “How does a typical professional spend their day”
Unnecessary interruptions including recovery time to get back on track – 28%

Creating something useful – 25%

Attending meetings (some productive, some not) – 20%

Searching for information (where on average 50% fail) – 15%

Thinking and reflecting – 12%

If one sums 28% (interruptions) + 5% (unproductive meetings) + 7% (failed searches for information), on average one “wastes” 40% of their time!!!

If each member of a [a company with 120,000 employees] could recoup half of that 40% (20%) would free up 24,000 people worth of productivity and if use a gross estimate of the cost per person at $100,000, the wasted spending is $12,000,000,000.

My response:

Agile addresses these problems.

Unnecessary interruptions including recovery time to get back on track: We protect the dev team from unnecessary interruptions. We make the team's process and progress visible so people don't have to interrupt us throughout the day. Want to know what we'll work on for the next couple of weeks? Join us during sprint planning. Want to know what we're working on today? Join our daily scrum. Want to see our progress and status? Look at our big visible burndown chart and task board, on the wall in our big open shared work area. Need the team to do something? Talk to the product owner, and he'll put your request on the product backlog.
Creating something useful: We have a strong product owner with a clear vision of what we'll deliver. He keeps a to do list for the team--the product backlog. We prioritize the product backlog, with the most valuable and useful items at the top. We only implement the highest priority, most valuable, most useful items, yielding the highest value and return on investment for our stakeholders. We get it done--ready to be deployed in production--every sprint; it's not useful until it has been deployed and people use it.
Attending meetings (some productive, some not): Meetings suck. We minimize meetings. We have only three required meetings: sprint planning, daily scrum, and sprint end. Everything else is waste, and optional. Ironically, you could also say that we also meet all the time--we are never not in a meeting. We work face to face in an extremely collocated environment, to maximize learning and team productivity.
Searching for information: We don't search for information; instead, information surrounds us. We post big visible information radiators in unmissible places--it's impossible not to know our project's status, our task breakdown, what's done, what's in progress, what's impeded. We collocate--it's impossible not to share information, teach each other, and answer each other's questions, almost by accident.

Use Agile, and stop wasting your time.

National cultures: know your team, know yourself

noreply@blogger.com (Richard) — Tue, 28 Jun 2011 12:00:00 +0000

Image source: http://www.tower.com/

Playing well together is important: communicating, learning, sharing, getting things done. Our native culture shapes how we think, how we behave, and how we perceive our coworkers.

Geert Hofstede is a master of understanding culture. In his book, Culture’s Consequences, 2nd ed., he shares the data and analysis of many years of research on national cultures. Hofstede defines culture as “the collective programming of the mind that distinguishes the members of one group or category of people from another” [p. 9].

Like an economist, Hofstede analyzes the data he has collected, factoring out variables that have no independent influence on culture. He identifies five orthogonal dimensions that he uses to characterize a country’s culture:

Power distance
Uncertainty avoidance
Individualism and collectivism
Masculinity and femininity
Long- versus short-term orientation

Here’s a brief overview of each dimension and its importance to me, as a manager in a multinational company.

Power distance (PDI)
Definition: “The extent to which the less powerful members of institutions and organizations within a country expect and accept that power is distributed unequally.”[p. 98]

Selected ranking, from greatest to least [p. 87]:

Venezuela (5-6 tied with one other)
India (10-11 tied)
Hong Kong (15-16 Hong Kong tied)
Turky (18-19 tied)
(median)
Taiwan (29-30 tied)
United States (38)
Canada (39)
Australia (41)
Germany (F.R.) (42-44 tied)
Great Britain (42-44 tied)
Finland (46)

What it means for me, as manager of a culturally diverse team:
As an American, I exhibit relatively low power distance. Be aware that Finns exhibit almost no power distance--we are all equals--while Indians and Turks expect and express large power distance--they may be afraid of and deferential to me.

Uncertainty avoidance (UAI)
Definition: “The extent to which the members of a culture feel threatened by uncertain or unknown situations” [p. 161]

Selected ranking, from greatest to least [p.151]:

France (10-15 tied with 5 others)
Turkey (16-17 tied)
Venezuela (21-22 tied)
Taiwan (26)
(median)
Germany (F.R.) (29)
Finland (31-32 tied)
Australia (37)
United States (43)
India (45)
Great Britain (47-48 tied)
Ireland (47-48 tied)
Hong Kong (49-50 tied)

What it means for me, as manager of a culturally diverse team:
As an American, I prefer and embrace ad hoc. Be aware that this is counter to the expectations of French, Turkish, etc., who prefer formalized policies and procedures.

Individualism and collectivism (IND)
Definition [p. 225]:

Individualism stands for a society in which the ties between individuals are loose: Everyone is expected to look after him/herself and her/his immediate family only. Collectivism stands for a society in which people from birth onwards are integrated into strong, cohesive in-groups, which throughout people’s lifetime continue to protect them in exchange for unquestioning loyalty.

Selected ranking, from greatest to least [p. 215]:

United States (1)
Australia (2)
Great Britain (3)
France (10-11 tied with one other)
Ireland (12)
Germany (F.R.) (15)
Finland (17)
India (21)
(median)
Turkey (28)
Hong Kong (37)
Taiwan (44)
Venezuela (50)

What it means for me, as manager of a culturally diverse team:
As an American, recognize my extreme individualism. Try hard to empathize with everyone else, who all exhibit stronger collectivist bonds than me.

Masculinity and femininity (MAS)
Definition [p. 297]:

Masculinity stands for a society in which social gender roles are clearly distinct: Men are supposed to be assertive, tough, and focused on material success; women are supposed to be more modest, tender, and concerned with the quality of life. Feminitity stands for a society in which social gender roles overlap: Both men and women are supposed to be modest, tender, and concerned with the quality of life.

Selected ranking, from greatest to least [p. 286]:

Venezuela (3)
Ireland (7-8 tied with one other)
Great Britain (9-10 tied)
Germany (9-10 tied)
United States (15)
Australia (16)
Hong Kong (18-19 tied)
India (20-21 tied)
(median)
Turkey (32-33 tied)
France (35-36 tied)
Finland (47)

What it means for me, as manager of a culturally diverse team:
As an American, I am culturally on the more masculine end of the scale. My Finnish coworkers are on the extreme feminine end of the scale. Recognize that we have different expectations about our family roles and the role of the company in our lives.

Long- versus short-term orientation (LTO)
Definition [p. 359]

Long Term Orientation stands for the fostering of virtues oriented towards future rewards, in particular, perseverance and thrift. Its opposite pole, Short Term Orientation, stands for the fostering of virtues related to the past and present, in particular, respect for tradition, preservation of ‘face’ and fulfilling social obligations.

Selected ranking, from greatest to least (this index has the smallest list of countries) [p. 356]:

China (1)
Hong Kong (2)
Taiwan (3)
India (7)
Sweden (12, median)
Germany (F.R.) (14)
Australia (15)
United States (17)
Great Britain (18)

What it means for me, as manager of a culturally diverse team:
As an American, recognize that I have more of a short-term orientation than my Asian coworkers. They might view my decisions and advice as thoughtless and counterproductive to long term success.

Rock-paper-scissors Happiness!

noreply@blogger.com (Richard) — Tue, 07 Jun 2011 12:00:00 +0000

We are wicked happy![Image from Scientific American]

Happiness is important. Happiness is a leading indicator of your team’s success. Many economists think a happiness metric is more important than GDP and other metrics.

Want to knew whether your team is happy--whether your team is trending toward success? Play this game, and find out.

Rock-paper-scissors Happiness
In this game, team members gather face to face. The game leader asks,

On a scale of 1 to 5, how happy are you with work? 1 means “not very happy.” 5 means “wicked happy.” How happy are you with work?

In the style of rock-paper-scissors, players simultaneously hold up one hand and a number of fingers.

The number of fingers each player hold up is the player’s happiness metric. The game leader records either each person’s happiness metric and the team’s average happiness metric. The leader may track happiness metric over time, on a chart like this:

Based on the team’s current happiness metric, the game leader may guide the team through a discussion. Why are we so happy today--what is going well that we should continue doing? Why are we so unhappy today--what do we need to fix? Because happiness metric is a leading indicator of team success, the leader’s goal is to discover how to maintain or improve the team’s happiness.

Happiness Poker is an alternate way to gauge the team’s happiness metric. In this variation, the game leader gives each player a partial deck of poker cards, ranging from 1 (ace) through 10. The leader asks the team, “How happy are you with work?” In the style of Planning Poker, the players simultaneously hold up a card to indicate their current happiness metric. The leader records the result and leads a discussion.

Is your team happy? How do you know? Are you sure?

Here’s a sample of sources on happiness metric:

Lean optimization of the home brewery

noreply@blogger.com (Richard) — Thu, 19 May 2011 12:00:00 +0000

Lean optimization: a case study
(Alternate title: Lean optimization of the home brewery)
Subtitle: Why does my back hurt?
(Alternate subtitle: How to convince my wife I need a kegerator)

Beer is good. Homebrew is better. I don’t brew often enough, but when I do, my back hurts the next day. I must be doing something wrong.

The goal is good beer and good times. How can I apply lean thinking to reach the goal more efficiently?

My house is my beer factory. I live in the top two floors of a triple decker, with access to the basement. The top floor is the Sanitizing Station, also known as the bathtub. This is where I clean, sanitize, and rinse the large glass carboys that I use as fermentation containers. The second floor is the Brewing Station, also known as the kitchen. This is where I mix and boil the beer, add yeast, sanitize bottles and smaller tools, and bottle the beer. The first floor is my neighbor’s apartment. No beer production happens here--this is wasted space; it might even be a competing brewery! The cellar is the Fermentation Station and Storage Area. This is where I store fermenting beer, bottled beer, and all the equipment.

A value stream map is one of the tools we use in lean optimization. To keep it simple, I have four steps in my value stream: Brewing, Fermentation, Bottle Conditioning, and Drinking the First Bottle. I use time spent in each stage as the simple metric of value added time.

How should I measure waste? Waste is usually represented as wasted time. In the home brewery, though, most of the time is spent waiting for the yeast to do their work. Fermenting and bottle conditioning take as long as they take, and they can’t really be optimized.

Did you notice that my beer factory is stacked vertically? Another kind of waste is unnecessary motion. What if I measured waste as vertical motion? Here’s the next iteration of my value stream map, including the waste incurred in each stage.

So where should I optimize? I only walk 4 flights of stairs in the Drinking the First Bottle stage. Compared to the amount of waste in the other stages, this isn’t a big deal.

An obvious improvement is to move the Sanitizing Station and Brewing Station to the cellar. I could build a cleaning area and kitchen in the cellar, and eliminate 18 flights of stairs. Great idea, but too expensive.

There is a potential low hanging fruit kind of improvement to the Fermentation Stage. I do a two stage fermentation, starting in the primary carboy on brew day, and transferring to the secondary carboy a few days or weeks later. If I used single stage fermentation, I could eliminate all the vertical motion here. This is inexpensive and it won’t make the beer taste dramatically worse, so it seems like a good idea. I think of this as opportunistic efficiency, and I’ll probably do it.

But the biggest source of waste is the Bottle Conditioning stage. I walk 34 flights of stairs on Bottle Conditioning day! I need the beer to be in some sort of container; how could I possibly eliminate or optimize this stage? To eliminate bottling, I need a crazy idea, some real innovation... How about a kegerator? That’s it! Instead of bottling, I’ll transfer the beer to a barrel and serve it from a kegerator. Here’s my target value stream:

And I’ve made a good case for it: it will prevent back injury, so it’s good for my health! This is my future:

Photo from Amazon

Relax, sit back, and enjoy a homebrew!

Low tech andon: it's all green

noreply@blogger.com (Richard) — Thu, 12 May 2011 00:41:00 +0000

High tech andon lights are great. Your build breaks, your tests don’t pass, a server goes down, and the bright red light goes on. The team swarms, someone fixes the build, and the light goes green. It’s all good.

But it takes some technical effort to set up that magic red/green light. Why not go low tech? My team is using giant green and red tri-fold presentation boards, like the ones you used at your middle school science fair. Anyone can raise the red andon any time and spread the word: something isn’t right, let’s swarm and fix it. They fix it and raise the green one. And it’s all good again.

What do you use for your big visible green/red indicator?

Special thanks to Patrick for turning "I need something big and green" into "here's a big green presentation board."

Highlights from Agile Games 2011

noreply@blogger.com (Richard) — Fri, 29 Apr 2011 12:00:00 +0000

Here are some highlights from the amazing Agile Games 2011 conference .

First, my major themes from the event:

Learn Fast, not Fail Fast
Teach People Early, not Disappoint People Early

Luke Hohmann of Innovation Games gave a rousing inspirational keynote about how awesome it is to work on software. One key problem he noted is that we don’t talk to our customers and end users enough. He mentioned Capers Jones’ analysis that companies that provide their workers two weeks of training per year on any topic are more productive than other companies.

The Where Are Your Keys? Fluency Game is an amazing approach to accelerating learning. Babies are great learners; Where Are Your Keys? is is a set of tools that create that same fun, supportive, engaging environment for knowledge acquisition in adults.

Jacquie Lloyd Smith of StrategicPlay led a session on Lego SeriousPlay. People love to play with Legos; if nothing else, it’s a great way to break the ice on a new team, get people to know each other, and overcome shyness.

Don McGreal from Tasty Cupcakes led White Elephant Sizing. For us New Englanders, that would be Yankee Gift Swap Sizing. This is a great way to get a team to quickly estimate the relative size of items in a product backlog.

Michael Sahota, Brian Bozzuto, and Johnny Scarborough led a workshop on Luke Hohmann’s Innovation Games. We played the 20/20 Vision Game to plan improvements for next year’s conference.

Michael McCullough of Tasty Cupcakes led us through a quick game incubator and helped us through a new game, Don’t Blow It. A game is an experience for people that drives self discovery. A game without a purpose is just a game. Our games have intent and purpose. To create a new game, follow the PLAID method:

Problem: have a problem
Lead objectives: think of ~3 objectives
Aspects of the game: who is my audience, what is the venue, etc.
Invent: collaboration, innovation, frustration
Debrief: Did we achieve self discovery? Ask people questions that lead to self discovery.

Alex Boutin led a session on the prize winning new game The Big Payoff. This game teaches how to maximize portfolio value, finish small projects so you gain value each quarter, and use Agile to have small projects that yield value each quarter

Agile & Ethics: Jay Conne led a discussion about the ethical basis of the Agile Manifesto. Agile is based on ethics, but they are implied and need to be exposed. One takeaway is that the Agile Manifesto states that we value X over Y, not X instead of Y.

Elevator Pitch: sell Agile to the CEO in 20 seconds: In this open space session, we discussed how to quickly sell Agile to a CEO. Here’s the outline of our elevator pitch:

Intro: Recognize and state the CEO’s problem, challenge, or opportunity in his language, or just ask what is his biggest problem
Meat: State that you’ve been thinking about the same problem, and that Agile tools & practices can solve it.
Close: Set up a longer follow-up meeting to go into details.

This is a sales pitch. Make sure you rehearse so you don’t choke under pressure. Use the CEO's style: if he is a hierarchical, high power distance person, behave that way; if he is an egalitarian, low power distance person, play that way.

Moss led an open space session on Games for Programming. One good idea is TDD Ping Pong: I write a test, you make it pass; then you write a test, and I make it pass. Another good idea is Test from a Hat: write the tests; put the test names in a hat; in random order, make the tests pass.

Short Games with Movement: This session was too much fun. We played numerous fun games that make you move and that quickly teach their lesson. Here’s the list of games:

Want me dead? Build me a mansion.

noreply@blogger.com (Richard) — Thu, 31 Mar 2011 12:00:00 +0000

I’ll be dead soon. I’ve been out in the cold rain for three hours. Hypothermia is setting in.

You try to sell me a mansion. You show me the plot plan and the floor plan; you did a lot of planning up front. You brag about the foundation, firm and solid, ready to last centuries. The infrastructure is excellent: all the best wiring, plumbing, heat, and air conditioning. Twelve bedrooms, six bathrooms, servants’ quarters. Hot tubs. Pool. Very impressive. Well done.

But I just died. All I needed was shelter.

"Building software is like building a house. You start with a strong foundation. Then you build one floor at a time--you can’t build the second floor without the first floor. You need excellent infrastructure--things like plumbing and wiring. Finally, you need a solid roof."

Bullshit!

Building software is best done iteratively and incrementally. Fill a need, get it done, and give it to your customer. Fill another need, make it better, get it done, and give it to your customer again.

The “it’s like building a house” metaphor is broken. Building a house can be done as incrementally as software:

I need protection from hypothermia. Build me a lean-to to keep me dry and protected from the wind. Done.
I need something a little more durable and warmer. Build (or buy) me a tent. Done.
I need a place to stay for the summer. Build me a cabin. Maybe with a sauna. Done.
I’ll be staying for the winter. Build me a brick house with a fireplace. Done.
I’ll be working in the city. Build me a townhouse with modern facilities. Done.

Do not build me a palace, from the foundation up. By the time you’re done, I’ll be dead, and you’ll be too late.

(Image from SurvivalJunction.com)

MobiCampBos4

noreply@blogger.com (Richard) — Fri, 04 Mar 2011 17:00:00 +0000

I led two sessions at this year’s Mobile Camp Boston on February 19: one on mobile consumer identity, and the other on agile software development.

Give them what they want: mobile consumer identity
We talked about knowing your mobile customers. The most important question for you to ask your customers is, would you buy my product? Followed by, why or why not? We discussed ways to identify your mobile customers as individuals, and ways to understand their wants, needs, and desires, with examples from my work at Nokia.

Use Agile for mobile and be awesome!
This was the fourth edition of my Agile for Mobile presentation. We improvised a discussion around Agile and Scrum. Why do we value Agile? What are the Agile behaviors we use in our work? Which practices work for us? What has worked for me, what should you try? (Agile talks from previous years: 2008, 2009, 2010)

Thanks to everyone who attended my sessions, and everyone who attended the Mobile Camp and helped make it happen.

(Photo from Mobile Camp Boston web page)

Board your plane paper-free

noreply@blogger.com (Richard) — Thu, 23 Dec 2010 13:00:00 +0000

I’m in my hotel room and I realize I should check-in for tomorrow morning’s flight home. I’m too cheap to pay extra for the hotel’s WiFi service. All I have is my phone and its web browser. I bring up the airline’s mobile web site, and a few minutes later I’m all set.

Pain free, 100% mobile check-in and boarding is here. Lufthansa does it really well. On your phone, browse to m.lufthansa.com. Enter your name and confirmation code, and they’ll let you select your seat, just like on the desktop web site. Confirm your check-in, and they’ll send you a text message or email with a link to your boarding pass.

Show your phone with the boarding pass and the 2D bar code on the screen to the nice security guard at the airport terminal. Place your phone on the 2D bar code scanner to board the plane. Enjoy the free German chocolate onboard. It couldn’t be easier.

Pro tip: Save your boarding pass on your phone’s local memory in case you can’t get a network connection at the airport. It’s really embarrassing when you hold up the line trying to download the bar code to show the nice security person that it’s a real boarding pass.

Pro tip #2: Peak around the corner at your Lufthansa gate, and you’ll find the coffee machine. Enjoy a free espresso!

8 ways to kill Agile

noreply@blogger.com (Richard) — Thu, 16 Dec 2010 13:00:00 +0000

Want to kill your high performance agile dev team? Make it hard for them to deploy to Production. Set up a bureaucracy of approval gates, review boards, committees, and meetings. Make sure they miss their deadlines and disappoint their customers. Control them until they can't get anything done.

Don’t let them deploy to their Staging environment. (1) Make them present their product to a VP for software maturity approval. (2) Then make them ask permission from the local change approval board. It doesn’t matter whether they approve, because you’ll (3) make them seek additional permission from the global change approval board. Ask for proof that all of their customers formally signed off; never mind that their customers run their own bureaucracies and can’t tell you who is authorized to approve. (4) Finally, make them get permission from the global Ops approval board. It doesn’t matter that the team practices DevOps, and that their Ops team is integrated into their Dev team--the global Ops approval board needs to rationalize their existence.

All that just to deploy in Staging, simply to rehearse Production deployment.

(5-8) Repeat these four formal approval gates for Production deployment. Ignore the fact that your high performance agile team knows what it’s doing and does it well. Just make them jump through the hoops. Eventually they’ll get tired, stop fighting it, and slow down. They’ll bow to your pressure and stop their frequent delivery of new value to their customers.

Or...

Instead of handcuffing your high performance agile team, how about helping them deliver value to their customers? Try asking them for one concise formal statement of readiness. They already produce it as part of their Definition of Done.

Nominate a single person from Dev and a single person from Ops to be responsible for deciding whether the product is ready for Staging or Production deployment. These guys cares about getting it right--they get fired if the team deploys something that sucks, something that yields downtime for their service or for their customers’ services.

The DevOps team wants to be great. Champion their cause, don’t get in the way. Help them deliver value to their customers.

Why can't we be as good as Nokia?

noreply@blogger.com (Richard) — Thu, 09 Dec 2010 13:00:00 +0000

Nokia has a great reputation in the Agile community. Why can't we be as good as Nokia? It turns out we can. Here's my presentation from the Nokia Agile Community Autumn Meet 2010 conference in Helsinki, held on December 7. Use the Nokia Test, a simple value stream map, and Theory of Constraints, and you can transform your dev team from good to great. Apply Scrum rigorously, and success just happens.

What do you think? Want to transform your team from good to great?

My Product Owner will kick ass

noreply@blogger.com (Richard) — Tue, 30 Nov 2010 13:00:00 +0000

My Product Owner is my business owner. He deserves all the credit when we succeed, and all the blame when we fail. He has the most important role in my Agile team. He should be the highest paid, because he takes the greatest risk: if he fails, he’s fired. So says Mike Dwyer, and I agree.

My PO will run my business unit. He will be a courageous, ballsy, gutsy entrepreneur. He will lead my dev team as if it were his personal business, with his own money on the line. My team costs around $2.5million per year. He will embrace this responsibility and direct our spending that money wisely.

My PO’s success will be measured by the amount of business value we deliver into production service. If we don’t deliver what he promises, he fails. If someone on another team blocks our production deployment, he fails. When we deploy in production, our PO succeeds. When our service approaches 100% uptime, he succeeds.

My PO will be our head sales guy. He will be our customers’ best friend, building deep relationships with them. He will schmooze. It’s his job to take them out for beer or dinner. He'll play golf with them and give them tickets to a show or a big game. He will get them to trust him.

My PO will know what our customers really want. Is it high availability? Is it new features? Is it guaranteed backward compatibility? He will listen and understand. And listen some more.

My PO will be a visionary. He will be a domain expert with a long term vision for our product. He will guide us from the big picture to the nitty-gritty details. He will care about every pixel in the UI.

My PO will sell both the vision and the detail to our customers. He’s already their best friend, and he spends a lot of time listening to what they want, so this should be easy. And when his vision isn't exactly what they ask for, he will convince them that it’s what they meant to ask for. He’ll sell our road map to them and convince them that every small release is a step on the way to what they want. He will turn our customers from antagonists into allies.

My PO will sell his vision to my dev team. He will inspire the team to build what our customers want and need. He will introduce our customers to the team, and the team to our customers, so they understand and trust each other.

My PO will define every product backlog item in extreme detail. Every backlog item will be ready-ready. I will know that it’s what our customers want and need before we start building it.

My PO will show up. He will attend our estimating meetings and explain the backlog items to us so we can estimate them well. He will help us on sprint planning day, explaining the goals and the details, and guiding us to choose the right backlog items and the right amount of work. He will take part in our daily scrums so we don’t go off track. He will watch our sprint demo and applaud us when we get it right or tell us we suck when we get it wrong.

My PO will win and bring us along with him. My PO will kick ass.

Hardening sprints? Sorry, you’re not Agile.

noreply@blogger.com (Richard) — Tue, 28 Sep 2010 12:00:00 +0000

We do a series of sprints to build our product, then we do 4-8 weeks of hardening sprints to really test our code and get the bugs out before we deploy it in production.

Guess what? You’re not Agile, and you’re not doing Scrum. You are using the jargon, maybe because it’s fashionable, or maybe because you’re Agile practices are misguided. But you’re not Agile.

In fact, you are doing Waterfall, masquerading as Scrum. You probably did a lot of big up front analysis and design, followed by a coding phase (your early “sprints”), followed by a testing phase (your “hardening sprints”). You are masquerading as Scrum by using the Scrum jargon: terms like Sprint, Burndown, and Product Owner. You are applying that jargon to Waterfall. Some people call this Cragile. I call it Shcrum.

(Diagram adapted from http://en.wikipedia.org/wiki/File:Waterfall_model.svg)

The problem with “hardening sprints” is that you are lying. You make believe your imaginary burndown during the initial sprints shows that you are approaching Done. But it’s a lie--you aren’t getting any closer to being ready for Production until you begin your Test phase. You wrote a pile of code that you didn’t test adequately. You don’t know how good it is, you don’t know how much work you have left to do, and you don’t know how much longer it will take, until you are deep into your Test phase.

I don’t mind that you’re doing Waterfall. Just don’t call it Scrum or Agile. And don’t do it on my team, because I don’t want my team to suck.

If you need “hardening sprints” before you can deploy in Production, you’re not Agile, and you’re not doing Scrum. What is stopping you from being Done at the end of each sprint?

A fire hose of programmers, a straw of testers

noreply@blogger.com (Richard) — Tue, 24 Aug 2010 12:00:00 +0000

The programmers write new code so fast, the testers can’t keep up. It’s like shooting a fire hose into a straw. It doesn’t matter how fast the programmers shoot new code out of the fire hose, because the testers have to get it all through the straw before we can say it’s Done and deploy it in production.

You have a problem
The problem is easy enough to recognize. You have a killer programmer team, but the test team can’t keep up. You have a bunch of features that were coded, so you think they are almost done, but the features haven’t been tested yet, so you can’t deploy them to production. You’re frustrated that you can’t get stuff out the door.

And it just gets worse. No matter how close the test team comes to catching up, the programmers keep adding new, untested code. It seems like you can never get Done, and you have no idea when you’ll get Done or how much more it will cost.

Your problem is you
You need to ask why. Make a list of reasons this is happening and think of ways to fix it. Here are some possible causes:

You have the wrong mix of players on your team: too many programmers, and not enough testers.
The test team is distracted. They spend too much time doing bug triage or preparing for future new features. They attend too many meetings. They spend too much time on customer or production support.
The test team has inadequate computing resources. Other teams borrow their test environments, totally blocking the test team. When the testers get their environment back, it takes too long to reconfigure. To make matters worse, components of the test environment are unreliable, with too little disk space or subpar network infrastructure.
The test team relies too heavily on manual testing.
Your release criteria (your Definition of Done) are so onerous that the team can’t ever be Done.

Fix it
Given that list of problems, the solutions seem obvious:

Stop hiring programmers--more programmers won’t help you get Done any faster. Add more testers, or make the programmers play tester.
Protect the test team from distractions. Your testers are the critical constraint--don’t let them do anything that doesn’t help them get Done. Other people can represent them in meetings or help with support issues.
Get the test team the computing resources it needs, and don’t let anyone else use those resources, for any reason. Stabilize the environment’s infrastructure. Manage the infrastructure yourself, so you can fix problems immediately instead of handing them off for another team to fix.
Automate!
Review your release criteria. Does every item add value? Does every item protect against low quality? Can you remove some criteria? Can you address the criteria earlier, as part of getting each story or sprint Done?

What are you doing about it?
Why can’t your test team keep up? What are you doing about the fire hose of new code shooting into the straw of testers?

Sports Tracker is everything I wanted out of RunKeeper

noreply@blogger.com (Richard) — Tue, 13 Jul 2010 12:00:00 +0000

Sports Tracker is everything I wanted out of RunKeeper, with the bonus that it runs on my Nokia E72. (Full disclosure: I now work for Nokia, and I carry an E72.) It is total sweetness: map your actual route, track your miles and time, and keep everything logged on a workout calendar. It also has nice views of your speed and altitude over time, and there is a cute playback mode so you can relive your glory. Download Sports Tracker from the Ovi Store, and be great.

Use the new Blogger tag cloud widget

noreply@blogger.com (Richard) — Tue, 06 Jul 2010 12:00:00 +0000

Blogger has a new (to me) tag cloud widget that's way better than my old one. To install it, edit your blog's layout by clicking New Post / Design / Page Elements. In the Page Elements window, click Add a Gadget. In the Gadgets list, find Labels and click +. In the Configure Labels window, click Cloud, then SAVE. Save your new design, and you're all set.

People need mastery and purpose, not bonuses

noreply@blogger.com (Richard) — Tue, 29 Jun 2010 12:00:00 +0000

Pay people enough that they don't have to worry about money, and they'll perform well. Don't bother with monetary incentives beyond that. Want people to perform better? Establish an environment that encourages mastery and purpose.

That's the essence of this great video from the nice people at the RSA. Thanks to Jeff Sutherland for the pointer.