Upgrade your unlocked iPhone to 3.1.2

It really couldn't be easier:
  1. Run AptBackup and tap Backup.
  2. Run iTunes on your PC and install the new firmware.
  3. Run blackra1n on your PC and click the button.
  4. Run blackra1n on your iPhone and install Cydia.
  5. Run Cydia. Install required updates, then install AptBackup.
  6. Run AptBackup and tap Restore.
  7. Run Terminal and change your default passwords for users mobile and root!


Brief intro to mobile app platforms

I presented Brief Intro to Mobile App Platforms last week, as a guest speaker at the New England Institute of Art's Mobile Design and Development course. The highlight of the day wasn't me, of course; it was the final project presentations--they were great! Thanks for inviting me, Chuck.


How's your Scrum?

Are you doing Scrum, or are you doing Scrum-But?

Many teams use the Nokia Test to evaluate their Scrumness. Bas Vodde presented the original Nokia Test in 2006; he used it as a simple way to evaluate the Agileness of development teams at Nokia. In 2007, Jeff Sutherland adapted the Nokia Test to Scrum.

Ken Schwaber recently developed a more comprehensive Scrum assessment. You can use it to evaluate your knowledge of Scrum and see how it improves over time. Ken is also using it to understand the Scrum community's knowledge of the Scrum Guide.


Activate G1 without Android data plan, redux

Our G1 was acting flaky--frequent reboots, as if the battery were disconnecting--so we got a warranty replacement. We still don't have a data plan, so activating the G1 is still interesting. My old hack to activate the G1 without an Android data plan (T-Mobile Android Unlimited Web) doesn't work any more; it looks like T-Mobile disallows G1 requests through the old WAP gateway.

Fortunately, wife just got a myTouch 3G and the matching Android data plan. To activate the new G1, we simply put wife's SIM in the G1, boot it, and activate the G1. We put the no-data SIM back in the G1, connect to the local WiFi network, and we're all set.


Peter Pan WiFi

WiFi! On a Peter Pan bus from Springfield to Boston! How cool is that?

In my speed test, I saw 372 kbit/sec and 0.228 seconds latency.


See Richard at ICCA Boston

Join me on Tuesday, November 17, as I present Winning Clients with Scrum and Agile at ICCA Boston. Here is the abstract. See you there!

Winning Clients with Scrum and Agile

Speaker: Richard Kasperowski, of Nellymoser
Your clients want to deliver great software, but traditional approaches get in the way. Use Scrum and other Agile approaches to show your clients how to deliver great products on time, helping them win, and helping you win new clients.
Attendees will learn:
  • How traditional software development methodologies often fail
  • Why Scrum and other Agile approaches can succeed
  • How to introduce Scrum to a development organization
  • Tools you can use to succeed with Scrum
  • Pitfalls related to Scrum and Agile
Richard Kasperowski is Director of Solutions and Services at Nellymoser, leading his engineering team building great mobile applications.  Richard ran a successful independent consulting practice for eight years before rejoining larger organizations. He has been developing software for over 20 years in a wide variety of roles, including engineering director, architect and developer. His blog can be found at kasperowski.com.  Richard is not an agile zealot, but rather someone who has come to embrace agile methodologies as a result of his real world experiences with them.


My Dvorak story

Update: See Read More on Dvorak for iPhone for more!

How Dvorak happened to me
I typed a lot.

I moused a lot.

I hurt a lot!

I was a young tech worker learning the trade, and I was a Computer Science student finishing my degree. I wrote code and I tested code. I designed computer chips using CAD tools. I wrote papers. I participated on Usenet and email lists. I spent 12 or more hours a day using the keyboard and mouse.

I developed repetitive stress injury (RSI) symptoms: sore, throbbing hands, wrists, elbows, and shoulders. Symptoms peaked during a hardware design course. For class assignments, I designed circuits using a CAD tool, and I did a lot of mousing. Near the end of the semester, I was away from home 24 hours a day, living at the office and in the computer lab, typing and mousing, working and finishing my circuit design assignments.

I hurt! I sought medical treatment for RSI, but I stopped short of a hard core diagnosis and surgical treatment. I read data on the marginal success rate of carpal tunnel surgery and decided it wasn't for me.

I read everything I could find about RSI, scouring Usenet, FTP sites, and printed books and magazines. I learned about the principles of the body's natural position and that work area ergonomics should try to put your body in a similar position: keep your back vertical, use a chair that supports your lower back, keep your feet flat on the floor, keep your forearms parallel to your desk, and more. (Harvard has a good introduction.) In the ideal body position, your hands are parallel to your body, contrary to the usual hand position while typing, so I tried a split keyboard slightly raised in the middle. I tried typing gloves and wrist rests for the keyboard and mouse. I tried left handed mousing, and a trackball instead of mouse. I learned to take typing breaks, using an automatic X11 based timer that popped up on my screen and made me stop typing. I learned that we stress our hands in our sleep, so I wore wrist splints to bed at night. And I discovered the Dvorak keyboard layout.

The intent of the Dvorak keyboard layout is to improve your typing speed. The most frequently typed letters are on the home row, directly beneath your fingers. Compared to the standard QWERTY key layout, your fingers don't move as far. I guessed that the Dvorak layout might be a good way to decrease the stress on my hands while typing--if your fingers don't move as far, they probably do less work and get strained less.

I spent a week learning to touch type Dvorak. I used an xmodmap config to map my QWERTY keyboard to a Dvorak layout. It was the same physical QWERTY keyboard, but with Dvorak outputs: press the S key and see an O on the screen; press D and see E; press F and see U. It was impossible to hunt and peck like this, so I had to learn how to touch type. My typing speed immediately slowed , but by the end of the week, it was back to normal.

Actually, my typing speed was better than normal. Just learning to touch type makes you type faster. According to the Dvorak spiel, touch typing Dvorak should make you a superstar touch typist, and I became a superstar touch typist! Ironically, this was counter to my goal: I ended up typing more, so Dvorak didn't help with RSI.

