W.

When transforming your organisation, who should lead your value streams?

Many times in my career, I’ve had the chance to experience exactly the kind of transformation that’s so often talked about: re-shaping a team into journey-focused value streams (or squads, themes, or whatever term you prefer). And in the process, I’ve repeatedly witnessed a decision-making process that confuses and confounds me.

Let me set the scene.

Moving from more traditional waterfall (or even Agile) delivery structures to something that focuses deeply on engagement or ROI  can be a real jolt, not just to an organization’s operations, but to its culture. It often leads to a flurry of activity, as teams develop new workflows and processes, and re-shape their operating models, often migrating from centralised to distributed teams.

Read more
U.

Understanding the importance of environment on People and Culture

Let’s consider for a moment how many large organisations are coming to the realisation that their size, legacy and ways of working have industrialised the ability to think and act creatively out of their businesses. They study start-ups and create innovation teams to try and emulate some of the practices they deploy to disrupt service, products and business sectors and they study agencies to understand how to create people and culture programs to engender better ways of working for their employees.

Keep reading…

O.

On being good Digital Neighbours: Transformation vs. BAU

Having worked as a consultant and contractor on both sides of the Transformation/BAU fence, there is often present a divide in ethos, ego and perception. In digital, People who work in the BAU arena typically optimise and maintain live websites, apps and software. BAU teams are predominantly made up of permanent members of staff because it often requires a lot of specialist training and continuity. As employees, they feel more a part of the fabric of the organisations they work for.

Keep reading…

D.

Digital Transformation without People is Legacy IT delivery

Many organisations are undertaking digital transformation programs to “put digital at the heart of their businesses”. This isn’t a new thing. In a way, by replacing legacy systems, upgrading IT infrastructure, and putting in CRM and distribution systems, we’ve been on this path for the better part of the last decade. In parallel to this, User Experience and in a larger sense, Customer Experience, have been gaining traction at putting the People closer to the centre of our designs and our organisations. So if at the same time we talk about putting digital at the centre of our organisations, what does that mean for People using digital systems?

Keep reading…

T.

Transforming Digital Transformation

“Digital Transformation” has become an interesting buzzword that in its own right seems to be rapidly transforming. Not so long ago, replacing software systems with integrated, customer-facing digital systems, and putting digital more at the core of your business was simply a large-scale technology infrastructure program. But everything requires a buzzword, and perhaps “large-scale technology infrastructure programs” had become laden with everything needing to be “enterprise-scale” using large “systems integrators” in an eco-system where technology – not the Customer – was in the driver’s seat.

Keep reading…

A.

Agile as the process

Over the last year or so I’ve come across quite a few people – technologists mostly – who keep asking the question – why can’t Agile be used as a methodology for both UX and development? Having spent some time considering it, I’ve put down a few thoughts below. Apologies in advance for the use of overused clichés.

So to begin, if you think about the differences between what we do as the differences between Architects and Construction teams working on buildings it might help.

Additions and renovations
Analogy: Think of this as modifying the interior of your home or building a small addition to an existing home.

Keep reading…

W.

Walking the line between Skunkworks and Business as Usual

Several times recently I’ve heard the word ‘skunkworks‘ mentioned. Most recently it was in a Guardian interview with Mark O’neill, the ‘leader of the government’s IT ‘skunkworks’ team – as well as CIO of two prominent UK Government departments.

I have to admit to being fascinated by the idea of a skunkworks capability in Government. Ideally, a skunkworks team is untethered from organisational rules and structures, and allowed the freedom and flexibility to focus on solving problems and pursuing real innovation – which often means failing a good number of times before (potentially) achieving a measure of success.

Keep reading…

A.

Are UX roles becoming multi-disciplinary?

Back in the early days of digital there were far fewer roles than there are today. You basically had people selling for the agencies, project managing, designing and writing content, and building. Life was simple – yet in many ways everyone’s role was multidisciplinary.

Early project managers’ roles encompassed sales, strategy, project management, account management, requirements gathering, and developing of site maps. This last bit, with some additional thinking and sketches, laid the groundwork for ‘creative’ designers to do their work – and also for a discipline that would eventually emerge and become what we know of today as User Experience.

User Experience had a hard-fought role to play in the digital process. UX professionals have come from project management, content, design and technology disciplines.

Keep reading…

T.

The 80:20 rule of Agile and UCD

I want to tackle the intersection of User-Centred Design (UCD) and Agile. I’ll start by saying I am fundamentally not an Agile detractor. I respect and appreciate the need for process to help shape and deliver complex projects.

When it comes to UCD I am a strong believer in designing the ‘right’ thing for the ‘right’ user – of course, I also strongly believe the most successful UCD projects find a good balance between the needs of the user and the business.

In my experience, whether intended or not, Agile has typically promoted the technology team to the front of the pack, with the consequence of producing the product through the eyes of a team focused on what it can do in the time (Sprint) and with the team (capabilities) to hand.

Keep reading…