http://www.imdb.com/title/tt0545817/ "You're a tiger! Grrrr!"

That was my favourite line from Dearth of a Salesman, a programme in Steve Coogan's Coogan's Run comedy series. He played IT salesman Gareth Cheeseman, a greasy, awkward little bag of anxieties, attending a sales conference and trying to further his tin-pushing career. It was a stereotypical portrayal of IT salespeople, of course. In reality, they're a knowledgeable bunch, with good interpersonal skills, well-versed in the art of understanding what customers need. But the biggest challenge facing IT salespeople today - and the industry trend that would leave a real-life, witless Gareth Cheeseman behind - is that customer needs are changing, dramatically.

Managed services is the cause of it all. With everything being offered as a service, the patterns of IT usage are changing. In Cheeseman's time (Coogan made the programme in 1995), IT salespeople sold hardware, and the software to run on that hardware. But as managed services take off, commentators believe that hardware sales to conventional customers will decline, even as it is bought in increasing quantities by third party service provides. Instead, IT departments will eventually buy managed services that they resell to their internal customers. 

There will be iterative steps along this road, of course. Private clouds will create a class of managed services designed to run inside organizations, still administered by IT departments, using their own hardware. But a trusted cadre of sysadmins and business analysts are telling me that this will effectively be replaced by public clouds over time as IT departments simply turn more of their equipment off altogether. 

What happens to the IT salesperson in this scenario? 

Firstly, they will be selling to different people. Expect them to deal more directly with line of business managers in customer organisations, who have wrested budget away from IT to make their own purchases. 

Secondly, commissions will change, because instead of selling servers and software licenses that require significant up-front capital investment, salespeople will be hawking contracts in which customer subscribe to online services for set periods of time. Customers will often pay for these services in smaller, more regular amounts, chalking them up as operational expenditure, which means that compensation packages for salespeople may change. 

Perhaps over time, though, the biggest challenge facing IT salespeople is that they may not be needed at all. Don't get me wrong - there will still be some tigers out there, roaming around, clinching large, intricate corporate contracts. But if line of business managers end up buying a lot of their functionality online by simply  purchasing a number of seats for an online service from a web site, that leaves the sales force out of a job - or at least selling to a far smaller number of specialist data centre operators. Are you exploring your options?

I've been meeting teams who complain to me the iteration is too long. "But, JR," they say, "we can't get anything done in four weeks. We have to move to six week iterations. We can't possibly commit to anything in four weeks. We need at least six weeks to finish anything."

They sit there, with their sincere faces. They look at me, expecting me to go along with them. I take a deep breath, and say, in my most sympathetic and sincere voice, "Oh boy. This is really hard. Ok, you've convinced me. The iteration is now two weeks long."

At first, they turn to each other congratulating each other that they've pulled something over on me. Then they turn back to me, and look at me like I've grown at least one more head. Or maybe that my head is turned around backwards. Inevitably, the tallest man stands up and tried to intimidate me physically. He doesn't realize that my stature is the smallest part of me, that I've been shorter than everyone else for so long that his attempt at intimidation is pitiful to me.

"Johanna, what do you mean, two weeks. Did you not hear us?"

"I heard you just fine. Do you really want to wait six weeks to discover why you can't release anything in six weeks either?'

That usually stops them in their tracks. "What do you mean?"

"If you don't think you can finish anything in four weeks, the chances are quite good you can't finish anything in six weeks either. If we make your iterations two weeks, you have to reduce the size of the work you take into your iterations. You will be more able to estimate the work. You will have less to test. You will have less opportunity to create technical debt. You have a shot at releasing what you created.

"But if you expand the timebox to six weeks, you won't get the feedback you need. You will never understand why you can't do anything in four weeks. You will never learn why you can't finish anything in four weeks. You will have a self-fullfilling prophecy: your four-week iteration will be too long."

At this point, they generally want to go back to a four-week iteration, because it looks better than a two-week iteration. But no, a four-week iteration is an excuse to do a waterfall iteration: one week of design, one to two weeks of development, one week of testing (which will get crunched into less than a week because the development will expand) and then quick, end the iteration. Some smart person will want a Gantt chart of the iteration, and another smart person will want a test plan. Their self-inflicted overhead will kill their agile efforts.