It was too late to return to QWERTY, though. Now that I was a speed demon touch typist, there was no going back.

Dvorak on mobile
As I got into mobile technology, I avoided phones with QWERTY keyboards. I didn't want to switch from Dvorak, thinking it would hurt my brain. It takes a little bit of mental acrobatics to switch between keyboard layouts, almost shopping in a country where you don't quite speak the local language. You can do it, but it's not trivial.

My first "smartphone" was an HP iPaq. I was attracted to the iPaq because of its handwriting UI. Using a stylus, you write on the screen instead of typing on a keyboard. Handwriting is a very natural UI on a small device, and it is a skill that we all learn as children. Most of us are better at handwriting than at typing. The handwriting recognition wasn't perfect, but it was good enough that I could use the iPaq as a notepad, taking notes in real time.

My next smartphone was an iPhone. I liked the idea of the on-screen keyboard, thinking it would support alternate layouts like Dvorak. I was wrong, though: no Dvorak, and there was no easy way to configure the keyboard layout. And at the time, there was no App Store, so there were no third party add-ons to solve the problem.

The iPhone's on-screen keyboard does two things well. First, it lets you slide your thumbs over the keys, displaying key clues so you know which key is hidden under your thumb. When you tap and hold a key, the key clue pops up, and you move your thumb around, looking at the key clues. When you see the clue for key you want, you let go, and the key you typed appears in the text box.

The other thing it does well is typo correction. When you misspell words, the keyboard automatically corrects your typos based on QWERTY patterns of typing errors. This lets you type, type, type, without worrying about typos: the keyboard corrects most typos for you.

I had jailbreaked my iPhone so I could use it on T-Mobile. A pleasant side effect of jailbreaking was the Cydia app market. In Cydia, I found a Russian keyboard add-on and a Dvorak hack. The Russian+Dvorak hack gave me a Dvorak keyboard layout, but it didn't give me the iPhone keyboard benefits. The key clues were in Cyrillic, so it was difficult not to make typos, and the typo corrector was still looking for QWERTY typo patterns, so the keyboard couldn't correct my typos properly. The Russian+Dvorak hack was a disappointment, so I reluctantly stuck with QWERTY.

A while later, iKeyEx was released. iKeyEx was a good alternate keyboard framework, with support for many international keyboard layouts. I installed iKeyEx and the Dvorak keyboard layout, and voila! I had an excellent Dvorak keyboard on my iPhone.

Tapping Dvorak on the iPhone was great, but I discovered something interesting. Thumb typing is a different skill from touch typing. Thumb typing is more like hunt-and-peck, especially with an on-screen keyboard, where there are no home keys or other tactile clues. It turned out that I could thumb type QWERTY faster than I could thumb type Dvorak. After all that work, I was better off with the QWERTY layout anyway.

Then I upgraded my iPhone to OS 3.0, which broke iKeyEx. No more Dvorak, even if I wanted it.

The bottom line
I reluctantly thumb type QWERTY on my phone, a little bit by choice, and a little bit because there is no choice. If I had a phone that had excellent Dvorak support, I might give it another try.


Mobile Service Architecture

This blog entry is adapted from the Mobile Service Architecture Wikepedia article I recently wrote.

Mobile Service Architecture (MSA) JSR 248 is a specification that describes an end-to-end wireless environment for J2ME. MSA includes a full set of 16 JSRs and a subset of 8 JSRs:

MSA Subset
The MSA Subset includes the following JSRs:
JSR # Specification or Technology
75 PDA Optional Packages for the J2ME Platform
82 Java APIs for Bluetooth
118 Mobile Information Device Profile (MIDP) 2.0 for Java ME
135 Java Mobile Media API (MMAPI) for Java ME
139 Connected Limited Device Configuration (CLDC) 1.1 for Java ME
184 Mobile 3D Graphics API for Java ME 1.0 and 1.1
205 Wireless Messaging API 2.0 (WMA) 2.0
226 Scalable 2D Vector Graphics API for Java ME

MSA includes the MSA Subset and the following JSRs:
JSR # Specification or Technology
172 Web Services Specification for Java ME
177 Security and Trust Services API for J2ME (SATSA)
179 Location API 1.0 for Java ME
180 Session Initiation Protocol (SIP) API for Java ME
211 Content Handler API (CHAPI)
229 Payment
234 Advanced Multimedia Supplements API for Java ME
238 Internationalization

See also
External links



I am the foremost authority on iPhone Dvorak (not!)

Update: See Read More on Dvorak for iPhone for more!

I am the world's foremost authority on using the Dvorak keyboard layout on iPhone.

No, I'm not! But I was mentioned in this article in the Wall Street Journal: Smart Phone Keyboards Seem Dumb to People of Their Type. Author Joseph de Avila does a good job introducing the topic to the general reader. Here's hoping that manufacturers like Apple take notice.


Eat at Beijing Kitchen

Beijing Kitchen is yummy. They are in Arlington Center, at 14 Medford St., Arlington, MA 02474-3106. Here is a scan of their menu. Call 781-648-8828 and place your order now!


See Bruni at the Middle East

Bruni's way cool photorealistic paintings are on display at the Middle East Corner now through mid-October. Join Bruni and the other artists at the opening reception for this group show on Monday, September 21, at 10:00 PM. RSVP on Facebook , and we'll see you Monday night.


Device access rules of thumb

