Posts

Showing posts from 2013

On Big Data and Travel

I've been meaning to write about "Big Data" for a while, especially when as an Artificial Intelligence graduate I saw the Venn diagram at the start of a recent Amadeus sponsored report included both machine learning and natural language processing. Also in Bain & Company's report their research showed that analytical capability had a strong correlation with top performing companies. So I thought I'd sum up some of the articles out there on the subject at the moment. Is it just hype? Gartner's analysis is that Big Data is currently at the peak of inflated expectations and heading towards the trough of disillusionment -  and Wired's article asking Is Big Data in the ‘Trough of Disillusionment’? showed areas that is already more advanced. Is the case that as the Japan Times OpEd Deflating the hype on big data claims "big data isn’t much more than a sexier version of statistics, with a few new tools that allow us to think more broadly ab

On innovation and management

In the past month I've been reading a lot and two particular articles caught my eye. The first article I found interesting was a case study by Suleimanagich  (2013) of how even successful implementations of new technology, e.g at the project level, doesn't guarantee success if the company strategy isn't correct.This is the story of how Kodak had invented a digital sensor before any digital cameras were available on the market. This seems to be a common assessment of Kodak's fortunes - they slipped up by not pursuing the innovation - for example "Kodak's Missed Opportunities" by Bergstein (2012) or The Economist's (2012) "The last Kodak moment?". So at this point in my journey I was thinking, why did Kodak fail? Which brings me onto the second article I found interesting this month. Avlesson and Spicer (2012) puts forward a stupidity-based theory of organisations, could this offer an explanation on why Kodak failed? Did Kodak suffer

On user experiences and needs

The Amadeus blog recently posted an interesting take on the fad "less is more" in a post entitled  Why the ‘less is more’ concept in software design often falls short of its intentions . At first I agreed wholeheartedly as the title and intro had lead me into some nice confirmation bias ("grrr! gosh darn those gurus selling us different flavours of snake oil every year!"). Then I thought about it a bit more and the new feature being discussed was meeting a need; people wanted it and were pleased it was now present. That made me think that there was possibly some effective product management going on .. lo and behold the post was written by a product manager! This sentence was the most telling : "how we define the worth of adding more features. For me, it is worth it if you are doing something for the human being who will be using the feature." So a focus on user need is important, as if by magic later that day I read the brilliant post   How to Work

BRIEFING: ThoughtWorks' QTB on Mobile and the “shattered future”

Some notes from last night’s ThoughtWorks' Quarterly Briefing on Mobile and the “shattered future” Session 1 : Giles Alexander Mobile Lead (Europe) at ThoughtWorks Talked about move from Clients -> Apps -> Products Clients are the old world desktop thick clients that started to get replaced but apps and everyone needed an app on their phone. But now increasingly the world is multi-screen and product is across devices, these are just ways of getting to product. It's not just a case of laptops, smartphones and tablets. Also have to consider other input types/devices like siri, Google glass. there are multiple channels and accessibility is important. Is Google glass just Segway for your face? e.g. Siri is a bit of a gimmick, not used for regular/serious use, is Google Glass the same? Couple of examples: realestate.com.au is a property listings site that started in print media. Business suited the internet well then along came mobile. While

On pets and projects

While watching the Little Cat Diaries the other day, the experiment comparing cats and dogs behaviour to an earlier experiment with children stuck me. In the original experiment the children were pleased to see parents who left then returned to the room as they saw them as a provider of security. They repeated this experiment first with dogs, who used their owners as points of reference and providers of security. The cats however, were different. They showed more interest in the stranger present in the room if anything. The conclusion was that the cats saw their owners as providers of resources. I like to think we can make a (fanciful?) analogy here with project managers and the team. Formal command and control processes guide project managers into becoming dog owners. I would suggest that agile techniques put them in the position of herding cats and therefore "merely" providing the resources needed to achieve the team goals. Be interested to hear peoples thoughts on th

On research and application

I am currently lucky enough to be working on a project where the developers are looking into what they can learn from academic computer science and spiking various options to explore the solution space. This got me thinking to how relatively rarely you see this, in my experience programmers tend not to read industrial journals in the same way that say civil or electrical engineers might.  One thing that I would expect to see more in agile literature are Grice's conversational maxims (Grice 1975) Maxim of Quantity: Make your contribution as informative as is required for the current purposes of the exchange. Do not make your contribution more informative than is required. Maxim of Quality: Do not say what you believe to be false. Do not say that for which you lack adequate evidence. Maxim of Relation: Be relevant. Maxim of Manner: Avoid obscurity of expression. Avoid ambiguity. Be brief (avoid unnecessary prolixity). Be orderly. For me the

On impact and behaviour

Something a bit different, some thoughts on impact mapping and a workshop that I was recently lucky enough to attend. One of the first product owner survival camps run by Gojko Adzic with Dave Evans. The workshop description starts with ... So you're a product owner with an agile team? Congratulations, you are the winner of the world record for the worst named, worst understood and most confusing role in software delivery. Apart from the fact that the PO almost never actually owns the product, they are pushed into an unrewarding role that is mostly about managing "someone else's problem". That certainly rang true for me ;) how can you take a backlog of items that you are positive that you need right now and prioritise for small, sane iterations. Further, how do you avoid WaterScrumFall in this world? The answer presented here was around impact mapping and expressing things in terms of business goal and how much the "customer" was willing to invest in t

On deployment and enviromental risk

One hot topic that you often get when you have project teams delivering functionality for user acceptance testing while support are testing ad hoc fixes for production issues is "Who owns the environment and how do we stop support and project work from interfering with each other?". I feel that all code changes and deployments to customer facing sites should have some kind of change management paperwork raised. Because of this you are able to catch scheduling/work conflicts in the change advisory board. A good change control process should help you think about the risk to your project and also help flag to other stakeholders that they might have a risk to consider. A very basic rule of thumb for deploying anything to production in a manually controlled environment is don't expect that no other changes to have been made since you took your base to work on and always check before merging in . Here I think a "manually controlled environment" is somewhere that d

On documentation and organisational knowledge

It's been a while since I've written up a work orientated blog post. At the moment two (relatively ;) exciting things are happening. One is the introduction of JIRA, Confluence and GreenHopper and the other is working on a series of projects to upgrade customers, getting them onto the latest version of our company's main product. I'm working along the lines of getting three categories of info in JIRA/confluence: 1.        Jira work items 2.        Confluence (upgrade) project wiki 3.        Confluence wiki page per customer The first item should be quite straight forward and contains information needed for the life time of that work and a point in time record of the system (i.e. what was the state of play when the JIRA was raised/worked on?). For example, a story on a feature has the handover documentation for the original implementation attached as word files, so the current state of play now is easily accessible. I've also then created a subtas