Now, maybe your agile pilot did succeed with four-week iterations. Good for you! But I'm meeting more and more teams whose pilots are not succeeding. They don't change what they are doing--they fit their silo'd teams into a four-week timebox and call it agile. They certainly get some value from the timebox. But they are not living the agile values and they are not transitioning to agile.

When you make the iterations shorter than you can imagine, you force yourself to change your practices. You force the team to consider continuous integration. You force the team to integrate the testers with the developers. You force the team to limit the number of stories in progress at one time. You force the team to reduce the number of stories under consideration for a timebox, so the team has a better idea of what they can commit to for an iteration.

Maybe each of these changes is not so big as a single change, but taken all together, they are a huge change for a given team. For the team who thought they could pull one over on me, each change was a big change, and all the changes together was a monumental shift in the way they worked. And, when I suggest we start the iteration on a Wednesday, I thought they were going to revolt, especially since it was Tuesday afternoon.

"Can't we start on Monday?" one of the developers plaintively asked.

"What do we gain by waiting?" I asked.

"We get accustomed to the ideas," he replied.

"You get to research and discover more ways you can push back and tell me why things won't work here," I answered."

Everyone laughed, nervously. I said, "Look, I'm asking you for two weeks. Starting tomorrow morning. The worst thing that happens is that you get through tomorrow morning and you hate me. Right? That's about me, not you. What do you have to lose? All you do is take it one step at a time. And I'm with you each step of the way. Ok?"

They agreed. I was concerned they would all be sick the next morning, but they all came into work on time. We did plan the next morning. And they did get through the next afternoon. They almost finished a small feature, which blew them away. By Friday afternoon, they had finished two stories off the backlog. And, they discovered what prevented them from making their integration continuous. And, they learned what the testers needed for an automated test system, and created a just-enough test automation system.

By the end of the iteration, they had finished eight of the ten stories on the backlog, discovered they had mis-estimated two of the stories, and had discovered five new stories. They had never worked like that before. When they provided a demo to the product owner, the PO was thrilled.

Not all teams have such great results. As with all changes, your mileage will vary. But when your team says, "the iteration is too long," consider shortening the duration, not lengthening it. The more opportunities the team has for feedback, the faster the team can learn.

I attended Microsoft TechEd USA last month, where the news highlight was a bunch of new features in Visual Studio. Although Microsoft is not revealing what is coming for Windows 8 development, it has shown a bunch of new features ranging from code clone detection, which aims to find code that was copied and pasted rather than being properly refactored, to new IntelliTrace agents that are designed to find bugs after deployment, rather than just in code you are developing.

They are decent features, and it seems that the new Visual Studio will further extend what is already an impressive range of capabilities. I have spent a lot of time researching Visual Studio 2010, the current version, and considering the scope of the tool, from mobile devices to multi-tier enterprise applications, I hold it in high regard.

Talk to developers about what they want to see in Visual Studio though, and you can bet that neither code clone detection nor IntelliTrace agents will be on their list. They would rather Microsoft fixed annoyances rather than adding features which they might not ever use. Performance is always high on the list: not doing new things, so much as doing the same things faster. Quick access to documentation is another. If you are like me, you often end up searching Google rather than pressing F1, since somehow Google can search the entire internet faster than Visual Studio can summon its own documentation.

Why is Windows Vista considered a flop, whereas Windows 7 has flown off the shelves? I doubt it is to do with thumbnails in the taskbar, or even the Libraries feature, presenting multiple folders as one, a neat feature but often not well understood.

My guess is that better performance is the main reason, followed by hundreds of small usability improvements which Microsoft made. Windows 7 is not perfect, but it generally runs better than its predecessor.

There is always pressure to add features. If you are a software giant like Microsoft, there are marketing reasons; you need those bullet points to win upgrades, or think you do. If you are a corporate developer, there is constant pressure to meet new requirements.

The problem: it is too easy to lose sight of what users often care about more, which is the performance and usability of the applications and features they already use most often.

Somehow, at planning meetings it is hard to justify spending time on improving features that already exist, rather than creating new ones, yet for improving the productivity and even the happiness of users it is often the right thing to do.