Mandating Velocity

Assume you are in the middle of preparing your release plan. The team - product managers, developers, performance engineers, user interface experts, and other - has come back with a plan that is based on a velocity of let's say 3.56 per week.

You are certainly interested in any improvement of speed. So you are considering to say: What if you would plan for 4 per week? Or maybe you are even considering to mandate a velocity of 4. Would that be a smart idea?

Let's have a look back to the "good old days". A manager describes a piece of work to one of his engineers and asks for the estimated effort required to do the job. The engineer comes back and says that he can build it in 28 days. The manager thinks about it and then says: I think you can build it in 25 days. You will get 25 days to build it. I expect it by ... (fill in a date).

What's wrong with this? For one, if the engineer is not stupid next time he will add what he thinks will removed from his estimate (3 days) plus some (maybe 2 days) in case the cuts are higher next time. So the initial estimate might be 32 days. The manager is not stupid either. Next time he might think that the estimates are "inflated" anyways and that "sand bagging" happens anyways and sure people are playing ping-pong or darts anyways. So it's safe to reduce the estimates by 10% or even more. Just to get to the "real" numbers.

All of this leads to a situation where nobody works with the real numbers anymore. Every single estimate becomes unreliable and as a consequence every project plan built on them is flacky and unreliable on the outset. The engineer and - using the approach on a large scale - the entire team is set up for failure. (Unless you don't have a problem with "whipping" them a little harder and expect them to work crazy hours, which may not be a problem for as maybe you don't have family and don't know how it feels when you miss important events in the lives of your kids.)

There are certainly chances that the engineer may finish the work in 25 instead of 28 days. But at what price? If it really takes that long to do the job properly and if the engineer is really working at the maximum sustainable pace then what is left? Quality. The only choice the engineer is left with is degrading quality. This could mean that code is no longer reviewed. It could mean that design is no longer reviewed. It could man that some error handling code is left out (good chances it won't get caught in system testing). It could mean that fewer tests are written or no tests at all.

How is this related to the initial story around a velocity of 3.56 versus 4? Well even if you don't challenge the estimates, mandating an increased velocity is in essence the same thing. You are saying that people are not working hard enough, are in cruise-mode, etc.

Eventually the velocity will increase. The numbers will go up, they will even achieve 5, 6, or any number that you choose. Just by osmosis the team will learn about your "technique" and it will adapt. The estimates for every single item will go up. If an item was estimated to be 2 it will then be 3 (or even 20!). Then the velocity will increase not only to 4 but they will achieve a breath taking 35! Just imagine!

But seriously. If you are interested in working with the true numbers so that you have realistic and reliable plans that you can base important decisions on then you shouldn't mandate velocity.

A different question is certainly when there is a project that is very critical to the company. If you have treated your people with openness, honesty, and fairness, I'm sure they will understand if as an exception extraordinary measures needs to be taken. However, if those are used in every other release cycle, it becomes normal mode of operation and hence unsustainable.

It all boils down to how you select your "supplier". Are you interested in getting only the cheapest one, no matter what? Or are you interested in a reliabel supplier that continuously reduces the cost / increases the output / improves the quality? -As a customer as well as a manager this is your choice. (My take on this: Sacrificing quality has never ever paid off.)

A reply from MindJet (makers of MindManager)

In one of my previous posts I mentioned that I wrote to MindJet and suggested a free trial with a sufficient time-out. Along with my request I sent a justification.

I already heard back from them. A person from their sales department provided me with the information the download - OK, everybody can do that - but also with details for an extended trial.

So here are the positive remarks:

1. Fast response. It was less than 24 hours after my enquiry.
2. Good enough response. I got the information that I was hoping for.

So, I guess, I'll give it a try, and then I'll take it from there.

Are your stakeholders on the same page?

Sometimes it's not good to rely on assumptions. One of those assumptions might be that you work with people from your product management team and you assume that a key stakeholder of that team is fully in line and on the same page with them.

This doesn't have to be the case as I just had to find out.

Over several months I used the assumption that the product specialist, who I have on my team as the proxy customers and backlog owners, were on the same page with their manager, the product manager. I think all of them thought, too, they were on the same page.

Only two weeks ago it turned out that the product manager had an entirely different understanding of the scope that would be available for an internal release than what at least one of the product specialists thought.

The result was a "sticker shock" for the product manager. With reason!

So what can we learn from this? There is certainly no guarantee that communication would have prevented this form happening. Remember all participants acted in good faith. Still more and more focused communication with your key stakeholders will reduce the likelihood of bad surprises.

So in my case I have arranged for weekly catch-ups with the particular product manager (Agile value: adapt). The intention is to keep each other informed as much as possible about developments that may have an impact on each others work.

Again, this highlights the superiority of direct communication (agile value!) over comprehensive documentation. Of course, regular written progress reports were provided during the same timeframe. And everybody thought everything is alright. Well, it wasn't. A key stakeholder wasn't on the same page.

Are your key stakeholders all on the same page?

More on MindManager

I just received a marketing email encouraging me to upgrade from MindManager 6 (MM6) to MindManager 7 (MM7).

Well, at least this time they don't try to sell me on all those performance improvements.

Still, why should I pay for an upgrade if I don't know whether the performance issues are fixed?

They claim that 91% of those customers who upgraded to MM7 are "satisfied" or "very satisfied" after they upgraded. What they didn't mention how many of the customers that are on version prior to MM7 are dissatisfied with the software and don't intend to upgrade any time soon.

Also, under the headline "MindManager Pro 7 by the numbers" they claim that there are over one million licenses of MindManager around the world. They didn't say whether this is just MM7 or whether this figure includes prior version. I assume the latter.

So overall, I do understand the intention. They would like to get people off old versions onto the current one, and that way they can collect the upgrade fees.

I sent an email to their sales department asking for a 90 days trial license key. I have upgraded to 5 then to 6, each time hoping that the performance issues are resolved. Each time I paid money then I got a license. This time I think it would be more than fair to do it the other way round. I get the license first - time-limited to 90 days - and if their product turns out to be as fantastic as they claim - which it is without doubt! (sarcasm!) - then I'll be happy to pay for the upgrade.

So let's see what they come back with. At the moment my confidence level regarding MindManager isn't very high.

Vodafone Vodem on Vista

It's great to have all those wireless options. It makes you much more flexible with regards to choose where you work and when you work.

Vodafone is offering their "Vodem" as one of the options for wireless data connectivity to the internet. In that sense they provide a tool for more agility. And that's the only reason I include my comment in this blog.

Officially the Vodem is supported on Vista, but in practice there are a few issues.

1. It doesn't seem to like some screen savers. I can deal with this by trying different ones.
2. It doesn't like AnyDVD, which is ok, too, as I can simply switch it off temporarily.
3. It doesn't like Hibernate. I don't like this one particularly as I don't want to reboot the machine each time I want to connect to the internet via the Vodem.
4. Sometimes it just stops working.

In any of these cases it still claims to be connected to the network but when you do an nslookup it can't find any server. Then you have to reconnect it, and restart "Vodafone Mobile Connect Lite" (Lite on what? Quality?)

Overall I have the impression that the quality of the drivers and firmware needs some serious improvement. With my previous data card I had similar issues under Windows XP and it didn't really improve in the long run.

Then I turned the Vodem around and read Huawei and "Assembled in China". I wonder whether the people at Huawei and/or Vodafone are proud of this product.

Bottom line, Vodafone's Vodem works to some degree on Vista but it is very flaky and they have still a long way to go until the reliability is where it should be. So if you are considering it for your team then you may want to give it a trial for quite some time before deciding on a full roll-out.