Tuesday 19 April 2011

From Zero to Agile in six months, part one

A couple of years ago, I worked on a Scrum project as product owner. It was my first Agile project. It was also my employer's first, and the first for the members of the Scrum team. All parties concerned are now committed to Agile methods.

The original team members wouldn't work any way other than Agile. The company runs every project using Scrum. I'm writing a blog about how great these methods are.

Doing one project Agile transformed us into Agile enthusiasts. We experienced how Scrum works, and we liked it. Here's how we got started…

Zero: The wall of questions

The company was, and is, in the business of mobile phone e-mail and PIM synchronisation. At the time, we offered a “powered by” service, that was sold by mobile phone operators. Our operators were asking us to support a new phone platform, called Android. We already supported a number of other platforms for them, such as old Windows Mobile, Symbian S60, and J2ME.

The company's product has a client-server architecture. So the decision to support a new phone platform is, at one level, no more than a decision to port the mobile client to that platform. But at a deeper level, the decision being made is how to transform the client for the new platform. That decision needs to be informed. The decision-maker, in the product management department, needed information, and asked all the following questions:

  • What kind of user interface do applications on this platform have? Should our application be like native applications, or be like our application on other platforms?
  • What PIM integration capabilities does the platform offer? We can produce a sandbox client, that has its own e-mail, contacts, calendar and tasks applications. We can also produce an engine client that synchronises directly to the native stores, with minimal user interface of its own. Or we can produce a hybrid, with some of its own sandbox applications, and some integration. Which of these could we do? Which should we do?
  • Can we pre-install our client “on-deck” so that customers can start using the service as soon as they take their new phone out of the box (OOB)? Our customers want this, but will it place restrictions on our client? Who would have to sign off the application in this case? The manufacturer? Google themselves? If we can't pre-install, what are our deployment options? The existing product can be downloaded from the service operator's website. Can we do that on the new platform?
  • Does the platform support background execution? We run constant synchronisation of changes to the user's PIM, not a foreground download-now service.
  • Our operators set up specific packet data routing and billing for users of our service. We also integrate with their AAA, LDAP or equivalent service for automatic identification of users, by MSISDN. This typically requires selection of Access Point Node (APN) at the device. Can we do that on this platform? Can we stop the user synchronising over WiFi, where we cannot identify them?
  • What do we need to do to optimise battery life? Half of this is in the Network, but the other half is on the device.
  • The platform has native synchronisation capabilities, with Gmail. Can we block that? How can our service integrate with that?
  • What kind of intrusive notifications or alerts can be played to the user, for example when they have new e-mail or a calendar appointment?
  • If our application is integrated with the native PIM stores, for what kind of change notifications can our application register? If there are no change notifications, and a user has say 1,000 contacts on their phone, is it feasible to poll the PIM stores?
  • What built-in encryption and data compression capabilities does the platform offer?
  • Are handsets available? Interaction design, and final testing, is best done with physical handsets, not emulators.
  • Is the platform mature enough? In other words, should we port now, or should we wait?
  • What is the commercial value of supporting this platform? Is it ever going to sell enough units?
These are all reasonable questions, but to whom are they addressed? Who will provide the answers? If there were a project team, then they would be answering. But we haven't decided to do the project yet, so there is no project team.

One: The decision

With no project team in place, what product management did was to ask around. They persuaded a developer to find the time to install the Android SDK. The developer had a look and told product management what they thought. Product management installed the SDK themselves. They tried out some things on the emulator, or on such pre-release devices as were available. They googled. After doing that for a week or two, they made the following statement about the decision to make an Android port of our client:

“This is not a decision that a SCRUM can deal with … This is a decision process that needs to be driven by product management and get executive level sign-off. These are non-trivial investments.”

It's true that it would be a non-trivial investment to dedicate a team to porting the client to the Android platform. The other two statements were false, or at least I believed them to be. I approached the head of engineering, directly.

(I should probably point out that I was in neither engineering nor product management, but in a separate product design group.)

