Starting my career in the software development trenches at consumer electronics company Psion, I've seen the challenges of recruitment from all angles. And as my career has evolved from job seeker to recruiter the frontline experience has stayed with me. Particularly the ability to recognise the very best skills for the job. I also have an appreciation from both angles of how important it is to invest time in recruitment to make the right decisions. A bad judgement call has repurcussions on the individual, the immediate team and the wider business. In recent weeks, I've once again found myself in a situation where considerable people growth is required.  I'm working on a project at Accenture, assisting their Embedded Mobility Services group.  Mobile is increasingly a hot topic, and there's strong demand for people providing expert consuItancy in a variety of mobile development project settings. This experience has led me to review my beliefs about the best way to carry out recruitment in such situations.  Permit me to think aloud...

To start with, I remain a huge fan of graduate recruitment programs.  The best graduates bring fire in their bellies: a "we can transform the world" attitude that doesn't know what's meant to be impossible - and often carries it out!  Of course, graduates typically take some time before they can be deployed in the frontline of commercial software development.  But if you plan ahead, and have effective "bootcamp" courses, you'll have new life in your teams soon enough.  There will be up-and-coming stars ready to step into the shoes left by any unexpected staff departures or transfers.  If you can hire a group of graduates at the same time, so much the better.  They can club together and help each other, sharing and magnifying what they each individually learn from their assigned managers and mentors.  That's the beauty of the network effect.

That's just one example of the importance of networks in hiring.  I place a big value on having prior knowledge of someone who is joining your team.  Rather than having to trust your judgement during a brief interviewing process, and whatever you can distill from references, you can rely on actual experience of what someone is like to work with.  This effect becomes more powerful when several of your current workforce can attest to the qualities of a would-be recruit, based on all having worked together at a previous company in the past.  I've seen the benefit of this effect via networks of employees, sometimes at competitive companies, who all knew each other and who could vouch for each others' capabilities during the recruitment process.  I've also utilised internal networks of high-calibre people from newly mergered and acquired companies, a time when talent can easily get overlooked.  The benefit here isn't just that you know that someone is a great professional.  It's that you already know what their particular special strengths are.  ("I recommend that you give this task to Mike.  At our last company, he did a fantastic job of a similar task.")

Next, I recommend hiring for flexibility, rather than simply trying to fit a current task description.  I like to see evidence of people coping with ambiguity, and delivering good results in more than one kind of setting.  That's because projects almost always change; likewise for organisational structures.  So while interviewing, I'm not trying to assess if the person I'm interviewing is the world expert in, say, C++ templates.  Instead, I'm looking for evidence that they could turn their hand to mastering whole new skill areas - including areas that we haven't yet realised will be important to future projects.

Similarly, rather than just looking for rational intelligence skills, I want to see evidence that someone can fit well into teams.  "Soft skills", such as inter-personal communication and grounded optimism, aren't an optional extra, even for roles with intense analytic content.  The best learning and the best performance comes from ... networks (to use that word again) - but you can't build high-functioning networks if your employees lack soft skills.

Finally, high-performing teams that address challenging problems benefit from internal variation.  So don't just look for near-clones of people who already work for you.  When scanning CVs, keep an eye open for markers of uniqueness and individuality.  At interview, these markers provide good topics to explore - where you can find out something of the underlying character of the candidate.

In summary, I see recruitment and induction as a task that deserves high focus from some of the most skilled and perceptive members of your existing workforce.  Skimp on these tasks and your organisation will suffer - sooner or later.  Invest well in these tasks, and you should see the calibre of your workforce steadily increase.

Anyone who has been in the IT sector for a reasonable amount of time will have collected their fair share of business cards. As a freelancer on the look out for new IT work, they used to be invaluable. Handing them out at conferences, training events, and even at chance meetings in the bar used to increase your chance of getting work. But with smartphones and social networking, are they as important as they used to be?

In Manage It! Your Guide to Modern, Pragmatic Project Management, I explained a schedule game called "We'll go faster now." That's the game where the project team thinks they can improve their speed, even though there is no data that says they can.

