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.

How effective are the world's governments at using technology to become more responsive? Technology has revolutionised the way that we do business, but the public sector has traditionally moved more cautiously than the private one. Now, a report from the Centre for Technology Policy Research in the UK has made some recommendations for the use of technology as an enabling mechanism for government.

The document discusses the concept of open government, which it defines as a government subject to public scrutiny, in which employees work in "smarter, better informed ways". In order to achieve open government, an administration cannot simply tack technology onto existing processes, the report warns. Instead, it suggests changing key processes from the centre outwards.

What might this look like? The report cites Tim O'Reilly, founder of technology publisher O'Reilly, arguing for government to be recast as an "open platform" that encourages innovation and change. To encourage this, the Centre for Technology Policy Research makes several suggestions.

Cultural changes are necessary to create an Internet-aware government, the document says. A vision must be created by leadership, outlining guiding principles that must then be enforced.

Audits should focus on outcomes, while enabling departments to achieve those goals using their own means. Opening up access to social media tools may help them to meet their objectives, by helping governmental organisations to listen to feedback from traditionally under-represented groups, such as front line workers. Other tools that could help to achieve positive outcomes include real-time communication tools such as live chat.

Other technology policies include a board-level, CIO function, compulsory training in technology and related policy for senior civil servants, and the integration of technology planning into public policy documents, rather than addressing it individually in dedicated IT planning documents. Other high-level recommendations include the revolutionising of procurement practices via the use of free cloud-based services for commodity functions such as social networking, and the replacement of all-rights-reserved licencing with open licence agreements in public contracts.

Talking of openness, the use of open standards and open source in public systems is a strong recommendation in the report. Government systems should support interoperability wherever they can, it said, adding that open source, taxpayer-funded code should be shared across all areas of government.

We are already starting to see cloud computing providers targeting this sector. For example, Google has been heavily targeting government players. The City of Los Angeles replaced its Novell Groupwise system with Google Apps last October. At a federal level, the US Government has launched its own cloud computing initiative under the banner Apps.gov, which includes applications from a number of cloud players, including Google and Salesforce.

Significantly, the UK Government just announced this week that it would be cutting $95m from its own IT budget, and David Cameron has in the past questioned the wisdom of large, centralised projects such as the National Health Service's mammoth Connecting for Health project. Instead, he has posited the idea of working with specialist cloud players to achieve similar goals. Signs are already emerging that we can expect a significant policy change in such areas.

All of this will radically change the role of service providers and the process of procurement in public sector IT, and those working in the area would do well to take note. A recent qualitative study conducted by Microsoft in conjunction with the Institute of Directors, called the Hybrid Organisation, describes the need to slim down the size of the state to the point where it performs on a third of national income, rather than half (see video, below). Technology will be crucial to driving the necessary efficiencies into government practice - and those with the know-how to make that happen will be able to capitalise on the trend.

This week was an important one for the Google Wave team. The company finally removed the invitation-only beta status from the product, meaning that anyone can use it. It also made the feature usable from within Google Apps, whereas it was only previously usable in individual Google accounts. The problem is that it may be a bit too late for this innovative product to make a dent in the way that people communicate.

Google Wave was announced a year ago at the company's I/O developer conference. It promised to revolutionise the way that people talked to each other online. It could be seen as an evolved version of instant messaging, with dramatically improved functionality. People could talk to each other in synchronous real time conversations, but could also revisit these conversations, known as Waves, over time. They could include other people in conversations at any time, and allow those people to replay the conversations chronologically to see how they had developed. People could insert comments at any point in a conversation, and could see each other typing. Waves could be embedded as objects, and accessed in different places.



The problem is that Google didn't do the best job of explaining the service to people, admitted Lars Rasmussen, one of the people who developed Wave. The product was daunting to use in its raw form. Rasmussen said this week that the team had failed to explain in the hour-long demo of the product what people might actually want to do with it.

The other big problem for Wave is one of critical mass. The service is designed to replace email, and it's about time that someone did. The first email was sent 40 years ago, and while it might have worked well then, it hasn't worked very well lately. Spam, excessive CCing, formatting issues, the difficulty of bringing someone into an email conversation that's been going on for a while - all of these problems make it a hindrance rather than a help for many.

But everyone uses email. Unless you're very important to someone, sending them an invitation to a Google Wave that could possibly require them to set up an account before they can even use it is going to be time prohibitive, and will probably mean you don't get a response at all, other than, "just mail me, will you?"

Then there's the availability problem. Yes, Google opened up access to Waves in Google Apps this week, but only in the Premier edition, which means that if you're a small business wanting to get into Wave communications, you'll have to pay for it.

