Nokia N9 Wi-Fi Hotspot fix

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
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

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.



Dear Future Product Owner

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

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

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!

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

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

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

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.

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."

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)



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)


Related Posts with Thumbnails