Year: 2012

Fixed price work is all the rage with IT finance departments and senior managers, even in this age of moving towards Agile methodologies and incremental delivery.

There’s definitely a big dichotomy between agile and fixed price, with the former based on flexible scope, frequent delivery and frequent business led prioritisation, and the later fixed scope, large delivery milestones and fixed priorities.

What I’ve found in a number of projects that attempted to be fixed price but flexible is that it leads to a large number of change requests. In itself this isn’t necessarily a bad thing – it’s surely better to have a change request than deliver the incorrect or out-of-date functionality. However, I’ve also observed that the cost of the change requests tends to increase, and frequently make the project overall uncompetitive compared to a regular non-fixed delivery.

I believe the reason for this is that the quotes for change requests build in an increasing risk premium. The logic for this is fairly simple:

1. Project is priced based on assumed perfect knowledge of the requirements, with a contingency.
2. Change request comes along, so the confidence about the overall requirements falls and a risk premium is added to cover assumed increased contingency requirements.
3. Another change request comes along, so the confidence falls further and the risk premium increases further.
4. etc etc

You can’t really blame the delivery team for this – it may be a bit naive to assume the requirements are clear/perfect at the start, but you have to work on some assumptions. Change requests typically mean that either the business are moving the requirements, or worse for existing systems that difficult parts of code/functionality are being uncovered; denying this increases the risk and the cost would be foolish.

I’m not sure there’s a good solution to this, but there are a couple of things I’ve seen.

Have a limit on change requests, either numeric or in percentage of cost terms.

This has a number of implications. For the delivery team, it means they have confidence the scope won’t keep changing, so the risk premium is lower. For the business, it means they have to think very clearly about changes and prioritise them properly.

Encourage a larger contingency, but allow use of it for small changes.

This means that a small amount of change is accepted and accounted for, so giving both sides more flexibility in how to manage it.

Overall I don’t believe fixed price is typically the right approach except for items which can be very clearly packaged (e.g. upgrades, migrations, modules linked by defined API), in most cases Agile will deliver a better solution more reliably. However, if you are using fixed price, perhaps the idea of a risk premium is useful.

Adding custom search providers to IE7 and IE8 was a bit convoluted, involving going to the Microsoft site to create the required XML based on a template URL. I could never work out why they didn’t build it into the browser, but it did kind-of work.

However, the MS site no longer offers this. A web search gives plenty of blogs telling you how to do it using the Microsoft site, but the option described is no longer there.

Fortunately, Eric Lawrence has put the functionality on his EnhanceIE.com site here:

www.enhanceie.com/ie/SearchBuilder.asp

Thanks Eric!

As I work in a big bank, I handle a lot of Powerpoint presentations. Most are cut-and-paste versions of others, slightly modified for whatever senior audience is relevant at the time.

Unfortunately the graphics capabilities of Powerpoint are limited, therefore a lot of presentations have Visio diagrams embedded in them (if I’m lucky, and not just a nasty pixelated bitmap instead).

When I’m “tweaking” a presentation, I’ve often found it necessary to re-organise the layout, including the Visio parts, and find that the size of the Viseo tends to go crazy, either leaving me with big white borders to crop or losing parts of the diagram off the side.

Fortunately I found the very very simple solution here:

Press the Ctrl key and move your mouse over the edge of the canvas; when you see your cursor turn into a double arrow, drag the canvas edge to the required size.

The only issue I’ve found is that Powerpoint can update the zoom level while you are doing this, which stops the operation and can make the canvas resize incorrectly. Just make sure you do it fast enough before Powerpoint can react!

Often heard advice in system design – Keep It Simple Stupid. It’s a reasonable idea, a little similar to the Agile principle of no gold plating, that simplicity is efficient and robust.

The trouble I find is that all too often it actually translates to Keep It Simple & Stupid, and the result is a design unnecessarily limited or lacking in flexibility. As is often the case in English, a simple word can have many meanings…

Clear, Clean, Pure, Transparent 🙂 these I want.

Amateur, Foolish, Naive, Stupid 🙁 not in my system thanks.

Is there a point to this? Not really, just a thought – I like the no gold plating rule, but KISS is just too simple for me.

I don’t write much on this blog, one of the reasons being lack of time. Since I spend a couple of hours a day on the train, I wondered if there was an iPhone app which would enable me to write and upload blog entries reasonably easily while on the move.

Unfortunately MT don’t have an app of their own, unlike several of the competitors such as WordPress and Blogger, therefore I tried several third party alternatives and report on their effectiveness here.

BlogPress

The first app I tried was BlogPress, which claims to offer connections to most of the leading blogging software, both online and offline editing and storage, and support for draft and published entries.

Connection to my MT installation was straightforward, and it managed to find all the current entries. Unfortunately it couldn’t distinguish the draft entries, and doesn’t get it right when you try to upload as draft, but that isn’t a show stopper since I’m happy to keep my drafts on the phone.

What let it down was a simple inability to handle newlines. I use Markdown for my editing, and BlogPress has two problems – it insists on replacing newlines with <br /> tags, and worse it compresses multiple newlines (i.e. paragraphs) into one, losing my formatting.

I’ve raised this as a bug with the developer, but currently it makes an otherwise decent solution unusable for me.

Oh, and it also kept claiming network issues, even on a reliable WiFi connection.

Movable Manager

I then tried Movable Manager, a MT specific application which also supports many of the additional fields specific to MT such as excerpts and keywords.

Connection to my MT installation was also straightforward, and it found all the current entries with operation being extremely fast. Unfortunately it has no concept of a draft entry, either offline or online, anything sent to the server is immediately published.