A friend asks a question:
We have a project where I need to test on various BlackBerry devices, and we have gotten along with the simulators, but I need more devices. I am planning on taking the SIM cards and just moving them around to the different BlackBerries, but do you have a recommendation for acquiring devices? I am looking at some of the electronic sellers and also eBay of course. But was wondering if you had a specific tactic for getting devices for the development and testing.
Dear friend, I'll try to help. First, here are some mobile app development rules of thumb. It looks like you are already following most of them:
  • Develop in the emulator first. There is no barrier to entry as a mobile developer if you start with device emulators, most of which are free. As a programmer, the feedback loop is fast: write and build your code, run it in the emulator, see how it behaves, and repeat.
  • Develop on a single reference device. Obtain one physical device and use it as your reference platform. Use only one reference device. If you try to support numerous reference devices, you'll spend too much time supporting the devices and not enough time adding new features to your app.
  • Your reference device must be a physical device. The physical device always behaves differently from the emulator. Your app isn't Done until you have it running on the physical device. Not having the physical device is a larger impediment to your success than any money you might save using only the emulator, so you must use a physical device.
  • When porting to new devices, do it on physical devices. As with the reference device, your app isn't Done until you have it running on the physical device, and not having the physical device is a larger impediment to your success than any money you might save using only the emulator.
  • Use DeviceAnywhere if you need a particular physical device immediately or if you want to save money on devices, voice plans, and data plans. DeviceAnywhere gives you web access to a huge library of physical devices. These are real devices hooked up to a hardware controller. You have remote control over the devices, and you can see the screen and listen to the audio in real time over the web. Be cautious, though: DeviceAnywhere is good, but it is much slower than having a physical device in your hands.
As far as obtaining physical devices goes, you'll have to buy them with actual cash money. You can get good deals on used and refurbished phones through vendors on eBay. If you need a new subscriber account, you can get a good deal from a carrier, as long as you don't mind another one or two year service contract.

Some carriers and device manufacturers have developer programs that give you free or low cost access to physical devices. RIM has a developers program, offering some support and a cheap Enterprise Server license, but you won't get devices. Other carriers and device OEMs offer prerelease devices.

Good luck, friend. Have fun building BlackBerry apps!


Porter Square apartment for rent

Email rent@kasperowski.com to view the apartment or apply for a lease.

3 bedrooms
1.5 bathrooms
975 square feet

Includes parking, private laundry, private storage, private back yard space

Well maintained apartment on tree-lined cul-de-sac
Recently renovated, open floor plan
2 blocks from the Porter Square T and commuter rail station
Near Davis Square
A short walk to shopping, restaurants, parks, yoga, martial arts,
Leslie, Harvard, elementary schools, etc.

No fee


Upcoming Agile Bazaar events

The Agile Bazaar is hosting two great events during the next two weeks. The warm up act is tomorrow night, July 23, with Johanna Rothman and other panelists discussing Agile Teamwork: The People Issues. The headliner is on August 6, with Jeff Sutherland presenting A Practical Roadmap to a Great Scrum. Both events begin at 6:00 PM at the Microsoft New England Research & Development Center at One Memorial Drive in Cambridge. See you there!



Three roles, ceremonies, artifacts, best practices

Scrum is a simple framework for product development and team improvement. At its basis, all it does is define three roles, three ceremonies, and three artifacts. There are three related best practices that are good to use, but that are not part of the definition of Scrum. This is a super-small summary of the four threes, based on Dan Mezick's Scrum-in-30-minutes presentation.

Scrum's three roles
  • Product Owner: owns and prioritizes the product backlog
  • Scrum Master: facilitates the Scrum process
  • Team: delivers a working product in increments
Scrum's three ceremonies
  • Sprint planning meeting: review the backlog, review backlog estimates, pull stories from backlog, and make a sprint commitment
  • Daily scrum: 15 minutes at the same time every day. What did you get done? What will you get done? What impediments are preventing you from getting things done?
  • Sprint review meeting
    • Part 1: demo
    • Part 2: retrospective. How can the team accelerate?
Scrum's three artifacts
  • Product backlog: list of user stories, prioritized by business value
  • Sprint backlog: pulled from the product backlog, the list of stories that the team has committed to delivering at the end of the current sprint
  • Burndown chart
    • Sprint burndown: task hours completed toward this sprint's commitment
    • Product burndown: story points completed toward some product release target
Three best practices
  • User stories: As a TYPE-OF-USER I want SOME-GOAL [so that SOME-REASON]. E.g., As an end user I want the app to work with my BlackBerry Enterprise Server configuration so that I can listen to audiobooks regardless of the BES configuration.
  • Planning poker: a fun, efficient way to estimate user stories and tasks, with the side effect that team members develop a shared understanding of each user story and task
  • Scrum board: an information radiator, including at least the task board for this sprint's commitment. The minimum swim lanes are Committed, In Progress, and Done, or, more generally,To Do, Doing, and Done.


Nuke your phone

A Hoffman box is an important tool for testing mobile apps. Does your app behave properly when it loses its network connection? What about when the connection is restored? What if it loses the connection while downloading data during a screen transition? What if the user cancels a transmit/receive action during a period of intermittent connectivity? Enumerate all the ways your app could break because of network connection problems, and use a Hoffman box to test your app on an actual phone.

"A Hoffman Box is an enclosure used to secure electrical and/or network equipment."[Wikepedia: Hoffman Box] I have three Hoffman boxes in my home: one in the basement where the main electric line enters the house; another one in the basement for the main feed to my apartment; and one inside my apartment, with individual circuits for each room. Hoffman is a company that makes these boxes. "Hoffman box" has become a generic term for these boxes, like Kleenex is often used as a generic term for tissue.

A Hoffman box

In the mobile apps industry, we have repurposed the Hoffman box. We use Hoffman boxes "to temporarily shield mobile devices from their carrier signals"[Wikepedia], helping us test the our apps and devices under adverse conditions. We don't use actual Hoffman-brand boxes--we apply the term Hoffman Box to any metallic enclosure that limits the device's ability to connect to the network. "Most industry Hoffman Boxes are modified faraday cages, built without an opposing electrical field running through them and often not grounded in any form."[Wikepedia]

Most of us don't have a spare Hoffman box that we can use for testing, but we do have an excellent substitute: the microwave oven in your kitchen. Your microwave oven is a box. Five sides of the box are shielded with metal, and the sixth side is shielded with a metal grid. Microwave transmission is blocked by the oven box so the oven doesn't cook you while you watch it cook your food. Thus your microwave oven is a Hoffman box.