Isn't this a bit backwards? Surely, if you're trying to persuade people to use a product that you've already admitted has been badly marketed and which few of them understand, you're going to want to give them a free ride?

I have a free Google Apps account, and a personal Google account that I use only because there isn't a Google Apps version of Google's Reader RSS aggregator. All of my contacts are in my Google Apps address book, rather than my personal one, and while I live on the Google Apps version of Gmail, I never check my personal Gmail account. I've tried using Wave in the personal version, and it's such a pain to log in and log out again, or to access each account using separate browsers, that I rarely bother.

This leaves enterprise users to take the open source Wave service and run instances of it in their own organisations, but as we know, enteprises tend to be a little conservative, especially in areas such as communication, which are often beset by regulatory constraints.

In short, it's going to take Wave a little longer to get off the ground than Google may have hoped, if indeed it makes it into the mainstream at all. And that's a real shame, because the concept initially showed a lot of promise. 

Microsoft's Open XML standard for Office documents is controversial. Depending on your point of view, it somewhere between a breakthrough in opening up the standard in which the world's most popular office suite saves documents, or a cynical ploy to counter the momentum behind OpenOffice and its rival Open Document XML standard. Amidst all the arguments, it is easy to lose sight of the simple fact that, whatever its merits, Microsoft Office does now save by default in an XML format.

When Office 2007 came out, it was not really sensible to use the new XML formats, such as .docx for Word and .xlsx for Excel, outside the safety of an intranet. If you sent one as an email attachment, there was a good chance the recipient would not be able to read it. Still, now we have Office 2010 and SharePoint 2010, and Open XML has become both more important and less troublesome. It is the only format fully supported by the new Office Web Apps, for example. Further, most of us have had to come to terms with Open XML, at least to the extent that we can open them. Maybe it is time to see if the new formats might actually be useful.

The most obvious advantage of XML is that you can read and write documents using standard XML libraries. There is no need to have Microsoft Office installed, or to try and run it behind the scenes on a web server in order to parse or generate documents. That said, an Open XML document is not a single file akin to an HTML page. Instead, it is a set of related XML files bundled together as a ZIP archive, using another Microsoft standard called the Open Packaging Convention (OPC) If you are curious, you can rename a .docx to .zip, extract the files, and have a look.

If you have in mind to generate Office documents using an XML library, the bad news is that it is not a trivial thing to get right. The good news, at least for .NET developers, is that Microsoft has an Open XML SDK that wraps this complexity. The further bad news though is that the SDK does not free you from having to understand how an Open XML document is put together.

I discovered this for myself after downloading the latest version of the SDK, newly updated for Office 2010. I wanted to investigate how easy it would be to have a web application generate Word documents for download. It turned out to be frustrating. There is what looks like a nice help document with the SDK, including Getting Started articles and a complete reference. Unfortunately, it does not tell the whole story. I was able to generate a simple document in no time, but was soon troubleshooting issues. For example, I found that whitespace at the end of text snippets was getting truncated, so that words ran together, until I figured out that a text element needs the space="preserve" attribute, wrapped by the .NET library as SpaceProcessingModeValues.Preserve. Using styles was also tricky. I followed the supplied article on applying a style to a paragraph, but although I used a standard Word style it was ignored. Styles are no use without a StylesDefinitionPart that contains definitions for the styles you will use.

In the end, the SDK documentation is little more than the famously lengthy Open XML specification, presented as classes and members instead of plain XML. There are few useful code examples.

Open XML is also verbose, and makes you realise how concise HTML is by comparison. You can embolden a word in HTML with a simple <b> element, but in Open XML you have to add a RunProperties element to the Run element that has your text, and then add the Bold element to RunProperties. Microsoft mitigates this verbosity by using very short element names; it is also one of the reasons for using ZIP compression on the final bundle.

It does get better, once you have done your homework on the OPC and Open XML, and created your own wrapper code for the .NET API. There is also a fantastic Productivity Tool included with the SDK, with which you can open and inspect Open XML documents. Its best feature is called Reflect Code, and generates the C# which creates the document you have opened. This means you can get a working example for any document, which can also be used as a starting point for your own document generation. For example, you can set up a document with some dummy text using the styles you need, generate the code, and then amend it to replace the dummy text with your own dynamic content. The only snag is that an innocent-looking and nearly blank Word document includes a large amount of metadata, themes and other stuff, so the generated code is over 2,000 lines long.

 

Microsoft could do a better job with the SDK documentation, but this is still a powerful tool for parsing and generating documents, and delivers a means of processing Microsoft Office files on the server without Office or SharePoint installed. If you want to know more, the official resource site is here. Finally, a commercial alternative with a more developer-friendly API  for both binary and Open XML Office documents is Syncfusion's Essential DocIO; I've not used it but have heard good reports.