Editing is good, with the content kept exactly as you type it, perfect for Markdown although there is no preview which makes the immediate publishing a bit of a leap of faith. It also has the ability to upload photos, but a word of warning – it silently overwrites existing files of the same name!

On the whole, simpler and more reliable than BlogPress, but lack of offline editing doesn’t fulfil my needs.

Nocs combination

I’d already been using Nocs as a Markdown enabled notepad to edit blog entries and other files, so I wondered if this could be used to solve my requirements.

The big advantage with Nocs is that it is designed for Markdown from the start, and it supports CSS controlled preview, so it’s possible to get a reasonable approximation of what it will look like on the real blog. Unfortunately it doesn’t directly connect to MT, only supporting local storage and Dropbox.

To get the entries from the phone onto the blog I added the iMT plugin to my MT installation to give me a usable control interface on the iPhone. This is a pretty good solution, although at time of writing the part handling comment management is giving an error.

Recommended Solution

At the moment my recommended solution is Nocs + iMT, with Movable Manager useful if you want to upload photos easily.

One thing about iMT is that there’s no option to jump into the full web interface. If this is a problem for you then Nocs + Movable Manager may be more appropriate.

This is a quick post to try out the iPhone app BlogPress that I’ve just installed.
Connecting to my Movable Type installation worked fine, and it finds all the existing posts although it doesn’t seem to correctly recognise the drafts.
Writing in the app is OK, the basic option to insert italic or bold text is a bit primitive but it does make adding hyperlinks easier. Support for something like Markdown would be good.
Saving an online draft still doesn’t seem to recognise the result as a draft, and loses some of the line feeds. Also the editor window doesn’t always scroll up in time when typing reaches the bottom, so the insertion point ends up under the keyboard.
Posting on an Edge network also doesn’t seem to work, just giving a network error even though direct access to the site works albeit slowly. Possibly the timeout is set too low, but it can’t be configured.

Strangely saving remotely as a draft, then reinserting the missing line breaks before publishing seems to work, but then they’re gone again when reopening 🙁

Update: The line compression problem is significant enough to make the app unusable for me. I’ve raised a bug report with the developer, maybe they’ll provide an update.

One of the hardest parts of my role is getting projects started, and it sometimes feels exacerbated by poor attempts to use Agile mindsets.

The fact is that a project needs a reasonably clear set of targets and plans in order to start successfully, with a defined order and a some idea of timelines. This is especially important where multiple applications and owners are involved and need to coordinate their work.

From an Agile viewpoint, I’m quite happy to adjust the plans based on experience and refine the details as the project progresses. The one thing I believe very strongly though is that you must start at the beginning.

Of course your beginning depends on your methodology, you can pick requirements, epics, acceptance criteria, data, test cases, etc etc. It doesn’t really matter, although I suspect it helps if each application area chooses the same option (I’ve never done a mixed methodology project of any size, I’d be interested to hear what happens if you run requirements driven and test driven parts in one project).

In several recent projects I’ve found that people are diving right in to the middle of the analysis, with no agreement on useful things like goals, ownership or basic timescales. The culprits are often recent Agile adopters who haven’t done anything big yet outside waterfall, and just throw away all the planning steps and hope they can adjust later.

The problem is that the analysis never seems to finish – how can it with no definition of done… Instead, people jump from one analysis task to the next and we end up with a load of 80% complete parts that don’t add up to anything useful.

I believe Agile planning and analysis can be done successfully, but as with anything in software development you need to follow some basic rules which I would suggest are:

1. Prioritise – some analysis has a fundamental impact on the project, some is detail or tweaking. Do the big stuff first, or you end up throwing away a lot of work from options later dropped.
2. Have a definition of done. Nothing is ever analysed 100%, nor should it be. Define how much certainty is needed, and make sure it is sensible and consistent across all tasks.
3. Write it down and Sign it off. Do it Agile if you can (stories in Jira, great), but make sure everyone is doing the same project!
4. Timebox and Review. Make sure you are getting somewhere and doing so efficiently, using sprints and retrospectives or something similar.

Of course it isn’t easy to influence this in big projects where no one person is fully responsible, but I have found that by pushing these principles you can move things in the right direction. Retrospectives are particularly powerful in this regard if you can get good open participation.

In the IT industry, this classic BIOS message is a byword for unhelpful responses and nonsense requests:

But even now, with usability experts around every corner and end-to-end user testing the norm, I still see some subtle and not so subtle examples…

UBS eBanking – Wrong Password

Put in the wrong password to UBS Quotes and you get this. So if I repeat my entry, will it accept the wrong password? Hopefully not…

 

My team is part onshore, next to the business users, part offshore outsourced where the two scrum teams are. Naturally in an Agile methodology this is a no-no, but rules are meant to be broken and given a choice of remote Agile or no Agile then it’s a no-brainer.

However, one thing we have found is that shorter sprints (two weeks) are actually less efficient and less Agile than slightly longer three week sprints. With overheads like planning and retrospective, the efficiency gain isn’t that surprising, but the Agility improvement is.

I put it all down to the communication lag.

Because the scrum teams are remote, there’s an inevitable delay in communication (although they are at least in virtually the same timezone). In a two week sprint there just isn’t enough time to respond, so ironically the close communication of Agile reverts to the guesses and assumptions of waterfall. In a three week sprint, as long as developers work on tasks in parallel, they have some scope to wait for responses.

It seems that in Agile the old adage of less haste more speed also applies.