Is the microwave oven an acceptable Hoffman box for testing mobile apps? The oven blasts your food with energy in the 2.45 GHz frequency band, so the oven's box shields against that frequency band. This table shows common frequency bands for the microwave oven, cellular networks, and WiFi networks:

850 MHz == 0.85 GHz

900 MHz == 0.90 GHz

1700 MHz == 1.7 GHz

1800 MHz == 1.8 GHz

1900 MHz == 1.9 GHz

2100 MHz == 2.1 GHz

2.4 GHz

2.45 GHz

5.0 GHz

I conducted some tests to see what happens to my phone inside a microwave oven. The test device is a first generation iPhone running on T-Mobile at 1.9 GHz [Wireless Advisor] and connected to a local WiFi network at 2.4 GHz.

For Test 1, I set the phone to Airplane Mode and I turn on the WiFi radio. The phone connects to my local WiFi network. I run Mobile Terminal and type ping kasperowski.com. The pings return to my phone in a few hundredths of a second. I place the phone upright in a plastic bowl in the microwave oven and shut the door. After a few seconds, ping reports No route to host, and the WiFi indicator goes dark. I remove the phone from the microwave oven. A few seconds later, the phone reconnects to the WiFi network and pings again return to the phone in hundredths of a second.

My microwave oven

Test 1: outside the oven, inside the oven, and outside the oven

For Test 2a, I unset Airplane Mode, and the phone reconnects to T-Mobile with an EDGE data connection. I turn off the WiFi radio. I ping kasperowski.com again, and the pings return in tenths of a second. I place the phone in the microwave oven and shut the door. After a few seconds, ping reports No route to host, the carrier indicator displays No Service, and the data network indicator goes dark. I remove the phone from the microwave oven. About a minute later, the phone reconnects to T-Mobile with an EDGE data connection. The next ping reports that it took about 71 seconds, and subsequent pings take tenths of a second.

Test 2a: outside the oven, inside the oven, and outside the oven

Test 2b is like test 2a, but the result is slightly different. When I place the phone in the microwave oven and shut the door, ping reports No route to host and the data network indicator goes dark, but the phone retains its GSM connection to T-Mobile.

Test 2b: outside the oven, inside the oven, and outside the oven

In all three tests, the phone lost its data connection when I placed it inside the microwave oven, and restored its data connection when I removed it from the oven. The microwave oven's box is designed to limit transmissions in the 2.45 GHz band, and I tested the 1.9 GHz and 2.4 GHz bands. For these frequency bands, the microwave oven is an excellent Hoffman box for testing mobile device connectivity.



Ken Schwaber's Flacid Scrum

Ken Schwaber presented "Flacid Scrum--A New Pandemic?" last night at the Agile Bazaar. Ken's talk was a one hour overview of Scrum, with the point that if it's ScrumBut, then it's not Scrum. Scrum works because it exposes organizational impediments to success, not despite exposing impediments. Don't adapt Scrum to your organization's dysfunctions; correct them!


Krausen is your friend

If you are a brewer, then krausen is your friend. I keep my brewing simple, without quantitative specific gravity measurements to inform me whether the beer has completed its fermentation or how much alcohol it contains. Instead, I count bubbles and watch krausen. After a week in the primary carboy, my active krausen is telling me that it's not yet time to rack to the secondary. This simplicity is relaxing.


Learning Agile via Agile Games

Michael de la Maza presented "Learning Agile via Agile Games" at Wednesday night's Agile Boston meeting. We played some fun games that would have been impossible to win if they weren't fun and if we didn't communicate with each other face to face.

One of the games was a brief Planning Poker exercise. Michael's point was that one of the valuable outcomes of Planning Poker is the discussion among team members, surfacing previously unknown requirements, enabling team members to understand and agree on product goals and requirements.

One of Michael's themes is that delivering a successful software product is 80% about the people and only 20% about the technology. He referenced some interesting sources, including The Psychology of Emotions, Fellings, and Thoughts, by Mark Pettinelli (affiliate link), and Paul Ekman's work on microexpressions. Michael mentioned the field of positive psychology and the Zappos core values as a way to inject positive psychology into a business:
  • Deliver WOW Through Service
  • Embrace and Drive Change
  • Create Fun and A Little Weirdness
  • Be Adventurous, Creative, and Open-Minded
  • Pursue Growth and Learning
  • Build Open and Honest Relationships With Communication
  • Build a Positive Team and Family Spirit
  • Do More With Less
  • Be Passionate and Determined
  • Be Humble


Acceptance criteria template

When is it Done? How do you know? Does your Product Owner agree? Does your customer agree?

When we estimate user story size and sprint task effort, we ask ourselves how we will know when a task or a story is done. We make a list of doneness tests, and we call them acceptance criteria. In the spirit of Mike Cohn's user story template, we use a simple but effective template to define our acceptance criteria:
We'll agree it's done when [testable present tense active voice predicate].
Here is an example:
We'll agree it's done when ...
  • A team member can localize the app to Mexican Spanish.
  • The app displays all menu items in Mexican Spanish, as specified in the localization file.
  • The app displays all messages and dialogs in Mexican Spanish, as specified in the localization file.
We review the acceptance criteria with our Product Owner and customer, and we all agree ahead of time on what it means to be Done. We avoid a lot of rework by agreeing on acceptance criteria before we commit to sprint tasks. We know our customer will accept our delivery because we tested against the acceptance criteria--the same acceptance criteria he will use to agree that we are Done.


This is push

Simon Judge writes about mobile push and wonders what technologies are available beyond IMAP, Microsoft DirectPush, iPhone's upcoming Push Notification Service, BlackBerry's push service, and SMS. Simon might not have been aware that Java ME solved this problem a few years ago in MIDP 2.0. If you are interested in push-enabled mobile apps on Java devices, read all about it here:


Story point inflation

My teams have begun estimating the size of product backlog items in story points. We estimate individual user stories and tasks in story points, we sum the individual estimates to give us the total amount of product backlog left, and we track product burndown in story points on a sprint-by-sprint basis. Tracking product burndown yields our sprint-by-sprint velocity, which we use to forecast our project done dates. At the micro level of each sprint, we continue to re-estimate user stories and tasks in man-hours of team effort, and we burn down the man-hours as we complete each task. As we gain more experience and confidence with story points, we may drop man-hours estimation and work entirely in story points.

We usually can't estimate the size of all the user stories up front, all at once. We want our meetings to be short--we'd rather spend our time building useful product--so we don't have enough time to estimate all the stories in one estimation meeting. We want to get started implementing the high value stories even though we haven't yet thoroughly estimated the lower value stories, so we begin the first sprint without having estimated everything up front. The product backlog changes over time, so there are always new stories to estimate after we get started. The team's understanding of the backlog deepens with each sprint, and they want to re-estimate stories that they previously estimated. All of these factors contribute to the reality that backlog estimation continues throughout the life of the project.

An unintended consequence of ongoing backlog estimation is story point inflation. Estimates for new stories are larger than for similar previously estimated stories, and previously estimated stories are re-estimated larger. Story A and Story B might be similar, but, after having completed Story A and learning that it was more difficult than they thought, the team estimates (or re-estimates) Story B larger. Are they sandbagging? Are they being honest? Are they conflating size and complexity, measured in story points, with effort, measured in man-hours?

Story point inflation is a problem. If you have estimated all the user stories in the product backlog, and if you haven't added any new stories, then the aggregate size of the product backlog shouldn't change--it is a constant. If you know your team's sprint-by-sprint velocity, then you can forecast your project done date. But if the size of the product backlog keeps growing due to re-estimation, then you have no way to gauge your team's true velocity, and no way to forecast your project done date.

In the future, we'll try to mitigate the problem of story point inflation by standardizing our size estimates for user stories. We'll post a table showing benchmark user stories and their estimated sizes across various projects, and we'll review all estimates against the benchmarks. This should help us avoid story point inflation. We'll have better, more stable estimates, a more accurate gauge of team velocity, and more accurate forecasts of our project done dates.

Related reading:
  • http://blog.mountaingoatsoftware.com/is-it-a-good-idea-to-establish-a-common-baseline-for-story-points and the comment http://blog.mountaingoatsoftware.com/is-it-a-good-idea-to-establish-a-common-baseline-for-story-points#comment-21036
  • http://jamesshore.com/Blog/Estimate-Inflation-A-Cautionary-Tale.html


Windows Start Menu doesn't pay attention to me

On my work PC, the Windows Starts Menu didn't pay attention to me. I told it that I don't need it to list an email client. I ran plenty of applications, and they appeared in the most recently used list. Every time I logged out, though, it ignored me, showing Outlook Express as the email client, and the default list of programs instead of my recent ones. Gosh, it really ground my gears.

How did this chaos happen? When I installed Windows XP, I created a local user for myself, richard. I logged in a local user richard, and Windows initialized some state for my user. Then I logged out, joined my company's Windows domain, and logged in as my domain user, richard. My domain user suffered the problems.

The only way I could fix it is by reinstalling Windows. I was careful not to log in as a local user named richard before logging in as my domain user named richard. All is well, and I sure do sleep better at night.


Stink test

Is the milk in your refrigerator safe to drink, or is it rotten? Open the bottle and take a sniff. If it stinks, it's probably rotten. You don't have to taste it. You don't have to drink a pint of it and see whether you get sick. You know immediately that it's no good. Throw it away and get a new jar of milk.

Stink test is a metaphor for an easy way to determine whether something is right or wrong. If it smells rotten, it probably is. Throw it away and start over. Stink test is a very simple heuristic for determining the validity of a statement or concept. The idea is to trust your intuition; you're probably right.

For example, say your team estimated that it would take one hour to complete a user story. You know that the story is very complex and probably can't be done in less than three days. The one hour estimate smells rotten. It can't be right--it doesn't pass the stink test. Throw it away and start over.

Synonyms include sniff test and scent test. Similar tests are the rice test and the spaghetti test. The spaghetti test metaphor is that you can tell whether your spaghetti is done by throwing it against your kitchen wall; if it sticks, it's done and ready to eat. Do you have a good idea? Are you sure? Lob it out there--does it stick? If it doesn't stick, it's either wrong or it's not ready yet.

Here are some examples:


i.word.com: the best iPhone dictionary

Merriam-Webster recently launched an excellent iPhone adaptation of their web site. Type m-w.com or i.word.com into Safari, look up a word, read the definition, and hear the pronunciation. Add a link to your home screen, and you won't notice that it's not a download app. This is by far the best English language dictionary for iPhone.


Skype for iPhone

Skype for iPhone was released on March 31. I had been waiting for this since I got my iPhone a year ago. I am an active, satisfied Skype user, using it every day to talk with people on my team around the world. I rely on Skype, and I was excited to try it out on my jailbreaked first generation iPhone running firmware 2.2.1.

It didn't go smoothly. After the happy splash screen, I tried to log in to my account. The result was an error message displaying this text:
No Network Connection
Please check your network settings
and try again.

Wristlock reported that he got past that error message by rebooting his iPhone. I rebooted, tried again, and my log in succeeded.

The proof of the pudding is in the voice call, so I called the lovely Skype Test Call woman. She let me down: she echoed a little, and her voice dropped out a bit. I told her a secret, and my voice came back with dropouts. Overall, the call quality was poor. Worse, Skype crashed during my test calls and immediately after my voice echoed back.

But wait! iPhone Hacks reports that the instability only occurs on jailbreaked iPhones, and Saurik already has a fix. I ran Cydia and updated Mobile Substrate. I rebooted the iPhone and tried Skype again. Audio was still a bit jittery during the short test call, but on a longer call to a coworker in Europe, the audio was good enough. Better yet, the Skype app didn't crash during our 10 minute conversation.