There's a similar management game, called "Double Your Velocity." Say a team is new to agile. They estimate they can complete 72 points in a two-week iteration. In the first iteration, they complete 30. Ok, they figure out what's wrong during the retrospective, and they complete 55 points in the second iteration. They learn more about their estimation, so they estimate the stories better, and they refine what done means, so they plan for 63 points in the third iteration. They make it! They keep proceeding, and eventually, they settle in at around 67-68 points per iteration.

Now, a senior manager wants to "help" the team. I see this often masquerading as "motivation." A senior manager comes to the team, gives them a pep talk, and says, "I want to see you double your points for the next iteration." Depending on the team, they may ignore the manager, flip the manager the bird, or placate the manager by doubling their points for each estimate.

This is a management velocity game. It's a game, because management can't motivate people to do more work. Teams can see what's slowing them down, remove those obstacles and maybe they can finish more work. But this business of "motivation"? What a bunch of nonsense. (Tell us how you really feel, Johanna :-))

The real problem is when the manager thinks that the placating team has increased velocity based on his or her actions or pep talk. That's when the team might think they can go faster now, or they keep playing with their estimation points.

Velocity is personal to a team. Period. Mucking with the points does not make the work get done faster.

Windows Phone 7 may not be available yet, but it is a great talking point. Following the collapsing market share of Window Mobile and the Kin debacle, will Microsoft be able to claw its way back into the SmartPhone market? With mobile apps increasingly important in both the consumer and business world, what would be the consequences of failure?

The strategic importance of the platform makes it interesting even if you think that there is little room for Microsoft's phone in a market dominated at the high end by the two As: Apple and Android.

There is even fierce competition among the also-rans, with Nokia pitching Symbian 3 and Maemo/Meego, and HP presumably about to do something with Palm WebOS. And what about Samsung's bada? There will be blood on the carpet; not all these operating systems will survive - and while that will be a shame from the point of view of diversity, it will be a relief to developers attempting to support the broadest number of devices.

So why even bother with Windows Phone 7? Well, there are a couple of obvious reasons. One is the possibility that Microsoft will deliver an excellent and delightful device. Likely? Past form says no; but the company knows what it is up against so you never know; early reviews of preview devices have been generally favourable.

The second reason is less speculative, which is the way Windows Phone 7 fits in with the rest of Microsoft's platform. If you are used to coding in Visual Studio with C#, then creating apps for Microsoft's new phone will be less challenging than doing so for iPhone or Android. A Windows Phone 7 app is essentially a .NET and Silverlight app, or for games XNA, and from what I have seen so far Microsoft has done a good job with the emulator and developer tools.

The disconnect here is that Microsoft's primary target for Windows Phone 7 is the consumer, whereas those armies of Visual Studio developers are largely building corporate apps. Some of them are also annoyed that Microsoft is not providing compatibility with existing Windows Mobile applications.

There are also significant limitations in Windows Phone 7 in its first release. There's no multi-tasking, which means you have to write code to handle your application being shut down and re-activated while giving the appearance of resuming where the user left off. There's no native code, which runs contrary to the instinct of experienced mobile developers, some of whome tried and failed to wrest acceptable performance from the Compact Framework, the mobile .NET Framework from pre-Silverlight days. There's no copy and paste - which does not seem a big deal to me, but some people seem to care a lot about this. Another annoyance is that all apps must be deployed throught Microsoft's Apple-style Marketplace, though I hope and expect that Microsoft will come up with a way round this for corporate roll-outs.

Future iterations of Windows Phone could remove these limitations, but in this instance Microsoft does not have time to release something not very good and get it right three versions later.

I'm keen to hear from developers who have tried the preview devices or the SDK. Like what you see? Intend to support it? I look forward to comments, because the success or failure of this product is going to be significant.

I've been reading a new survey of mobile developers from VisionMobile. Around 400 developers were surveyed, and the platforms covered were iPhone, Android, Symbian, BlackBerry, Java ME, Windows Phone, Flash, and the mobile Web.

The topic is significant. Companies everywhere are crying out for mobile apps, especially for Apple iPhone but increasingly for Google Android as well. The device+cloud computing model is today's big trend, and support for mobile devices in some form or other is becoming necessary for a wide range of applications and web sites.

The first notable fact is the extent to which iPhone and Android dominate. This chart on page 10 tells the story: there is little relationship between the device installed base and the number of available apps. Windows Phone, for example, has 75 million devices out there but only 13,500 apps; iPhone has 60 million devices and 225,000 apps.

 

