Ciaran’s Omnipurpose Blog

Years and years ago, when I was running Insurance Data Warehouse projects, I had a Business Analyst in my team with whom I often had misunderstandings because she was far more precise with her language than I was. Most of the time anyway.

I think this Business Analyst was unusual – as a species, we’re pretty imprecise with our language and this can cause confusion. The Business Analyst produced the most precisely worded requirements documents, which were reviewed and signed off and handed over for development. However, the teams receiving these documents were not always as precise, so misunderstandings were inevitable. This is why I’m a big fan of the User Story and the close contact between development teams and their customers that Scrum fosters.

We have Agile Breakfast sessions every few months at the office. These are hosted by our PMO Director, Head of Agile Project Management and almost always have Kenny Rubin as our special guest. Kenny is our embedded course trainer for Scrum at my company. I had done my Certified Scrum Master training with Mike Cohn whilst at Conchango, but took my Certified Product Owner with Kenny.

What’s more – our Agile breakfasts include delicious pastries and all the coffee you can drink!

During a discussion on the subject of estimating, and more scarily, reporting estimates to senior management, Kenny discussed the need for accurate estimates. Here are some examples of accurate estimates:

1. The project will complete on 15th August 2011
2. The project will complete in the week beginning 15th August 2011
3. The project will complete  in August 2011
4. The project will complete in Fiscal Quarter 2

I’m at the Agile 2010 Conference in Orlando. There are many excellent presenters here. Naturally, there is a lot of talk about Agile artefacts, including Product Backlogs.

I was surprised to hear advocacy of MoSCoW for prioritisation as opposed to the purer “Essential Yes/No” flag and sorting the backlog by value/ feasibility/ cost etc.

For those unfamiliar with the concept, MoSCoW is a prioritisation method:

M – MUST have this.
S – SHOULD have this if at all possible.
C – COULD have this if it does not affect anything else.
W – WON’T have this time but WOULD like in the future.

A few years ago, I was at a client introducing SCRUM. It was a new client, so I was there to push the door open a little more and hopefully set a good impression to get new work. We were engaged to build a tool from scratch for the client to resell. The Product Owner reported to a “Product Director”. The difficulty was that I could negotiate with the Product Owner, but the real authority and accountability for the product and its value lay with the Product Director.

The Product Owner was excellent. He saw the day-to-day difficulties in getting the software built and compromised features to ensure that what we delivered was what was really needed to make the end client happy. The “Product Director” was still thinking about us a little too contractually. He also wanted every last possible drop of functionality (he was getting it) in order to impress his own clients.

I think we did a fantastic job. The Product Owner did too. I think the Product Director also did. However, he decided that MoSCoW really meant:

M – MUST have this.
S – Bloody well SHOULD have this!!
C – We COULD have had this if you had worked faster!!
W – I suppose we WON’T have this now and it’s all your fault.

Asking your Product Owner if something is essential and forcing them to answer “Yes” or “No” avoids this problem.

I’m at the Agile 2010 conference in Orlando. I’ve travelled out here with some colleague from work and we’ve tactically split up to cover as much of the conference as possible. The conference is being held at Disneyworld, which is a little strange. For example, the towels in my room have been arranged into a Mickey Mouse shape (one big circle, 2 little ones), and my pancakes at breakfast were too. It’s also huge: there are about 1600 people at this conference.

There were so many good sessions today, and so many at the same time, so it was going to be disappointing on some level. Topics I attended included:

• Becoming Agile in an imperfect world – fairly good introduction to organisation change. It was amusing to see some near replica slides of what I used to present as a Conchango consultant.
• The incentive Trap – hosted my my old colleagues Mark Summers and Simon Bennett: dealt with how to incentivise well.
• Beyond Scope, Schedule and Cost: Optimising Value – great overview of how to focus on delivering value rather than just banging out scope for the sake of it; how to measure and plan for value and how to ensure accountability for value realisation. Pat Reed, IT Delivery Manager at GAP related some good war stories here.

A curious feature of the conference was the “Twitterfall”. Anyone tweeting with the #Agile2010 hastag would be displayed on one of many plasma screens in the convention center. Something that Jim Highsmith said caught my ear, so I tweeted it. It got retweeted pretty heavily and I ended up meeting some nice people out of the whole thing: social media really is social!

I have no idea why my hand in this photo looks like some comedy appendage. Oh well. Here’s looking forward to tomorrow and hopefully no jet lag!

I'm a big fan of lists. Heck – show me a project manager who isn't a fan of lists! I'm especially fond of lists that explain how not to do something. This way, I feel as though I'm learning from the expensively-gained experience of others.

The list isn't meant to be exhaustive and isn't meant to be in order, but I hope this list proves useful to someone, somewhere:

Mistake #1:Keep the team and the stakeholders apart - I've worked in some (large) organisations where the lead developers are on good drinking terms with the Directors. I've worked in other organisations where there has been a wall of separation between the people who have the business vision and those who actually need to build the tools to deliver that vision. In one memorable case, the only contact the team was permitted to have with stakeholders was a set of documents written by business analysts from another part of the business. Of course there always has to be a balance struck between proper use of time and the importance of the project, but communication, especially at the outset of a project, is vital.

Mistake #2: Communicate infrequently – If the project is important, people will be interested and should be asking as much as being told how the project is progressing. Frequent, early communication allows for project plans and budgets to become exposed to real life challenges and be up for discussion. Early communication allows stakeholders to see what they're getting and reject or change it early. Frequent communication builds up an important level of trust: that the stakeholders care what the team is doing and that the team is doing its level best to deliver what the stakeholders need. This trust is a useful currency for when the challenges come later in the project.

Mistake #3: Save all your testing until the last minute – If you're running an agile project, you're likely to be testing every 2-4 weeks, depending on the length of your sprint. "Fail Early" is the philosophy here. If you're doing things in a traditional waterfall manner, you're probably hoping that there'll be only a handful of defects revealed during your testing phase. Consider instead breaking your project into a series of mini-waterfalls that will allow your testers to get on the case as early into the development process as possible.

Mistake #4: Don't tell a client when they're wrong – The client has brought you in for a reason, so you shouldn't be afraid of making suggestions on how to best set up the project for success. Of course, there are diplomatic ways of doing this, and it helps to know when to exercise discretion.

Mistake #5: Put the client on the critical path without telling them – Working in collaboration with a client means that very often, you're dependent on them for things like servers, meeting attendance, approval etc. Make very clear up front just what you need from the client and when you'll need it by. If you're nervous, keep it on the risk log for regular review with the client (you're doing that, aren't you?)

Mistake #6: Focus on contracts not collaboration – Something unexpected always happens in a project. If things go very wrong, there's always a temptation to throw blame around and cover your back. It's just the human thing to do. It's also the wrong thing to do. Both you and the client have a lot invested in a project; financially, emotionally and in terms of career. It's in both your interests to find a way out of a problem together: fix the problem not the blame: focus on working together, rather than scoring contractual points and you'll be much closer to a positive result for all.

Mistake #7: Mix your methodologies – Are you running this project in Agile or in Waterfall? Does everybody share the same expectations about how the project will proceed and what their responsibilities are? A common mistake for newcomers to Agile is to fix your time, scope and cost on a project, which is fine if you have contingency, but Agile doesn't work like that. Similarly, people who have dipped a toe in the Agile water and have decided it's not for them often take the bits they like, such as the great flexibility in accommodating changes to requirements, and try to apply this to Waterfall – this is dangerous because waterfall projects, by their non-iterative nature, don't allow for iterative changes without some significant upheaval or nimble footwork.

Mistake #8: Just get on with it and never look back – Make sure you kick your project off well. At no other time in a project do you get such a golden chance to motivate your team by sharing the vision with them, agreeing ways of working, setting expectations and understanding risks. Simillarly, take time throughout the project (and again at the end) to look back and see how you're all working, what to keep doing and what to do differently. Agile calls these moments retrospectives, but you can call them whatever you like.

Mistake #9: Extract every waking hour from your team – Overtime is quite often a fact of life, especially at the end of a marathon project. Overtime is demonstrated to give your team a performance boost in the short term, but carry this on indefinitely and you get burn out, a dip in quality and a loss of momentum. Swapping out burnt-out people is costly. Not to mention, it's not very nice to put people in this position in the first place.

Mistake #10: Never, ever change your plan – Again, this is where project management is as much art as science. Be risk averse: We project managers love risk and issue logs. Change is as often as not a good thing. If a plan changes throughout the project, it's a sign that it's being used, understood and reflects reality. If the plan isn't changing, perhaps nobody's actually following it.

Well, I had quite a few more than these 10, but I think I'll keep my powder dry for another post. Of course, I'd be very grateful for your comments and suggestions for the next 10.

This post originally appeared on my Conchango Blog in 2007.

Conchango has been working intensively over the past two months with Microsoft and Associated Newspapers to create an application that allows users to to read the Daily Mail and Mail on Sunday using advanced screen reading technology. The application launches today. It has been dubbed “The eReader”.

The application is built on .NET3 and uses XAML and WPF for presentation.