The bottom line: Skype for iPhone works fine. Use it as your mobile Skype client or as a backup when your PC crashes.


Firefox: An unknown error occurred while printing 2

A while back, I had trouble printing from Firefox. I had an unreliable solution that worked for a lot of people a lot of the time. It didn't work all the time, though, and it didn't work for everyone.

The best solution is simply to uninstall Firefox, delete your Firefox profile, and reinstall Firefox. Sync your bookmarks ahead of time with Google Toolbar/Google Bookmarks or FoxMarks if you don't want to lose them. I was initially too stubborn to clean up and reinstall Firefox, but after having done it, everything works better. I am a happier man and a better citizen for having done it. Give it a try.


MobileCampBoston2 notes

These are my notes from two sessions I attended on Saturday at MobiCamp Boston 2.

Building Android apps

Android apps can run in background
Linux-based security
App is Java/J2ME + lots of extra classes from Google
Activity: your app's basic view, e.g. HelloStart
All package names start with "android"
android.location.LocationListener: for location services
DDMS: your good debugging interface
... and I spent the rest of the hour downloading and configuring Eclipse and the Androd SDK, and then writing Hello World and running it in the G1 emulator.

Selling on the app store: the first 6 months
JJ Rohrer from Elegant Technologies, LLC

He built a bunch of apps, many of which were derived from each other. He tracked the tweaks he made to each app and charted the impact of each change.
No intentional marketing--just a bunch of experiments

JJ's experiments:
  • Front page (launch day): great sales numbers
  • Most apps have asymptotic decline after launch day (Elegant Words)
  • Upgrade: sales spike, but not as high as launch day (Would it be a good idea to publish upgrades as new apps? Because launch day spike exceeds upgrade day spike.) (Fresh apps sell better.) (publish upgrades frequently to get the repeated sales spikes) (Updates list is separate from new releases list)
  • Professional redesign: sales spike, but not as high as first upgrade
  • Upgrade adding skinning: sales spike, but maybe not related to skinning
  • Refer a Friend yields more purchases than in-app catalog of other apps, but hardly anyone uses refer a friend anyway (2% tap the button)
  • Web app staff pick: great usage spike
  • Category doesn't seem to make a difference
  • Free lite version of app: didn't lead to purchases of full version, probably cannibalized sales of full version
  • Android: Clone PowerNap for Android. 1000 downloads per day for free on Android store. Attempted to sell through Handango--got only 2 sales at $1.99. Relaunched on android store as pay app; can't discover it in app store, even via search.
  • Localize product description but not app (e.g., sell to Japanese consumers): no sales impact
  • Localize app (currency): no sales impact
  • Advertising
    • Facebook: cheap, no sales impact
    • LinkedIn: expensive, no sales impact
    • Google: targeted, no sales impact
  • Apple's changing guidelnes and enforcement
  • Search doesn't necesarily return his apps
Category, rank, free count, paid count (sales per day)
  • education, top 1, , 100
  • lifestyle, top 50, 300, 25
  • games, top 1, , 10000

android vs iphone
platform, free count, paid count (sales per day)
  • iphone, 125, 2
  • android, 1000, 0.25
Localytics: cross platform analytics

Use Google Alerts to discover who is saying what about you.

Pirates: maybe 30% of server hits are from pirates

  • Distribution trumps all. Top 100 or featured item.
  • App is useful
  • Personalization
  • Being on pp store isn't enough on its own
  • Get as many Day 1 reviews as possible
  • Launching early on platform is more profitable


Agile for mobile

Agile for mobile

These are my notes from a presentation I gave Saturday at MobiCamp Boston 2.

The pitch
  • ... or maybe it's in the product development, too
  • Software engineering is where you spend most of your effort, time, and money when you build your mobile app
  • Scrum can help control your software engineering effort/time/expense
  • I'll share some of my team's practices