The reason is that Apple has created a viable ecosystem for development, as well as a superb mobile platform. Much as I dislike the locked-down nature of that platform, and its Apple tax, I acknowledge and admire what has been achieved.

Android has just 20 million devices but 72,000 apps. I'd guess that the quality of those apps is not as high on average, but it's still clear that iPhone now has competition.

If this paper is to be believed, Android will even pass iPhone. Android is identified as the most popular among developers, with around 60% using it versus 50% on iPhone. Why?

We believe that Android's lead in developer mindshare ahead of Apple's iOS is down to two factors: first the $99 fee developers have to pay in order to deploy their applications, an entry barrier which reduces the innovation from developing countries. Secondly, the very effective use of open source licensing as a marketing technique to attract developers to Google's Android.

Another factor is that Android apparently offers the best developer experience. In an appendix, the survey tests iOS, Android, Symbian and Java ME for coding, debugging, device emulation and support resources. Novices could create a simple app more quickly on Android. The coding effort was less; building 9 simple apps took nearly 3000 lines of code on Symbian, versus just under 1500 lines on iPhone and a little over 1000 lines on Android. Debugging is faster on Android. The survey comes up with the following claim:

Using the above data, we can say that when developing common applications, each hour of work for a given Android developer, irrespective of level of experience, equals 1 hour and 10 minutes for a Symbian developer, 1 hour and 20 minutes for a Java ME developer and approximately 1 hour and 30 minutes for an iPhone developer.

Contentious, no doubt, and a lot will depend on what sort of app is being developed. Still, a good result for Android.

Both iPhone and Android seem safe bets, but what about other platforms? Adobe Flash is an interesting one:

Our research further indicates that Flash developer mindshare seems to be in decline, despite Flash's installed handset base of more than 1.3B devices. Adobe's string of execution failures has meant that the installed base for Flash Lite is extremely fragmented, breaking the write-once-show-anywhere story for media brands who are Adobe's key customers. At the same time, Flash, the much-touted replacement for Flash Lite, was more than 18 months late, while Flash Lite shipments have stagnated, dropping from 43 percent to 15 percent of handsets sold from 1H09 to 2H09. This leaves Adobe with a rapidly shrinking window of opportunity, primarily on Android handsets, while having been banned from Apple's growing empire, and slowly seeing the adoption of HTML5, yet another replacement threat for Flash.

That's overly negative in my view. In favour of Flash is that it runs on the Web and desktop as well as on mobile, and will run across a number of mobile platforms. Even so, the research shows the pressure on Adobe to deliver mobile Flash, which will not be in the hands of the public until Android 1.2 "froyo" is availble on devices; and the Apple problem will not go away.

Symbian is in trouble too; in fact, since Nokia is now moving to MeeGo for smartphones, it now has little interest for developers. Some observers think Nokia should go to Android instead.

Java ME? Windows?

The vast majority of Java ME respondents have lost faith in the write-once-runanywhere vision. Moreover, anecdotal developer testimonials suggest that half of Windows Phone MVP developers (valued for their commitment to the platform) carry an iPhone, and would think twice before re-investing in Windows Phone.

That strikes me as accurate. Predicting the future is hard though. Google Android came from nowhere; it is possible that a couple of years from now different patterns will have emerged.

For now though, it's iPhone and Android all the way.

I like tracking velocity for an iteration when I'm using agile. Teams often take several iterations to find their velocity--anywhere from 3 to 7 iterations. That's because the team has to relearn how to estimate, to make requirements user stories, to think about what done means, and how to make their stories smaller. I like estimating in points rather than hours or days, and that can be a challenge for people who are unaccustomed to thinking about relative size rather than duration. (See How to Estimate Without Time Units for a  quick summary.)

I find tracking velocity helpful in these ways:

1. Once we get past the first few iterations, velocity should be relatively constant, unless people are missing. If it is not, that's an indication that something might not be right.
   
2. A decrease in velocity, assuming no one is on vacation or away, may indicate technical debt.
3. An increase in velocity may indicate technical debt because the features are not really done.
4. Or, a velocity increase may be a result of the team revising how they create user stories or estimate.