We’ve been running a mixed team of Conchango and Associated staff at their palatial offices in Kensington. Lots of people at Conchango have been keen to be involved on the project as it has been very exciting to work on this new technology. Amongst them have been Howard van Roojen, Martin Rennie, John Rayner, Stuart Preston, Richard Wand,Hiia Immonen and Keni Barwick. Unsurprisingly, you’ll probably notice that a few of these people have started blogging about WPF and Vista!

The project aims to place the Daily Mail at the vanguard of Vista (could I trademark this alliteration?). The Mail will be the only newspaper in Europe that fields an application of this kind for an exclusive period.

Some of you may recognise this kind of application from the New York Times Reader. It is based on the same technology as the NYT reader and we’ve been working with the same Microsoft team in Seattle that built the reflow and reading technology.

The eReader application allows a user to download and cache up to seven days news on his or her laptop/ tablet PC or Ultra-mobile PC. Minimum requirements are Windows XP SP2, a 1Ghz processor and a 512Mb RAM. Once the news is cached, it can be read even when not connected to the Internet and presents the news in a format that is easy on the eye and can be scaled to fit the device it is being read on. A “News in Pictures” feature allows the user to browse the news visually and then dive right into the story. Vista-only functionality includes a sidebar gadget and a “Speak the News” feature. Stylistically, it looks very like the Daily Mail, with a managed “tabloid feel” frontpage and Daily Mail fonts throughout.

The eReader project’s been an intensive 2 months of work. We originally came in at the end of November and ran incredibly short sprints of initially 1-week each. This was because we were unsure of what the new technology was capable of and wanted to control the risk as much as possible. We moved onto 2-week sprints soon after we started. Even 2-week sprints are incredibly tough to manage and to work within. Balancing off short sprints with pretty large milestones has been an interesting opportunity to make good use of the sublime coffee shop here at Associated New

This post originally appeared on my Conchango Blog in 2006.

I need to upgrade my personal mobile phone pretty badly. Conchango issue us with lovely Vodafone v1240 Smartphones, but I was looking out for a hot new deal to upgrade my tired old Nokia 6230.

I’m a typical web user. I want to get to my information quickly and with the minimum of navigation; so I ran a search on the Orange website, using the prominently positioned search bar at the top of the page.

The result of my search was surprising. I was offered a variety of links to sites other than the Orange site. I could buy an N80 from Three, Vodafone, The Phone Spot, O2. In fact, the Orange site helpfully pointed me towards an N80 from anyone but Orange.

Being a typical click first, think later web user, I had failed to notice that I had been searching the web through the Orange site. Orange are clearly trying to be helpful to their customers by including a web-search tool on their site. However, I don’t think of Orange when I want to search the web. I think of Google. I don’t think that in this day and age that it makes sense to assume that your ISP users will keep your homepage as their default.

I was going to say that there is no difference between going to the Orange site and, say, Freeserve. Of course that might be something to do with the fact that Freeserve was co-opted into the Orange brand. I remember the old Freeserve page well. It was fairly useful in 1999, but even then I skipped by it for dedicated content that I wanted.

It is all very well using your brand as a glorified Google advertising partner, but what if people stop coming to your site because you’re not offering anything compelling or interesting in the first place?

So that is an example of a company not “getting”, in terms of what users want, where the Internet is going, or just failing to see the need to keep up.

Compare this to New Line Cinema and their approach to “Snakes on a plane”, the new vehicle for Samuel L. Jackson, famed for his profligate use of profanity at volume. A considerable buzz was generated on the internet after the title was discussed on a Hollywood screenwriter’s blog in August 2005. Since then:

1. The title was changed from “Pacific Air Flight 121″ back to its original working title of “Snakes on a Plane” after fan pressure.
2. Fans were inspired to create graphics for fictional movies about other animals in odd settings, such as “Bears on a Submarine” “Carnivorous Lions on an Overweight Middle Eastern Woman” and “Sharks on a Roller Coaster” (Tagline: You must be this tall…to DIE!).
3. Spoof auditions for the movie were filmed and shared through websites such as YouTube, Digg and IFilm.
4. A competition was organised to to write and record music videos inspired by the movie concept. The top 3 videos were featured on MTV, CNN, and MSNBC after being put on YouTube.
5. Filming wrapped in September 2005. Although “Snakes on a Plane” had been a minor movie in New Line cinema’s line-up, an additional five days of shooting was ordered in early March 2006. Contrary to the usual indication of problems with the film, this reshoot was to bring the movie in line with growing fan expectations. Among the additions is a line that originated as an Internet parody of Samuel L. Jackson’s typical movie persona, which I don’t need to rehearse on a family-friendly Conchango Blog!
6. The studio also opened the door, via a deal with Cafepress, to fan designs relating to the film including T-Shirts, mugs etc. The Studio actually permitted fans to become official licensees of Snakes on a Plane merchandise.