If you want to know how to estimate without using time units, here's how I do it:

For my work, I block out half-day chunks of time. I find that I can do some tasks in that half-day chunk (1, 2, or 3), and finish enough on any one thing that I can safely mark it as done enough and go on to the next task.

Some days, I have tons of little things to do: return calls, make lists, prepare to do something. Some days I have larger tasks: write a blog entry, draft a workshop, write a ton of email. Some days I have quite large tasks: draft 1 of a piece of a chapter, draft 1 of an article, draft 1 of a report.

Most weeks, I have a mix of things that are small, medium, and large. I no longer worry or estimate how long any of these things will take. I know about how many of the small, medium, and large tasks I can finish in a week. I can make my lists taking that into account.

If you are a developer or tester or BA or technical writer or a whatever (don't want to leave anyone out :-), you can do the same thing. Here's my recipe:

1. Make sure you've taken any task larger than a half-day chunk and broken it down into smaller tasks. That's why you see draft 1's for articles. I can write a draft in less than a half-day. I can't finish all the editing and have a great article at the end of a half-day. So, I don't try to do so.
2. Be clear on what done means for a particular task. If you don't know what done means, you can't get there. You'll either "finish" without getting to a reasonable stopping point and then you worry, or you can't finish in less than a half-day chunk.
3. Do just that one task until it's done. Commit to it. Finish it.
   

Now you have a little recipe for getting the tasks done. Here's how you apply it to your estimation. When someone asks how long something will take, you look at all your little tasks. Make sure they small, medium, or large, where large still fits in a half-day. You get no more than 10 half-days in a week. How many of these tasks can you do in a week? Add them up, and there you have your estimation without having to define how many hours a given task is.

If you're part of a project team, and want to try this on a larger scale, I particularly like the Fibonacci series (1, 2, 3, 5, 8, 13, 20) for estimating how large and complex a task is. As a team, use a Delphi approach (everyone gets together and as a group agrees on a number. For me, and when I teach my estimation workshop, any task larger than a 13 means "we have no clue and 20 is as good a number as any other number." When you hear someone is a specialist and can finish something earlier,  take the larger of the two values.

Other folks use t-shirt sizing: XS, S, M, L, XL, 2XL, 3XL. I don't like that as much, because, in my experience, teams don't learn to break tasks down enough, and have too many M, L, XL tasks. YMMV.

Now, it doesn't matter if you work in iterations or not. Take a week. As a group, ask "How many of these tasks can we do in a week?" Discuss the question. Arrive at a number you can all live with. You're done!

Remember that estimates are guesses. They are likely to be wrong, especially if you use time-based units. That's because we are either optimists or pessimists and because we never have ideal hours, days, or weeks. Try this and see what happens to your estimations.

At the Future of Web Applications conference earlier this month I spoke to Microsoft's corporate VP of the .NET Developer Platform, Scott Guthrie about ASP.NET MVC. Guthrie is a co-inventor of ASP.NET along with Mark Anders, now at Adobe. A few months back I wrote a piece entitled ASP.NET MVC rescues Microsoft's web platform, but I wanted to hear from Guthrie how he sees the framework evolving, and to explore whether it is time to abandon the older Web Forms approach. How does he see the future of the platform?

"The amount of buzz and religious fanaticism about [ASP.NET MVC] is amongst the highest I've been involved in, certainly since .NET 1.0 and Silverlight. Some people prefer the Web Forms model  and I emphasise that Web Forms is not going away, there's all the new stuff that's coming for Web Forms 4.0.

"MVC is an alternative way to do UI and still leverage ASP.NET. For crowds like the one here at FOWA that wants total control over the markup, and who like test-driven development, it's a dream framework. Those folk tend to be more online, so they communicate better which is part of the reason you hear the buzz. I think we'll have more than a million developers using ASP.NET MVC within the first twelve months."

In your talk you mentioned the stackoverflow site which performs very well but runs on not very much in terms of hardware? Is ASP.NET MVC more efficient than Web Forms?

"ASP.NET itself has always been really fast, we've had a lot of success with large sites. One of the things people like about ASP.NET MVC is that the model fits to what they are expecting, for the large LAMP contingent which is heavily represented at this conference.  And when they do the performance testing they say 'Holy cow, this thing is fast.'  Stackoverflow is a great example, written I think within three weeks and scaling to that level with two machines. Performance is a feature, and one of the reasons StackOverflow works as well as it does is that it's instantaneous response time.

"Conchango just did a site, implemented in 20 weeks, a giant ecommerce project, it's 100% ASP.NET MVC. The SEO is phenomenal, the YSlow rating is phenomenal, they're just blown away. It was fun talking to them last night - the guy was jokingly saying, 'I can't believe it works so well'. It's like the best marketing literature in the world times ten. More and more when I give talks I'd say half the people are new to ASP.NET MVC, and the other half come upand say, 'by the way we've done five sites on it.' That's great to hear."

On equivalent hardware and leaving aside different coding styles, is ASP.NET MVC going to scale that bit better than Web Forms?

"No. The reality is you can build hugely scalable sites with each. Where it does help a little bit is that there is smaller page size and there's a bit more control. There's less abstractions."

And the page lifecycle is shorter?

"It is shorter. I don't think that's making any measurable perf difference. It's more that it naturally flows to what they're doing. I do think it's fast, in the same way that web forms can be fast too. But it promotes a certain way of working that, if you know what you're doing, you tend to build really fast apps."

What about the open source aspect? Are people contributing code?

"People are not contributing code directly to ASP.NET MVC, but we're shippling JQuery and we're shipping JQuery validation which are open source projects, and we are integrating them into our code. With JQuery in ASP.NET MVC version 1.0 we just shippped it, whereas in version 2.0 we have helper libraries that are making big usage of it.

"I'd say that's a first for Microsoft, we're actually taking open source software that has multiple contributors, and using it in a deep way within our own product.

"We ship the ASP.NET MVC source code under an OSI Licence. You can take the code, you can modify it, you can do builds. I know a few people that have done customer tweaks, but for the most part it's that people like being able to learn the product through the code. There's also the reassurance of knowing that if they ran into something, they could fix it."

Would you consider accepting community contributions to the code?

"We've thought about it. I think a lot of people interpret open source as 'hey, anyone can just submit stuff'. The reality is that pretty much every open source project has a closed set of contributors. They come from multiple organisations or backgrounds, but you don't check anything into the Linux kernel without Linus or Andrew signing off on the fix. That would be true of ASP.NET MVC, in that there would be a core set of contributors. At some point I think we will probably open it up to let people to contribute code, or at least patches."

What's new in the latest ASP.NET MVC 2.0 preview?

"The ability to easily do forms validation for input, server-side and especially client-side in a very declarative, easy way, is a huge productivity win.

"'Areas' provide a way to take a large project and easily structure it into multiple small projects.

"New form helpers and what we call editor and display templates for customising them  is an innovative way to get strong typing, intellisense and debugging support, and a lot of flexibility in terms of UI generation.

"Asynchronous controllers allow you to call call services on the web, the Twitter, the Facebooks of the world, and  much more efficiently  scale your web server. The classic problem if you're calling Twitter is what's the response time of Twitter? What's the response time of Facebook? Most web servers are multi-threaded so they're processing multiple requests, but say they have 10 threads running and 15 requests come in, and each of those requests need to go and access Twitter, you're going to block 5 people while nothing is going on on the server. With the Async support we provide a way that you within your app can say, I'm going to wait for a while, yield back the thread, and when the data comes back reschedule me. It can dramatically improve the scalability of the site.

"We're doing a bunch of work around helpers for caching, paging, and a other things. In general it's a compatible release, we're trying to listen to the community, keep it a very transparent, Agile-based development process and knock off the top asks.

"We ship the source to every preview, take lots of feedback. That's the other thing people have really liked about the project, this open feedback. They don't feel like we're telling them, here's the way it is, take it or leave it. They like the fact that we've been iterating with them."

Guthrie is diplomatic about the question of Web Forms versus ASP.NET MVC, and even though I pressed him, would not quite agree that it performs much better. Clearly Web Forms is not going away. Take a look though at some of the comments from practitioners like Howard van Rooijen of EMC (formerly Conchango):

One of the great aspects of ASP.NET MVC is how lean and clean the architecture is - there is so little background noise compared to WebForms; possibly the best illustration of this is the difference between the MVC Request Pipeline vs. WebForm Page Lifecycle. The number of hoops you are forced to jump through in WebForms, compared to MVC is quite staggering.

Overall I heard nothing to change my general opinion, that if you can use ASP.NET MVC rather than Web Forms, you probably should.

At last week's Agile conference, I spoke with a number of managers who weren't sure what their jobs were, now that their teams had moved to agile. They knew they weren't supposed to reassign people in the middle of a sprint, or even break up a team that's working together well, but they weren't sure what they were supposed to do.

Giving effective feedback, and coaching other people in how to give effective feedback is a great thing to do. Chances are quite good that few people in your organization know how to do so. In Behind Closed Doors: Secrets of Great Management, Esther and I suggest this model of feedback:

• Create an opening to deliver feedback.
• Describe the behavior or result in a way the person can hear.
• State the impact using "I" language.
• Make a request for changed behavior.

You need to create an opening so you know that the other person has time and is in the right frame of mind to hear you. A one-on-one is a great opportunity to give and receive feedback.

When you describe the behavior, avoid using labels. "You always break the build" just begs for one exception. "I noticed that you broke the build  Monday, and twice on Tuesday." People can argue with data, but it's much harder to argue with data you can measure.

When you state the impact using "I" language, you can explain the result personally. "When the build is broken, I hear about it from everyone. I suspect you do too. It's an obstacle I can't remove without you. I feel helpless, which is not a feeling I like."

When you make a request for changed behavior, you can ask to problem solve. "What would it take for you to avoid breaking the build?" Sometimes, the person you are giving feedback to doesn't realize they have an impediment that you need to resolve. One developer said, "I don't have virtual machine with the environment and I have no other machines." He went on to explain what he did have and what he needed. I hadn't realized that his build problem was really my problem to solve. Oops.

Giving effective feedback, not beating around the bush, being clear and firm, not labeling people, is the mark of a congruent team member and team manager. Learn how and you'll have a much happier team.

Microsoft's Eric Nelson conducted a poll on how many businesses still use Visual Basic 6. It is hard to make sense of the statistics, since there was a built-in bias:

This survey was sent out to individuals we "suspected" had Visual Basic 6.0 heritage but it was also widely advertised through the MSDN Flash to UK developers.

In other words, only Windows developers were consulted, and those more likely to be using VB 6 were specially targetted. Some results:

• 86.53% of respondents still program with VB 6
• 87.62% actively maintain VB 6 applications
• 46.81% have more than 100,000 lines of VB 6 code running
• 42.58% plan to keep their applications in VB 6 for the forseeable future, even though most respondents believe that neither runtime nor the development environment is now supported by Microsoft
• 51.76% plan to migrate their VB 6 applications to .NET (mostly to VB.NET, but a fair amount to C#), but are in no hurry to do so: most said "over the next three years"

See the original post for more detail. I'd like to know more about the wider picture - how many companies overall still use VB 6 - but although these figures are skewed I can well believe that there is a lot of VB 6 out there.

Incidentally, the respondents are correct in believing that the VB 6 IDE is no longer supported. Extended support ended in March 2008. However, note that Visual Basic for Applications, which partly shares the same runtime, remains part of Office and therefore is supported. The VB 6.0 runtime is supported at least until 10 years after the release of Windows Server 2008; see this paper for exactly what is and is not included.

I noticed that msvbvm60.dll, along with other VB 6.0 runtime files, is also in my beta copy of Windows 7. I guess that will nudge the support life for the runtime even further into the future.

The bottom line is that Microsoft would be crazy to release a mainstream version of Windows that could not run VB 6 applications. For the most part, laggard VB 6 developers are safe, though there could be third-party components that stop working. Another point is that VB 6 will always be 32-bit.

All this prompts a few observations.

First, if you have skills in VB 6.0, it looks like you will be in demand for a while.

Second, my own views on VB 6.0 are mixed. I recognize that it was a revolutionary and very capable tool; but if anyone is inclined to wax lyrical about its merits, I point them towards Verity Stob's Thirteen Ways to Loathe VB and Bring your Hatchet by Bruce McKinney. At best, it is a flawed platform.

Third, I do see the sense in leaving well alone in many cases. VB 6.0 is lightweight compared to .NET, and runs on a wider range of hardware. Migrating code is perilous unless you have rigorous unit tests; some quirk in VB may catch you out, so that ported code does not work in quite the same way.

It strikes me that there is little value in migrating from, say, a VB 6.0 client application to a .NET Windows Forms application. My instinct would be either to leave it be, or redesign it as a web application. Otherwise the risk is that your new ported application will be just like the old version, but slower.

Microsoft has a summary of the options here, which seems to promote the idea of hybrid applications, perhaps using the Interop Forms Toolkit to embed .NET controls in VB 6 forms. Maybe, but there is a danger of getting the worst of both worlds. That said, every case is different so there is little value in generalizing. The important thing is to have a technical and business rationale for the path you choose.

Last week Sun launched JavaFX, its Java-based platform for Rich Internet Applications. Sun picked up the high level of interest in Adobe's Flash as an application runtime, and perhaps Microsoft's Silverlight as well, and hurriedly developed its own equivalent. JavaFX is a new scripting language that runs on the JVM (Java Virtual Machine) and is optimized for graphical effects and multimedia. It brings to Java animation features like timelines and motion paths, support for a variety of audio and video codecs, and a way of coding a graphical user interface without the supposed complexities of Swing with its Model/View/Controller (MVC) design. JavaFX applets can run within or outside the browser. One innovation is that you can drag an applet out of a web page and onto your desktop. If you close the browser, the applet keeps running, thanks to support for out-of-process plugins in Internet Explorer 7 and Firefox.

So far JavaFX has received a mixed reception, and it is easy to see why. The launch was rushed, and some early visitors to the site had a bad experience, with videos that would not play or samples that did not run. Videos running in JavaFX flash unpleasantly if you resize the browser. The install experience is not as smooth as for Flash or Silverlight in my experience, because you need to install the Java Runtime Environment (JRE) as well as the JavaFX plugin. The download size is larger, although this is disguised by Sun's slimmed-down initial install. The idea is that you get up and running quickly, while the rest of the JRE installs in the background. The SDK does not yet run on Linux or Solaris, although the applets themselves should run because they only require the standard JRE plus a runtime jar (add-on library) and can be executed using Java Web Start. The latest NetBeans has JavaFX support, but another downer is the lack of any dedicated visual design tools. Sun only offers an export add-on for Adobe's Photoshop and Illustrator, or a converter for SVG (Scalable Vector Graphics). There is no 3D API yet, though it is promised.

It is easy to be negative; but some of these problems will disappear as JavaFX matures. A visual design tool is in the works, as is a mobile version that will be shown at the Mobile World conference in February next year. JavaFX will have a place for Java developers who are envious of what Flash and Silverlight can do. While it may not match Flash in terms of broad runtime deployment, I'm guessing that Sun will outpace Microsoft in this respect. JavaFX also has a couple of advantages over Flash, including more sophisticated client-side security and better code performance in some scenarios. The Java VM is mature and well optimized. Adobe's ActionScript virtual machine does have a just-in-time compiler, but seems slower than either Silverlight or Java for code execution. Speed of graphical effects is another matter, and while I have not seen any comparisons yet, I suspect Adobe's long multimedia experience may come into play here.

JavaFX will be welcomed then by Java developers who need more expressive graphics in their applications, and will be an interesting option for those developing games for mobile devices. Try as I might though, I'm finding it hard to believe that this is a huge section of the market, or that Sun will have much success persuading designers to target JavaFX rather than Flash, or that JavaFX will win much market share from Adobe for web-hosted video. Swing works well these days, its MVC architecture has merit, and it is well-suited to the kinds of Enterprise applications which commonly have Java clients. JavaFX is a useful addition to Java, but I doubt that Adobe is losing sleep over its likely impact. That said, I'm keen to hear from developers with plans for JavaFX applications, so don't hesitate to let me know.

You may have heard "there's no room for project managers--or any other kind of manager for that matter--in agile." Well, there is. Sort of. The role for managers and project managers is much closer to a form of servant leadership. It's certainly not command-and-control project management. Here are some ideas that may help you move closer to an agile approach for project management.

Ask the project team to explain what their deliverables are to get to the next milestone. Forget this business of assigning people tasks. The people on your team are grownups. You can treat them like grownups. You don't have to--and you shouldn't--assign them work every day. Not only should you not assign them tasks, you should ask them--as a team--to tell you what they have to do to get to the next milestone. Let them fight it out, ahem, discuss it. The more discussion, the more confidence you have in the schedule.

Use iterative or rolling wave scheduling, so you don't try to create an entire schedule before you know what's going on, or worse, once you realize the original schedule was someone's pipe dream. Once they've reached one milestone, it's time to estimate and plan to get to the next one.

Make people on the team estimate their own work, or, even better, estimate their work as a group. A group's estimates are bound to be better than an individual's, and much better than a manager's estimate. Group estimation is a form of Wideband Delphi, an estimation approach that's been around forever, and works like a champ. When people create their own estimates, they tend to track them, because their estimate is part of their deliverables.

Consider using timeboxes to help focus people on the work they have to finish now, not the work for later. Timeboxes are a time-honored approach to finishing pieces of work. Use them.

The more you move from command-and-control to guiding/steering the team, the more they will produce. And, the more you practice ideas like these, the more flexible you are as a project manager, which makes your value go way up. And, it's easier to find a job.

So you've decided the agilists aren't completely crazy and maybe it's time to think about it. And, your waterfall project is in the dumps. You'd like to make some progress, and oh, maybe even find another job because you can't see how your company can live through this project disaster.

If you're considering how to integrate Agile into your work, here are four tips you can try to implement now:

Decrease the size of your tasks so you can get to done faster. One of the issues in non-agile lifecycles is that the tasks tend to be too big. It's common to see 1-week, 2, 3, 4, even 6-week tasks. The problem with tasks that large is that people get lost in the task. They lose sight of what done means. They wait until too late to start the task (also known as student syndrome). It's just too hard to do. So, instead of trying to manage big tasks, break every task down into smaller pieces. I like 1 or 2-day tasks max (also known as inch-pebbles).

Work in short timeboxes. Once you have smaller task sizes, make a todo list for just one week at a time. I have to admit, I have my big todo list, so I can track and see all the work I have to do. But my working todo list is just one week long. Because I work in short timeboxes of one week, I have a pretty good idea of what I can get done in a week. And, I know when I'm not making progress in a week, so I have some early warning signs.

This can be quite difficult to do if you have many partially finished tasks, or if your boss wants you to multitask, or if you are depending on other people for input into your work, or if you've never received feedback about your estimates. Don't worry if your estimates are wrong. Estimates are just guesses, so guess for now, and track your work. I don't track actual hours per task, I just look at my one-week list and see how much I have on it and where I am during the week, and where I am at the end of the week. I often have a task or two I did not finish. I don't beat myself about it and neither should you. Take that information and re-estimate what you can do for the next week.

Finish partially completed work. One of the biggest changes I found when I moved to agile is I had much less partially completed work. I still have several articles (and books!) in progress, but they are all at reasonable stopping points. When you have partially completed work that's not at a reasonable stopping point, you feel a pull to go back to it until you get it to a reasonable stopping point. That pull causes you to multitask, which prevents you from finishing more work. So the more work you can get to a reasonable stopping point, the better. That frees your mind to go do the next piece of work. Which means you can do small pieces of work and get to done faster.

One of the ways I do this is to use the SCM system to help me. I integrate continuously, no matter what I'm writing (code, tests, documentation, project plans). That way the latest version is checked in, and I know the state that it's in and I don't have to think about it.

Know what done means. Any given task may have a different definition of done, but a project's definition of done is "fit to release." Since the project has to be ready to release, I like my pieces to be ready to release also. Sometimes, as one individual contributor, that's not possible until other people have done their parts. But make your pieces as done as you can make them.

For me, this means working by feature more than working by architecture. If your project manager is still organizing the work by architecture, offer to work with others across the architecture so you finish a feature, even if you don't finish the architectural layer. Yes, this may seem counter-intuitive, but it's faster and leads to finished product earlier.

Why should you do this? Because if you're looking for a job, even if you don't have agile experience, these practices will help you add value to your organization now. And you can talk about them in interviews.