Velocity changes are not good or bad, they are. And, if you track velocity, you will have more information about the team's progress.

I particularly like to track velocity as a burnup chart.

I'm just back from Adobe's partner conference in Amsterdam, where George Neill, Lead Experience Architect at Adobe Consulting, shows us this great slide depicting a woman processing mortgage applications. She has a PC on her desk which is running her organisation's app for managing mortgage applications. However, around here desk are multiple signs of usability failure. On her left, a paper calendar with names and phone numbers handwritten onto deadline days. On her right, an old-fashioned paper roll calculator. In front of her, a pile of paper forms colour coded with post-it notes. The app, Neill notes, should be handling all these tasks, but one glance at the user's working process is sufficient to expose its poor design.

All good stuff. The next thing we see is a nice application built with an Adobe Flex front-end and an Adobe LiveCycle back-end, with the not-so-subtle implication that these user-experience (UX) focused tools will help us create applications that fix this kind of design failure. There's also talk here at Adobe's partner conference of a new era in software built on customer experience, and how consumer technology from iPhone to Facebook and Twitter is raising expectations when it comes to business applications. There are even a few digs at developers, the people who, it is alleged, hate it when requirements change and who develop software geared towards the IT system which which it integrates, rather than towards users.

There is truth in all of this, but I'm cautious. It is easy to find a poor application and poke fun at it, but the idea of observing users and creating applications that improve their productivity is not a new one, and it is not necessary to use Adobe's stuff in order to do good software design. There are even times when it gets in the way. I recall spending time looking for a campsite on the web, for a holiday, and how it was in general the simple HTML sites rather than the "rich" Flash-driven ones that were easier to navigate. Admittedly the average campsite does not create web applications to Enterprise standard, but the underlying point is that there is a case for simple as well as a case for rich. Never forget "skip the intro".

The key question here: how do we define excellence in user experience? Let me state the obvious for the moment.

Applications that have functional deficiencies will not be rescued by any amount of eye candy or beautiful state transitions; and if the user is surrounded by post-it notes and antique calculators I'd suggest that this is not primarily a UX issue, unless we strip all meaning from the term and use it for every aspect of software design, features and performance.

Second, software can deliver a good UX without necessarily having gorgeous graphics and multimedia. As a business software user, I value applications that let me accomplish tasks quickly and easily. Question: think of a web application that changed the world, partly thanks to superb UX? Answer: Google search. Question: how much PhotoShop and Flash was used in designing the fantastic Google home page?

The case for user-centric software design is irrefutable; but we need rigour when it comes to working out what that means and how to achieve it. I like this comment which I found in an 2004 paper by Larry Constantine:

User-centered design is a good idea in need of improvement. The needed improvement is found in practices that put uses rather than users at the center of design and in changing the prime objective from enhancing user experience to enhancing user performance.

UP rather than UX resonates with me. It also reminds me of Kathy Sierra's mantra: creating passionate users. If the current rush towards UX puts the focus there, I am all in favour. If it means newly empowered designers imposing some sort of visual or multimedia experience on us whether we like it or not, count me out.

A client who's trying to move to agile is having trouble with the idea of literally standing at standup meetings. "I get the whole part of keeping the meeting short, but why do we have to stand up? My legs get tired."

I explained that when people don't stand, they are more likely to initiate and jump into sidebar conversations, aka rat-holes. "We don't do that here."

Um, yes, they did. And, we had the video to prove it. We were trying to do a feature-in-a-day, something I often do with clients, to see where the bottlenecks are, and how little they can actually do and still deliver valuable results. We were doing one-hour timeboxes with standups in between to see what was actually going on. We gained a number of valuable insights in our standups:

1. The one-hour timebox was too short. We should have done two-hour timeboxes. But we didn't because not everyone could free their schedules to participate every two hours, so we learned something about their projects and their daily organization.
2. When everyone stood up, the standups were no more than 5 minutes. When even one person sat down, we had tangents and rat-hole discussions.
   
3. They discovered that creating a project on their configuration management system cost them more than 30 minutes. Very interesting.
4. They learned that they had people who were even more specialized than they originally thought.
5. Almost everyone was quite willing to learn what other people do and how to help them.

If you are considering moving to agile, try a feature-in-a-day. And, as you do that, do practice standup meetings and standing up for them.