The head of engineering was receptive. He had already anticipated that he would be asked to deliver an Android client sometime soon. He had assembled a team: coders, testers, even a Scrum Master. The team had been waiting a month for product management to assign a Product Owner. When I offered to be the product owner myself, he said: Yes.

Two: Agile answers

So the team got the go-ahead. Great. But the go-ahead to do what? Where should they start?

Well, the questions posed by product management still needed to be answered, so the team should start there. Product Management were right with the questions they were asking. Where they were wrong was thinking that a Scrum could not give them answers. True, the main delivery of a Scrum team is usually software, but it is also possible for a Scrum to answer questions.

A Scrum works from a product backlog, comprised of user stories. A user story has a title, a list of confirmations, and some conversation. (When using cards, the conversation is what is written on the back of the card.) For the Scrum to give product management answers then, the questions need to be rewritten as user stories. Here is an example of a question rewritten as a user story, from the team's first sprint:

ID: 20027

Title: Use service that is integrated with native PIM applications

Conversation
Proof of integration capabilities with native PIM applications
This story could be met by a small stand-alone test application
Support for recurrent calendar items was part of this but is now a separate story
Confirmation
Engineering assessment written
Try each of the following operations: Read, Create, Edit, Delete on each of the following native stores: Contacts, Task, Calendar
Try non-recurrent calendar items only

As the story says, at the end of the sprint, the product owner will have run a test application that demonstrates the operations. The product owner will also have read an Engineering assessment. Only then will the story be marked as Done.

The question will have been answered, and the answer will be objective. The product owner could show the assessment and test application to their colleagues. Compared with the pre-Agile asking around, this approach relies less on what was said or googled, and more on what can be shown. The cost is higher, but the process has created concrete evidence, not hearsay.

All the functional questions can be rewritten as user stories. They may not all be answered in the first sprint but, week-by-week, the Scrum team will work its way through the product backlog. On this particular project, the Scrum had answered all but one question after two sprints. The remaining question was one that actually could not be answered by a Scrum team, at least not a software development Scrum team.

This was the question that related to the commercial value of doing the work, and is addressed by Scrum in a different way.

Three: Agile commercials

Scrum does not answer the commercial value question directly, but it does represent a resolution to the issue of commercial value.

Implicit in Scrum is that we might re-assign the team at the end of a Sprint. The work done in that sprint could be wasted, if the project was cancelled at that point. Our Sprints were three weeks long, so the company stood to waste 3 weeks of the team's time by cancelling. With a team of ten, that's 150 person-days. Does that sound bad?

Under the pre-Agile process that the company used to run, the team would have been put on the project for six months. With the same team, that represents 1,300 person-days. This means that the question being asked is: In six months time, will it have been worth spending 1,300 person-days on this project?

Under Scrum, the question being asked was: Is it worth spending 150 days right now? Then, in three weeks time, the question will be: Is it worth spending another 150 days?

So, although Scrum does not address the issue of commercial value explicitly, it does make the commercial questions easier to answer.

Conclusion of part one

The evidential approach of Scrum lends itself well to the investigation of new product areas. The length of a Sprint represents a cap on the amount of effort being risked. But …

Did Scrum deliver? After the investigation, and assuming the effort did get risked right up to the end of the product development, did the company end up with software that could be sold?

Yes. Six months after the decision to wait had been ignored, the client was in the Android market place. Everybody had learnt a great deal, including Product Management. They described the project at that stage as:

“a tremendous job … the process … in place has returned us the best client we’ve ever done.”

That turn-around in attitude, and the profitability of the software, was a success for Agile methods.

A side point is that sticking to procedure will not always ensure that your employer takes the right action. Sometimes you need a personal network, and a personal reputation, to be effective.

The next post will be about the use of Scrum in a geographically distributed team, specifically: China, UK, USA. Included in that post will be my response to the Distributed Scrum Primer here http://www.goodagile.com/distributedscrumprimer/. I agree with about half of it.