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.

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.

I'm discussing some engagements with some so-called "Agile" clients. I ask them what they mean by agile, and they say they work in timeboxes (most of the time), and that they have a ranked list of requirements. And, then they say that when the developers are done, they hand off to the testers at the end of the iteration. They don't understand why the testers can't keep up.

Development isn't the only activity that needs to happen in the timebox. Testing, writing, anything else that you need to get to releaseable product is what has to happen in the timebox. That's why agile requires cross-functional teams for the entire duration of the timebox. (I would argue for the entire project.)

Here's an example. Say you're working on a medical device. You have development to do, testing, a little documentation, and the requirements traceability matrix to fill in so you have an audit trail. You would need some developers, at least one tester, a writer, and either that team needs to know how to do the paperwork, or you need someone from the process group to work with the team. At the end of the iteration, you have finished features: tested, documented for the user, and documented for an auditor.

You can't do this without a cross-functional team. But too many managers are concerned about wasting people's time. "But the writer isn't busy the entire time. I want people working at 100% capacity!" Here are some arguments against that kind of thinking:

1. Do you care more about keeping people busy or releasing the product? If you care more about releasing, it won't matter if people are only partially "utilized." They can either help out or think about how to make the rest of the project work easier for the rest of the project team. When people have a little slack time, they can think about how they work.
2. You don't actually know how much time the writer needs to make the documentation correct, or how much time the tester needs to test. People who are not developers are so accustomed to doing the bare minimum (or less), they don't always know what it takes to do a great job.
3. People who are not fully "utilized" can provide early feedback to the others in the team, whether that feedback is about the project or the project's process. The team can catch problems early rather than too late.
   

The cross-functional team optimizes for the project and therefore the product, not the individual. If you are already working in timeboxes, great. If you have a single-function team, add one more function the next iteration. Keep those people there the entire iteration. See what happens. I bet you decide to add any other missing functions for the next iteration.

Don't think you can do agile with a single-function team. Yes, you can work in timeboxes, which is almost always a great idea. But you aren't getting the advantages of agile with a single-function team. You're still pushing the feedback downstream instead of receiving the feedback right away. Try an integrated, cross-functional team. You may be surprised by how fast you can go--or at least, by knowing earlier that you are not going to be able to meet a release date.

I've been working with some clients transitioning to agile. The senior managers want to know when the project will be done.

I can understand why they want to know. But before you start a project, you can't know with any certainty! What you can do is use rolling wave planning to know more as you proceed.

The way to use rolling wave planning for agile is this:

1. Lay out the major features you want in a product roadmap. You can organize the product roadmap by week, month, or quarter. I recommend no longer duration than one quarter.
2. Now, create the stories that go with the features in the order in which you want them done.
3. Work with the team to further refine the stories as they plan the first iteration.
   
4. The team completes the first iteration.
5. Now, assuming the team has worked together before, and that the product owner has refined the user stories as much as possible in the previous iteration, the team takes the time to do a gross estimation of all the remaining features in the roadmap. If the team has not worked together before or is new to agile, they need a few more iterations to practice estimating before they can provide a gross estimate that's at all useful.
6. Lay out, on a timeline, approximately when the team thinks they can finish the features, based on the gross estimate.
7. Now, lay out the major milestones (when you will have finished features) on a timeline. Every iteration, you note what you actually completed. When it makes sense, say every 4 weeks, re-estimate the entire backlog, if you need to provide a more accurate estimate. Since you'll be within +/- a few iterations at the beginning, I don't normally suggest you re-estimate all that often in the beginning. But you could.

Now, you have a rolling wave of what you think you can accomplish when. And, you are closing in on a date for your managers.

I recently led a project portfolio management workshop. Before we started, the senior manager had sent me a lovely spreadsheet with all the projects--all 15 of them. I was concerned. I was sure they had more projects based on our earlier conversations. But, ok, maybe they only had 15 projects.

During the workshop, I asked each of the managers to write down all their projects, one to an index card. We would deal with overlapping projects (people in one group working on another group's project) once we got all the cards down.

They started writing. We got to about 55 projects, including the 15 on the original spreadsheet. That's more what I expected.

Now, they started to rank the projects. Every time they had a question about how to staff a project, the senior manager would pick up the card and "worry" it. He waved it around. He flipped it over, side to side. He put it down. He picked it up.

At one point he turned to me and said, "You know, if we didn't have these index cards, I could have ignored this project now, and not have to make these difficult decisions." He paused for a few seconds, and finished with, "But I get paid to make these decisions, don't I?"

He does. And, now he has the tools to make those decisions. One of the tools is making all the work transparent, which is what writing the projects on index cards does. 

Start with index cards (or stickies) whenever you can, to make the work transparent. Then, if you need to, such as if you have a geographically distributed team, move to some form of electronic too. But remember, the tool will always be a second-best tool.

Index cards have a powerful effect on how we think about the work. The power of the index card is in the way it makes the work transparent to you, and in our ability to easily move them around. Use that power to see and manage the work

I'm at the QCon conference in London, one that I particularly value for its vendor-neutrality and strong content. Yesterday we heard from Robert Martin, founder of Object Mentor, on the subject of software craftmanship, or how to avoid bad code. One of Martin's points is that having code that works is not enough. He makes an analogy with a machine. It's not enough that your car works; when you open the bonnet you want to see good engineering, not a tangle of pipes, wires and belts that somehow hangs together.

Software is vulnerable to poor craftsmanship because code is often well hidden from customers and end-users. Still, the programmer knows whether they are putting together something that just about works, or crafting something excellent that will be understandable and maintainable long into the future.

Martin's talk turned out to be a practical one. There was nothing really new; but plenty to think about. Here are a few of his tips:

• Keep functions and methods short. How short? His principle is to use extract method refactoring until there is nothing more to extract. I got the feeling that he would consider anything over 20 lines suspect.
• Have functions with only a few arguments - preferably no more than two - and don't use boolean arguments because they cause confusion.
• Similarly, a class should be a small batch of code, with only a few variables, a couple of dozen methods.
• Eliminate duplication in your code; use abstraction.
• Give public methods short names, but use long descriptive names for private methods. The code is the documentation.
• Improve code slightly every time you touch it. Sometimes the opposite happens; code decays as fixes get added. If you improve it instead, your project improves over time.
• You need comprehensive tests, otherwise you do not dare to make changes in case something breaks. Test code should be of the same quality as production code; if your tests are slow and buggy, you will not use them or trust them.
• Have short iterations. A month may be too long. Two weeks is good. One week, he suggests, may be ideal; or even less in some cases.

You may not agree with all of these; but I like the underlying objective, which is to code to a high standard rather than just fixing bugs until it runs.

Agree? You can sign the Manifesto for Software Craftsmanship.

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.