Why Agile
  • Not because
    • It's trendy
    • It's cool
    • You think it allows you to be lazy
    • You don't like process
    • (because actually is a strict process, and it doesn't allow you to be ad hoc or lazy)
  • Because software engineering is the most expensive, most time consuming, least predictable part of product development
  • Need a way to mitigate the expense, control the cost, decrease risk, and get product into market faster
  • How: Eliminate Waste
    • Don't do things that don't have high business value
    • Don't make development team switch context frequently
    • Communicate
      • Frequently
      • High bandwidth
      • High signal:noise ratio
      • Know what to work on, what not to work on
Why Scrum in particular
  • Not XP
    • XP is great, but the practices don't scale well to the management level
    • XP is too micro-level, with individual practices like pair programming and unit testing
  • Scrum is a full framework for agile management and product development
  • Scrum framework is easier to communicate to management.
Scrum heritage
  • Backlog
  • Sprints
    • Goal: produce a unit of potentially releasable software
      • With no new technical debt
    • 2 weeks long
      • Long enough to get stuff done
      • Short enough so it feels urgent and so you can frequent feedback from customer
      • 10 work days: division by 10 is easy
    • Sprint planning meeting
      • Estimate stories
        • Estimate all unestimated stories in release backlog
        • Planning Poker
          • Avoids anchoring
          • Fun and accurate
          • Quick
      • Select, commit
        • Select highest business value items from backlog
        • Publicly, to each other
        • Based on team's known velocity
          • Review team's historic velocity to make sure commitment is reasonable.
        • Velocity per team, per day, per team member
          • Typically 4-6 hours per person per day
        • Team, not management, makes commitment
        • People tend to keep commitments that they make for themselves and that they make publicly.
      • Keep commitment stable for sprint duration
        • Don't switch context too frequently--it wastes development time (Eliminate Waste)
        • Scrum Master protects the team
    • Sprint review meeting
      • Demo
      • Retrospective
        • Team determines how to increase velocity (Eliminate Waste)
      • Gauge sprint velocity
        • Able to predict final done date after a few sprints
        • Release backlog / team velocity => # of sprints left
    • Deliver to customer on last day of each sprint
  • Burndown chart
      • Sprint burndown
      • Project burndown
      • How many hours did you commit do getting done? How many hours are left?
        • Offers clues to whether your sprint is on track.
        • Slope of graph compared to ideal linear slope
        • How close to 0 work left?
        • What sprint day is it?
        • Are you on track?
      • Able to make adjustments based on actual progress data
        • Add people
        • Remove committed items
        • Warn product owner, customer
      • Burndown hours/story points when story is Done
      • What is Done? What does Done mean?
      • Publicly track actual progress against commitments
    • Daily scrum
      • What did you get done yesterday? What do you plan to get done today? What are the impediments to getting things done?
      • Publicly track actual progress against commitments
      • Look for impediments that prevent team from meeting commitments
      • Scrum Master removes impediments
      • Communicate
    • Weekly scrum-of-scrums
      • With each customer
      • With senior management
Agile != lazy or ad hoc
  • Deliberate
  • Surprisingly detail oriented
  • Lots of communication through the Scrum rituals (burndown chart, daily scrum, sprint planning and review meetings)
  • You are not excused from excellent up front project planning
  • You are excused from anything that doesn't help the team get closer to being Done (Eliminate Waste!)
  • Fixed fee project difficult to reconcile with Agile.
    • When will it be done?
    • How much will it cost?
  • Estimation
    • Can't estimate stories/requirements you don't know about
    • Can't properly estimate stories that change
  • Difficult to get people to prioritize backlog
  • Eliminate waste
    • Don't work on stuff that has low biz value
    • Save, money
    • Increase velocity
      • Velocity is a vector. The direction is always "toward the most business value."
  • Backlog grooming forces people to state and agree on priorities
    • Painful but must be done
  • Able to accurately predict done date
    • After a few sprints
    • If you know team's velocity and size of backlog, you can predict done date
  • Able to tell customer not to add or change requirements
    • Easy to show customer how adding to backlog delays done date
  • Happier dev team, customer, management


Mobile success factors: how to succeed, how to fail

These are my notes from a presentation I gave Saturday at MobiCamp Boston 2.

The pitch

  • You are building a mobile app
  • You want it to be successful
  • How do you do that?
  • Is there something in product development that you can control? Of course, but we all know how to build a great app, so that doesn't distinguish you.
  • So it's all about the marketing, right?
  • I surveyed six mobile apps to find out why some of them are successes and other are not.
  • What are the key mobile success factors that will help you win?
  • Sit in on my talk to hear about the survey and find out why some apps succeed and some don't.
  • We can all build excellent mobile apps
  • What it is that makes successful mobile apps?
  • If you were to build a new mobile app, what kind of app would be your best bet? What kind of marketing would be your best bet?
  • Be patient--the answers come later in the talk.
  • Disclaimer
    • This is early research.
    • Think of it as the seed of some useful information.
    • Needs to be tuned and improved
  • Given two apps that are almost exactly the same, why is one successful but the other is not?
  • How can all the apps we build be successful?
  • Background reading
    • Theory of Constraints
      • A friend gave me the book The Goal: A Process of Ongoing Improvement by Eli Goldratt
      • A business novel. Instead of a dry how to guide, it is a dry novel, telling the story of a business team running a division of a failing company and how they fix it, make it succeed.
      • Got excited about it, read the two follow up books
    • Scrum
      • ToC, Toyota production system tuned for software engineering (really for any business)
    • Toyota production system
      • Eliminate waste
      • For software, see Scrum: don't do things that have low business value
  • ToC process
    • Identify your goal
    • Identify the biggest constraint on achieving your goal
      • Globally, through the whole system, not just in your area of responsibility (for me, this means not just in software engineering)
    • Fix that constraint
    • Repeat
  • ToC in practice, for mobile apps
    • Identify your goal
      • Make money by building successful mobile apps
    • Identify the biggest constraints on achieving your goal
      • Product development
        • How can I build more apps faster?
      • Marketing
        • How can I sell more apps after they are built?
    • Prioritize
    • Fix that constraint
    • Repeat
Product development
  • Product life span
    • Product development is most expensive, most time consuming, riskiest part
    • Large revenue opportunity at end of product development
  • Definition: everything that goes into building an app suitable for sale to consumers
  • UX design
  • Software engineering
    • Most expensive, most time consuming, riskiest part
    • Address via Scrum
      • Scrum is like Theory of Constraints tuned for Software Engineering. When applied well here, Scrum mitigates this constraint, but doesn't eliminate it.
  • Product life span
    • Many smaller revenue opportunities beginning at product launch
  • Definition: everything that goes into selling the app to consumers and making money on it
  • Given two apps that are almost exactly the same (Music1 and Music2), why is one successful but the other is not?
    • Same product development work, so eliminate product development as biggest constraint
    • It must be the marketing--our biggest constraint on success

  • Identify mobile apps to evaluate
    • Identified six mobile apps
    • Due to nondisclosure agreements, cannot name apps, who built them, or for whom they were built
    • Things these apps have in common
      • All apps are currently available to consumers
      • All apps have a monthly subscription revenue model, not one time purchase
      • All are data connected. Getting and storing data OTA on a remote server
    • None are iPhone App Store apps
    • Some are downloadable app's, some are preloaded on phones, some are web apps
  • Gauge each app's perceived level of success
    • Ask producer, sponsor: is this app successful?
      • Keep it simple: binary answer, Yes or No
    • Qualitative, not numeric. "I know it when I see it."
    • Adequate for this study; people have internalized goals for the apps and have no hesitation communicating whether an app is successful or not
    • 3 successful, 2 not successful, 1 not sure
  • Enumerate obvious characteristics/dimensions
    • 22 characteristics/dimensions to help understand why some apps succeed and other don't
    • Mostly marketing oriented, but some product development oriented
    • State each characteristic as a predicate, e.g. Is it a web app? Is it inexpensive? Does it include streaming video?
      • Keep it simple: binary answer, Yes or No
    • Try to construct the predicate such that the answer should be positive for a successful app
  • For each characteristic/predicate/dimension
    • Answer the predicate for each app: Yes or No.
      • Predicate nature keeps it simple.
    • Derive a success correlation score
      • The probability that a successful app has this characteristic
      • If you have this characteristic, are you likely to succeed?
      • The number of Yes answers divided the number of successful apps
    • Derive a failure correlation score
      • The probability that an unsuccessful app lacks this characteristic
      • If you lack this characteristic, are you likely to fail?
      • The number of No answers divided by the number of unsuccessful apps
    • Combine success score and failure score into a weighted score
      • weighted-success-correlation = success-correlation * num-successful-apps
      • weighted-failure-correlation = failure-correlation * num-unsuccessful-apps
      • weighted-score = (weighted-success-correlation + weighted-failure-correlation) / num-apps
  • Sort dimensions by combined weighted success score
    • High score => correlates to success
    • Low score => does not correlate to success
  • If combined weighted success score is >0.50, then the dimension is a success factor
  • In general, ignore the "not sure" app. It is not obviously either a success or a failure, so its results don't help.
Results: top success factors
  • High: combined weighted correlation score == 1.00
    • Acceptable number of subscribers
      • A proxy for "acceptable monthly revenue"
      • "Acceptable" different from "high". Depends on app's target number of subscribers or target revenue.
      • A new app with 1,000 subscription events per month might be acceptable. An app that had high product development cost and has 100,000 subscription events per month might be unacceptable.
      • Based on your criteria, if the app's number of subscribers meets its target, whatever that target is, then the app is successful.
    • Inexpensive (Retail price less than $2.75 per month)
      • Consumers will buy it if it's inexpensive.
      • $2.50 per month is an attractive price point.
      • Two of the successful apps are quasi-free: included for free
        • In monthly membership of a related service, or
        • In the price of the carrier's data plan.
      • Unsuccessful apps are as high as $5 per month
    • Web app
      • Two of the successful apps are web only
      • One of the successful apps is both web and download/preload
      • Web apps have a low barrier to use compared to download apps
        • There is nothing to download--just launch it in your mobile web browser
      • Successful apps are either
        • Easy to find on carrier deck, or
        • Have easy way to send URL to your phone via SMS
      • Easy to adapt web app to large number of devices
  • Next best success factors: combined weighted correlation score == 0.80
    • Small carrier size
      • Small carrier == has less then 50million subscribers
      • Two of the successful apps are on a small carrier deck
      • Both of the unsuccessful apps are on a large carrier deck
    • Few competing apps on deck / in app store
      • Two of the successful apps are one-of-a-kind on the carrier deck
      • The two unsuccessful apps have many competitors
      • May be a corollary to "Small carrier size"
      • Do app vendors perceive "large carrier" as "large potential market of consumers"? Are too many vendors attracted to large carriers, leading to too much app competition?
    • Long term deck / app store promotion
      • Two of the successful apps have been long term featured items on carrier's deck
      • The two unsuccessful apps have not been featured items for more than one or two weeks at a time.
    • Carrier branding
      • Two of the successful apps are the "CarrierX Special Cool App", extending the carrier's brand name to the product category
      • Neither unsuccessful app is carrier branded.
      • Another corollary to "small carrier size" and "long term deck / app store promotion"? Does carrier prefer to promote it because of the branding?
Results: bottom success factors (non-success factors)
  • Product category
    • Not a numeric success score
    • The factor that got me started on this: if two apps are virtually identical, but one is successful and the other isn't, why?
    • Survey uses category names from iPhone App Store. 2 Music apps, 2 Entertainment apps, 1 Lifestyle, 1 Sports
    • One Music app is successful, the other isn't
    • One Entertainment app is successful, the other isn't
    • Product category not a predictor of success.
  • Low: combined weighted correlation score == 0.20
    • Product >12 months on market
      • Product age does not correlate to success
      • One successful app is one month old; another is 24 months old
    • Short term deck / app store promotions
      • Similar to, but not the exact complement of "long term deck / app store promotion"
      • Occasional short term promotions do not yield success
    • Short term mobile web advertising
      • Targeted to supported devices
      • Occasional short term advertising does not yield success
      • No apps had long term mobile web advertising, so don't know whether that would be a success factor
    • Famous brand
      • Only one of the successful apps has a famous brand name
      • Both unsuccessful apps have a famous brand name
    • Downloadable app
      • Similar to "web app"
      • Downloading is a barrier to installation?
      • More difficult to adapt app to a large number of devices
        • Device fragmentation: Java, BREW, iPhone, Android, screen sizes, etc.
    • Streaming video
      • Only one successful app is video oriented
      • Both unsuccessful apps contain stream video
  • If you were to bet on the success of a new mobile app, what should you look for?
  • Bet on
    • Inexpensive (Retail price less than $2.75 per month)
    • Web app
      • Or at least a web alternative to a download app
      • E.g. Remember the Milk
    • Few competing apps on deck / in app store
    • Long term deck / app store promotion
  • Don't bet on
    • Downloadable app
    • Streaming video
    • Short term promotions or advertising
    • Famous brand
  • It's only six apps with a specific revenue model (monthly subscription)--may not apply to you
Next steps
  • Identify additional apps to evaluate
    • Including single-purchase apps
    • Global survey?
  • Devise a quantitative measure of app success
    • Better than "I know it when I see it."
  • Identify additional dimensions (including more non-marketing factors), evaluate apps in those dimensions
    • Free trial
  • Strengthen statistical model
    • Although these initial results pass the stink test
      • Stink Test: If it smells rotten, it probably is.
      • These results don't smell rotten.
  • Grow this seed into a useful tree.


Related Posts with Thumbnails